Принудительно запускать существующее приложение с включенной виртуализацией UAC

Question

Я видел несколько вопросов, которые противоположны этому;"Как отключить виртуализацию?"Это не мой вопрос.Я хочу заставить приложение работать с виртуализацией enabled .

У меня есть приложение, которое прекрасно работает под Windows XP, но, поскольку оно записывает свою конфигурацию в рабочий каталог (подпапка«C: \ Program Files (x86)»), он не работает полностью под Windows 7. Если я использую диспетчер задач, чтобы включить виртуализацию UAC, он прекрасно сохраняет свою конфигурацию, но, конечно, затем не может загрузить этоconfig.

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

Я обнаружил предложение , что я положил немного магии в реестр на HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags.Для полноты я также поместил его в Wow6432Node, но ни один из них не дал никакого эффекта.

Answer 1

Файловая система виртуализируется в определенных сценариях, поэтому ваш вопрос, как по-прежнему включать ее, когда ваше приложение не соответствует требованиям? Вряд ли это возможно, MSDN :

Виртуализация недоступна в следующих сценариях:

• Виртуализация не распространяется на приложения с повышенными правами и работающие с маркером полного административного доступа.

• Виртуализация поддерживает только 32-разрядные приложения. 64-разрядные приложения без повышенных прав просто получают сообщение об отказе в доступе, когда попытка получить дескриптор (уникальный идентификатор) объекта Windows. Собственные 64-битные приложения Windows должны быть совместимы с UAC и для записи данных в правильные места.

• Виртуализация отключена для приложения, если приложение включает манифест приложения с запрошенным уровнем выполнения приписывать.

Answer 2

это может произойти слишком поздно, но я являюсь автором предложения, которое вы нашли для активации виртуализации UAC, и в моем сообщении была ошибка. Ключи реестра для изменения следующие:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\ 
HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\

(обратите внимание на "Слои" в приложении)

так что полный пример будет:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Some Company\\someprogram.exe"="RUNASINVOKER"

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

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Some Company\\someprogram.exe"="WINXPSP3 RUNASINVOKER"

-

Мне искренне жаль, что вы потеряли немало времени из-за моей ошибки.

И, кстати, позвольте мне выразить свое несогласие с постом Яна Бойда. Есть места, где привилегии на запись не должны предоставляться всем, например, эта, поскольку она нарушает базовое правило безопасности «Общесистемные записи должны быть авторизованы только для привилегированных принципалов». Program Files - это общесистемное место, а не пользовательское.

Конечно, все правила имеют исключения, но в данном случае можно представить, что файл конфигурации, созданный со злым умыслом, заставляет программу выполнить произвольную команду, когда пользователь ее запускает. С другой стороны, можно представить «ошибку удаления» другим пользователем, которая приведет к сбою приложения. С другой стороны, исполняемые файлы приложений в Program Files часто запускаются администратором рано или поздно. Даже если вы этого не хотите, при удалении программ очень часто запускаются исполняемые файлы деинсталляции, которые находятся в Program Files. Возможно, процедура удаления будет использовать этот конфигурационный файл, который может иметь последствия, если он будет создан злонамеренно.

Конечно, вы можете сказать, это звучит как-то параноидально, согласился. Я изменил некоторые списки ACL NTFS в Program Files во времена Win XP и после этого мог спать, но зачем рисковать, когда инструменты доступны?

Answer 3

Я нашел одно не очень хорошо процитированное условие, когда виртуализация UAC НЕ работает: когда файл в Program Files помечен как только для чтения .

То есть предположим, что файлC:\Program Files\<whatever>\config.ini помечен как доступный только для чтения.Когда приложение попытается изменить его, виртуализация UAC вернет ошибку отказано в доступе вместо ее повторного преобразования в %LOCALAPPDATA%\VirtualStore\<whatever>\config.ini.

Хотя я не нашел это документированным, это поведение, вероятно, выполненопо своему замыслу, поскольку в этом есть какой-то смысл.

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

Answer 4

в этих других ответах есть несколько хороших моментов.
на самом деле я проголосовал за все из них.
так что давайте все объединим их вместе и добавим ещеаспект ...

ОП упоминает о каком-то "устаревшем приложении старых времен".
, поэтому мы можем предположить, что это x86 (32 бита), а также не включает какой-либо манифест (и, в частности, не указывает никакой "требуемый уровень_выполнения").

-

Роман Р. имеет хорошие моменты в своем ответе относительно файлов x64 и manifest:
https://stackoverflow.com/a/8853363/1468842
, но все эти условия, кажется, не применяются в этом случае.

NovHak обрисовывает в общих чертах примерно AppCompatFlags с RUNASIVOKER в своем ответе:
https://stackoverflow.com/a/25903006/1468842

Диего Кейроз добавляет интересный аспект относительно флага read-only в своем ответе:
https://stackoverflow.com/a/42934048/1468842

Ян Бойд заявляет, что, вероятно, вам даже не стоит идти на эту «виртуализацию», а вместо этого установить в соответствии ACL на эти файлы, представляющие интерес (например, «config»)..ini "):
https://stackoverflow.com/a/12940213/1468842

и вот здесь добавляется дополнительный / новый аспект:
можно установить policy в отключить вся виртуализация - для всей системы:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableVirtualization"=dword:00000000

на самом деле я применяю эту политику на каждой системе, которой я владею.
, потому что в противном случае это приведет к сбивающему с толку поведению на multi-userокружения.
, где UserA применяет некоторые изменения, и все идет хорошо.
, но затем UnserB не получает изменения, сделанные UserA.

в случае сбоя какого-либо старого дрянного программного обеспечения оно должно «сработать»!
и не утверждать, что все прошло «отлично».
ИМХО эта штука с «виртуализацией» была наихудшим дизайнерским решением Microsoft,когда-либо.

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

-

, поэтому, вероятно, окончательный контрольный список будет:

• - это приложение x86 или x64 ?
• есть ли у файла манифест (включая requestedExecutionLevel)?
• Вы проверили атрибут только для чтения (например, из этих файлов INI)?
• существует ли политика , чтобы заставить EnableVirtualization 0?
• иметьвы пробовали AppCompatFlags с RUNASIVOKER?
• или просто выбрали ACL вместо виртуализации

-

В конце мы обсуждаем, как запустить старое унаследованное приложение.
Используя любые обходные пути и хаки, которые мы можем придумать.
Это, вероятно, лучше обсудить на superuser или serverfault.

на stackoverflow (нацелен на programmers), мы все знаем: пора привести все наши собственные программы в соответствие с концепцией UAC и как реализовать вещи «правильным» способом - «Microsoft»кстати :)

Answer 5

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

Если вы работали под управлением Windows 2000, или Windows XP, или Windows Vista, или Windows 7, или Windows 8, решение остается тем же:

• предоставить соответствующие разрешения для этих мест

---

Например, если вашей программе нужно изменить файлы в:

C:\Program Files\Blizzard\World of Warcraft

Тогда правильное действие равно для изменения разрешений для папки World of Warcraft. По сути, это то, что Microsoft применила к World of Warcraft . (При следующем запуске все пользователи получают полный доступ к папке - как еще можно обновлять WoW независимо от того, какой пользователь вошел в систему.)

Если вы хотите, чтобы пользователи могли изменять файлы в местоположении: вы должны предоставить им разрешение. Если вы были стандартным пользователем, пытающимся запустить WoW на Windows XP , у вас возникнет та же проблема - и вам нужно применить то же решение.

---

Ваше приложение записывает свою конфигурацию в:

C:\Program Files (x86)\Hyperion Pro\preferences.ini

тогда вы, фактически, do хотите предоставить Users Full Control этому файлу:

Итак, ваш:

• приложение не настроено для работы в качестве администратора
• пользователи не могут изменять исполняемый файл
• пользователи могут изменять Configuration.ini

Предоставление разрешений - это не плохо; это как вы администрируете свой сервер.

---

Есть два решения:

• Установите на C:\ProgramData\Contoso\Preferences.ini и включите ACL во время установки
• Установите на C:\Program Files\Contoso\Preferences.ini и включите ACL во время установки

И если вы посмотрите на руководство парня из AppCompat в Microsoft:

Куда записывать программные данные вместо программных файлов?

Общее обновление кода приложения таково: «мое приложение использовалось для записи файлов в программные файлы. Это место было таким же хорошим, как и любое другое. На нем уже было имя моего приложения, и поскольку мои пользователи были администраторами, оно работало нормально. Но теперь я вижу, что это может быть не настолько хорошим местом для вещей, как я когда-то думал, потому что с UAC даже администраторы работают со стандартными пользовательскими привилегиями большую часть времени. Итак, куда мне вместо этого положить мои файлы? »

FOLDERID_ProgramData

Пользователь никогда не захочет просматривать здесь в Проводнике, и измененные здесь настройки должны повлиять на каждого пользователя на машине. Расположение по умолчанию:% systemdrive% ProgramData, который является скрытой папкой, при установке Windows Vista. Вы хотите создать свой каталог и установить необходимые ACL во время установки.

Итак, у вас есть два решения:

• создайте свой файл во время установки и включите ACL, чтобы все пользователи могли изменять его во время выполнения
• создайте ваш файл во время установки и включите ACL, чтобы все пользователи могли изменять его во время выполнения

Разница только в семантике. Папка Program Files предназначена для программ files . Вы не хотите хранить данные здесь.

• И это , а не , потому что Диего Кейроз имеет какое-то представление о безопасности.
• Это потому, что туда идут только программы.

Иногда машины отображаются с одинаковыми программными файлами снова и снова. Вам не нужны данные для каждой машины в вашем изображении. Эти данные принадлежат ProgramData .

И это не проблема безопасности.

Некоторые люди должны узнать, где находится граница безопасности.