Web service can't open named pipe - access denied

Question

Hi All,

I've got a C++ service which provides a named pipe to clients with a NULL SECURITY_ATTRIBUTES as follows:

hPipe = CreateNamedPipe( lpszPipename, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED, PIPE_TYPE_BYTE | PIPE_READMODE_BYTE | PIPE_WAIT, PIPE_UNLIMITED_INSTANCES, BUFSIZE, BUFSIZE, 0, NULL);

There is a dll which uses this pipe to get services.

There is a c# GUI which uses the dll and works fine.

There is a .net web site which also uses this dll (the exact same one on the same PC) but always gets permission denied when it tries to open the pipe.

Any one know why this might happen and how to fix it?

Also does anyone know of a good tutorial on SECURITY_ATTRIBUTES because I haven't understood the msdn info yet.

Thanks, Patrick

Answer 1

Check the kind of authentication in use on the ASP.NET web site, and the impersonation settings in the web.config file for that site. The chances are, the ASP.NET code is running under an account that isn't allowed to create named pipes on your machine.

You might be able to fix it by granting more permissions to the account in use by the ASP.NET app, or by configuring that web app to use a different (more-highly-privileged) account. Having said that, do you really want remote visitors to your web site to be able to create named pipes? I won't lecture you, I presume you've thought about that.

The most approachable, and thorough, description of SECURITY_ATTRIBUTES I've ever seen is in this book by Keith Brown... http://www.amazon.co.uk/gp/product/0201604426.

Answer 2

The default ACL for named pipes (what you get with a null security descriptor) grants write access only to LocalSystem, Administrators, and the pipe's owner/creator. Unless your web application is running under one of those accounts (which by default it would not be) you won't be able to get write access. (I'm assuming you're asking for read/write.)

There are a couple of options...

1. Have the web application run under the same account as the service that created the pipe.

2. Configure the web application to use impersonation, either by specifying a specific user with write access in web.config, or by setting it to use the user passed in by IIS (and accessing the application from a user account with write access).

3. Manually impersonate a user with write access for the duration of the pipe access (e.g., with WindowsIdentity.Impersonate).

4. Use a non-default security descriptor on the pipe that grants write access to Everyone (or the specific account running the application, although that would be more complicated to set up).

There's an example of creating a simple security descriptor here; you should be able to modify it to suit your needs.

Answer 3

Adding the line:

< identity impersonate="true"/>

to the < system.web> section of the web.config file allowed access to the pipe. I wouldn't advise others to use this as I'm not sure of the security implications but it suits our requirements for now.

Thanks to both Eric and Martin for giving me pointers in the right direction.