Проблема удаления Wix Toolset RegistrySearch MSI INFO 1402 "Не удалось открыть ключ. Убедитесь, что у вас достаточно доступа к этому ключу"

Question

У меня большая проблема при попытке удалить приложение, которое я создал, установщик для использования WiX Toolset v3.11

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

 <Property Id="MyProperty" Value="DefaultValue">
      <RegistrySearch Id="MyPropertyRegSearch" Root="HKLM" Key="Software\Company\Installer" Name="myproperty" Type="raw" />
 </Property>

, тогда у меня есть компонент, который обрабатывает запись реестра.

 <Component Id="InstallPropertiesWrite" Guid="*">
    <RegistryKey Root="HKLM" Key="Software\Company\Installer" Action="createAndRemoveOnUninstall">
        <RegistryValue Name="myproperty" Type="string" Value="[MyProperty]">
        </RegistryValue>
    </RegistryKey>
</Component>

все это прекрасно работает .

Моя проблема заключается в том, что при удалении в журнале установки появляется сообщение об ошибке:

MSI (s) (CC: D4) [14: 59: 26: 414 ]: Примечание: 1: 1402 2: HKEY_LOCAL_MACHINE32 \ Software \ Company \ Installer 3: 5 Информация 1402. Не удалось открыть ключ: HKEY_LOCAL_MACHINE32 \ Software \ Company \ Installer. Системная ошибка 5. Убедитесь, что у вас есть достаточный доступ к этому ключу, или обратитесь в службу поддержки.

Теперь я запустил монитор процесса, чтобы определить точный ключ и учетную запись, которая пытается получить доступ к этому ключу реестра. и это HKLM \ Software \ WOW6432Node \ Company \ Installer , что является правильным, поэтому я не верю, что это 32/64-битная проблема. Монитор процессов также обнаружил, что исполняемый файл msiexe c, пытающийся получить доступ к этому ключу, работает под пользователем NT AUTHORITY \ SYSTEM .

Я подтвердил, что SYSTEM учетная запись имеет «Полный доступ» разрешений (через regedit) для этого ключа, но я все еще получаю сообщение об ошибке.

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

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

<Permission User="Everyone" GenericAll="yes" />

Answer 1

Отказано в разрешении : Вверху у меня часто возникают непредвиденные проблемы с отказом в доступе, когда вы 1) применяете ошибочное разрешение ACL как часть вашей установки (легко сделать), а также из других установок , которые вы установили, конечно, 2) используют сверхактивные сканеры вредоносных программ, которые блокируют вещи, 3) использовать настраиваемые действия, которые выполняются в неправильном контексте (олицетворение), и изменять то, что не следует ( не нужно использовать C# для применения списков ACL, таких как или this или this или this - используйте встроенные конструкции WiX, показанные ниже), 4), когда люди вызывают настройки для запуска через странные механизмы, такие как "runas" и аналогичные, 5) некоторые изменения калибровки ОС могут мешать вашим пользовательским спискам ACL - не так часто, но возможно, и, наконец, 6) иногда вы видите такие проблемы на случайных машинах, и вы никогда не работаете Причина и проблема никогда не видны в другом месте. Просто так упоминается. И есть и другие причины - конечно.

Раньше были шаблоны для стандартных разрешений ОС, которые можно было повторно применить к машинам, сломанным из-за неправильного разрешения ACL. Я не уверен, как они будут называться сегодня или если они все еще существуют. Шаблоны безопасности администратора или что-то в этом роде.

---

ACL : разрешения ACL сложны, и их изменение часто может привести к строки того, что вы видите, и многие другие (активный каталог, повреждение системы, неожиданные проблемы после обновлений и т. д. c ...). Это трудно сделать правильно. Как правило: придерживайтесь своих собственных папок, когда возитесь с ACL. Если ты можешь. Или, что еще лучше, полностью избегайте разрешения ACL (список некоторых подходов для достижения этой цели).

Разрешение WiX ACL Действительно, есть несколько способов применить разрешения ACL с WiX, вот середина страницы списка: Изменяет ли WiX разрешения для моего файла Notes.ini?

Повторяя суть этого здесь (путая этот длинный ответ):

• Разрешение (отображается на встроенную стандартную таблицу MSI LockPermissions ). Пример .
• PermissionEx (спецификация WiX c Разрешение расширения Util - сопоставление с пользовательской таблицей WiX). Пример .
• PermissionEx (отображается на встроенную стандартную таблицу MSI MsiLockPermissionsEx - функция добавлена ​​в Windows Установщик версии 5). Вот пример .
• FileSharePermission (спецификация WiX c Разрешение общего доступа к файлу расширения Util - сопоставляется с пользовательской таблицей WiX).

Два элемента PermissionEx должны оба выполнять то, что вам нужно, то есть обновлять, а не заменять существующий ACL. Обратите внимание, что общая проблема с ACL состоит в том, что порядок элементов управления доступом имеет значение, другими словами: порядок элементов разрешения важен.

---

util: PermissionEx : похоже, что элемент util:PermissionEx объединяет новые ACE в ACL, а не заменяет то, что есть. Я не уверен на 100% - проверю.

Пример WiX util:PermissionEx - реализован в WixUtilExtension.dll:

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
     xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">

<..>

<Component Feature="MyFeature">
   <File Source="D:\MyFile.exe">
      <util:PermissionEx User="Everyone" GenericAll="yes" />
   </File>
</Component>

1. Сначала необходимо добавить пространство имен xmlns:util="http://schemas.microsoft.com/wix/UtilExtension" к элементу верхнего уровня "Wix" в исходном файле.
2. Затем необходимо добавить ссылку на WixUtilExtension.dll если вы находитесь в Visual Studio (или укажите путь к нему, если вы компилируете с candle.exe и light.exe самостоятельно - см. образец внизу здесь - этот образец предназначен для GUI, но это тот же подход для dll Util).
3. Наконец, вы добавляете необходимые вам права доступа к файлу, реестру или любому другому элементу, к которому вам нужно добавить его. Допустимые элементы, указанные в документации: CreateFolder, File, Registry, RegistryKey, RegistryValue. См. Документацию здесь .

---

Ссылки :

• Система. UnauthorizedAccessException при запуске .exe под программными файлами
• WIX: предоставление разрешений для папки (WixQueryOsWellKnownSID)
• Разрешения WiX, как мне express «Изменить» с точки зрения флагов DACL
• Установка разрешений NTFS в C#. NET
• Как запретить пользователям доступ к папке с помощью установщика wix

Answer 2

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

<Permission User="Interactive" GenericAll="yes" />

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

Обновление:

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

Итак, я изучал атрибут полномочий и уведомление Добавить (не компилируется) и ChangePermission (без эффекта), которые, похоже, не документированы где угодно. :(

Решение:

Я изменил свой существующий элемент Permission , чтобы использовать элемент PermissionEx из расширения Util как это позволило сохранить все существующие разрешения и добавить только необходимые мне разрешения.