Проблемка такая, однако: Named Pipe при использовании между процессами на локальной машине (да еще я и с правами администратора сижу) все работает отлично. На разных машинах работает, ежели на машине-сервере прописать себя как администатора. Но это, разумеется, очень нехорошо. Так вот вопрос: как это все протащить, чтобы можно было... Э-э-э... Даже не знаю, как именно это определить. :(

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

TL>Проблемка такая, однако: Named Pipe при использовании между процессами на локальной машине (да еще я и с правами администратора сижу) все работает отлично. На разных машинах работает, ежели на машине-сервере прописать себя как администатора. Но это, разумеется, очень нехорошо. Так вот вопрос: как это все протащить, чтобы можно было... Э-э-э... Даже не знаю, как именно это определить. :(

В вызов CreateNamedPipe нужно передать security descriptor with NULL DACL. Пример создания такого дескриптора есть в MSDN, ключевые слова для поиска "NULL DACL".

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

AF>Здравствуйте The Lex, Вы писали:

AF>В вызов CreateNamedPipe нужно передать security descriptor with NULL DACL. Пример создания такого дескриптора есть в MSDN, ключевые слова для поиска "NULL DACL".

При несколько более подробном рассмотрении оказалось, что можно связываться по Named Pipe с помощью функции CallNamedPipe(...), как это и делалось ранее, но для этого на машине-сервере должен быть прописан пользователь, под которым запущен клиент на машине-клиенте. Причем просто прописан, и не иметь больше никаких прав. Он должен быть только активирован. Если вход деактивировать — соеденение не происходит.

На этом дальнейшие исследования приостановлены. Работает — и ладно... :)

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

AF>Здравствуйте The Lex, Вы писали:

TL>>Проблемка такая, однако: Named Pipe при использовании между процессами на локальной машине (да еще я и с правами администратора сижу) все работает отлично. На разных машинах работает, ежели на машине-сервере прописать себя как администатора. Но это, разумеется, очень нехорошо. Так вот вопрос: как это все протащить, чтобы можно было... Э-э-э... Даже не знаю, как именно это определить. :(

AF>В вызов CreateNamedPipe нужно передать security descriptor with NULL DACL. Пример создания такого дескриптора есть в MSDN, ключевые слова для поиска "NULL DACL".

Так оно, конечно, работает.
А почему не работают другие методы? Например, я хочу добавить/изменить права доступа для какого-то юзера или группы. Причем уже после того, как Named Pipe создан (клиенты еще не подключались). Для обычного файла я могу это сделать несколькими способами:
1. GetNamedSecurityInfo(), получаю Dacl, на его основе создаю новый с нужными ACE, потом SetNamedSecurityInfo().
2. GetSecurityInfo()/SetSecurityInfo(): аналогично, но через HANDLE нужного файла.
3. GetFileSecurity()/SetFileSecurity().

С файлами все нормально работает. Например, задаю маску GENERIC_READ | GENERIC_WRITE, а потом в обычном Explorer'e смотрю permissions. Все как положено: Special access (RW).

А пробую применять эти функции для Named Pipe, возникают проблемы. Если Named Pipe создан другим процессом, получаю сообщ. "The specified resource name can not be found in the image file".
Если же задаю permissions сразу после вызова CreateNamedPipe в той же программе, то ошибок не возникает. А если из другой программы прочитать эти Permissions, то видно, что они изменились. Но зато когда клиент обращается к такому Pipe (даже локально!), появляется сообщение, что нет свободных экземпляров Pipe (хотя ни одного клиента еще не подключилось).

Еще можно понять (и то — с большой натяжкой), почему не работает GetNamedSecurityInfo. В MSDN написано, что эта ф-я работает с файлами. А про GetSecurityInfo написано, что она работает и с Named Pipes, но на самом деле — не работает: "The specified resource name can not be found in the image file".

Неужели нельзя изменить Permissions после создания Pipe?
Это баг в NT или просто у меня знаний маловато?

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

AF>Здравствуйте The Lex, Вы писали:

TL>>Проблемка такая, однако: Named Pipe при использовании между процессами на локальной машине (да еще я и с правами администратора сижу) все работает отлично. На разных машинах работает, ежели на машине-сервере прописать себя как администатора. Но это, разумеется, очень нехорошо. Так вот вопрос: как это все протащить, чтобы можно было... Э-э-э... Даже не знаю, как именно это определить.

AF>В вызов CreateNamedPipe нужно передать security descriptor with NULL DACL. Пример создания такого дескриптора есть в MSDN, ключевые слова для поиска "NULL DACL".

Тут новый вопрос пришел, я тему перечитал и решил тоже спросить...

Так вот, Вы, Alex, имели в виду при создании Pipe на сервере передать ему security descriptor with NULL DACL? А что это будет означать? Получится (я еще не пробовал эмпирически), что любой пользователь сможет подключиться к этому каналу, так? Я правильно понял?

Если так, то получится, прямо скажем, некоторая дыра в системе безопасности. А это нехорошо.

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

TL>>>Проблемка такая, однако: Named Pipe при использовании между процессами на локальной машине (да еще я и с правами администратора сижу) все работает отлично. На разных машинах работает, ежели на машине-сервере прописать себя как администатора. Но это, разумеется, очень нехорошо. Так вот вопрос: как это все протащить, чтобы можно было... Э-э-э... Даже не знаю, как именно это определить.

AF>>В вызов CreateNamedPipe нужно передать security descriptor with NULL DACL. Пример создания такого дескриптора есть в MSDN, ключевые слова для поиска "NULL DACL".

TL> Тут новый вопрос пришел, я тему перечитал и решил тоже спросить...

TL>Так вот, Вы, Alex, имели в виду при создании Pipe на сервере передать ему security descriptor with NULL DACL? А что это будет означать? Получится (я еще не пробовал эмпирически), что любой пользователь сможет подключиться к этому каналу, так? Я правильно понял?

Да.

TL>Если так, то получится, прямо скажем, некоторая дыра в системе безопасности. А это нехорошо.

Это зависит от того, что вы хотите. Если вы не хотите, чтобы кто угодно мог подключаться, надо настроить DACL более тонко.