Как настроить параметр программы, который может изменить пользователь, который не может изменить пользователь?

Question

Мое приложение должно прочитать опцию при запуске, чтобы проверить, должно ли оно запускаться в режиме только для чтения. Опция не должна быть изменена пользователем.

Обычно я делаю это сейчас, используя значение, установленное в разделе HKLM \ Software системного реестра. Администратор устанавливает значение, и пользователи не могут его изменить (у них нет прав на изменение записей в HKLM).

Проблема в том, что на компьютере с терминальным сервером (или Citrix) это влияет на всех пользователей. Я хотел бы найти способ сделать это для каждого пользователя. Как другие справляются с этим? Есть ли в системном реестре раздел для такого типа настройки для каждого пользователя, который пользователь не может изменить?

Спасибо за любые предложения или комментарии!

Answer 1

По сути, это то, для чего нужен ключ HKEY_CURRENT_USER\Software\Policies, т. Е. Ключ в пользовательской части реестра, который по умолчанию доступен только для чтения самому пользователю.

По соглашению иерархия ключей должна дополнять ту, что у вас уже есть под HKEY_CURRENT_USER\Software, например если ваши обычные пользовательские настройки хранятся в HKEY_CURRENT_USER\Software\MyCompany\MyProgram, то защищенные пользовательские настройки (или «политики» в MS lingo) должны храниться в HKEY_CURRENT_USER\Software\Policies\MyCompany\MyProgram

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

Answer 2

Концепция области пользовательских настроек, которую пользователь не может изменить, на самом деле не имеет смысла - если это пользовательские настройки, «вы» (пользователь) ожидаете, что сможете их изменить.

Я могу придумать две альтернативы:

• Напишите ваши настройки в HKLM, но есть различные настройки для каждого пользователя и глобальные резервные настройки для пользователей без настройки
• Напишите их в HKCU, но используйте API-интерфейсы безопасности реестра для предотвращения они пишут ему. Вам, вероятно, понадобится разрешения больше, чем их предотвратить их отмену разрешения изменения. Мне это не очень нравится вариант, но если вы хотите следовать ему Вы, вероятно, хотите начать с RegGetKeySecurity и RegSetKeySecurity API. Это статья может быть интересна как хорошо.

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

Answer 3

Как насчет двух настроек?

1) Установите флаг в HKLM, указав, что только чтение только является поведением по умолчанию на этом компьютере.

2) Для всех пользователей, которым необходим полный доступ, установите токен в HKCU, который разрешает полный доступ.

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

Answer 4

Почему вы не храните опции в своей собственной базе данных? Это кажется разумным и достаточно удобным (по крайней мере, мне 8)) Нет проблем с созданием «портативной» версии вашего продукта. Пользователи не беспокоятся о каких-либо настройках, которые вам не нужны.

Answer 5

• Возьмите один из файлов, поставляемых с вашей программой, который не должен изменяться (по крайней мере, пользователем с ограниченными правами). Если такого файла нет, создайте его только для этой цели.
• Позвольте администратору установить права доступа только для чтения к этому файлу для этих пользователей с ограниченными правами.
• В программе проверьте, есть ли у вас права на запись в этот файл.

Answer 6

Что не так с HKCU вместо HKLM? Это будет для каждого пользователя. К сожалению, пользователь может изменить его, если пользователь знает, как редактировать реестр и найти ключ.