Проблемы с правами при инстале
February 7th, 2009 Begemot Posted in Рабочее
Работа приносит первый плоды – нашел два бага, в продукте. Первый странный, непонятный, но уже вроде как исправленный, так что и писать нечего. А вот про проблему в инсталяторе я как-то раньше и не задумывался. У меня и на тестовых компах все было хорошо (я-то работаю под админом), народ тоже ни разу не жаловался, а там оказывается страшная бага:)
Если ставить приложение под простым юзером – нет прав писать в Program Files. Если запускать от имени админа, то все ставится, но каталог данных пользователя – берет админский… Для инсталяции использую старый верный скрипт для NSIS’a. Вообщем буду сегодня разбиратся. А то не хорошо получается, приходится себе же устанавливать свой же софт через одно место 🙂
Так что если вы не уверены будут ли ваши инстляторы работать под limited user, самое время проверить. А если уверены – киньте в меня примером 🙂
February 7th, 2009 at 8:55
Во-первых, у юзеров и не должно быть прав писать в Program Files, на то они и юзера 🙂
Под вистой и далее, по идее, Program Files юзеру сделаются виртуальные, а под предыдущими оперсистемами проверяй в инсталяторе уровень привилегий и отказывайся ставить, если не админ.
Во-вторых, что значит “но каталог данных пользователя – берет админский…”? Разве программа не создаст юзеру набор данных, когда он запустит её? Зачем создавать его инсталятором?
February 7th, 2009 at 9:14
хм, то есть это нормально что юзеру невозможно записать в Programm files и исправлять это не надо???
Ну самому проверять и отказываться ставить это сильно странно. Наоборот нужно что бы ставили, ставили, ставили…:)
А про каталог пользователя – некоторые данные лучше ставить инсталлятором чем генерить, например начальную базу данных.
Ну и тут еще другая ловушка в которую я попался – когда оно отказалось ставится, я запустил инстал от имени админа, в конце инсталяции запускается сама прога – опять же от имени админа – и все что я сделал за тот сеанс работы (прога хранит заметки) осталось в app data админа. А я на следующий день сильно удивлялся, где мои данные:)
February 7th, 2009 at 11:36
Да, это нормально – юзерам право писать в Program Files не дано ещё на уровне файловой системы.
А отказываться нужно не молча, а объяснять, что ставить может только администратор.
И если начальную базу данных в профиле юзера генерирует инсталятор, то как потом запустить её под другим эккаунтом? Ставить ещё раз? И так для каждого юзера?
February 7th, 2009 at 12:09
При установке копируй начальную БД или в Program Files или в All Users. А затем при запуске под любым юзером копируй эту БД в профиль этого юзера и работай уже с ней.
А то, что в конце инсталляции запускается под админом, то я думаю это можно пофиксить (и даже нужно), чтобы оно запускалось с правами текущего юзера. Как это делать в NSIS – я не знаю (сам пользую Inno Setup).
February 7th, 2009 at 12:14
Да ну нафик, самому себе сократить количество инсталяций:)
С базой конечно не очень хорошо получилось.. этот вопрос не продуман. Но с другой стороны база не является необходимой для работы, есть хорошо, нету программа создаст пустую.
February 7th, 2009 at 12:26
1. Админские права можно в NSIS вроде можно требовать через RequestExecutionLevel
2. А кто мешает БД записать в юзерскую директорию через константы $DOCUMENTS или $APPDATA?
Тоже встречался с заморочкой в Виста, но у меня там все печальнее было, нужно было регать COM-DLL – и под Вистой инсталлер просто ронялся.
February 7th, 2009 at 12:50
>2. А кто мешает БД записать в юзерскую директорию через константы $DOCUMENTS или $APPDATA?
Так и делаю, проблема в том что видимо для инсталлера запущенного от имени админа $APPDATA указывает на папку админа:)
February 7th, 2009 at 1:11
“$LOCALAPPDATA The local (nonroaming!!!) application data directory.”
Не оно?
February 7th, 2009 at 1:17
в инно это решено.. на канале обсуждали же
February 7th, 2009 at 2:59
Может вам эта штука поможет
UAC plug-in
http://nsis.sourceforge.net/UAC_plug-in
February 8th, 2009 at 3:01
Загляни в доку на MultiUser.nsh, там кое-что предусмотрено уже – можно и заставить инсталятор ругаться, если запустил не админ, и помочь не админам ставить прогу в собственную юзерскую директорию.
February 8th, 2009 at 5:24
Вообщем я тут немного поэксперементировал главная проблема следующая. Если в висте под обычным юзером запускать инсталятор – он автоматом требует пароль админа и запускается из-под его учетки. В конце установки стартует программа – и стартует она опять же под аккаунтом админа, соответственно все сохраняется в его application data. А для юзера все данные сохраненные в первом сеансе работы – выглядят как потерянные.
Вторая проблема – программа прописывается в автозапуск админу, а не юзеру.
Чего делать ума не приложу:(
February 8th, 2009 at 8:49
Как вариант. RequestExecutionLevel admin заменить на RequestExecutionLevel highest; если юзер не админ, предложить ему поставить программу локально либо обратиться к админу.
February 9th, 2009 at 11:11
В NSIS можно указать в каком контексте интерпретировать шелл директории. Делается это с помощью функции:
SetShellVarContext
А далее: SetOutPath “$APPDATA…
По поводу автозапуска тут в инсталляторе вроде ни как. Разве что перебирать всех существующих пользователей на компе и прописываться им всем, но, ИМХО, геморно и неправильно. В автозагрузку должна писать себя сама программа. При первом старте она она по дефолту пишется в Run. Или опять таки можно закинуть ярлык в папку автозагрузки для всех пользователей.
Проблема с потерей данных при первом запуске из под админа решается просто – нужно убрать запуск программы по завершению программы или сделать его опциональным.
February 10th, 2009 at 7:35
Долгая битва кажется увенчалась определенными успехами 🙂
Спасибо, Андрею за ссылку, часть проблем удалось решить. Завтра еще на работе проверю как он себя ведет и напишу как справился.
February 11th, 2009 at 4:14
Мучаюсь теми же проблемами.
Если использовать тот вариант, что создавать файлы в директории APPDATA пользователя-не админа не во время установки, а во время запуска программы, то возникает вопрос: как все подчищать во время удаления программы?
Допустим на компьютере несколько пользователей. Есть один администратор и все остальные обычные пользователи. Администратор установил программу, и все ей пользуются. У каждого пользователя в APPDATA программа создает нужные ей файлы. Потом админ удаляет программу. Как она должна подчищать за собой? Не будет же она у всех пользователей чистить свои данные в APPDATA?
February 11th, 2009 at 4:27
А если создавать где-нибудь в нечто вроде Shared_Files, а название файла, к примеру, привязывать к имени пользователя (аккаунта в Винде)!?!
February 11th, 2009 at 4:52
От варианта подчищять, я отказался – пусть лучше у сотни юзеров останется несколько лишних файлов, чем один случайно грохнет все свои наработки… Да и корректно это сделать трудно все равно.
Это для одной программы, а для другой, у которой база данных может быть довольно большой, я вот не знаю что делать – пока думаю может просто говорить юзеру что бд мы не удаляем во избежание, и открывать ему папку в проводнике – пусть сам чего хочет то и делает… Или вообще забить, ну останется пусть даже 50-100 метров в апп дата, кого это сейчас волнует?
February 11th, 2009 at 5:16
Имхо политически неправильно удалять данные и настройки другим юзерам, особенно если ты не админ. Если у них эти данные есть – значит им эта программа, возможно, ещё нужна?
February 11th, 2009 at 5:40
2Begemot: у меня была такая же ситуация с автоматическими бекапными копиями юзерских документов. Сделал галку в Uninstaller`е (NSIS) “Удалить резервные копии” – по умолчанию выключена. Нареканий не было.
Из жизненного опыта: если уж выбирать из 2-ух зол – тогда имхо пользовательскую БД лучше оставить. У меня в давние времена в описанной схеме галка “Удалять резервные копии” была включена… Ну дык короче один таки шарахнул свои копии случайно, когда ставил новую версию (несмотря на 33 уверения чтобы ставили поверх, удалял перед этим предыдущую версию)… В общем, “секоса чудного” ((С) :)) тогда поимел немало! Так что если из двух зол, то уж лучше не стоит, пусть БД остается.
February 25th, 2009 at 9:21
Есть же all users\application data\ (не помню, какой там системный алиас)
February 25th, 2009 at 4:51
и чем all users\application data\ может помочь?
February 26th, 2009 at 2:52
Тем, что там (вместо Program Files) можно хранить данные своего приложения независимо от того, какой юзер пользуется программой в данный момент.
February 26th, 2009 at 3:06
Конкретно в моем случае это не подходит, мне надо каждому юзеру ставить демонстрационную дб – которую он превратит в свою рабочую. И разумеется, у каждого юзера, она должна быть своя.
February 28th, 2009 at 8:14
Данные, специфичные для каждого конкретного юзера хранятся в [имя юзера]\Application Data… При необходимости можно разрешить юзеру хранить базу в любом другом удобном для него месте. Или я чего-то еще не понимаю.
April 1st, 2009 at 12:53
Begemot, ну как, решил проблему? У меня точно такая же ситуация, интересно…
April 3rd, 2009 at 4:47
Да, не то что бы решил, но более-менее приемлимый workaround нашелся, все хочу пост написать о том как это сделать, но с этой работой – времени вообще не на что не остается:(
Постараюсь на этих выходных написать все-таки.
April 4th, 2009 at 5:53
[…] Решение проблемы […]