Why are pipes considered dangerous to use in Windows/unix/linux?

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.

From stackoverflow

• (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 malicious user can write any desired data into the named pipe if they have permission.

  Also, any user with permissions can read from the pipe and intercept data coming out of it if you have not exclusively locked it. The data is then missing from the input stream that the reader is expecting.

  James Curran : But doesn't this just boil down to "people with permission can do bad things", which is true with every OS feature?

  Adam Bellaire : That's true, but I think the most obvious failure case is having multiple processes running under the same user. They will all have the same permissions and access to the pipe, so you have to manage that access to prevent race conditions. e.g. TCP sockets, by contrast, are process-to-process.

  ConcernedOfTunbridgeWells : The main reason (and this apples to Windows named pipes to some extent as well) is that the pipes live in a public namespace, whereas sockets are private once a connection is established (assuming the TCP stream itself is not hijacked).