netnews@wnuxb.UUCP (Heiby) (04/24/85)
Unix Technical Digest Wed, 24 Apr 85 Volume 1 : Issue 45
Today's Topics:
4.2 quirks...
unix quirks (chmod 000 dir) (2 msgs)
4.2 Request - readonly ROOT filesystem (2 msgs)
Anyone fixed this bug in 4.2BSD dump/restore?
killing idle processes
Safe version of system(3) call.
TERMCAPs extensions...
Unkillable processes
----------------------------------------------------------------------
Date: 10 Apr 85 13:38:58 GMT
From: argv@ucb-vax.ARPA
Subject: 4.2 quirks...
% mkdir foo
% chmod 000 foo
% cd foo
foo: no such file or directory
% WHAT?
no match.
% touch bar
% chmod 777 bar
% bar
at this point, my .csrhc is being sourced... and after that, it sits there..
shouldn't it only exec a csh if the first char is a #? That's what it says
in OUR manual.
Next fun item:
#!/bin/csh -f
echo -n "Go: "
set foo = $<
if ($foo =~ *\ *) echo true
echo done
This simple little ditty is supposed to check to see if there exists
a space in the variable "foo" that got it's value from the keyboard.
If there is no space, everything is fine -- it doesn't satisfy the
expression. If there IS a space, we get:
if: expression syntax.
fooey.
I found I had to enclose $foo in double quotes in order for the
expression to work. And it does.
Can someone please explain to me what shell script does with strings
so that this is necessary?
--
Dan Heller (aka Frank)
UUCP: ucbvax!ucscc!argv {ihnp4,sun,cbosgd,decwrl}!qubix!ucscc!argv
ARPA: argv%ucscc.uucp@ucb-vax.arpa
CSnet: c.argv@ucsc.csnet
------------------------------
Date: 13 Apr 85 07:36:44 GMT
From: argv@ucb-vax.ARPA
Subject: unix quirks (chmod 000 dir)
>>% mkdir foo
>>% chmod 000 foo
>>% cd foo
>>foo: no such file or directory
>>% WHAT?
>>no match.
>I assume you are surprised by by the fact that shutting off the
>permissions to a directory you own makes it impossible for you
>to change to it. That's not a quirk, that's a bona-fide feature.
>What else could turning off your own permissions mean? Why have
>them? I personally find this a real plus under UNIX in general,
>it's *nice* to be able to protect me from me as usually my files
>are in the gravest danger from *me*.
You don't seem to understand: it shouldn't say: "no such file or directory",
it should say: "Permission denied." The example, was just that, an example.
This "bug" appears all the time whenever the permission is denied, it comes
up with the wrong error message! Try to cd into a path that you never had
any problems with and it says that it doesn't even EXIST. Then you panic and
call the system administrator and request a back up recovery and spend a
lot of time and effort (sometimes even money) to get a directory replaced
that never even went away. I just want the correct error message. Is this
clear now?
--
Dan Heller (aka Frank)
UUCP: ucbvax!ucscc!argv {ihnp4,sun,cbosgd,decwrl}!qubix!ucscc!argv
ARPA: argv%ucscc.uucp@ucb-vax.arpa
CSnet: c.argv@ucsc.csnet
------------------------------
Date: 21 Apr 85 18:56:17 GMT
From: mike@whuxl.UUCP (BALDWIN)
Subject: unix quirks (chmod 000 dir)
>You don't seem to understand: it shouldn't say: "no such file or directory",
>it should say: "Permission denied." The example, was just that, an example.
Sorry, folks, but the REAL answer to this is the cdpath variable. If it can't
chdir somewhere, csh will go down $cdpath, and the error message you end up
getting is that of the LAST component in cdpath:
% mkdir rc
% chmod 0 rc
% set cdpath = (. /etc)
% cd rc
rc: Not a directory
% set cdpath = (/etc .)
% cd rc
rc: Permission denied
If cdpath is unset, you will always get the "right" error message.
--
Michael Baldwin
AT&T Bell Labs
harpo!whuxl!mike
------------------------------
Date: 16 Apr 85 15:09:50 GMT
From: lazear@mitre.ARPA (Walt Lazear)
Subject: 4.2 Request - readonly ROOT filesystem
The Air Force did indeed use a form of read-only root filesystem, as a
strategy to avoid the hassles of integrating software releases into
operational filesystems. All we distributed was a root on which there
should be no lasting changes, so that if it crashed or trashed, you
could read a fresh copy from the distribution tape (we duplicated the
original Bell 'tp' format for distribution tapes).
Two points, however. First, we found we could not mount the root truly
read-only. There are updates to inodes (I forget what, but probably
last accessed times) that must occur, so we lived with a normally mounted
root that could be 'refreshed' at any point by reading in a new copy.
The second point is even more important. IT WAS A LOT OF WORK TO GET THERE!!
The overall scheme was to have the /usr filesystem be where volatile and
site specific stuff resided. As Joe Yao pointed out, that means moving
Bell supplied programs from /usr/bin to /bin, and databases from /etc
(passwd, group, ttys) to /usr/etc. You would be amazed at how incestuous
programs were, even back in V6! One would call another to do certain
functions, and would use an absolute pathname (not unreasonable, since
there were no search rules with exec(2)). All references to /usr/bin
had to be changed to /bin and programs recompiled (before 'make' was
around).
Overall, the effort was worth it. Sites had merely to boot a new root
to activate the software release, they did not have to dump that filesystem
(ever) because they had a copy sitting on the distribution tape, and
their local applications were nicely partitioned from system stuff.
Alas, all this disappeared when they bit the bullet and adopted SysIII and
SysV, but they decided not to be the central distribution center for the
Air Force any longer. Sites should go directly to ATT for software and
support (and to fend for themselves generally).
Sorry to go on so long, but I wanted to indicate that there was merit in
the idea, especially when you might be supporting distant sites (ours were
in Mississippi, Alabama, and Ohio, while we were in the Pentagon in DC)
with inexperienced word processor operators as your system administrators.
Walt (Lazear at MITRE)
------------------------------
Date: 16 Apr 85 21:47:13 GMT
From: ron@BRL-TGR (Ron Natalie)
Subject: 4.2 Request - readonly ROOT filesystem
Our BRL/JHU UNIX systems (which are a hodge podge of various versions of
UNIX) will run with a physically right protected route.
-Ron
------------------------------
Date: 13 Apr 85 17:58:14 GMT
From: grandi@noao.UUCP (Steve Grandi)
Subject: Anyone fixed this bug in 4.2BSD dump/restore?
We have several filesystems set up on our RA81s with block sizes of
8192 and fragment sizes of 2048. When I dump and then restore such
filesystems, lots and lots of "spurious"
resync restore, skipped 1 blocks
error messages appear on the console. Apparently, as we never seem to
lose any data, there is a bug in dump that adds an extra tape block at
the end of each inode's dump causing restore to complain when it is
looking for header record.
Has anyone deduced the fix for this bug? My quick perusal of the dump
code was not very productive. We currently have a real flaky RA81 drive
(that's another story!!) and I'm getting real tired of having my
restores slowed to a crawl waiting for the console to print all the
"resync" messages. I can always ctrl-O the output, but then any
useful messages are also lost.
--
Steve Grandi, National Optical Astronomy Observatories, Tucson, AZ, 602-325-9228
{arizona,decvax,hao,ihnp4,seismo}!noao!grandi noao!grandi@lbl-csam.ARPA
------------------------------
Date: 17 Apr 85 18:29:28 GMT
From: ables@mcc-db.UUCP (King Ables)
Subject: killing idle processes
Well, as promised (and as so few people do) here is a summary
of what I found out from people's replys to my query about killing
off idle jobs. As it happens, the problem solved itself, but I
am still grateful for those who replied and I intend to keep the
information around in case I need it sometime in the future.
Most people either had made a kernel hack or had a short shell
script that did an effective although perhaps not very clean
(either they could be fooled by an expert, or could make
a mistake in certain situations) kill on idle users.
The suggestions for coming up with a method from scratch
centered around:
1) hacking w or ps (which some people had done)
2) using last mod time of /dev/tty?? as a basis for "idleness,"
then all you have to do is send a HUP signal (SIGHUP) to the
process you want to kill (some said also send a SIGCONT).
3) use the csh 'autologout' feature (honor system)
People who had (and sent me) a program or a set of programs are
listed below. If people think any of these programs should be
posted to net.sources, please contact the originator of the reply
(listed below), not me. I don't think it's my place to post
someone else's code, and this way, we won't chance multiple
postings. If, for some reason, the originator asks me to post it,
I certainly will be glad to.
Raleigh Romine (seismo!romine)
reaper package (programs, makefile, man pages, etc.)
All files total about 18000 characters.
Jim Knutson (ut-sally!ut-ngp!knutson)
killidle.c program - 3944 characters
Andrew M. Rudoff (seismo!hao!nbires!boulder!andy)
hup, tout programs
tout is a timeout program a user can execute from
within .login (honor system) - 1963 characters
hup is an easy hangup program (so you don't have
to look up his PID) - 1323 characters
Jim Palmer (nbires!utopia!palmer)
jaws package (program and 6 awk scripts) - total of
about 1500 characters
Rick Auricchio (seismo!nsc!cadtec!rick) has a program called gr.c
(grim reaper) which he did not send, but said he might want to post
if there is enough interest.
The following are comments that I felt warranted exposure for some
reason:
Bjorn Eriksen (seismo!mcvax!enea!ber)
> I have a modified version of 'ps' called 'idle' that is run from
> crontab and loggs people off after a specified time (given as an
> option to idle). It checks if people have only the login-shell
> running. If they have other jobs they won't be logged out. It also
> checks a list of "trusted users" that shouldn't be killed.
> It's for 4.2BSD.
Doug Gwyn (gwyn@BRL-TGR.ARPA)
> There is NO way of knowing whether a user is really asleep or not.
> Some of our 5620 DMD users make no demands on the host for hours,
> but they DO need the line left open.
Dick Dramstad (rad@Mitre-Bedford.ARPA)
> We're using a modified csh here which has as one of its added
> features an "autologout" setting. The "newcsh" was done by Ken Greer
> (?lately? of HP Labs), and includes Tenex-style command and filename
> completion, history saving across login sessions, and an idle-time
> autologout.
>
> His implementation allows the user to set the idle time length or
> unset it completely (it's just a shell variable that's used), but you
> could make it mandatory if you wanted. It only works when the user is
> idle at the shell command level, not when they're idle in some other
> program, such as an editor, but we've noticed that when users walk
> away from their terminal they're usually at the shell level anyway.
>
> Implementation is (almost) trivial; add an alarm(60*idlelimit)
> call in the csh after a command completion, an alarm(0) call just
> before the fork for a command exec, and set up an interrupt handling
> routine for the alarm signal which would do the usual logout stuff.
Also thanks to others who replied whose comments were genericly included:
seismo!noao!terak!asuvax!mot!fred
Dave Harrison (ihnp4!utcs!utfyzx!harrison)
Richard G. Bubenik (seismo!wucs!rick)
Dan Messinger (ihnp4!umn-cs!digi-g!dan)
Greg Woods (nbires!hao!woods)
------
-King
ARPA: ables@mcc
UUCP: {ihnp4,seismo,ctvax}!ut-sally!mcc-db!ables
------------------------------
Date: 21 Apr 85 01:44:12 GMT
From: karsh@geowhiz.UUCP (Bruce Karsh)
Subject: Safe version of system(3) call.
If you call the system(3) service from a program that is
setuid'ed to root, the argument of the call runs with root
privleges. I wrote a protected version of system(3) that
I think is secure, and does what you would expect. Is this
really secure, does it really do what one would expect, and
is this really the best way to do it? I'd appreciate any
comments.
For the record, we are running System III on a Masscomp.
It would be nice if this routine didn't care which flavor
of UN*X it ran on.
safesystem(string)
char *string;
{
int status,pid;
pid=fork();
if(pid == 0)
{
setuid(getuid());
system(string);
}
else
{
while (wait(&status) != pid) ;
}
}
--
Bruce Karsh, U. Wisc. Dept. Geology and Geophysics,
1215 W Dayton, Madison, WI 53706 -- (608) 262-1697
{ihnp4,seismo}!uwvax!geowhiz!karsh
------------------------------
Date: 12 Apr 85 21:12:47 GMT
From: wcs@ho95b.UUCP (Bill Stewart)
Subject: TERMCAPs extensions...
Barry Shein at BU asked if there was some way to inform TERMCAP and
similar programs about different window sizes, for terminals that
support multiple windows, and suggested environment variables as one approach.
System V Release 2 and the Teletype 5620 terminal provide some
support for this. (The 5620 is the production equivalent of the
BLIT bitmapped graphics terminal.) The TERMINFO version of curses
recognizes the variables LINES and COLUMNS as the dimensions of the
window, and can optionally be compiled to try using the 5620/blit
ioctl to check window size. This means that any programs using
libcurses.a can know how big windows are (if they bother to ask
curses instead of wiring in 24x80), and for programs that don't
need curses but just want a screen width (e.g. ls -C), the variables
are available.
Some of the terminal emulation programs that run on
the 5620 will automatically set and export the LINES and COLUMNS
variables whenever the window size changes; "emacsterm" exports
these, plus TERMCAP, TERM, and TERMINFO so that anything
screen-oriented gets the right information. This approach is useful
in a remote execution environment, where the program can't always DO
an ioctl to the real device, especially if you can pass environment
variables.
Bill Stewart, ihnp4!ho95c!wcs at AT&T Bell Labs.
------------------------------
Date: 18 Apr 85 16:05:30 GMT
From: mrl@drutx.UUCP (LongoMR)
Subject: Unkillable processes
I have seen several times in the past years, processes which cannot
be killed on UNIX. I have been told that one of two things can be
happening. One, the process is waiting on a non-existant wait channel, or
two, the process is running with a negative priority level. This seems
to happen at random on random processes. Has anyone else seen this and,
if so, how is the problem handled?
Mark Longo AT&T ISL Denver
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / netnews@wnuxb.UUCP | unix-request@cbosgd.UUCP
AT&T Information Systems, Inc., Lisle, IL (CU-D21)