Доброго времени суток!

Задача:
пользователь A (не администратор, член групы Users) запускает программу
(которую и разрабатываем), которая должна создать процесс (неинтерактивный)
от имени пользователя B (который на самом деле явл. локальным администратором)

Платформа:
WinXP SP2

Решение:
Использовал CreateProcessWithLogonW

     PROCESS_INFORMATION pi;
     memset( &pi, 0, sizeof( PROCESS_INFORMATION ) );

     STARTUPINFOW si;
     memset( &si, 0, sizeof( STARTUPINFOW ) );
     si.cb = sizeof(si);
     si.dwFlags = STARTF_USESHOWWINDOW;
     si.wShowWindow = SW_HIDE; 

     BOOL Result = CreateProcessWithLogonW(
              admName, // username
              L".",                  // domain
              admPwd,  // password
              LOGON_NETCREDENTIALS_ONLY,
              ServerExecutableUNC, // UNC path to application
              NULL,    // command line
              CREATE_DEFAULT_ERROR_MODE, // CreationFlags
              NULL,    // Environment
              NULL,    // CurrentDirectory
              &si, &pi );

Проблема:
Всe работало, пока приложение ServerExecutableUNC было на локальном диске.
Однако если оно расположено на сетевом ресурсе, который доступен для пользователя A (как и полагается),
но недоступен для пользователя В, то CreateProcessWithLogonW заканчивается неудачей.
(что-то вроде Unknown username or bad password)

Вот что пишет MSDN про CreateProcessWithLogonW:

CreateProcessWithLogonW accesses the specified directory and executable image in the security context of the target user. If the executable image is on a network and a network drive letter is specified in the path, the network drive letter is not available to the target user, as network drive letters can be assigned for each logon. If a network drive letter is specified, this function fails. If the executable image is on a network, use the UNC path.

Все так и получается.

Знаю, что есть функция CreateProcessAsUser, которая, похоже, могла бы подойти, поскольку

By default, CreateProcessAsUser accesses the directory and executable image in the security context of the caller.

Но заставить её работать из простого приложения (не сервиса) мне не удалось...

Как быть?

Если я все понимаю правильно, нужно как-то разрешить доступ пользователю B к сетевому ресурсу
(утрируя, где-то ввести имя/пароль), но где это делать?

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

Заранее спасибо за помощь,
j0t.

А какую ошибку возвращает CreateProcessAsUser? Чем химичить с правами доступа лучше использовать ф-ции по назначению, а CreateProcessAsUser — как раз то, что нужно.

Здравствуйте, j0t, Вы писали:

j0t>Доброго времени суток!

j0t>Знаю, что есть функция CreateProcessAsUser, которая, похоже, могла бы подойти, поскольку
j0t>

j0t>By default, CreateProcessAsUser accesses the directory and executable image in the security context of the caller.

j0t>Но заставить её работать из простого приложения (не сервиса) мне не удалось...

j0t>Как быть?

Для успешного выполнения функции CreateProcessAsUser вызывающий пользователь должен иметь привилегии:
SE_ASSIGNPRIMARYTOKEN_NAME "Replace a process level token" (по-умолчанию только у сервисов — LOCAL SERVICE и NETWORK SERVICE, а также у HTTP Anonymous User) и SE_INCREASE_QUOTA_NAME "Adjust memory quotas for a process" (по-умолчанию тоже что и для SE_ASSIGNPRIMARYTOKEN_NAME + Администраторы).

Есть ещё LogonUser, но с ней ещё хуже — до Windows 2003 ей была нужна SE_TCB_NAME (Act as part of the operating system) — по умолчанию только у System`а.

Таким образом вызвать эти функции просто так не удасться даже администратору (но с админом проще — он может сам себе выставить привилегии перед вызовом, а потом их снова убрать). С обычным пользователем всё гораздо сложнее.
В случае просто пользователя обычно пишется сервис (в данном случае рекомендую запускать его под NETWORK SERVICE, потому что доступ к сетевому ресурсу), который по запросу из клиентского приложений вызывает одну из этих функций. Всё.

Здравствуйте, ghostrider, Вы писали:

G>А какую ошибку возвращает CreateProcessAsUser? Чем химичить с правами доступа лучше использовать ф-ции по назначению, а CreateProcessAsUser — как раз то, что нужно.

CreateProcessAsUser возвращает ошибку

1314: A required privilege is not held by the client.

что и неудивительно, если принять во внимание, что вызывается CreateProcessAsUser под простым пользователем.

Здравствуйте, j0t, Вы писали:

j0t>Здравствуйте, ghostrider, Вы писали:

G>>А какую ошибку возвращает CreateProcessAsUser? Чем химичить с правами доступа лучше использовать ф-ции по назначению, а CreateProcessAsUser — как раз то, что нужно.

j0t>CreateProcessAsUser возвращает ошибку

j0t>1314: A required privilege is not held by the client.

j0t>что и неудивительно, если принять во внимание, что вызывается CreateProcessAsUser под простым пользователем.

См. ниже

Автор: Mr. None
Дата: 11.05.06

я уже ответил на этот вопрос, вроде бы.

Здравствуйте, Mr. None, Вы писали:

MN>Для успешного выполнения функции CreateProcessAsUser вызывающий пользователь должен иметь привилегии:
MN>SE_ASSIGNPRIMARYTOKEN_NAME "Replace a process level token" (по-умолчанию только у сервисов — LOCAL SERVICE и NETWORK SERVICE, а также у HTTP Anonymous User) и SE_INCREASE_QUOTA_NAME "Adjust memory quotas for a process" (по-умолчанию тоже что и для SE_ASSIGNPRIMARYTOKEN_NAME + Администраторы).

MN>Есть ещё LogonUser, но с ней ещё хуже — до Windows 2003 ей была нужна SE_TCB_NAME (Act as part of the operating system) — по умолчанию только у System`а.

MN>Таким образом вызвать эти функции просто так не удасться даже администратору (но с админом проще — он может сам себе выставить привилегии перед вызовом, а потом их снова убрать). С обычным пользователем всё гораздо сложнее.

Спасибо за разяснения, я все так себе и представлял


MN>В случае просто пользователя обычно пишется сервис (в данном случае рекомендую запускать его под NETWORK SERVICE, потому что доступ к сетевому ресурсу), который по запросу из клиентского приложений вызывает одну из этих функций. Всё.

Думал о написании сервиса, но останавливали следующие моменты:
1) не хотелось неоправданных усложнений
2) может ли модуль сервиса лежать на сети?
3) насколько я понимаю, сервис нужно обязательно инсталлировать (или нет?)
простой пользователь этого не сможет делать, а администратору — лишняя работа...

существуют ли "динамические" сервисы?

Кстати, на самом деле CreateProcessWithLogon использует стандартный сервис SecondaryLogon

Здравствуйте, Mr. None, Вы писали:

[Skip]

MN>Есть ещё LogonUser, но с ней ещё хуже — до Windows 2003 ей была нужна SE_TCB_NAME (Act as part of the operating system) — по умолчанию только у System`а.

Странненько, у меня LogonUser + ImpersonateLoggedOnUser + RevertToSelf работают на ура. Windows 2000 Proffesional. И я Local админ.
Плюс такого подхода в том что не нужно создавать дополнительный процесс. Права выставляются на поток.

Здравствуйте, Danchik, Вы писали:

D>Здравствуйте, Mr. None, Вы писали:

D>[Skip]

MN>>Есть ещё LogonUser, но с ней ещё хуже — до Windows 2003 ей была нужна SE_TCB_NAME (Act as part of the operating system) — по умолчанию только у System`а.

D>Странненько, у меня LogonUser + ImpersonateLoggedOnUser + RevertToSelf работают на ура. Windows 2000 Proffesional. И я Local админ.
D>Плюс такого подхода в том что не нужно создавать дополнительный процесс. Права выставляются на поток.

Порверьте, может быть ваш локал админ уже давно имеет "Act as part of the operating system", ибо если нет, то это какая-то магия. Требование на наличие этой привелегии для выполнение LogonUser было снято только в Win2003 (возможно WinXP тоже, но не уверен).

Здравствуйте, j0t, Вы писали:

j0t>Здравствуйте, Mr. None, Вы писали:

MN>>В случае просто пользователя обычно пишется сервис (в данном случае рекомендую запускать его под NETWORK SERVICE, потому что доступ к сетевому ресурсу), который по запросу из клиентского приложений вызывает одну из этих функций. Всё.

j0t>Думал о написании сервиса, но останавливали следующие моменты:
j0t>1) не хотелось неоправданных усложнений
Это стандартное решение

j0t>2) может ли модуль сервиса лежать на сети?
не уверен (читай — не пробовал ).

j0t>3) насколько я понимаю, сервис нужно обязательно инсталлировать (или нет?)
j0t>простой пользователь этого не сможет делать, а администратору — лишняя работа...
Если вы не хотите загружать администратора, то боюсь ничего у вас не выйдет. Я только не могу понять, почему вы не хотите написать простейший инсталятор, который выполнит всю нужную работу...
Вообще что-то у меня много сомнений насчёт того, что вы делаете... Например, как, если вы не хотите загружать администратора, ваша программа запустит что-либо от имени администратора — откуда она возьмёт логин, пароль (учётная запись Administrator в общем случае может быть переименована)?
1) Они будут захардкожены в коде? — тогда нафиг вообще все эти извращения, лучше дайте всем сразу админские права, ибо это не защита.
2) Они будут будут храниться в реестра в открытом виде? — см. предыдущий ответ.
3) Они будут храниться в реест в зашифрованном виде? А где ключ — захардкожен в программе? — тоже самое, что и предыдущие варианты.

j0t>существуют ли "динамические" сервисы?
что значит динамические сервисы?

j0t>Кстати, на самом деле CreateProcessWithLogon использует стандартный сервис SecondaryLogon
я в курсе, но в своём сервисе у вас будет больше возможностей для извращения с правами и прочей радости: вы всегда можете запустить его под специфичным пользователем, которому дать все привелегии и открыть доступ к нужному вам файлу в сети, потому что SecondaryLogon, работающий от имени LocalSystem, лезет на сетку под аккаунтом системы, если вы в домене, то для решения проблемы (возможно) достаточно дать права соответствующему компьютерному аккаунту, если же вы не в домене, то сделать это невозможно.

Здравствуйте, Mr. None, Вы писали:

[Skip]

D>>Странненько, у меня LogonUser + ImpersonateLoggedOnUser + RevertToSelf работают на ура. Windows 2000 Proffesional. И я Local админ.
D>>Плюс такого подхода в том что не нужно создавать дополнительный процесс. Права выставляются на поток.

MN>Порверьте, может быть ваш локал админ уже давно имеет "Act as part of the operating system", ибо если нет, то это какая-то магия. Требование на наличие этой привелегии для выполнение LogonUser было снято только в Win2003 (возможно WinXP тоже, но не уверен).

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

Здравствуйте, Danchik, Вы писали:

D>Здравствуйте, Mr. None, Вы писали:

D>[Skip]

D>>>Странненько, у меня LogonUser + ImpersonateLoggedOnUser + RevertToSelf работают на ура. Windows 2000 Proffesional. И я Local админ.
D>>>Плюс такого подхода в том что не нужно создавать дополнительный процесс. Права выставляются на поток.

MN>>Порверьте, может быть ваш локал админ уже давно имеет "Act as part of the operating system", ибо если нет, то это какая-то магия. Требование на наличие этой привелегии для выполнение LogonUser было снято только в Win2003 (возможно WinXP тоже, но не уверен).

D>Да действительно, у меня стоит эта привилегия. И при чем только на меня. Икс его знает кто ее выставил... Может какая то тулза для своей работы требовала...

Здравствуйте, Mr. None, Вы писали:

MN>Вообще что-то у меня много сомнений насчёт того, что вы делаете... Например, как, если вы не хотите загружать администратора, ваша программа запустит что-либо от имени администратора — откуда она возьмёт логин, пароль (учётная запись Administrator в общем случае может быть переименована)?

Абсолютно с вами согласен — но ничего поделать не могу.
Дело в том, что имеет место такая "смешнаю" "политика безопасности" предприятия:
admin credentials [почти] везде одинаковые, и не знает их только конечный полльзователь,
который, как известно, тупой

MN>что значит динамические сервисы?

Ну я имел ввиду возможность работы с сервисами без их регистрации в регистру.
Но это уже оффтоп.

j0t>>Кстати, на самом деле CreateProcessWithLogon использует стандартный сервис SecondaryLogon
MN>я в курсе, но в своём сервисе у вас будет больше возможностей для извращения с правами и прочей радости: вы всегда можете запустить его под специфичным пользователем, которому дать все привелегии и открыть доступ к нужному вам файлу в сети, потому что SecondaryLogon, работающий от имени LocalSystem, лезет на сетку под аккаунтом системы, если вы в домене, то для решения проблемы (возможно) достаточно дать права соответствующему компьютерному аккаунту, если же вы не в домене, то сделать это невозможно.

Согласен. Надо только взвесить, стоит ли игра свеч...

На самом деле описанная проблема (с "неконсистентностью" прав) очень редка и в этом случае правда лучше адимна на помощь звать Он все и сделает.

Вобщем, тема закрыта.
Всем спасибо, особенно Mr. None!

Здравствуйте, j0t, Вы писали:

j0t>Здравствуйте, Mr. None, Вы писали:

MN>>Вообще что-то у меня много сомнений насчёт того, что вы делаете... Например, как, если вы не хотите загружать администратора, ваша программа запустит что-либо от имени администратора — откуда она возьмёт логин, пароль (учётная запись Administrator в общем случае может быть переименована)?

j0t>Абсолютно с вами согласен — но ничего поделать не могу.
j0t>Дело в том, что имеет место такая "смешнаю" "политика безопасности" предприятия:
j0t>admin credentials [почти] везде одинаковые, и не знает их только конечный полльзователь,
j0t>который, как известно, тупой

Вопрос не о том. Каким образом ваша программа, запущенная обычным пользователем, запустит что-то под учётной записью администратора; кто ей сообщит пароль, откуда она его возьмёт?
Чистое IMHO: тут следовало бы немного подумать и сделать редизайн. Вообще запускать что-то в интерактивном режиме с повышением привилегий — плохая идея (небезопасно, bad style и всё такое). Если нужны высокие привелегии, пишите сервис и общайтесь с ним — так безопаснее. Представьте себе, что у вас есть интерактивное приложение, которое запускает обычный пользователь, но которое работает с правами администратора! В этом приложении используются стандартные диалоги типа OpenFile? А вы помните, что в этих диалогах можно щёлкнув правой кнопкой мышки открыть меню по управлению файлами — скопировать, удалить, переместить, открыть свойства (а там есть вкладка по управлению правами) — заметьте, все эти операции будут выполняться с правами администратора... То есть обычный юзер запросто сможет зайти в каталог Windows, что-нть удалить, что-нть записать, нарулить какие хочет права — и нету вашей политики безопасности. А сколько ещё подобных подводных камней? Вы не задумывались?

j0t>>>Кстати, на самом деле CreateProcessWithLogon использует стандартный сервис SecondaryLogon
MN>>я в курсе, но в своём сервисе у вас будет больше возможностей для извращения с правами и прочей радости: вы всегда можете запустить его под специфичным пользователем, которому дать все привелегии и открыть доступ к нужному вам файлу в сети, потому что SecondaryLogon, работающий от имени LocalSystem, лезет на сетку под аккаунтом системы, если вы в домене, то для решения проблемы (возможно) достаточно дать права соответствующему компьютерному аккаунту, если же вы не в домене, то сделать это невозможно.

j0t>Согласен. Надо только взвесить, стоит ли игра свеч...
Скажит что дороже — лишняя неделя работы или безопасность сети всего предприятия? Спросите об этом у вашего ПМа, боса, заказчика... Я выше привёл пример потенциальной уязвимости при запуске интерактивного приложения с повышенными привилегиями...

j0t>Вобщем, тема закрыта.
Как знать, как знать . Обратите внимание на мой комментарий выше...

j0t>Всем спасибо, особенно Mr. None!
Да не за что...

Здравствуйте, Mr. None, Вы писали:

MN>Чистое IMHO: тут следовало бы немного подумать и сделать редизайн. Вообще запускать что-то в интерактивном режиме с повышением привилегий — плохая идея (небезопасно, bad style и всё такое). Если нужны высокие привелегии, пишите сервис и общайтесь с ним — так безопаснее. Представьте себе, что у вас есть интерактивное приложение, которое запускает обычный пользователь, но которое работает с правами администратора! В этом приложении используются стандартные диалоги типа OpenFile? А вы помните, что в этих диалогах можно щёлкнув правой кнопкой мышки открыть меню по управлению файлами — скопировать, удалить, переместить, открыть свойства (а там есть вкладка по управлению правами) — заметьте, все эти операции будут выполняться с правами администратора... То есть обычный юзер запросто сможет зайти в каталог Windows, что-нть удалить, что-нть записать, нарулить какие хочет права — и нету вашей политики безопасности. А сколько ещё подобных подводных камней? Вы не задумывались?

Возможно, я не сказал об этом в самом начале — приложение, запускаемое под учетной записью админа, никоим образом не взаиможействует с пользователем — это RPC server, предоставляющий некоторые функции для установки необходимых компонентов, у него не ни одного окна или диалога.