mailer-daemon@lindy.stanford.edu (Mail Delivery Subsystem) (03/20/88)
----- Transcript of session follows -----
>>> RCPT To:<//+@score.stanford.edu>
<<< 550 No such local mailbox as "//+", recipient rejected
550 //+@SCORE.STANFORD.EDU... User unknown
----- Unsent message follows -----
Received: by Forsythe.Stanford.EDU; Sat, 19 Mar 88 12:36:36 PST
Received: by BYUADMIN (Mailer X1.25) id 7070; Sat, 19 Mar 88 13:36:56 MST
Date: Sat, 19 Mar 88 14:00:13 CST
Reply-To: Unix-Wizards@BRL.ARPA
Sender: Unix-Wizards Mailing List <UNIX-WIZ%NDSUVM1.BITNET@Forsythe.Stanford.EDU>
From: Vince Fuller <VAF@score.stanford.edu>
Subject: Obscure UNIX question
X-To: UNIX-WIZARDS@BRL.ARPA, INFO-UNIX@BRL.ARPA
To: "000," <//+@SCORE.STANFORD.EDU>
I am attempting to write an application that will talk to a child process via
a PTY. I want to make this communication as completely half duplex as possible,
e.g. my program sends a command string to the PTY then reads the response and
processes it. Because I do not have control over the format of the output from
the child process and it is safe to assume that it is synchronous (i.e. it
reads its input, generates some output, then reads some more input), I want to
be able to read output from the PTY until the child blocks for input. Is there
any way for me to detect that the child process has done this (blocked for
input)? My groveling about in the UNIX manual pages for pty(4), tty(4), et. al.
hasn't gotten me anywhere. Alternatively, if it is not possible to do what I
want, can someone suggest an alternative method to write this application? In
summary, what I want to do is two step loop in the parent process:
1) Send command to child process by writing on master end of PTY.
2) Read and process child's output by reading from master end of PTY until
child is finished processing the command. The child is considered to be
"finished" when it blocks for input while reading from the slave end of
PTY - this is the state that I need to be able to detect.
Thanks,
Vince Fuller, Stanford Networking Systems
-------
-------mailer-daemon@lindy.stanford.edu (Mail Delivery Subsystem) (03/20/88)
----- Transcript of session follows -----
>>> RCPT To:<//+@score.stanford.edu>
<<< 550 No such local mailbox as "//+", recipient rejected
550 //+@SCORE.STANFORD.EDU... User unknown
----- Unsent message follows -----
Received: by Forsythe.Stanford.EDU; Sat, 19 Mar 88 12:36:40 PST
Received: by BYUADMIN (Mailer X1.25) id 7072; Sat, 19 Mar 88 13:36:56 MST
Date: Sat, 19 Mar 88 14:00:13 CST
Reply-To: Unix-Wizards@BRL.ARPA
Sender: Unix-Wizards Mailing List <UNIX-WIZ%NDSUVM1.BITNET@Forsythe.Stanford.EDU>
From: Vince Fuller <VAF@score.stanford.edu>
Subject: Obscure UNIX question
X-To: UNIX-WIZARDS@BRL.ARPA, INFO-UNIX@BRL.ARPA
To: 0010 <//+@SCORE.STANFORD.EDU>
I am attempting to write an application that will talk to a child process via
a PTY. I want to make this communication as completely half duplex as possible,
e.g. my program sends a command string to the PTY then reads the response and
processes it. Because I do not have control over the format of the output from
the child process and it is safe to assume that it is synchronous (i.e. it
reads its input, generates some output, then reads some more input), I want to
be able to read output from the PTY until the child blocks for input. Is there
any way for me to detect that the child process has done this (blocked for
input)? My groveling about in the UNIX manual pages for pty(4), tty(4), et. al.
hasn't gotten me anywhere. Alternatively, if it is not possible to do what I
want, can someone suggest an alternative method to write this application? In
summary, what I want to do is two step loop in the parent process:
1) Send command to child process by writing on master end of PTY.
2) Read and process child's output by reading from master end of PTY until
child is finished processing the command. The child is considered to be
"finished" when it blocks for input while reading from the slave end of
PTY - this is the state that I need to be able to detect.
Thanks,
Vince Fuller, Stanford Networking Systems
-------
-------mailer-daemon@lindy.stanford.edu (Mail Delivery Subsystem) (03/20/88)
----- Transcript of session follows -----
>>> RCPT To:<//@score.stanford.edu>
<<< 550 No such local mailbox as "//", recipient rejected
550 //@SCORE.STANFORD.EDU... User unknown
----- Unsent message follows -----
Received: by Forsythe.Stanford.EDU; Sat, 19 Mar 88 12:36:31 PST
Received: by BYUADMIN (Mailer X1.25) id 7069; Sat, 19 Mar 88 13:36:55 MST
Date: Sat, 19 Mar 88 14:00:13 CST
Reply-To: Unix-Wizards@BRL.ARPA
Sender: Unix-Wizards Mailing List <UNIX-WIZ%NDSUVM1.BITNET@Forsythe.Stanford.EDU>
From: Vince Fuller <VAF@score.stanford.edu>
Subject: Obscure UNIX question
X-To: UNIX-WIZARDS@BRL.ARPA, INFO-UNIX@BRL.ARPA
To: //@SCORE.STANFORD.EDU
I am attempting to write an application that will talk to a child process via
a PTY. I want to make this communication as completely half duplex as possible,
e.g. my program sends a command string to the PTY then reads the response and
processes it. Because I do not have control over the format of the output from
the child process and it is safe to assume that it is synchronous (i.e. it
reads its input, generates some output, then reads some more input), I want to
be able to read output from the PTY until the child blocks for input. Is there
any way for me to detect that the child process has done this (blocked for
input)? My groveling about in the UNIX manual pages for pty(4), tty(4), et. al.
hasn't gotten me anywhere. Alternatively, if it is not possible to do what I
want, can someone suggest an alternative method to write this application? In
summary, what I want to do is two step loop in the parent process:
1) Send command to child process by writing on master end of PTY.
2) Read and process child's output by reading from master end of PTY until
child is finished processing the command. The child is considered to be
"finished" when it blocks for input while reading from the slave end of
PTY - this is the state that I need to be able to detect.
Thanks,
Vince Fuller, Stanford Networking Systems
-------
-------mailer-daemon@lindy.stanford.edu (Mail Delivery Subsystem) (03/29/88)
----- Transcript of session follows -----
>>> RCPT To:<//@umunhum.stanford.edu>
<<< 550 <//@umunhum.stanford.edu>... Can't create output
550 //@UMUNHUM.STANFORD.EDU... User unknown
----- Unsent message follows -----
Received: by Forsythe.Stanford.EDU; Mon, 28 Mar 88 12:11:38 PST
Received: by BYUADMIN (Mailer X1.25) id 1424; Mon, 28 Mar 88 13:11:43 MST
Date: Sat, 26 Mar 88 11:49:52 PST
Reply-To: Unix-Wizards@BRL.ARPA
Sender: Unix-Wizards Mailing List <UNIX-WIZ%NDSUVM1.BITNET@Forsythe.Stanford.EDU>
From: Michael Chepponis <cheppo@umunhum.stanford.edu>
Subject: Problems with GNU C 1.18 and GNU C++ 1.18.1
X-To: acornrc!bob@umunhum.stanford.edu
X-Cc: unix-wizards@sem.brl.mil
To: //@UMUNHUM.STANFORD.EDU
In-Reply-To: Bob Weissman's message of 16 Mar 88 22:21:47 GMT
Supposedly every version of GNU C is tested for bootstrapping itself
on a microvax at MIT before it is distributed. But that might be
a different version of Unix.
The most effective way to address your problems would be to
inform the people who would like to do something about them,
by sending a bug report. Read the chapter on reporting bugs
in the Info file `internals' and send a bug report to
bug-gcc@prep.ai.mit.edu.
I'm not an expert on GNU C myself, which is why I suggest you
talk to the people who are.mailer-daemon@lindy.stanford.edu (Mail Delivery Subsystem) (03/29/88)
----- Transcript of session follows -----
>>> RCPT To:<//+@umunhum.stanford.edu>
<<< 550 <//+@umunhum.stanford.edu>... Can't create output
550 //+@UMUNHUM.STANFORD.EDU... User unknown
----- Unsent message follows -----
Received: by Forsythe.Stanford.EDU; Mon, 28 Mar 88 12:11:47 PST
Received: by BYUADMIN (Mailer X1.25) id 1425; Mon, 28 Mar 88 13:11:44 MST
Date: Sat, 26 Mar 88 11:49:52 PST
Reply-To: Unix-Wizards@BRL.ARPA
Sender: Unix-Wizards Mailing List <UNIX-WIZ%NDSUVM1.BITNET@Forsythe.Stanford.EDU>
From: Michael Chepponis <cheppo@umunhum.stanford.edu>
Subject: Problems with GNU C 1.18 and GNU C++ 1.18.1
X-To: acornrc!bob@umunhum.stanford.edu
X-Cc: unix-wizards@sem.brl.mil
To: "000," <//+@UMUNHUM.STANFORD.EDU>
In-Reply-To: Bob Weissman's message of 16 Mar 88 22:21:47 GMT
Supposedly every version of GNU C is tested for bootstrapping itself
on a microvax at MIT before it is distributed. But that might be
a different version of Unix.
The most effective way to address your problems would be to
inform the people who would like to do something about them,
by sending a bug report. Read the chapter on reporting bugs
in the Info file `internals' and send a bug report to
bug-gcc@prep.ai.mit.edu.
I'm not an expert on GNU C myself, which is why I suggest you
talk to the people who are.MAILER-DAEMON@slcs.slb.com (Mail Delivery Subsystem) (06/07/89)
----- Transcript of session follows ----- >>> RCPT To:<guthery@ASC.SLB.COM> <<< 550 <guthery@ASC.SLB.COM>... User unknown 550 asc.slb.com::guthery... User unknown ----- Unsent message follows ----- Return-Path: <unix-wizards@brl.mil> Received: from asc.psi by slcs.SLCS.SLB.COM (3.2/SLCS Relay 1.1) id AA12156; Wed, 7 Jun 89 07:19:20 CDT Apparently-To: asc.slb.com::guthery X-Vms-To: UNIX-WIZARDS@brl.mil Received: from relay.cs.net by sdr.slb.com; Wed, 7 Jun 89 05:04 EST Received: from sem.brl.mil by RELAY.CS.NET id aa00690; 7 Jun 89 3:39 EDT Received: from SEM.BRL.MIL by SEM.BRL.MIL id aa26080; 7 Jun 89 2:53 EDT Received: from sem.brl.mil by SEM.BRL.MIL id aa26024; 7 Jun 89 2:45 EDT Date: Wed, 07 Jun 89 02:45:29 EST From: The Moderator <Unix-Wizards-Request@brl.mil> Subject: UNIX-WIZARDS Digest V7#100 To: UNIX-WIZARDS@brl.mil Reply-To: UNIX-WIZARDS@brl.mil Message-Id: <8906070245.aa26024@SEM.BRL.MIL> UNIX-WIZARDS Digest Wed, 07 Jun 1989 V7#100 Today's Topics: Re: GNU, security, and RMS Re: keyscan wanted Re: Optimal for loop on the 68020. access() Re: What kind of things would you wnat in the GNU OS Long filenames (was: What kinds of things would you want in the GNU OS?) sys V.3.2 swap problem: unterminated sleep? Re: GNU, security, and RMS Re: Getting rid of the root account Re: GNU os suggestions -- system data interfaces Re: GNU OS suggestion -- memory "advice" Re: What kinds of things would you want in the GNU OS? Positional Parameter Settin in function Directory Editor Re: What kind of things would you wnat in the GNU OS Re: What kinds of things would you want in the GNU OS? Re: Getting rid of the root account Locks for exclusive access to resources Van Jacobson's version of SLIP with header compression... Re^2: GNU, security, and RMS UNIX Sys V Tunable Parameters Re: keyscan wanted Re: Re^2: GNU, security, and RMS Re: What kinds of things would you want in the GNU OS? Re: Optimal for loop on the 68020. Re:Getting rid of the root account (Was: GNU OS) Re: GNU, security, and RMS redirect stdin when using execl Re: GNU OS suggestion -- memory "advice" Re: Getting rid of the root account Re: security (PCs) Re: GNU os suggestions -- system data interfaces inode table hacking Re: Positional Parameter Settin in function Re: GNU os suggestions -- system data interfaces Building a Sun boot tape. sh functions with "local variables" ----------------------------------------------------------------- From: carroll@s.cs.uiuc.edu Subject: Re: GNU, security, and RMS Date: 4 Jun 89 18:32:00 GMT Nf-ID: #R:thor.acc.stolaf.edu:2322:s.cs.uiuc.edu:216100012:000:1640 Nf-From: s.cs.uiuc.edu!carroll Jun 4 13:32:00 1989 To: unix-wizards@sem.brl.mil /* Written 1:55 pm Jun 3, 1989 by haynes@ucbarpa.Berkeley.EDU in s.cs.uiuc.edu:comp.unix.wizards */ In article <2322@thor.acc.stolaf.edu> mike@stolaf.edu writes: >(2) There should not be security among the users of a computer system. Well, you have a right to your opinion; but a corollary of this belief is that all the users of a computer system have to be mutually friendly and responsible and trust one another. ^^^^^^^^^^^ /* End of text from s.cs.uiuc.edu:comp.unix.wizards */ Put with "skillful" with "responsible". I used to share a couple systems with some associates of mine, all of whom I trusted complete to be _honest_ and _ethical_. I certainly did _not_ trust all of them to be _skillful_. As an example, I have a friend who I'd trust in my house while I'm gone, but I'd _never_ loan him the keys to my car because _he doesn't know how to drive_. Similarly, I didnt' give my some of my associates full priviledges because _they didn't know enough to be safe_. If ever one was a wizard kernel-hacker, then it wouldn't be a problem. But that doesn't happen in the real world. Properly used security also prevents _accidents_. Further, I kept private information on the system - I trusted them not to look, even with root priviledges, if I set the permissions to exclude normal logons. Setting everything 666 (or 777) strikes me as bogus. How are others to know what they are welcome to look at / edit or not? Alan M. Carroll "And there you are carroll@s.cs.uiuc.edu Saying 'We have the Moon, so now the Stars...'" CS Grad / U of Ill @ Urbana ...{ucbvax,pur-ee,convex}!s.cs.uiuc.edu!carroll ----------------------------- From: "T. William Wells" <bill@twwells.uucp> Subject: Re: keyscan wanted Date: 5 Jun 89 23:59:54 GMT Expires: Sender: Followup-To: Keywords: To: unix-wizards@sem.brl.mil In article <607@wn2.sci.kun.nl> medfys@wn2.sci.kun.nl (Victor Langeveld/Tjeerd Dijkstra) writes: : In article <1006@twwells.uucp>, bill@twwells.uucp (T. William Wells) : writes: : > In article <475@wn2.sci.kun.nl> medfys@wn2.sci.kun.nl (Victor Langeveld/Tjeerd Dijkstra) writes: : > : I am searching for a (small?) routine that informs me about a : > : possible pressed key. This routine should *not* wait for input, : > : but return immediately, wether succesfull or not. : > : Suggestions? : > : > Yes. Tell us what hardware and OS you are talking about. : > : > For example, this should be doable on my system, a '386 running : > Microport's Unix, by telling the driver to return scan codes and : > doing nonblocking reads. It's all in the relevant sections of the : > manual, under keyboard(7), open(2), and fcntl(2), and maybe a few : > other places I can't think of off hand. : > : > But on your system, who knows? We certainly don't, since we don't : > know the system. : > : > --- : > Bill { uunet | novavax } !twwells!bill : : There is no need to know what hardware this should be working on. : Mr Charles Thayer (Thanks again, Charles!) gave me a perfect solution: : : int key_pressed() : { : int mask=1; : struct timeval wait; : : wait.tv_sec=0; : wait.tv_usec=0; : return (select(1,&mask,0,0,&wait)); : } : : This can be used as e.g. if(!key_pressed) { do stuff} else { key : handling}. Works fine! (As is should (?) on any unix machine) Leaving aside the possible interpretational problem (the solution I suggested *really* permits checking for key pressed, and key released, too), you're talking BSD. Your code won't work on my sysV 3.0 and on many others. --- Bill { uunet | novavax } !twwells!bill ----------------------------- From: Stephen Uitti <suitti@haddock.ima.isc.com> Subject: Re: Optimal for loop on the 68020. Date: 5 Jun 89 20:15:12 GMT Keywords: for ( i = COUNT; --i >= 0; ) To: unix-wizards@sem.brl.mil In article <11993@well.UUCP> Jef Poskanzer <pokey@well.com> writes: >I compiled the following different kinds of for loops: > for ( i = 0; i < COUNT; i++ ) > for ( i = 0; i < COUNT; ++i ) > for ( i = 0; ++i <= COUNT; ) > for ( i = 0; i++ < COUNT; ) > for ( i = COUNT; i > 0; i-- ) > for ( i = COUNT; i > 0; --i ) > for ( i = COUNT; --i >= 0; ) > for ( i = COUNT; i-- > 0; ) >on a Sun 3/50 with both SunOS 3.5 cc and gcc 1.35, and looked at the >generated code and the timings. COUNT was a small (< 127) compile-time >constant. A huge amount of time ago, i did this for the PDP-11 using the Ritchie compiler. This compiler is not awesomely bright, but i had the impression that it wasn't quite as bad as PCC (or even less portable). The optimal loop would use the "sob" (subtract one and branch if not zero) instruction. The code that caused it to be emitted was register i; i = COUNT; do { loop body; } while (--i); This is much clearer than anything with for(), since it tends to get (even stupidly) compiled to: register i; i = COUNT; mov $COUNT,r2 do { L1: loop body; loop body... } while (--i); sob r2,L1 The compiler seemed to be smart enough to know not to use it if the loop was too long. Thus, at worst, the sob would be replaced by: sub $1,r2 jne L1 The trouble with "for" loops is that it is defined as "test at the top", when most single instructions loops are "test at bottom". The VAX (PCC based) compiler's optimizer would convert many loops that used multiple instructions to use a single complicated instruction. Unfortunately, the VAX 780 (ubiquitous at the time) generally ran these slower. One case was the acbl (add, compare and branch longword). The optimizer would replace the three instructions (something like:) add $1,r2 cmp $END,r2 bne L1 with the "acbl" and all its arguments. Both codings take the same number of bytes (25!). The multiple instructions are faster (on the 780). Newer VAXen have different relative timing. I recall this case coming from the prime number sieve benchmark. The loop could not be easily converted to the do-while. I haven't gotten a chance to play with gcc (real work to do). I've heard it can do wonders, and thought it did better multi-statement optimization. Still, all the silly side-effects semantics of C make it hard to tell a compiler how to take mediocre source and produce good code from it. It is best to start with good source. Though i hardly ever write assembler anymore (and it seems never for speed or size), i've still yet to bump into a C compiler that produces code that i can't improve on at a glance. This may change if/when i start working with scoreboarded RISC processors (88K), in that instruction cycle counting looks hard (requiring more than a glance). Stephen. ----------------------------- From: Mike McNally <m5@lynx.uucp> Subject: access() Date: 5 Jun 89 17:30:15 GMT To: unix-wizards@sem.brl.mil Is it appropriate that access("somefile", X_OK) always succeeds (returns 0), whether "somefile" has an "x" bit or not, when called while the eff. user id is root? For the curious, I tested this under 4.3BSD on my Integrated "Solutions" 68020 box with the following program: main(ac, av) int ac; char **av; { printf("%d\n", access(av[1], atoi(av[2]))); } The program is invoked as "t something 1". When run on a particular file while not setuid to root, it prints -1 for a plain text file without any "x" bits. After I setuid to root, the exact same invocation prints 0. Of course, even while setuid, an attempt to execute the file fails with EACCES. Note that I don't want to start another war about the usefulness of access(). -- Mike McNally Lynx Real-Time Systems uucp: {voder,athsys}!lynx!m5 phone: 408 370 2233 Where equal mind and contest equal, go. ----------------------------- From: Roy Smith <roy@phri.uucp> Subject: Re: What kind of things would you wnat in the GNU OS Date: 6 Jun 89 01:26:52 GMT To: unix-wizards@sem.brl.mil In article <19851@adm.BRL.MIL> cherry.STCWR@xerox.com writes: > I'd say put [VM & symlinks] in. Let the user determine whether to use > them or not. The fact that they are there doesn't hurt an OS. It is thinking like this that led us from the 40k kernels I used to run back in the v6 days to the 500+k kernels we see today. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network" ----------------------------- From: "Bruce G. Barnett" <barnett@crdgw1.crd.ge.com> Subject: Long filenames (was: What kinds of things would you want in the GNU OS?) Date: 6 Jun 89 04:07:16 GMT Sender: news@crdgw1.crd.ge.com Keywords: OS filenames To: unix-wizards@sem.brl.mil In article <9422@alice.UUCP>, andrew@alice (Andrew Hume) writes: > my point is that if you have structured names like ><machine><report>-<option>.<time_period> (barnett's example), >the "lazy part" is putting that in the filename and using the >shell's pattern matching to select files. The alternative >(there are obviously bunches) is to put this database in a file >that looks like ><datafile>\t<machine>\t<report>\t<option>\t<time_period> >and use awk (or cut) to select on arbitrary fields. e.g. > more `awk '$2=="mymachine"{print $1}'` > >this is only slighlty more work, much more flexible AND >doesn't require the kernel to support gargantuan filenames. Wrong. It would require much more work and be much less flexible. Example: If I wanted to print out all weekly sa -in and sa -im reports for machines vaxA and SunB that ocurred in January, I could type: My Method: print {vaxA,sunB}*sa-i[nm]*Jan*WEEK Your method: print `awk '$2 ~ /vaxA|sunB/ && $3 == "sa" && $4 ~/i[nm]/ && \ $5 ~ /Jan.*WEEK/ {print $1}' data ` Disadvantages with your method: 1. Simple queries now require either an AWK programmer or a a sophisticated script. 2. The file "data" must be keep up to date. If 50 files were created a day, and files could be deleted whenever the disk filled up, keeping this file up to date requires an extra step. 3. The biggest disadvantage is that if dozens of scripts were written, and it became necessary to change the database, all of the scripts would have to be re-written. If I had to re-implement my report scheme on a system with filenames less than 14 characters, it would have taken me twice as long to do it. There are so many advantages to long filenames: I have never had a problem with a shell script that did mv $1 $1.orig I have enabled GNU emacs's numbered backups mechanism, so that old files are renamed file.~1~ file.~2~ ... file.~12~ etc. (By default GNUemacs keeps the two oldest and two newest versions). If I used this scheme, then all of my non-SCCS awk scripts would be limited to five characters: (e.g. abcde.awk.~12~) I can also use filenames to indicate the function of the script. (e.g. "archive-to-tape-old-newsgroups" vs. "ar2tape-oldng") But the biggest win is the ability to use the filename for the data. Another example is the large USENET archive I keep. First of all, I store old articles using the format ./news.group/yy-mm/article-id (The top directory is the newsgroup. The next directory tells me the year and month of the posting. The filename is the article-ID of the article). There is a one-line summary of the subject line in the file ./LOGS/news.group which contains the filename and subject line. When I archive the big-old newsgroups to tape, the log file is renamed (appending the current date to the filename). There are so many advantages to this scheme. Articles are always a known depth from the top (comp.binaries.ibm.pc.d vs. comp/binaries/ibm/pc/d). There is a simple way to determine if an article is archived twice. The filename contains all of the information needed. I don't have to search another file to determine the name for the archive. I now have the following pieces of data available: The newsgroup The year and month of the posting The article-ID The machine the article was posted from The filename of the article on the disk or tape If the article has been archived to disk, I also have: The name of the tape the archive is on When I created the above tape Now ALL of the above information is stored in filenames. The log file is the filename and the subject line. I don't need files to keep information about files, especially when I have to keep track of 400,000 files. My database queries are done with grep, cat and find. Once I find the file I am interested in, I use a very simple awk command to do something with the files. In short, the fact that I have hundreds of thousands of files with the length of 30 characters (which is NOT gargantuan in my mind) allows me a simple, elegant method of organizing data. The same task on a machine with the archaic limit of 14 characters would have make the task more difficult, more complex, more inflexible and more inefficient. -- Bruce G. Barnett <barnett@crdgw1.ge.com> a.k.a. <barnett@[192.35.44.4]> uunet!crdgw1.ge.com!barnett barnett@crdgw1.UUCP ----------------------------- From: Andrew Klossner <andrew@frip.wv.tek.com> Subject: sys V.3.2 swap problem: unterminated sleep? Date: 5 Jun 89 16:23:59 GMT Sender: nobody@orca.wv.tek.com To: unix-wizards@sem.brl.mil In the vanilla 3b2 sources for system V.3.2, in file os/swapalloc.c, a process can go to sleep waiting for more swap space with this line: sleep(&swapwold, PMEM); However, there doesn't seem to be a corresponding wakeup. We have systems that lock up just after printing the "DANGER: Out of swap space." message that precedes this sleep. Is this really a bug, or am I misinterpreting? If it's a bug, has someone already fixed this? I'd be delighted not to reinvent this wheel. [Please send e-mail; you know what it's like trying to keep up with this group ...] -=- Andrew Klossner (uunet!tektronix!orca!frip!andrew) [UUCP] (andrew%frip.wv.tek.com@relay.cs.net) [ARPA] ----------------------------- From: "John F. Haugh II" <jfh@rpp386.dallas.tx.us> Subject: Re: GNU, security, and RMS Date: 6 Jun 89 05:50:26 GMT To: unix-wizards@sem.brl.mil In article <2322@thor.acc.stolaf.edu> mike@stolaf.edu writes: >As for my beliefs on the subject: > >(1) Anyone who thinks a UNIX-compatible system can be `secure' has > some serious delusions. Timing windows and covert channels abound. The NCSC believes a UNIX-compatible system can be made A1 secure. Apple recently announced a B2 [ B1? ] secure compartmented workstation. The IBM RT/PC runs a C2 capable version of UNIX, complete with all the nasty BSD cruft. How much longer until a B3 workstation is announced by a real player, like DEC or Sun? [ A more likely question is how long until AT&T or IBM buys Apple ... ] -- John F. Haugh II +-Button of the Week Club:------------- VoiceNet: (512) 832-8832 Data: -8835 | "AIX is a three letter word, InterNet: jfh@rpp386.Cactus.Org | and it's BLUE." UucpNet : <backbone>!bigtex!rpp386!jfh +-------------------------------------- ----------------------------- From: "John F. Haugh II" <jfh@rpp386.dallas.tx.us> Subject: Re: Getting rid of the root account Date: 6 Jun 89 06:10:42 GMT To: unix-wizards@sem.brl.mil In article <1961@ubu.warwick.UUCP> mirk@uk.ac.warwick.cs (Mike Taylor) writes: >Uuuh, are you sure? There seems to be a prevailing feeling that the >whole of UNIX is something that was cobbled together ar random by >people writing bits without thinking about whether or not they were >secure, made sense or whatever. I would suspect that stopped being the official feeling of AT&T when UNIX became a commercial product. Commercial operating systems need to have security features so that buyers will pay real money for them ... > While this is largely true of >Berkeley UNIX, or at least, of those bits that have been added since >V7, the concept of a root id belongs to fundamental core UNIX, it is >one of the concepts that Thompson, Richie and friends though long and >hard about when they were designing UNIX. Monolithic privilege is simple, elegant and neither secure nor trustable. Any single flaw in the privilege scheme may be exploited to obtain complete privilege. Given the choice between monolithic root privilege, or VMS-like privileges, I'd much rather have the VMS approach. -- John F. Haugh II +-Button of the Week Club:------------- VoiceNet: (512) 832-8832 Data: -8835 | "AIX is a three letter word, InterNet: jfh@rpp386.Cactus.Org | and it's BLUE." UucpNet : <backbone>!bigtex!rpp386!jfh +-------------------------------------- ----------------------------- From: Richard Michael Todd <rmtodd@uokmax.uucp> Subject: Re: GNU os suggestions -- system data interfaces Date: 5 Jun 89 22:09:37 GMT To: unix-wizards@sem.brl.mil In article <1344@marvin.Solbourne.COM> dce@Solbourne.com (David Elliott) writes: >Two items that I find particularly annoying are getting kernel data >values and handling system files. Getting kernel data values isn't too much of a problem (once you master nlist and friends), though as UNIX is currently implemented it's extremely ugly. The main problem I seem to run into is figuring out just what kernel variable you need, what format it is in, and what it means once you've got it. The closest thing you find to documentation is groveling through /usr/include/sys and seeing if anything interesting seems to be useful. (Then you get to guess which other include files /usr/include/sys/whatever.h needs to have precede it. I've often wished for all include files to clearly state in a comment: NEEDS sys/types.h, sys/page.h, etc..) Anyway, what I'm saying is that to a large extent the existing kernel internals need to be documented. Granted, a better interface to reading kernel internal variables and structures would be nice, but unless the variables are documented it won't do you much good. >The nlist interface to the kernel is a major hassle for a number of >reasons. First of all, I find that in a lot of development >environments, the kernel that is running is not /vmunix or /unix, but >is some other item. Secondly, people often want to know things like >the load average without having to make their programs setuid (or >worse, they get root permission and start playing system god without >having enough experience). Finally, sizes of data structures change, Well, really such programs ought to be setgid kmem (or whatever group owns /dev/kmem), but still your point applies--it makes it impossible for Joe User to write such programs himself, and is a pain even for Joe Sysadmin. >yet there is no interface for getting these sizes, and in heavy >development environments, you can't even guarantee that your sys header >files match the kernel (or any kernel, for that matter). Programs like >ps would be a lot more useable in the face of kernel programmers if >this data were available at run-time. Agreed. It would be nice if there was an improved version of nlist that could read not only the address of the kernel data structure, but the type and size as well (presumably the kernel would be compiled with -g), and automatically read in the right amount of data. Of course, an even better approach is to have some system call to fetch kernel data yourself, without requiring that /dev/kmem be accessible. Encore has such a system call, called inq_stats; ps and its friends are implemented using inq_stats, and mere users can write their own ps-like programs for collecting data on processes. Of course, the flip side of this is that if you want some information that isn't one of the types inq_stats will give, you're SOL (e.g. as far as I and a friend of mine can tell, there's no way to tell from inq_stats data if a process is swapped out.) Still, such a call is useful. -- Richard Todd rmtodd@chinet.chi.il.us or rmtodd@uokmax.ecn.uoknor.edu aka ...!sun!texsun!uokmax!rmtodd "Never re-invent the wheel unnecessarily; yours may have corners."-henry@utzoo ----------------------------- From: Andrew Klossner <andrew@frip.wv.tek.com> Subject: Re: GNU OS suggestion -- memory "advice" Date: 5 Jun 89 19:46:16 GMT Sender: nobody@orca.wv.tek.com To: unix-wizards@sem.brl.mil [] "Programmers can often predict what areas of a program or chunks of data space are going to be used more often than others, yet there is generally no way for the programmer to say that a chunk of code is or is not needed often, or is only called at a point at which speed is not critical." Some research in the 1970s, when demand paging was new (to many of us), suggested that programmers cannot do as good a job as they think they can in predicting memory access behavior. In general, totally uninformed, dynamic LRU memory migration was found to win over extensively tweaked, programmed memory migration. (This was reported in a CACM in about mid-decade; sorry I can't quote chapter and verse from memory.) "In one case, a developer described a case in which a large array was being scanned a number of times in both row-major and column-major order. He noticed that the slowdown came in the latter case since the OS was paging his data in an inefficient manner." Well, sure; in column-major order (assuming a non-Fortran language), the program is stepping to a new page much more often than in row-major order. If a single row is a page or more in size, column-major order will touch a new page with every single index iteration. No amount of memory advise to the OS can mitigate the result of this pathological behavior. -=- Andrew Klossner (uunet!tektronix!orca!frip!andrew) [UUCP] (andrew%frip.wv.tek.com@relay.cs.net) [ARPA] ----------------------------- From: John F Carr <jfc@athena.mit.edu> Subject: Re: What kinds of things would you want in the GNU OS? Date: 6 Jun 89 08:04:43 GMT Sender: daemon@bloom-beacon.mit.edu To: unix-wizards@sem.brl.mil In article <3306@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes: >Just out of curiousity, is anyone out there using the Andrew system >(AFS)? I've been told that the machines hooked up to it have a truly >transparent file system (i.e. a friend of mine at Univ. of Mich. can >get at files on CMU's systems without knowing which campus they're >on). True? If so, I'd think this would be much preferable to all the >"remote mount" junk.... > For security...something along the lines of Kerberos would be great. We use AFS+Kerberos at project Athena. It's now in the almost releasable state. There are some changes that need to be made before we can use it for normal file service. It should be said that AFS is not a replacement for NFS. Ways in which AFS wins: Performance: it keeps a local cache of recently accessed files (this cache is not destroyed by reboot), so performance is much better. Transparency: there is no need to explicitly mount a filesystem. Directories can be moved around without the owner knowing or caring (important for load-balancing). I can tell anyone to look at athena.mit.edu/mit/jfc/README.afs in his afs filesystem, and he will be able to get to it from anywhere with a net connection. Quota: quota control is per-directory instead of per-filesystem (this is an important requirement in our environment, since per-user quota doesn't "do the right thing" on group-writeable directories). Access control: Access control lists per directory, updates are instantaneous. (At Athena the group lists on NFS servers are updated no more than daily.) Ways in which AFS loses: Access control: There are per-directory acls, but no way (yet) to set permission on an individual file. Filesystem format: You can't export a UNIX filesystem via AFS. There isn't any good way to get at AFS files on the same machine, except through AFS (which means sending them over the network, back to your disk [now in your AFS cache], and then reading them). Ease of setup: With our Kerberos authenticated NFS, untrusted servers are possible (since each NFS server uses a different key to authenticate requests, breaking into one server does nothing for the others). With AFS, all servers share a key (so root access to a server is equivalent to root access to files on other local servers). This means you can't add a random machine to AFS while maintaining security. Some of the problems will be fixed over time. For most of our file service needs, AFS wins big over NFS. NFS won't go away, because it is more widely used (measured by number of sites and number of machine/OS types) and because it works with a UNIX filesystem, but it will get a lot less use in the future. --John Carr (jfc@athena.mit.edu) ----------------------------- From: Paul Houtz <gph@hpsemc.hp.com> Subject: Positional Parameter Settin in function Date: 5 Jun 89 23:33:11 GMT To: unix-wizards@sem.brl.mil In my ksh, the "set" command doesn't seem to work within a function: As a shell command I do the following: $ set `date` $ echo $4 16:31:00 Now if I declare a function: $ foo () { / set `date` / } $ foo $ echo $4 16:31:00 As you can see, the old `date` is still in the positional parameters, otherwise the seconds part of the date should have changed by now. Is this a bug in ksh? Is it a feature? Is there some explanation of this feature? Thanks for any help you can give. Paul Houtz HP Technology Access Center 10670 N. Tantau Avenue Cupertino, Ca 95014 (408) 725-3864 hplabs!hpda!hpsemc!gph gph%hpsemc@hplabs.HP.COM ----------------------------- From: Owner <donegan@stanton.uucp> Subject: Directory Editor Date: 5 Jun 89 00:04:06 GMT Followup-To: poster Keywords: directory,damaged,fix To: unix-wizards@sem.brl.mil I'm sorry if this has been covered before, but is there source code available which would allow me(root) to edit a directory file directly? The reason for this need is that every once in a while either inews or xbbs fries a directory entry. This is rare, but the process of tar'ing a large file tree and rm -r'ing it and then untar'ing it is a little tedious when I can see via hd exactly what the problem is. The fsck utility does not catch this particular problem. Thanks for any help... -- Steven P. Donegan These opinions are given on MY time, not Area Telecommunications Engineer Western Digital's - They wouldn't agree! Western Digital Corp. stanton!donegan || donegan@stanton.UUCP || donegan%stanton@UUCP ----------------------------- From: Robert Cousins <rec@dg.dg.com> Subject: Re: What kind of things would you wnat in the GNU OS Date: 5 Jun 89 14:39:19 GMT To: unix-wizards@sem.brl.mil IMHO, the features of such an operating system should be (in approximately this priority): 0. Semantic compatibility with Unix 1. Portability 1.5 Multiprocessor support 2. Functionality 3. Extensability 4. Innovative While I am sure that many people will disagree with the above priority list, relatively few will disagree with the contents (save to add some important ones I can't think of right now). The real issues will be choosing the reference hardware and establishing some form of ABI/BCS for the hardware. It is important to note that there is a tremendous amount of room left for inovation while maintaining compatibility with Unix. One of the common complaints is that there is no user level facility for asynchronous I/O, yet there is an easy way to provide a form of it -- remove the buffer from the user's address space and cause a page fault on the next reference to the page(s). The faulted program is then suspended until the completion of the I/O request (which may be immediate if the I/O request has completed). This allows the user task to return from the I/O call immediately yet have the Unix semantics remain the same. Other examples of potential innovation include an improved interface between X windows and the operating system, improved file systems (which take advantage of implicit parallelism in file operations), better networking support (it seems that EVERYONE (except for one or two) runs the BSD networking code with only minor hacking), making the kernel REENTRANT would also help. Lastly, creating a new algorithm to replace linear searches might just help a lot. Just my $.02 worth. Robert Cousins Dept. Mgr, Workstation Dev't. Data General Corp. Speaking for myself alone. ----------------------------- From: "Greg A. Woods" <woods@eci386.uucp> Subject: Re: What kinds of things would you want in the GNU OS? Date: 6 Jun 89 00:01:20 GMT Keywords: GNU OS features kernel fun! network transparent filesystem To: unix-wizards@sem.brl.mil In article <209@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes: > In article <1989May26.224924.5293@eci386.uucp> woods@eci386.UUCP (That's ME) writes: > > | Second, a leading '//' with a special meaning is a tremendous KLUDGE! > | It's even worse than "machine_A:/"! > > Nope, sorry, // is a small kludge, and machine_A:/ is the tremendous kludge. > Your syntax attaches special to another character. With the // syntax, > the special chars remain limited to / and null. I see '//' as a huge kludge, 'cause it special-cases the meaning of two consecutive slashes when they appear at the beginning of a line. This goes directly against the understood meaning of consecutive slashes (i.e. scrunch them into one slash). The "mach_A:/" at least identifies this syntax as a kludge (to the eye, and the machine). Besides, using a second character is better than overloading an already used one. Of course I don't like either syntax. I want to be able to put directory hierarchies anywhere I please, whether they are on a remote machine, or local. That's part of what network tranparency for filesystems is all about. The meaning of "mounting a filesystem" should be exactly the same, be it a local mount of a physically local disk, or a remote mount of a filesystem advertised to the network. Further in article <209@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes: > Why do you want to have to mount somebody else's filesystem on your > system just to be able to access it? It's already mounted on their > system. All you need is a way to get to it. Cause if I'm on a metropolitan sized network (> 1000 machines), I don't want 1000 root directories! But that's only a tiny part of it. The way to get into some filesystem is to mount it. It doesn't matter where that filesystem physically resides. This is part of filesystem semantics. Besides, I don't want to have to make my entire filesystem available to the network. I may want to make all of some local mount (i.e. partition) available, or I may want to make an entire directory hierarchy (other than root) available, and I don't want the ability to make all of my filesystem available. One way to do this by advertising a directory name to the network as available to be mounted remotely. I may want to be able to put a password on this capability too, perhaps in conjunction with some form of authentication service like Kerberos(sp?). Even further in article <209@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes: > One additional requirement I forgot to list in my previous article > is that remote devices must be as transparent as regular files. > Some inferior network filesystems break the "a file is a file is a file" > rule. Of course. That's another aspect to transparency. RFS goes to great lengths not to break filesystem semantics (and so far as I can see, it succeeds). The entire concept of network transparency to filesystem semantics is of utmost importance. If attention is not paid to this aspect, of an operating system, the result will be another huge pile of kludges. PS: I had hoped, given the forum, that I wouldn't have to "waste" bandwidth talking about this stuff in detail. However, if one person responds in such a way to indicate I didn't get my point across, I'd guess there are at least 10 more who didn't get it either. Anyway, I don't mind stating my humble opinion! :-) No offense intended Snoopy! PPS: I should hope this discussion is not only serving to clarify a few points, but to also provide some input to those people who want to work on the GNU design and implementation. -- Greg A. Woods woods@{{utgpu,eci386,ontmoh,tmsoft}.UUCP,gpu.utcs.UToronto.CA,utorgpu.BITNET} +1-416-443-1734 [h] +1-416-595-5425 [w] Toronto, Ontario CANADA ----------------------------- From: Doug Gwyn <gwyn@smoke.brl.mil> Subject: Re: Getting rid of the root account Date: 6 Jun 89 15:08:25 GMT To: unix-wizards@sem.brl.mil In article <16638@rpp386.Dallas.TX.US> jfh@rpp386.cactus.org (John F. Haugh II) writes: >Monolithic privilege is simple, elegant and neither secure nor >trustable. Any single flaw in the privilege scheme may be exploited >to obtain complete privilege. To the contrary, the kernel implementation of UID 0 being the ONLY privileged UID along with the set-UID implementation is small and simple enough to be completely validated. That provides sufficient kernel support for layered implementation of more elaborate security schemes. You need to distinguish between the typical hodge-podge of user-mode privileged programs found on commercial UNIX systems and the inherent security hooks. The latter make possible implementation of a provably secure, trustworthy multi-level security scheme. More elaborate kernel hooks make it harder to be sure there are no loopholes. It doesn't matter what a "flaw" would mean if you can PROVE there are no flaws. ----------------------------- From: "T. William Wells" <bill@twwells.uucp> Subject: Locks for exclusive access to resources Date: 6 Jun 89 11:27:33 GMT Expires: Sender: Followup-To: Keywords: To: unix-wizards@sem.brl.mil I'm looking for information on how to prevent two unrelated processes from accessing an unspecified resource. The method should be independent of the kind of UNIX being used and should, ideally, work even when the processes are running on different machines attached to the same network. I only know of four methods that might work. 1) Opening a lock file with O_EXCL. 2) Using link, mknod, or mkdir to create the lock. (But aren't there some systems where mkdir isn't atomic?) 3) Creating a file with permissions 000 (but this won't necessarily work if one of the requestors' is root, right?) 4) Using a server process to handle either the requests or the access. I'd appreciate hard information about which methods are usable and the advantages and disadvantages of each. Please respond via e-mail and I will summarize. --- Bill { uunet | novavax } !twwells!bill ----------------------------- From: Jacob Parnas <jparnas@larouch.uucp> Subject: Van Jacobson's version of SLIP with header compression... Date: 6 Jun 89 06:25:15 GMT Followup-To: comp.dcom.modems To: unix-wizards@sem.brl.mil Last usenix, telebit was using Van Jacobson's version of SLIP in their terminal server. At the Telebit BOF, the word was that this code would be publically accessible in a few weeks (that was in Feb, 1989). Does any one know where to get a copy of this code? Thanks for your help, -------------------------------------------------------------------------------- | Jacob M. Parnas | DISCLAIMER: The above message is from | | IBM Thomas J. Watson Research Center | me and is not from my employer. IBM | | Arpanet: jparnas@ibm.com | might completely disagree with me. | | Bitnet: jparnas@yktvmx.bitnet \---------------------------------------| | Home: ..!uunet!bywater!acheron!larouch!jparnas | Phone: (914) 945-1635 | -------------------------------------------------------------------------------- ----------------------------- From: Scott Alexander <salex@grad1.cis.upenn.edu> Subject: Re^2: GNU, security, and RMS Date: 6 Jun 89 17:48:32 GMT Sender: news@SCOTTY.DCCS.UPENN.EDU To: unix-wizards@sem.brl.mil In article <2698@solo1.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >jamesa@arabian.Sun.COM (James D. Allen) writes: >\... Bravo! I'll do an occasional >\ % chmod 600 Personal_little_black_book >\ to discourage casual snooping, but I always make /dev/mem and >\ /dev/disk `rw-r--r--'. If a user wants to write his own improved >\ `df' or `ps', more power to him. > >More power to the user who wants to write his own improved version of `cat' to >get `Personal_little_black_book' from /dev/disk itself. >-- > "Your password [should be] like your |Maarten Litmaath @ VU Amsterdam: > toothbrush." (Don Alvarez) |maart@cs.vu.nl, mcvax!botter!maart I've worked in many groups where most of the people knew the root password. In those groups, I use protection to give a hint about how I want my files accessed. Further, I give names which give a further hint. Thus, people know that if I've protected something in my work directory, that's probably the current version and if they pick it up, they deserve what they get. However, it's known that my personal directory is personal stuff and that I consider looking at that stuff as a violation of my privacy. There is an element that easier security makes it easier to break in, but there's also an element that more strenuous security makes it more fun to break in. As such, I've always been a fan of weaker security and very strong administrative action against anyone who breaks the implicit trust. Scott ----------------------------- From: "maurice.r.baker" <mrb1@cbnewsh.att.com> Subject: UNIX Sys V Tunable Parameters Date: 6 Jun 89 15:38:46 GMT Keywords: UNIX Tunable Param MSGMAP MSGSSZ MSGSEG MSGMAX MSGMNB MSGTQL MSGMNI To: unix-wizards@sem.brl.mil Hello --- I am posting the following message for a co-worker. Please respond directly to her, if possible --- I will, however, watch the affected newsgroups for replies and pass them along with e-mail replies to me. Thank you very much in advance; we would appreciate any insights, help, references, etc. RTFM'ing the documentation we have on hand has not proven to be of much value in this case. M. Baker, homxc!mrb1 ---Here's her message--- Subject: Message queue tunable parameters On a 3B2/600 running SV 3.1.1, how do the tunable parameters MSGMAP, MSGSSZ and MSGSEG relate to the others (MSGMAX, MSGMNB, MSGTQL, MSGMNI)? Say, for instance, MSGMNB=16384, MSGTQL=1500, MSGMNI=50, and MSGMAX=1024. Do the remaining parameters need to be increased in relation to these values? The maximum value for MSGSSZ * MSGSEG is 131072 (128K). What effect would it have to set the parameters for this value? Thanks, Janet Keyes AT&T Bell Labs, Holmdel, 2C530 201-949-8484 email to: aquaman!jek ------------------------- ----------------------------- From: Guy Harris <guy@auspex.auspex.com> Subject: Re: keyscan wanted Date: 6 Jun 89 18:30:10 GMT To: unix-wizards@sem.brl.mil >Works fine! (As is should (?) on any unix machine) On any UNIX machine that has "select"; not all of them do. (Yes, Mr. Wells was right; you *do* need to know what flavor of the OS - not necessarily what hardware - you're running. You just happened to luck out, in that Mr. Thayer and you were presumably running versions of UNIX similar enough that his solution worked on your machine.) ----------------------------- From: Guy Harris <guy@auspex.auspex.com> Subject: Re: keyscan wanted Date: 6 Jun 89 18:33:48 GMT To: unix-wizards@sem.brl.mil >As long as the machine in question has select(2), which automatically assumes >a UNIX with some BSD extensions - SYSV hacks will have to use poll(2) instead. Unless, of course: 1) their System V doesn't have "poll" (releases before S5R3 didn't have it, unless there was some version that snuck it in as an undocumented feature, say); 2) their System V doesn't have the device that you're trying to "poll" as a streams device, and doesn't support "poll" on non-streams devices (I've not seen any release from AT&T that 1) has *all* its ttys as streams devices or 2) supports "poll" on non-streams devices, although S5R4 may do both). ----------------------------- From: "Clyde W. Hoover" <clyde@ut-emx.uucp> Subject: Re: Re^2: GNU, security, and RMS Date: 6 Jun 89 19:53:19 GMT Sender: news@ut-emx.uucp Posted: Tue Jun 6 14:53:19 1989 To: unix-wizards@sem.brl.mil Out here in the "real-world" where users cannot be trusted to behave themselves and the Junior Hacker League lives, security is a MUST. Having been a sys admin in a variety of UNIX environments, I vote for UNIX having "high" security by default with directions provided on how to lessen it if desired. It is always easier (from a techincal viewpoint) to start restrictive and loosen up. The political issues of system security is another kettle of assorted aquatic creatures... Remember how many people were sure their SMTP connections were "secure" until last November :-) Shouter-To-Dead-Parrots @ Univ. of Texas Computation Center; Austin, Texas clyde@emx.utexas.edu; ...!cs.utexas.edu!ut-emx!clyde Tip #268: Don't feel insecure or inferior! Remember, you're ORGANIC!! You could win an argument with almost any rock! ----------------------------- From: Jan Edler <edler@cmcl2.nyu.edu> Subject: Re: What kinds of things would you want in the GNU OS? Date: 6 Jun 89 20:52:24 GMT To: unix-wizards@sem.brl.mil In article <1989Jun3.004854.18111@light.uucp>, bvs@light.UUCP (Bakul Shah) writes: > open("/etc/passwd", ...) >and > open("src/os", ...) > >can be replaced by calls like > > obj_open(root, "etc/passwd", ...) >and > obj_open(cwd, "src/os", ...) > >In effect the concept of `current directory' disappears as one can >keep any number of directory handles around and walk relative to >them. Which directories can be walked depends upon the initial >set of handles + directories reachable from this initial set. We considered extending the kernel/user interface in something like this way, but tentatively rejected it. Our goal wasn't to "objectify" the system, or to move namei out of the kernel, or anything like that. It was simply to generalize the notion of cwd, so that a process can efficiently reference files in any of several frequently-used directories. We decided that it was better to extend the pathname notion, than to extend all system calls taking pathnames so they take a handle too. The reason for this preference wasn't to avoid modifying all those system calls, or to avoid needing a compatibility library. It was the desire to treat handle+path specifications as simple strings that can be used exactly the same way pathnames have always been used. We've been a bit indecisive about the exact form of pathname extension. My current preference is to say that "/@" at the beginning of a pathname, followed by a file descriptor number (as a string of digits) and a "/", means to take the object referred to by the file descriptor as the search starting point. There are several issues relevant to this design, including: - Prevention of real entries in "/" like "@nnn". This is aesthetically unfortunate, but I don't think it's too serious. How many systems out there have entries in / like this? - Inability to transparently splice "/" on the front of a pathname. This is easily fixed by allowing 1 or more "/" chars in front of the "@". - We have to decide what to do about paths like "/foo/../@nnn/bar" and /@rootfd/@nnn/bar: my preference is that they are undefined -- /@nnn only has special meaning at the beginning of a path. But it wouldn't be too hard to make such paths work in the "expected" way. - "Dangling reference" confusion resulting when a program closes a file descriptor and later uses a pathname dependent on that fd. Of course the serious problem is when the fd has since been reassigned by a subsequent open. There is no better fix for this problem than to insist that programmers not close descriptors they didn't open (except for 0,1,2). - The need to convert back and forth between strings and integers is annoying. - A new open flag (O_EXEC), as previously discussed in this newsgroup, might be useful when dealing with file descriptors of directories. - Changing the lead-in string from "/@nnn" to "/@/nnn" might be advantageous because /@/ could be implemented as some kind of mount point on some systems, although this would be slower than more direct implementation strategies. - We have to decide about the degenerate case, opening "/@nnn" (i.e., nothing after the fd): does the resulting file descriptor share the same file pointer as the original? This question must also be addressed by /dev/fd/nnn implementations (do they all do the same thing in every case?). I'm sure I've forgotten some additional issues. Nevertheless, the ability to express such "handles" as part of pathname strings seems valuable. We can define conventional environment strings like $cwd, $root, and others, containing the file descriptor numbers to be inherited over exec; this removes the need to define special meaning for additional fd numbers, beyond 0,1,2. Any comments? Jan Edler NYU Ultracomputer Research Laboratory edler@nyu.edu ...!cmcl2!edler (212) 998-3353 ----------------------------- From: Jan Edler <edler@cmcl2.nyu.edu> Subject: Re: Optimal for loop on the 68020. Date: 6 Jun 89 21:06:02 GMT Followup-To: comp.unix.wizards Keywords: for ( i = COUNT; --i >= 0; ) To: unix-wizards@sem.brl.mil In article <17891@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <11993@well.UUCP> pokey@well.UUCP (Jef Poskanzer) writes: >>... COUNT was a small (< 127) compile-time constant. >> for ( i = COUNT; --i >= 0; ) > >[all but gcc -O -fstrength-reduce deleted] > >> moveq #COUNT,d0 >> jra tag2 >>tag1: >> <loop body> >>tag2: >> dbra d0,tag1 >> clrw d0 >> subql #1,d0 >> jcc tag1 I prefer moveq #COUNT,d0 jra tag3 tag1: swap d0 tag2: <loop body> tag3: dbra d0,tag2 swap d0 dbra d0,tag1 But it doesn't really make that much difference, I guess. However, the compiler shouldn't do either of these when d0 is initialized to a value < 65536. Jan Edler NYU Ultracomputer Research Laboratory edler@nyu.edu ----------------------------- From: Dinah Anderson <dinah@shell.uucp> Subject: Re:Getting rid of the root account (Was: GNU OS) Date: 6 Jun 89 16:28:51 GMT Sender: usenet@shell.com To: unix-wizards@sem.brl.mil In article <3, I think> jfh@rpp386.cactus.org (John F. Haugh II) writes: > I think [a previous poster] meant getting rid of UID == 0 being a > privileged user. Again, this an Orange Book requirement. It also > makes much sense. Programs should have privilege, not users. The > ability to access a program can then be limited to a collection of > users or groups. But what you are really saying is that a certain group of users would have the privilege to access a program which provides a certain privilege or access. I agree with the basics of what you are saying, but the real issue is the users running the programs, not the programs themselves. We need to know who is running what programs (for accountability in extreme sensitive cases.) Dinah Anderson Shell Oil Company, Information Center (713) 795-3287 ..!{sun,psuvax,bcm,rice}!shell!dinah ----------------------------- From: Dinah Anderson <dinah@shell.uucp> Subject: Re: GNU, security, and RMS Date: 6 Jun 89 16:33:54 GMT Sender: usenet@shell.com To: unix-wizards@sem.brl.mil In article <29457@ucbvax.BERKELEY.EDU>, haynes@ucscc.ucsc.edu writes: >Well, you have a right to your opinion; but a corollary of this belief >is that all the users of a computer system have to be mutually friendly >and responsible and trust one another. Which sounds like the mythical >home town where people don't need to lock the doors when they leave home. This no longer applies in the distributed operating system environment- especially when this environment crosses administrative domains. I no longer look at unix systems as standalone systems that just happen to be on a network. You have to consider all systems and your network is as secure as the least secure member (without the implementation of secure routers or 3rd party authentication systems.) Dinah Anderson Shell Oil Company, Information Center (713) 795-3287 ..!{sun,psuvax,bcm,rice}!shell!dinah ----------------------------- From: Ron Winnacott <ron@sc50.uucp> Subject: redirect stdin when using execl Date: 6 Jun 89 14:26:11 GMT Keywords: execl redirect stdin < To: unix-wizards@sem.brl.mil Hello net. Can anyone tell me how to redirect stdin when I use execl to start a new program. The problem I am haveing is this, I am writing a C program that forks then execl's a new program, But I need to use a redirect "<" in the execl call. execl("/bin/mail","mail","ron","<","/tmp/tfile",NULL); The fork works fine, and mail starts and has a PPID of 1, but it just sits there waiting for the letter and EOF to come from stdin. If you can help me please email to !uunet!attcan!telly!sc50!ron Thanks ron winacott. -- Ron Winacott. Unisys Canada, Support center. phone- (416) 495-4585 uucp - uunet!attcan!telly!sc50!ron *** All comments/statements made are MINE and MINE alone. *** ----------------------------- From: Anton Rang <rang@cpsin3.cps.msu.edu> Subject: Re: GNU OS suggestion -- memory "advice" Date: 6 Jun 89 22:55:18 GMT Sender: usenet@cps3xx.uucp To: unix-wizards@sem.brl.mil In article <3496@orca.WV.TEK.COM> andrew@frip.WV.TEK.COM (Andrew Klossner) writes: > [ stuff about row-major vs. column-major order ] > >Well, sure; in column-major order (assuming a non-Fortran language), >the program is stepping to a new page much more often than in row-major >order. If a single row is a page or more in size, column-major order >will touch a new page with every single index iteration. No amount of >memory advice to the OS can mitigate the result of this pathological >behavior. How about asking for a LIFO paging strategy on that section of memory? +---------------------------+------------------------+ | Anton Rang (grad student) | "VMS Forever!" | | Michigan State University | rang@cpswh.cps.msu.edu | +---------------------------+------------------------+ ----------------------------- From: Anton Rang <rang@cpsin3.cps.msu.edu> Subject: Re: Getting rid of the root account Date: 6 Jun 89 23:06:08 GMT Sender: usenet@cps3xx.uucp To: unix-wizards@sem.brl.mil In article <10370@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <16638@rpp386.Dallas.TX.US> jfh@rpp386.cactus.org (John F. Haugh II) writes: >>Monolithic privilege is simple, elegant and neither secure nor >>trustable. Any single flaw in the privilege scheme may be exploited >>to obtain complete privilege. > >To the contrary, the kernel implementation of UID 0 being the ONLY >privileged UID along with the set-UID implementation is small and >simple enough to be completely validated. [ stuff about layers ] > More >elaborate kernel hooks make it harder to be sure there are no loopholes. Why? If you have a layered security system, every part of it must be validated. It's no easier than putting it in the kernel. What's more, if you have a single privilege, you have to ensure that EVERY operation you do is provably secure. I doubt this is doable with existing validation mechanisms. >It doesn't matter what a "flaw" would mean if you can PROVE there are >no flaws. This can be done (well, approximated) much more easily if you have a large number of distinct privileges. If a section of code is running with, say, "GROUP" privilege (under VMS, this gives access to other processes in the group, and allows access to group data structures), you don't need to worry that a call to open a file will read a protected file. With monolithic privilege, any privileged code could do this. I've done some (little) work on security validation. It's not easy. Monolithic privilege schemes don't help at all. +---------------------------+------------------------+ | Anton Rang (grad student) | "VMS Forever!" | | Michigan State University | rang@cpswh.cps.msu.edu | +---------------------------+------------------------+ ----------------------------- From: Anton Rang <rang@cpsin3.cps.msu.edu> Subject: Re: security (PCs) Date: 6 Jun 89 23:12:35 GMT Sender: usenet@cps3xx.uucp To: unix-wizards@sem.brl.mil In article <19896@adm.BRL.MIL> bzs@bu-cs.bu.edu (Barry Shein) writes: [ about security ] >Although I'd probably agree with what you're trying to say I just want >to point out that 10 Million PC's and about 1 Million Mac's say you're >(we're?) wrong. There's no concept of security on those machines >(heck, there's no concept of a "user" tho various things have been >hacked on top for network add-on software.) I'd have to call that >representative of "many" people. We can go back to "reason" but, hey, >11 million user's voted with their pocketbooks, hard to dispute. Then again, my Macs aren't connected to a network where anybody can come in and (ab)use them. They're in my dorm room. It's locked if I'm not there. I don't know of any businesses which leave valuable information on PCs which are not in locked offices. I don't CARE about security on a single-user machine. If I had my own VAX with VMS, and it wasn't networked, I could disable all the security and just run with all the privileges all the time. (I wouldn't, because security helps prevent mistakes too, but I could.) If you want an OS for a multi-user machine, you need security. Anton +---------------------------+------------------------+ | Anton Rang (grad student) | "VMS Forever!" | | Michigan State University | rang@cpswh.cps.msu.edu | +---------------------------+------------------------+ ----------------------------- From: Ted Lemon <mellon@zayante.pa.dec.com> Subject: Re: GNU os suggestions -- system data interfaces Date: 7 Jun 89 00:07:22 GMT Sender: news@decwrl.dec.com To: unix-wizards@sem.brl.mil rmtodd@uokmax.UUCP (Richard Michael Todd) sez: >Getting kernel data values isn't too much of a problem (once you master >nlist and friends), though as UNIX is currently implemented it's extremely >ugly. The main problem I seem to run into is figuring out just what kernel >variable you need, what format it is in, and what it means once you've got >it. Well, that's part of it. The other part is that thrashing through the kernel's name list takes a lot of time on small machines. It is highly undesirable to have to do this on a regular basis. On a typical small machine, doing a ps is an unbelievably slow operation. It really shouldn't be. Usually, when you do a ps, it's because the system is misbehaving, often because it's overloaded. The last thing you need is some mondo bizarro program that thrashes through the kernel's name list and brings the CPU to its knees in the process. _MelloN_ ----------------------------- From: Keith Farrar <keith@xanadu.com> Subject: inode table hacking Date: 6 Jun 89 21:24:41 GMT Followup-To: keith@xanadu.UUCP (Keith Farrar) Keywords: kernel, inodes, kmem To: unix-wizards@sem.brl.mil I would like to increase the number of entries I can stuff into my inode table. I am using a sun4/280 with 32MB, and I've been plagued by "out of inode" errors daily for the last few weeks. This particular problem pops up as soon as automount (SunOS 4.0.1) starts mounting remote filesystems. Keith --------------------------------------------------------------- I don't think I like your tone of voice. --------------------------------------------------------------- ----------------------------- From: "L. Mark Larsen" <lml@cbnews.att.com> Subject: Re: Positional Parameter Settin in function Date: 6 Jun 89 22:05:50 GMT To: unix-wizards@sem.brl.mil # In article <570024@hpsemc.HP.COM> gph@hpsemc.HP.COM (Paul Houtz) writes: # # In my ksh, the "set" command doesn't seem to work within a function: # It works in a function - it just sets the positional parameters for *that* function - not the current shell. # As a shell command I do the following: (example deleted) # # Is this a bug in ksh? Is it a feature? Is there some explanation of this # feature? This is not a bug but the way functions are supposed to work. To modify the positional parameters of the current shell by executing some shell script, use ". filename [args]" (reads the file and executes it in the current environment). Note that Bourne shell does not allow arguments and that in ksh, passing arguments in this manner is the same as setting the positional parameters of the current shell. cheers, -lml ----------------------------- From: David Elliott <dce@solbourne.com> Subject: Re: GNU os suggestions -- system data interfaces Date: 7 Jun 89 00:51:40 GMT To: unix-wizards@sem.brl.mil In article <3307@uokmax.UUCP> rmtodd@uokmax.UUCP (Richard Michael Todd) writes: >In article <1344@marvin.Solbourne.COM> dce@Solbourne.com (David Elliott) writes: >>Two items that I find particularly annoying are getting kernel data >>values and handling system files. > Getting kernel data values isn't too much of a problem (once you master >nlist and friends), though as UNIX is currently implemented it's extremely >ugly. Neither is programming a 6502, but luckily we don't have to program them. The whole point of my posting was to point out an area that could use some improvement, and GNU is all about improving Unix. As far as it not being that much of a problem, it is, as I pointed out a problem if the kernel you are running is not the same as the one that you ask nlist to look at. > Granted, a better interface to reading kernel internal variables and >structures would be nice, but unless the variables are documented it >won't do you much good. Agreed. If the interface were, for example, a system call made specifically for getting this type of kernel data, you'd have to document it. Hopefully, you could even make some of it standard (load average, for example). Also, why not have such an interface? Nlist really doesn't give you much of an advantage, and it's really gross to have to go reading symbols out of a file, and then (sometimes) masking the address, and then reading it. Why not go ahead and implement a standard, simple interface? >Well, really such programs ought to be setgid kmem (or whatever group >owns /dev/kmem), but still your point applies--it makes it impossible for >Joe User to write such programs himself, and is a pain even for Joe Sysadmin. No, they should not "ought" to be, they "must" be. This is because /dev/kmem is a security hole. For years, /dev/mem was readable by everyone, and people, like the authors of various Emacs variants, used that. I'll argue that /dev/kmem is more of a security hole now than ever. I've seen two cases in the last year in which someone changed /dev/kmem to be readable by everyone because of some free software needing to use it. There are a lot of people who don't know it's a security hole, so people start using it. -- David Elliott dce@Solbourne.COM ...!{boulder,nbires,sun}!stan!dce ----------------------------- From: John Chambers <jc@minya.uucp> Subject: Building a Sun boot tape. Date: 6 Jun 89 16:05:55 GMT To: unix-wizards@sem.brl.mil Well, I tried this in comp.sys.sun, which is moderated, and the mail has just bounced back to me (several times, even ;-), so I thought I'd go to the real experts... A situation has come up where it'd be read nice to be able to build a Sun boot tape. The Sun manuals don't seem to cover this. Does anyone know how to do it? The scenario is a client who has a "turnkey" system that is in an unknown initial state, and we'd like to send a tape that can install a standard set of stuff. The users at the system are likely to be real dummies when it comes to computers, and they aren't stongly motivated to become Sun hackers. Imagine your typical army enlisted fellow, and you have about the right sort of image. We can get at the EPROMs in the boxes before delivery, and we believe that we can set them up so that they will first attempt to boot from tape, if that exists and contains a bootable file system, falling back to disk if the tape isn't bootable. The idea then is that the recipient of a tape could just insert it in the drive, turn on the machine, and watch it load itself. It'd be easy enough to put invocations of our own programs into /etc/rc.boot, and we'd be off and installing. In extreme cases, we could even put our own proxy in for /etc/init, which would do its thing, then do a couple of renames to install the real init, and exec it. That's elementary for a Unix hacker. The problem is how we get our stuff into a bootable tape, which is obviously not in the usual tar or cpio formats. I expect my mailbox to fill up with scripts from people wanting to show off their expertise... -- -- All opinions Copyright 1989 by John Chambers; for licensing information contact: John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393) ----------------------------- From: David Elliott <dce@solbourne.com> Subject: sh functions with "local variables" Date: 7 Jun 89 03:10:48 GMT To: unix-wizards@sem.brl.mil Here's an interesting problem for all of you sh/ksh wizards out there. I normally write shell scripts using a template like this: main() { ... } sub1() { ... } ... main ${1+"$@"} # don't ask, just use it Now, in modern versions of sh (post SVR2, I think), function parameters are local to the function, but there's no way to have local variables otherwise. Let me clarify this a little. Yes, if you force a subshell, either by parenthese or redirection, the changes in the subshell don't affect the main thread, but that's not really what I'm looking for. Now, if the function doesn't have any arguments, or if you can use the arguments early and get rid of them, you can use "set" to put values in $1-$9, which is one way to have local variables. Still, real local variables would be great. Of course, arrays would be nice, too. Maybe it's time to implement sh++? -- David Elliott dce@Solbourne.COM ...!{boulder,nbires,sun}!stan!dce ----------------------------- End of UNIX-WIZARDS Digest **************************