Xref: utzoo comp.unix.questions:11588 comp.unix.wizards:14586
Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!ukma!tut.cis.ohio-state.edu!ucbvax!ulysses!smb
From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: Inter-machine networking on System V
Message-ID: <11196@ulysses.homer.nj.att.com>
Date: 8 Feb 89 23:07:25 GMT
References: <446@thirdi.UUCP> <11181@ulysses.homer.nj.att.com> <501@gonzo.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 17

In article <501@gonzo.UUCP>, daveb@gonzo.UUCP (Dave Brower) writes:
> (Actually, a /dev/spx "stream pipe" sometimes exists, but it is
> undocumented and unsupported, I think.  It also isn't bidirectional,
> which is annoying).

Yes it is bidirectional; however, it's only a half-pipe.  More precisely,
to create a stream pipe one has to open /dev/spx twice, and issue the
I_FDINSERT on one file descriptor passing down the value of the second
file descriptor.  (Don't blame me, folks; I didn't invent /dev/spx or
the ioctl.)

In the distributed system, /dev/spx is mode 644, I believe; it's certainly
not 666.  I cannot vouch for the security of a system in which /dev/spx is
made generally available; its primary (sole?) purpose is to support parts
of RFS, and it's quite possible that the security of RFS could be compromised
by such a change.  On the other hand, I don't know that such a scenario
is possible; I've never felt the urge to dig that deeply into RFS internals.