named-pipes

Why are pipes considered dangerous to use? What can be done to avoid these security issues? I'm mostly interested in Windows, but if you have other OS information, please provide. (assuming you're talking about Unix named pipes from the mention of 'c' and 'IPC'. Windows named pipes work somewhat differently) Anyone with permissions can write to a named pipe, so you have to be careful with permissions and locking (see flock() ). If an application trusts the input it's getting from the named pipe (which will usually be the case unless you explicitly build input validation into it) then a

UPDATE: Looking through the protocol here , I can't figure out what goes into the Unsized Envelope Record. I can't find any examples online. ORIGINAL: I have the following WCF service static void Main(string[] args) { var inst = new PlusFiver(); using (ServiceHost host = new ServiceHost(inst, new Uri[] { new Uri("net.pipe://localhost") })) { host.AddServiceEndpoint(typeof(IPlusFive), new NetNamedPipeBinding(NetNamedPipeSecurityMode.None), "PipePlusFive"); host.Open(); Console.WriteLine("Service is Available. Press enter to exit."); Console.ReadLine(); host.Close(); } } [ServiceContract] public

I use a named pipe and I want to reuse the same pipe on the server to allow connecting another client once the original client has disconnected. What I do is: server creates a pipe using CreateNamedPipe server writes data using WriteFile , and retries doing so as long as error ERROR_PIPE_LISTENING is returned (which is before any client is connected) clients connects using CreateFile client reads data client close pipe handle using CloseHandle at this point server gets error ERROR_NO_DATA when it attemps to write more data server disconnects the pipe using DisconnectNamedPipe , which I hoped

I have inherited a 20-year-old interactive command-line unix application that is no longer supported by its vendor. We need to automate some tasks in this application. The most troublesome of these is creating thousands of new records with slightly different parameters (e.g. different identifiers, different names). The records have to be created in sequence, one at a time, which would take many months (and therefore dollars) to do manually. In most cases, creating a record has a very predictable pattern of keying in commands, reading responses, keying in further commands, etc. However, some

I need to find a way to be notified when a System.IO.Pipe.NamedPipeServerStream opened in asynchronous mode has more data available for reading on it- a WaitHandle would be ideal. I cannot simply use BeginRead() to obtain such a handle because it's possible that i might be signaled by another thread which wants to write to the pipe- so I have to release the lock on the pipe and wait for the write to be complete, and NamedPipeServerStream doesnt have a CancelAsync method. I also tried calling BeginRead(), then calling the win32 function CancelIO on the pipe if the thread gets signaled, but I

I would like to know if netNamedPipeBinding is considered safe: On one hand NetNamedPipeBinding implements security only on the transport Layer and it uses NTLM ( source ) that is no longer recommended by Microsoft ( source ) On the other hand the Named Pipie is not accessible from a remote computer, and there is no way to eavesdrop on a particular open pipe instance being used to transfer data, or write data to it, unless one can obtain the handle to the specific instance concerned. This is the reason why I don't know what to think about the security of this solution. Chris Dickson You are