Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: scs@lokkur.dexter.mi.us (Steve Simmons)
Newsgroups: comp.sys.sun
Subject: Re: Tape drive securiry
Keywords: SunOS
Message-ID: <1334@lokkur.UUCP>
Date: 5 May 89 19:16:39 GMT
References: <8904032031.AA03691@helios>
Sender: usenet@rice.edu
Organization: Inland Sea Software, Ltd.
Lines: 43
Approved: Sun-Spots@rice.edu
Original-Date: 22 Apr 89 18:18:16 GMT
X-Sun-Spots-Digest: Volume 7, Issue 268, message 6 of 21

root%helios.UCSC.EDU@ucscc.ucsc.edu (De Clarke Sys Mgr) writes:
>X-Sun-Spots-Digest: Volume 7, Issue 238, message 12 of 14
> . . .  U**x does not provide, as far as this
>neophyte knows, an equivalent to the VMS ALLOCATE command, which allocates
>a device to a user.  When B has mounted a tape on /dev/rmt* . . . A
>can write on it.  Also,  . . . has no way of finding whose that tape is . . .
>
>Now, all you U**x fans tell me there ain't nothing VMS can do that U**x
>can't do (sometimes better);  and often enough you have been right.  How
>do we solve this one?

It doesn't even take a daemon, you can do it with rsh for the local/remote
stuff.  No, I haven't written one.  But I *did* design one, and here's
how it was going to work:

A suid command would be used, called (not by coincidence) tape_allocate.
Give the command 'tape_allocate rmt0', and it would go thru the following
sequence:

Look for the lock file.  If not found, create it.  Write into the
lock file the user's login id, system, and PID.  Now change the ownership
of the tape file (/dev/rmt0) to the user.  Change the mode to 600.  Now
the user has exclusive use of the tape drive.

Lock file names are very carefully selected so all logical devices
which reflect the same physical device map together.

The most difficult piece (conceptually) was how to deal with users
who walk away and forget to unallocate the drive.  Here's the sequence
that solves the problem.  When a lock is found, the contents are
read.  A 'rsh system kill 0 pid' is done to see if the remote user
is still active (note this requires suid execution on the remote
system).  If the user PID is no longer active, the lock is blasted
and given to the new user.  If it is active, the name and system of
lock holder is printed so you can call/talk and see if he's still
really using it.

And if you get around to writing this little jewel, please post!  :-)

-- 
+ Steve Simmons, Inland Sea Software, Ltd.         scs@lokkur.dexter.mi.us +
|    9353 Hidden Lake, Dexter, MI. 48130                   313-426-8981    |
+          "When Dexter's on the Internet can Hell be far behind?"         +