Проблемы с правами при инстале

February 7th, 2009 Begemot Posted in Рабочее

Работа приносит первый плоды - нашел два бага, в продукте. Первый странный, непонятный, но уже вроде как исправленный, так что и писать нечего. А вот про проблему в инсталяторе я как-то раньше и не задумывался. У меня и на тестовых компах все было хорошо (я-то работаю под админом), народ тоже ни разу не жаловался, а там оказывается страшная бага:)

Если ставить приложение под простым юзером - нет прав писать в Program Files. Если запускать от имени админа, то все ставится, но каталог данных пользователя - берет админский... Для инсталяции использую старый верный скрипт для NSIS'a.  Вообщем буду сегодня разбиратся. А то не хорошо получается, приходится себе же устанавливать свой же софт через одно место 🙂

Так что если вы не уверены будут ли ваши инстляторы работать под limited user, самое время проверить. А если уверены - киньте в меня примером 🙂


Если вам понравился этот пост вы можете подписаться на RSS или мы можем доставлять вам новые посты прямо в ваш почтовый ящик.

Related:

Posted in Рабочее

28 Responses to “Проблемы с правами при инстале”

  1. Во-первых, у юзеров и не должно быть прав писать в Program Files, на то они и юзера 🙂
    Под вистой и далее, по идее, Program Files юзеру сделаются виртуальные, а под предыдущими оперсистемами проверяй в инсталяторе уровень привилегий и отказывайся ставить, если не админ.

    Во-вторых, что значит “но каталог данных пользователя – берет админский…”? Разве программа не создаст юзеру набор данных, когда он запустит её? Зачем создавать его инсталятором?

  2. хм, то есть это нормально что юзеру невозможно записать в Programm files и исправлять это не надо???

    Ну самому проверять и отказываться ставить это сильно странно. Наоборот нужно что бы ставили, ставили, ставили…:)

    А про каталог пользователя – некоторые данные лучше ставить инсталлятором чем генерить, например начальную базу данных.

    Ну и тут еще другая ловушка в которую я попался – когда оно отказалось ставится, я запустил инстал от имени админа, в конце инсталяции запускается сама прога – опять же от имени админа – и все что я сделал за тот сеанс работы (прога хранит заметки) осталось в app data админа. А я на следующий день сильно удивлялся, где мои данные:)

  3. Да, это нормально – юзерам право писать в Program Files не дано ещё на уровне файловой системы.

    А отказываться нужно не молча, а объяснять, что ставить может только администратор.

    И если начальную базу данных в профиле юзера генерирует инсталятор, то как потом запустить её под другим эккаунтом? Ставить ещё раз? И так для каждого юзера?

  4. При установке копируй начальную БД или в Program Files или в All Users. А затем при запуске под любым юзером копируй эту БД в профиль этого юзера и работай уже с ней.
    А то, что в конце инсталляции запускается под админом, то я думаю это можно пофиксить (и даже нужно), чтобы оно запускалось с правами текущего юзера. Как это делать в NSIS – я не знаю (сам пользую Inno Setup).

  5. Да ну нафик, самому себе сократить количество инсталяций:)

    С базой конечно не очень хорошо получилось.. этот вопрос не продуман. Но с другой стороны база не является необходимой для работы, есть хорошо, нету программа создаст пустую.

  6. 1. Админские права можно в NSIS вроде можно требовать через RequestExecutionLevel
    2. А кто мешает БД записать в юзерскую директорию через константы $DOCUMENTS или $APPDATA?

    Тоже встречался с заморочкой в Виста, но у меня там все печальнее было, нужно было регать COM-DLL – и под Вистой инсталлер просто ронялся.

  7. >2. А кто мешает БД записать в юзерскую директорию через константы $DOCUMENTS или $APPDATA?
    Так и делаю, проблема в том что видимо для инсталлера запущенного от имени админа $APPDATA указывает на папку админа:)

  8. “$LOCALAPPDATA The local (nonroaming!!!) application data directory.”
    Не оно?

  9. в инно это решено.. на канале обсуждали же

  10. Может вам эта штука поможет

    UAC plug-in
    http://nsis.sourceforge.net/UAC_plug-in

  11. Загляни в доку на MultiUser.nsh, там кое-что предусмотрено уже – можно и заставить инсталятор ругаться, если запустил не админ, и помочь не админам ставить прогу в собственную юзерскую директорию.

  12. Вообщем я тут немного поэксперементировал главная проблема следующая. Если в висте под обычным юзером запускать инсталятор – он автоматом требует пароль админа и запускается из-под его учетки. В конце установки стартует программа – и стартует она опять же под аккаунтом админа, соответственно все сохраняется в его application data. А для юзера все данные сохраненные в первом сеансе работы – выглядят как потерянные.
    Вторая проблема – программа прописывается в автозапуск админу, а не юзеру.

    Чего делать ума не приложу:(

  13. Как вариант. RequestExecutionLevel admin заменить на RequestExecutionLevel highest; если юзер не админ, предложить ему поставить программу локально либо обратиться к админу.

  14. В NSIS можно указать в каком контексте интерпретировать шелл директории. Делается это с помощью функции:

    SetShellVarContext

    А далее: SetOutPath “$APPDATA…

    По поводу автозапуска тут в инсталляторе вроде ни как. Разве что перебирать всех существующих пользователей на компе и прописываться им всем, но, ИМХО, геморно и неправильно. В автозагрузку должна писать себя сама программа. При первом старте она она по дефолту пишется в Run. Или опять таки можно закинуть ярлык в папку автозагрузки для всех пользователей.

    Проблема с потерей данных при первом запуске из под админа решается просто – нужно убрать запуск программы по завершению программы или сделать его опциональным.

  15. Долгая битва кажется увенчалась определенными успехами 🙂
    Спасибо, Андрею за ссылку, часть проблем удалось решить. Завтра еще на работе проверю как он себя ведет и напишу как справился.

  16. Мучаюсь теми же проблемами.

    Если использовать тот вариант, что создавать файлы в директории APPDATA пользователя-не админа не во время установки, а во время запуска программы, то возникает вопрос: как все подчищать во время удаления программы?

    Допустим на компьютере несколько пользователей. Есть один администратор и все остальные обычные пользователи. Администратор установил программу, и все ей пользуются. У каждого пользователя в APPDATA программа создает нужные ей файлы. Потом админ удаляет программу. Как она должна подчищать за собой? Не будет же она у всех пользователей чистить свои данные в APPDATA?

  17. А если создавать где-нибудь в нечто вроде Shared_Files, а название файла, к примеру, привязывать к имени пользователя (аккаунта в Винде)!?!

  18. От варианта подчищять, я отказался – пусть лучше у сотни юзеров останется несколько лишних файлов, чем один случайно грохнет все свои наработки… Да и корректно это сделать трудно все равно.

    Это для одной программы, а для другой, у которой база данных может быть довольно большой, я вот не знаю что делать – пока думаю может просто говорить юзеру что бд мы не удаляем во избежание, и открывать ему папку в проводнике – пусть сам чего хочет то и делает… Или вообще забить, ну останется пусть даже 50-100 метров в апп дата, кого это сейчас волнует?

  19. Имхо политически неправильно удалять данные и настройки другим юзерам, особенно если ты не админ. Если у них эти данные есть – значит им эта программа, возможно, ещё нужна?

  20. 2Begemot: у меня была такая же ситуация с автоматическими бекапными копиями юзерских документов. Сделал галку в Uninstaller`е (NSIS) “Удалить резервные копии” – по умолчанию выключена. Нареканий не было.
    Из жизненного опыта: если уж выбирать из 2-ух зол – тогда имхо пользовательскую БД лучше оставить. У меня в давние времена в описанной схеме галка “Удалять резервные копии” была включена… Ну дык короче один таки шарахнул свои копии случайно, когда ставил новую версию (несмотря на 33 уверения чтобы ставили поверх, удалял перед этим предыдущую версию)… В общем, “секоса чудного” ((С) :)) тогда поимел немало! Так что если из двух зол, то уж лучше не стоит, пусть БД остается.

  21. Есть же all users\application data\ (не помню, какой там системный алиас)

  22. и чем all users\application data\ может помочь?

  23. Тем, что там (вместо Program Files) можно хранить данные своего приложения независимо от того, какой юзер пользуется программой в данный момент.

  24. Конкретно в моем случае это не подходит, мне надо каждому юзеру ставить демонстрационную дб – которую он превратит в свою рабочую. И разумеется, у каждого юзера, она должна быть своя.

  25. Данные, специфичные для каждого конкретного юзера хранятся в [имя юзера]\Application Data… При необходимости можно разрешить юзеру хранить базу в любом другом удобном для него месте. Или я чего-то еще не понимаю.

  26. AnalogXP Says:

    Begemot, ну как, решил проблему? У меня точно такая же ситуация, интересно…

  27. Да, не то что бы решил, но более-менее приемлимый workaround нашелся, все хочу пост написать о том как это сделать, но с этой работой – времени вообще не на что не остается:(

    Постараюсь на этих выходных написать все-таки.

  28. […] Решение проблемы […]