| |||||||||||||
What's the problem?What's the problem?Posted Oct 28, 2010 11:49 UTC (Thu) by michaeljt (subscriber, #39183)In reply to: What's the problem? by neilbrown Parent article: Ghosts of Unix Past: a historical search for design patterns
> I imagine that if you already had a pipe between two processes (possible using a named pipe in the filesystem) then one process could:
> > openat(pipefd, NULL, flags); > >and the other process could notice (via a poll() message) and > > accept(pipefd, ....) > >and they would each get an end of a (optionally bi-directional) pipe. This pipe would be private to the two, in contrast to the named pipe which is shared by every process that opens it.
Pardon me if I am being dense here, but isn't that roughly what Unix domain sockets do?
> If you really wanted to pass a file descriptor, you then 'splice' the file descriptor that you to pass onto the pipe. That gives the other end direct access to your file descriptor.
If we are talking about something accessible through the filesystem then surely either a process is allowed to open it (in which case they can be given permissions to do so) or they are not (in which case, well, they shouldn't be). I know there are edge cases like processes which grab a resource and drop privileges, but in that case permission to access the resource is tied to the fact that only a given process binary will manipulate it, and I don't know if you really gain much through passing it through a pipe or a socket instead, as you would need to add lots of extra security checks anyway to be sure you were really talking to that binary (so to speak).
(Log in to post comments)
What's the problem? Posted Oct 28, 2010 14:35 UTC (Thu) by nix (subscriber, #2304) [Link]
Yes, this is just like Unix-domain sockets. Neil's point is that the Unix-domain socket API is needlessly clumsy for this application: his proposed API would be much better (only nobody would use it for years if implemented, because it's Linux-specific).
|
|||||||||||||