scjones@sdrc.UUCP (Larry Jones) (09/19/89)
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 it looks like this would be a perfect solution to a nasty problem I have, I was wondering if ANYONE knows how to use this device? I tried the obvious, opening the device, forking, writing from one process and reading from the other, but the read returns an error (EIO). The write does seem to work OK, though. From reading all the STREAMS related stuff I could get my hands on, my suspicion is that I need to open two different streams to the device and then use some obscure ioctl to link them together, but the details elude me. Can anyone help? ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC scjones@SDRC.UU.NET 2000 Eastman Dr. BIX: ltl Milford, OH 45150-2789 AT&T: (513) 576-2070 "I have plenty of good sense. I just choose to ignore it." -Calvin
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (09/19/89)
In article <812@sdrc.UUCP>, scjones@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@ulysses.att.com