Здравствуйте -lexa-, Вы писали:
AF>>А если в этот момент нет интерактивного пользователя? А если их несколько, подключенных через через Terminal services? Уж сколько раз твердили миру, не дело показывать UI из сервера...
L>На счет интерактивного пользователя — он точно есть в этот момент. Просто в силу уже реализованного до меня один и тот же сервис используется как DCOM сервер и сервис в обычном понимании.
Значит, пришло время их разделить.
L>Той части которая работает с GUI юзер в Logon не нужен — достаточно LocalSytem а для корректной работы DCOM в Log on Local System использоваться не может ... если не включать на компе сервере NULL сессии что может пагубно как я понял отразиться на безопасности...
Честно говоря, ничего не понял из выше сказанного. DCOM сам по себе прекрасно работает в LocalSystem и NULL сессии тут не при чем. Похоже, вы из сервиса пытаетесь обращаться к сетевым ресурсам, тогда действительно, из LocalSystem это работать не будет.
AF>>1. Зарегистрируй сервис как интерактивный (SERVICE_INTERACTIVE_PROCESS)
L>данное возможно по моим данным только при работе с Logon LocalSystem т.е. данный флаг при регистрации образно говоря выставляет соответствующую галочку в свойствах сервиса
Естественно.
AF>>2. Скачай http://www.alexfedotov.com/samples/svcui.zip и посмотри как устроена функция ThreadInteract. Вызов MessageBox замени на свой диалог.
L>Пример скачал... код метода ThreadInteract очень похож на мой неработающий и на тот что я находил в MSDN....
L>В Вашем коде на сколько я понял полностью отсутствует код связанный с инперсонализацией... поэтому вероятно данный пример не работает с юзерами в Log on отличными от LocalHost.
Этот метод тоже будет работать только в LocalSystem. Фактически, чтобы показать UI сервис должен выполняться в LocalSystem или в контексте интерактивного пользователя, в противном случае у него просто нет необходимых прав доступа к рабочему столу интерактивного пользователя.
L>Меня же интересовали именно механизмы инперсонализации....
Да, есть такой способ. Подразумевается, что какая-то программа, выполняющаяся в контексте интерактивного пользователя, вызывает сервис, используя named pipes, RPC или COM. Обрабатывая этот вызов, сервис имперсонирует клиента и таким образом получает доступ к рабочему столу. Но вызов должен исходить от интерактивного пользователя, что, насколько я понимаю, в ваших экспериментах было не так.
