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

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

L>>Хм, Inproc-server удаленно вообще никак нельзя запустить, т.ч. проблема его защиты вообще лишена смысла.

KS>Inproc сервер реально запускается именно DLLHOST'ом. Это понятно. Почему же защита лишена смысла? Ведь, если не устанавливать ограничений, любой может вызвать CoCreateInstanceEx?

Если это понятно, то зачем говорить про In-proc server? Так бы и говорил, что есть Outproc-server, на который и ставится защита через Dcomcnfg.

KS>>>>>Еще один вариант. Service запускается под именем domain\admin. На Comp2 делаем расшаренный каталог \\Comp2\sharedDir\, в котором расположен file.txt, на который имеет права _только_ domain\admin. Перед открытием файла \\Comp2\sharedDir\file.txt Service имперсонируется под именем domain\user, прав на этот файл не имеющий. И все равно открытие файла происходит нормально!

L>>Здесь ровно та же самая ситуация, что и с запуском удаленного сервера. Обращение к сетевому диску происходит под тем юзером, под которым запущен сервис, а не под имперсонированным, со всеми вытекающими последствиями. Почему это происходит именно так — я уже написал ранее.

KS>Уважаемый Lexey, что-то здесь не то. Если бы то, что вы написали, было верно, не работала бы следующая ситуация:
KS>Service на Comp1 работает под системным эккаунтом.
KS>Service имперсонируется под именем domain\admin и пытается получить доуступ к файлам а расшаренном каталоге на Comp2.
KS>Это проходит! Если бы "Обращение к сетевому диску происходило под тем юзером, под которым запущен сервис", то это не работало бы, а это работает.

Вот тут я уже ничего не понимаю. В описанной конструкции это никак не может работать (разве что у domain\admin уже есть установленное соединение с Comp2\ipc$, т.е. его аутентификация на Comp2 уже ранее состоялась — в таком варианте это возможно будет работать).