редактирование реестра с правами пользователя

[maxutov]

возможно ли средствами Windows редактировать реестр с правами пользователя а не админа?

средствами c++

Сообщение отредактировано: maxutov - 20.10.23, 07:42

[Qraizer]

Тут нет разницы, на чём писать. Программить нужно посредством WinAPI, и это можно делать хоть на Бейсике или Ассемблере. Соответственно успех операций будет зависеть от прав доступа к ключам и значениям реестра, и контролируется это опять же самой ОС. Если прав достаточно, будет успех.
Не всё, что позволено Администратору, будет позволено и бык... ой, Пользователю. Если вопрос о повышении прав, то это отдельный разговор, и он опять же независим от языка.

[maxutov]

а как createprocess создать с функциями админа
разве в security ничего не надо писать?

#include <windows.h>
 
int main() {
    // Создаем структуру STARTUPINFO, которая будет использована для запуска нового процесса
    STARTUPINFO si;
    ZeroMemory(&si, sizeof(si));
    si.cb = sizeof(si);
 
    // Создаем структуру PROCESS_INFORMATION, которая будет содержать информацию о новом процессе
    PROCESS_INFORMATION pi;
 
    // Создаем новый процесс с правами администратора
    BOOL success = CreateProcess(L"C:\\Path\\To\\Your\\Executable.exe", NULL, NULL, NULL, FALSE, CREATE_NEW_CONSOLE | CREATE_NEW_PROCESS_GROUP | CREATE_UNICODE_ENVIRONMENT, NULL, NULL, &si, &pi);
 
    if (success) {
        // Процесс успешно создан
 
        // Ожидаем завершения процесса
        WaitForSingleObject(pi.hProcess, INFINITE);
 
        // Закрываем дескрипторы процесса и потока
        CloseHandle(pi.hProcess);
        CloseHandle(pi.hThread);
    } else {
        // Произошла ошибка при создании процесса
        DWORD error = GetLastError();
        // обработка ошибки
    }
 
    return 0;
}

Сообщение отредактировано: maxutov - 02.11.23, 07:43

[Qraizer]

Ну как сказать... Во-первых, тут нужно понимать, как вообще работает система безопасности в WinAPI. Любое действие определяется характеристиками учётной записи пользователя, залогиненного в систему и от имени которого это действие выполняется. Это делается посредством того, что любая сессия начинается со входа пользователя, в процессе которого система генерирует т.н. токен, в котором лежат все права и привилегии, которыми этот пользователь обладает. Они суммируются на основе прав и привилегий как самой учётной записи пользователя, так и групп, в которые эта учётная запись входит. (И ещё дополнительно управляется Локальными и Групповыми Политиками Безопасности, которые можно настроить у себя в "Администрировании", или это может сделать контроллер домена в соответствие с тем, как это настроил Администратор домена.) В дальнейшем эта информация сравнивается с теми правами и/или привилегиями, которые необходимы для осуществления запрошенного действия, которые в свою очередь управляются как фиксированными правилами (привилегии), так и настраиваемыми (права). Последние в частности управляются дескрипторами безопасности (Security Descriptors), назначенными объекту воздействия, например, файлу. Так и получается, что, например, chkdsk не сможет залочить том для исправления ошибок файловой системы, если его запускает Пользователь, т.к. в его токене нет соответствующей привилегии, но сможет от имени Администратора, у которого такая привилегия есть; или нельзя будет открыть файл на запись с правами, определяющими, что Пользователь его может только читать, потому что в его дескрипторе безопасности для Пользователя атрибуты разрешают "только чтение".
Во-вторых, отсюда следует, что CreateProcess() не сумеет решить твою задачу, ибо всегда работает от имени залогиненного в текущую сессию пользователя и работает от его токена. И дело тут совсем не в дескрипторах безопасности, они лишь позволяют указать, что и кому можно делать с объектом (в данном случае процессом Executable) после его создания. Модифицировать имеющийся токен невозможно, кроме как включать или выключать разрешённые токену привилегии и удалять их из токена. Тут нужна CreateProcessAsUser(), которой можно передать любой валидный токен. Сам токен нужно получить LogonUser(), и не факт, что он ещё будет успешен, т.к. локальные политики безопасности могут запретить осуществлять недостаточно привилегированным учётным записями подобные действия. Администратор вот достаточно привилегирован. Система тоже, собственно поэтому создание интерактивной сессии на логонскрине и возможно.
Довольно сложно это всё выглядит, ну а как иначе-то? Если б это было просто, любой зловред смог бы делать всё, и никакой антивирус ему не указ. Но на деле не так уж это сложно. Повозившись с документацией и поняв философию системы безопасности, многое станет логичным и понятным.

Сообщение отредактировано: Qraizer - 02.11.23, 21:49

[Feldsher]

Раздел для прав пользователя есть в реестре там ведь))

[ЫукпШ]

Цитата Qraizer @ 02.11.23, 21:40

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

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

Цитата

возможно ли средствами Windows редактировать реестр с правами пользователя а не админа?

Общая логика доступа к реестру такая:

1. если приложение юзера меняет какие-то свои настройки только для
этого юзера, тогда для редакции реестра права администратора не нужны.
Это легко установить даже опытным путём.
Например, можно запустить regedit и вручную
править реестр в ветке HKEY_CURRENR_USER\Software\....

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

Сообщение отредактировано: ЫукпШ - 03.11.23, 13:50