Подправил код слегка. Избавился от Jedi.

В основной рабочей процедуре службы в цикле через заданный интервал проверяю наличие процесса и, если нужно, выполняю запуск:



Это сообщение отредактировал(а) Romero - 22.2.2011, 13:18

Теоретический вопрос. Для выполнения действий процедуры RunApp у службы должны быть права системы. А можно ли получить подобные привилегии (и удачно запустить программу от чужого имени) из обычного приложения (которое не имеет прав системы, но, допустим, запущена от имени Администратора)?

И еще, когда я гляжу на другие найденные в Интернете примеры кода запуска процесса от имени активного пользователя, у меня возникает ощущение, что в моем коде чего-то не хватает. Он слишком лаконичный  Например, по сравнению с функцией RunApplication отсюда. С виду то всё работает, но вдруг что упустил важного.

Попробуйте запустить что-нибудь "не свое", тогда узнаете 
У меня больше всего проблем возникло с запуском ACDSee - нехватало параметров в Environment.
В остальном - читайте в MSDN описания тех функций, которые задействуете.
Например, про первый параметр CreateProcessAsUser пишут



Если смотреть в библию, то упираемся в WTSQueryUserToken:


Добавлено через 6 минут и 5 секунд

Установить службу> выйти из системы> войти под гостем> сменить пользователя на админа (т.е. чтобы получилось 2 одновременно запущенные сессии - первая "гость" и вторая "админ")

Добавлено через 7 минут и 26 секунд

Проверил под виртуальной XP SP3 - работает.

В выходные проверил на Win7x64 - работает. В сеансе Гостя - тоже. Проверял так: запустил сеанс Админа, Программа стартанула; переключился на Гостя (сеанс Админа был активен) - стартанула (в списке процессов видно, что от имени Гостя, как и положено), переключился на другого Админа - тоже стартанула (в списке процессов уже три копии - каждая от имени своего юзера). Или критично было именно "выйти из системы", после чего первым запустить сеанс Гостя?

На ХР когда проверял, возникла проблема, но сейчас до меня дошло, что это мог я сам накосячить. Перепроверю позже.

Запускать "не своё" нужды нет. Пока проблем в работе моей связки не обнаружил, буду считать, что все удачно "прокатило"  Тестирование на нескольких сотнях компов покажет, хватает ли этого кода...

Спасибо за ответы, kami!

Подскажите, пожалуйста, что изменить в моем коде выше, чтобы Программа продолжалась запускаться на рабочем столе активного пользователя, НО с правами родителя (то есть службы)?

а что не так сейчас?
Что говорит по этому поводу ProcessExplorer? (а именно - закладка Security свойств процесса)

Я так понимаю, речь о верхней строке в этой вкладке? Там указан активный пользователь.

Romero, нет, о последней строке в верхнем списке, называется "обязательная метка>чего-то там".
Вот это "чего-то там" может быть "обязательный уровень системы", "средний обязательный уровень" и так далее.
Также достаточно важным является нижний список - установленные процессу привилегии. Ибо даже не будучи запущенным "от системы", но имея нужную привилегию, можно выполнить достаточно многое (но не всё, как пример - WTSQueryUserToken, рассмотренный ранее). Какая привилегия нужна - это, само собой - в MSDN.

Добавлено через 1 минуту и 32 секунды
И вообще - почему возникли сомнения, что программа, запущенная на активном десктопе,  не обладает нужными правами?

Там стоит "Integrity".


Как минимум по тому, что у запускаемой службой Программы нет прав писать в Program files - это первое, что заметил. Думаю, это явно говорит, что права от службы не передались.

Поднял свой старый код, вспомнил, почему забросил это дело.
Всё начинается с WTSQueryUserToken.
По какой-то (не выясненной мной) причине, у этого полученного токена в TokenGroups для группы "администраторы" стоит SE_GROUP_USE_FOR_DENY_ONLY. А для работы программы с правами админа, в идеале должно быть значение SE_GROUP_OWNER. Сие (SE_GROUP_USE_FOR_DENY_ONLY) автоматически означает, что права администратора для всего, что будет запускаться под этим токеном будут заблокированы. Установка TokenIntegrityLevel для токена не даст ничего, по причине (опять-таки) блокировки прав доступа.
А теперь - самое интересное - никакими манипуляциями заменить SE_GROUP_USE_FOR_DENY_ONLY на любое другое значение нельзя. Так прописано в MSDN и подтверждено опытами.
Позже выложу код, как пытался это сделать.

Общий вывод: сервису чего-то не хватает для того, чтобы получить primarytoken с правильно установленным значением SID and Attributes для группы "администраторы".


Может, Гуру чего посоветуют...

Это сообщение отредактировал(а) kami - 28.4.2011, 18:42

Почитал про имперсонацию, попробовал после получения токена активного пользователя дать ему права таким образом:

Фокус не прошел. Может, я неправильно понял теорию? 

Смотря что нужно было этим кодом сделать и откуда он вызывается. Это раз. 
Второе - DuplicateToken создает impersonationToken. CreateProcessAsUser требует для работы primary token, который можно получить с помощью DuplicateTokenEx.
Ну и - само собой, если в "исходном" токене нет нужных правов, то в дубликате они не появятся.

Добавлено @ 20:33
ах да, кроме

не помешает добавить TOKEN_EXECUTE

Это сообщение отредактировал(а) kami - 12.5.2011, 20:34

Нужно передать привилегии вызывающего процесса (службы, запущенной под системной учеткой). Вызывается после получения юзерского токена, перед вызовом CreateProcessAsUser.
Вот про различие токенов я и не разобрался, попробую сегодня DuplicateTokenEx, спасибо.
В исходном токене, я надеюсь, все нужные права будут при таком подходе:

где hToken - токен активного юзера, sysToken - токен службы, запущенной от имени системы.
Результат - приложение запускается на рабочем столе юзера, но и с его правами (проверяю попыткой записи в системную директорию).
Где-то что-то не докрутил еще...