Re: problem with pipes IPC
- From: Janma <rohitku@xxxxxxxxx>
- Date: Thu, 26 Feb 2009 03:01:43 -0800 (PST)
Thanks Joe.. I solved this problem by using separate pipes for
different accounts since having multiple pipes wont be an overhead.
On Feb 26, 2:52 am, Joseph M. Newcomer <newco...@xxxxxxxxxxxx> wrote:
Several issues, see below...
On Wed, 25 Feb 2009 03:16:08 -0800 (PST), Janma <rohi...@xxxxxxxxx> wrote:
I have created a named pipe for an admin user in the following way.
HANDLE hPipe = CreateNamedPipe(
g_TrayPipe, // pipe name
PIPE_ACCESS_INBOUND, // read/write access
****
The comment is inconsistent with the access actually specified.
****> PIPE_TYPE_MESSAGE | // message type pipe
****
Message pipes have strange behavior sometimes. Do you really want to do this? I've found
PIPE_TYPE_BYTE to be a safer choice.
****> PIPE_READMODE_MESSAGE | // message-read mode
PIPE_WAIT, // blocking mode
PIPE_UNLIMITED_INSTANCES, // max. instances
BUFSIZE, // output buffer size
BUFSIZE, // input buffer size
NMPWAIT_USE_DEFAULT_WAIT, // client time-out
NULL); // default security attribute
if (INVALID_HANDLE_VALUE == hPipe)
{
CloseHandle(hPipe);
****
Why are you attempting close an invalid handle? This will cause your program to crash
with an uncaught exception (I think it is 8 or 9). Note that this exception is not
documented.
****> return;
}
Now if i log off admin user and step into a non-admin and try to
create the pipe it works fine. But if i do a switch user and go from
admin to non-admin, then non-admin user cannot create pipe with the
same name.
****
This is probably an issue of security. You would be attempting to create a pipe with
different security properties, so the ability to connect to the pipe or not would depend
on which particular pipe instance was connected to. The documentation says nothing about
this, but I suspect that is the problem. You would not be allowed to create two pipes of
the same name with different security properties, which is what is happening. Otherwise,
the non-admin account could spoof an administrative account by creating a pipe of the same
name. You should probably treat this as an unresolvable situation, and not try to create
a pipe unless you specify an identical security token (rather than NULL, for default
security) at both creations.
****
****>This is understood as the admin user's pipe is open waiting for
connection. Here the pipe is working as global.
My requirement is that i want the pipe to work as a local one just as
we can do for a mutex.
****
Unfortunately, pipes don't work that way. Named pipes are by definition always global and
visible to everyone who has access to the machine (whether or not remote users can connect
is based on the security set, but that's a different issue). So you can't create a "local
pipe" because the name is inherently global.
Mutexes exist in the local session namespace, and that is a completely different
mechanism, not shared with named pipes.
There are rather complex mechanisms you can create using anonymous pipes, wherein the
client contacts via a PostMessage the server (which must be running on the same machine,
in the same desktop, that is, not as a system service) and gives a window handle to
receive replies, and its process ID; then the server creates a duplicate handle in the
process, and does a PostMessage to notify the client what the handle is. Then ordinary
anonymous pipe transactions can occur. This is a bit clumsy, but its the only workaround
I can think of at the moment.
joe
****
Thanks,
Rohit
Joseph M. Newcomer [MVP]
email: newco...@xxxxxxxxxxxx
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm
.
- References:
- problem with pipes IPC
- From: Janma
- Re: problem with pipes IPC
- From: Joseph M . Newcomer
- problem with pipes IPC
- Prev by Date: Re: Resource ID question
- Next by Date: Re: Removing visible border from Dialog with Menu
- Previous by thread: Re: problem with pipes IPC
- Next by thread: Font color
- Index(es):
Relevant Pages
|
Loading
