Сменить владельца ключа реестра (subinacl)
 

Пытаюсь реализовать задачу по добавлению некоторых пунктов в меню элемента Windows 10 "Этот компьютер".

1. Хочу сменить владельца на ветку реестра "HKEY_CLASSES_ROOT\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}\shell".
2. Дать полный доступ группе "Администраторы" на эту же ветку.
3. Внести нужные изменения.
4. Вернуть значения доступа ветки реестра и владельца в исходное состояние.

Вот на первом пункте возникла накладка...

При выполнении команды в cmd (запущенной от имени "Администратора":
получаю результат "...RegSetKeySecurity Error: 5 Отказано в доступе".

Почему не срабатывает данная команда я не понял. :dont-know :durak:

Anton04, а если двумя командами, сначала /setowner, затем /grant.

Petya V4sechkin,

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

Э… По сравнению с чем «ничего не поменялось»? С этим:
?! Ибо на скриншоте я вижу, что владелец сменён, права назначены.

Не поменялся владелец, проверяю визуально в редакторе реестра.

Я это тоже вижу, но по факту владелец ветки остался прежним и права тоже. :dont-know

Anton04, а система у вас 64-битная?
Интересно, работает ли subinacl корректно в 64-битной системе.

Оно самое:

Iska, а почему выдаёт NAME NOT FOUND?

Anton04, поскольку 64-битной версии subinacl нет, можете использовать другую утилиту, например SetACL.exe.

Например NTFS разрешения на файлы в 64-bit`ной системе subinacl редактирует корректно.

Об данной утилите я знаю, просто хотелось использовать относительно стандартную утилиту от MS.

Тогда вопрос, а что в данном случае рекомендует использовать MS в командной строке? Или у MS ответ один - PowerShell ?

Registry Keys Affected by WOW64 (Windows)

Потому, что в перенаправленном …\Wow6432Node\… нет такого раздела. Для x64 приложений указанный раздел напрямую (без рефлексии на Wow6432Node) виден и доступен. (На всякий случай, по скриншоту — я для экспериментов специально создавал раздел с GUID, отличающимся от существующего последней буквой, «e» вместо «d»; с ним и игрался) И как я понимаю, извне это перенаправление обращений в реестр для x86-приложений под x64 ОС никак не отключить.

Цитата:

Цитата Anton04 Например NTFS разрешения на файлы в 64-bit`ной системе subinacl редактирует корректно. »

Вот не думаю.

Уже упомянутый SetACL.exe и, не поверите — старичка Regini.exe.

Сейчас проверил: в папке System32 ничего он не редактирует (потому что система в SysWOW64 перенаправляет). Хотя можно использовать псевдоним SysNative.

Цитата:

Цитата Iska я для экспериментов специально создавал раздел с GUID, отличающимся от существующего последней буквой, «e» вместо «d»; с ним и игрался

А, разницу в одну букву я не заметил :)
Просто исходный раздел есть и в Wow6432Node тоже.

Цитата:

Цитата Iska Вот не думаю. »

Проверенно ещё на 64-bit`ной Win7, если в Win10 ничего принципиального не поменяли, то и там должно работать.

Почему не поверю, ещё как поверю! Просто хотелось использовать один инструмент для редактирования разрешения и в NTFS и в реестре.

P.S. Спасибо, буду смотреть в сторону утилиты SetACL, может мне и подойдёт.

Я делал разрешения для файлов и папок в каталогах "Program Files" и "Program Files (x86)" и там у меня всё срабатывает.

Anton04, для файловой системы перенаправление касается только папки %windir%\System32:
File System Redirector

У меня (под Windows 7 x64), в HKCU — нет, в HKCR — есть (на скриншоте ошибка и там, и там из-за того, что я сам создавал раздел с чуть изменённым именем, как писал выше).

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

Davis McCarn

How to change Registry Permissions with RegIni.exe (VBScript)

Про subinacl интересно, но задача изначально содержала ненужные условия (пункты 1, 2, 4). Всё проще - от https://www.outsidethebox.ms/10539/#_Toc277326816 и до конца

Vadikan,

Хм... то же интересный подход, правда я мыслил шире, т.к. подобных изменений может возникнуть масса в любых частях реестра и изначально не известно на какие ветки реестра даны те или иные разрешения и чтоб каждый раз не проверять обратился именно к процессу смены владельца т.п. Как правильно сказано не всегда учётная запись "Система" или "TrustedInstaller" имеет полный доступ к тем или иным веткам реестра.
Это к тому, что за ранее не известно какие разрешения MS вдруг поменяет, а в теории данные команды должны срабатывать в 99 % случаев.

Не много не понятно будет ли работать такая вот команда: psexec -i -s regedit /s "c:\test.reg" или tshell.exe regedit /s "c:\test.reg"

P.S. Благодарю за идею. :hi:

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

Ну да, что есть, то есть...
Будем тестить, то что есть psexec и Trusted Shell.

P.S. Очень жаль, что у MS нету решения из коробки по поводу внесения изменений в реестр от имени системы или TrustedInstaller (powershell я не беру во внимание, хоть и знаю что он хорош).