Unix Technical Digest V1 #22
Ron Heiby (The Moderator)
unix-request at cbosgd.UUCP
Thu Mar 14 14:05:01 AEST 1985
Unix Technical Digest Thu, 14 Mar 85 Volume 1 : Issue 22
Today's Topics:
protect tape access (3 msgs)
Summary of books on Unix systems programming
system will not shutdown (2 msgs)
----------------------------------------------------------------------
Date: 7 Feb 85 14:04:25 GMT
From: jle at ncsu.UUCP (Jamie Evans)
Subject: protect tape access
Does anyone have a neat way by which a tape drive is
protected from use by anyone else other that the user who has
mounted the tape? Since we are in a university environment,
often a student has mounted a tape to write on and someone else,
thinking that the tape was their's, has written over the tape.
We have a 780 running 4.2 with a ancient TE16 tape drive. I was
wondering if someone else had encountered this problem, and had
a nice solution.
Please mail responses, do not post them to the net.
-Jamie Evans-
decvax!mcnc!ncsu!jle
mcnc!ncsu!jle
------------------------------
Date: 11 Feb 85 21:28:53 GMT
From: BostonU SysMgr <root%bostonu.csnet at csnet-relay.arpa>
Subject: protect tape access
I started to put one in my system, tell me if you
find one but my scheme went like this:
create a psuedo-user 'free' (or some such)
free owns the tape drive (owner/group)
make a tapealloc command called something which
is setuid. It chowns the tape drive and forks a
sub-shell. When the subshell exits it returns it
to 'free'. The reason for the subshell is that
any attempt to log out (eg. hanging up a phone)
will free up the tape drive again (you may have
to play with signals in tapealloc but it is straightforward.)
The major problem is: The subshell method could make a
few things awkward but this is not an unusual constraint
and a user could still 'hog' a tape drive although at
least now a 'ls -l /dev/?mt*' lists who is using what.
Also, you will have to chown some set of devices
(eg, /dev/mt0, /dev/rmt0, /dev/mt8 etc on 4.2bsd)
but this is still reasonable.
-Barry Shein
[oh yeah, make sure you do your setuids correctly before
forking that (setuid'd) subshell.]
------------------------------
Date: 12 Feb 85 00:47:27 GMT
From: Doug Gwyn (VLD/VMB) <gwyn at Brl-Vld.ARPA>
Subject: protect tape access
One doesn't need a subshell nor a hack to "init" if he arranges for
borrowed devices to be reclaimed by the allocator when appropriate.
------------------------------
Date: 15 Feb 85 18:01:14 GMT
From: gregbo at houxm.UUCP (Greg Skinner)
Subject: Summary of books on Unix systems programming
Here are the responses I got for my question re: looking for books where Unix
systems programming is discussed.
---------
The Independant UNIX Bookstore (somewhere in Calif.) rates
McGilton and Morgan's introduction to UNIX as its top seller.
I forget the exact title, they all sound pretty much alike,
I have seen the book and it seems both comprehensive and easy
to read.
---------
There is quite a nice book called "Operating Systems: The Xinu Approach"
(I can't remember the author's name offhand) that gives quite a nice
guide to the internals of a unix type operating system with examples
of some of the more obscure system things used in unix.
---------
The UNIX Programming Environment by Kernighan and Pike.
---------
I'd suggest you start with `The UNIX Programming Environment' by Kernighan
and Pike. It goes into some of these topics. After that, try book by
Kaare Christian (The UNIX Operating System, Wiley-Interscience) which gives
some detail on how the system works. After that, go to the source code
and wade in... [I liked this comment the best ... seems like you wind up doing
that most of the time, anyway --gregbo]
---------
All comments were much appreciated.
--
Greg Skinner (gregbo)
{allegra,cbosgd,ihnp4}!houxm!gregbo
------------------------------
Date: 14 Feb 85 21:23:00 GMT
From: jcc at siemens.UUCP
Subject: system will not shutdown
We seem to be having a problem with /etc/shutdown. To shut
the system down, I usually use the command:
/etc/shutdown -h +5 "comment"
Shutdown starts, gives back its pid number, then just hangs there
forever. A "ps" of the pid shows the state "I <". Has anyone
else had this problem? Is /etc/shutdown waiting for a resource it
can not get? As always, all suggestions or comments are welcomed.
Thank you,
Joe Camaratta
princeton!siemens!jcc
------------------------------
Date: 17 Feb 85 04:18:56 GMT
From: chuqui at nsc.UUCP (Chuq Von Rospach)
Subject: system will not shutdown
I've seen this occasionally. What seems to be happening is that the 'wall'
that shutdown does hangs on a terminal for some reason and doesn't ever
complete, and the shutdown never moves beyond that. I'm not sure why it
should hang on the wall (^Q?) and I've never been motivated to find it--
that is what 'kill 1 1' is for...
chuq
--
>From left field, near the warning track: Chuq Von Rospach
{cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui at decwrl.ARPA
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / ihnp4!{wnuxa!heiby|wnuxb!netnews}
AT&T Information Systems, Inc.
Lisle, IL (CU-D21)
More information about the Mod.unix
mailing list