Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!hellgate.utah.edu!helios.ee.lbl.gov!ucsd!brian
From: brian@ucsd.Edu (Brian Kantor)
Newsgroups: comp.unix.wizards
Subject: programmatic devices
Message-ID: <10641@ucsd.Edu>
Date: 28 Dec 89 14:18:51 GMT
Organization: The Avant-Garde of the Now, Ltd.
Lines: 61

I don't have time to write this, but if I had them, I'd use them, so
here it is the idea raw and unfettered....

A programmatic device (pdev) is a program (an executable binary) living
in the /dev directory.  When a user program tries to open it for
reading or writing, a process is started that runs the program, and
ties its stdin and stdout to the user program open.  All I/O to and
from the pdev appears to the user as though it is simply reading and
writing a device; the pdev can open real or pseudo-devices and do real
I/O as appropriate.  Ordinarily, the last close will cause the pdev to
stop running and exit.

The permissions bits would control access just as they do to real files
and devices, SUID and SGID would work, with some redefinitions:

	The owner 'execute' bit means that the pdev is exclusive access;
	as long as one process has the pdev open all others attempting to
	open it will block (or get EWOULDBLOCK).  The group and other
	execute bits are ignored.

	The read or write bits are used as in normal Unix file system
	semantics.  If neither is on for the process requesting the
	open, the pdev process is not started and EACCES is returned.
	An attempt to read or write an open pdev in violation of the
	permissions granted also returns EACCES.

	The 'sticky' bit means that the pdev starts running on the
	first open and does not exit on the last close; the second and
	subsequent opens of the pdev will talk to the same process for
	as long as it stays running.  'sticky' probably implies exclusive
	access, since there is no multiplexing [i.e., all I/O between
	the pdev and the user program is on the pdev's stdin/out].

	The exclusive-access bit in the open system call causes the
	pdev to grant exclusive access (i.e., to behave as though it
	had the owner execute bit on) but only temporarily; when the
	process requesting exclusive access closes the pdev it reverts
	to whatever access the owner execute bit grants.  (I don't see
	a need nor a way for a process to grant multiple access to a pdev
	that the system manager has set up as exclusive.)

I don't know what IOCTLs should do with pdevs.

The applications for this range from expanded security (where the
pdev enforces/allows access to real devices), more complete device
independence (now you can make every modem look like a Hayes),
special interfaces to bizarre devices, etc, etc.  In a way, they're
simple-minded streams without all the streams claptrap.

As I say, I haven't got time to write these.  But it might make a
nice senior project for some real up-and-coming Unix student wizard.
Just be sure to give me credit in the paper.

Oh, and if this isn't an original idea, pardon me.  I honestly can't
remember having heard of this before in the Unix world.  (It is vaguely
reminiscent of the Class-B security procedures in the Burroughs B-6500
et seq, but is much much more general than that was.)

	Brian Kantor	UCSD Network Operations
			UCSD C-024, La Jolla, CA 92093-0124 USA
			brian@ucsd.edu ucsd!brian BRIAN@UCSD