Stream Pipes

[Steven M. Bellovin]

In article <812 at sdrc.UUCP>, scjones at sdrc.UUCP (Larry Jones) writes:
> On my Microport System V/386 and a number of other versions of
> System V that I've checked, there is a "stream pipe" device
> driver (sp) and a single node in the file system (/dev/spx) which
> is a clone device interface to it.  HOWEVER, there is NO MAN PAGE
> which describes how to use the danged thing.

Since this is about the 3rd or 4th time I've answered this question,
I'll post my reply this time instead of emailing it.  A few
disclaimers first, though:  (a) nothing I say is the official opinion
of AT&T, etc.;  (b) none of this will be relevant in SVR4, which has
real stream pipes;  (c) it's possible that /dev/spx will even go away
in SVR4 -- I just don't know;  (d) there's some chance that making this facility
available will open up security holes -- more on that later.

When you open /dev/spx, two things happen.  First, /dev/spx is supposed
to be configured to point to the clone driver; thus, each open of it gets
an unused channel.  Second, each such channel is a *half-pipe* -- it just
has a path down into the kernel; it's not tied to anything else.  The
two halves are linked together via the I_FDINSERT ioctl(), one of the
more baroque (not to say downright bizarre) operators available.  At
that point, you have a fully-functional stream pipe.  This whole process
is usually encapsulated into a single routine spipe(), of course.
And in fact, it's already been done for you -- there's an spipe() routine
in one of the RFS libraries -- libns.a last time I checked.

There are weirder things you can do, too.  For example, if you're running
as root, you can use fstat() and mknod() to create a named version of
the particular channel you're using, providing you with a stream version
of a FIFO.  If you observe a careful protocol with I_SENDFD and I_RECVFD,
you can implement a channel-per-connection.  I discussed some of these
things in my paper on the tty session manager at the summer '88 (San
Francisco) Usenix; see it for details.

Now the security warning...  Since /dev/spx was a special-purpose feature
put in to support RFS, and was not intended for use by ordinary users,
/dev/spx is not normally world-accessible.  (I don't remember if it was
644 or 600, but since at least one half has to be opened for write that
doesn't matter much.)  As far as I know, no one -- including me -- has
done any analysis to see if RFS security is compromised by this.  For
that matter, I won't warrant that the driver is robust against weird
things being written to it, or against odd failure modes.  It is quite
conceivable that malicious users can use it to crash the system.

		--Steve Bellovin
		smb at ulysses.att.com