bzs@bu-cs.bu.edu (Barry Shein) (05/06/89)
From: root%helios.UCSC.EDU@ucscc.ucsc.edu (De Clarke Sys Mgr) >...We have one tape drive on >our 4/280. This is the problem: 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. A simple setuid program which manipulates ownership/permission on the tape drive devices is probably all you need. Something like: create a psuedo-user "free" which owns the tape drive when not in use. Change permissions to something like 600. write a short program which just changes ownership to the user if currently owned by free or back to free when done. you might want to add a few lines to rc.local which, eg, rewinds and unloads any tape mounted on reboot and resets the ownership to user free. How good an idea this is might take some experience. It really shouldn't take more than about a screenful or two of C code. Could be done with shell scripts but setuid shell scripts are fraught with security problems. If you wanted to get fancier you could fork a subshell after setting the tape ownership so any interruption (eg. hanging up) would reset the tape drive, optional and possibly a nuisance (eg. you'd lose your history list.) -Barry Shein, Software Tool & Die There's nothing more terrifying to hardware vendors than satisfied customers.
scs@lokkur.dexter.mi.us (Steve Simmons) (05/06/89)
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?" +