Returned mail: User unknown
Mail Delivery Subsystem
MAILER-DAEMON at slcs.slb.com
Wed Jun 7 22:59:17 AEST 1989
----- Transcript of session follows -----
>>> RCPT To:<guthery at ASC.SLB.COM>
<<< 550 <guthery at ASC.SLB.COM>... User unknown
550 asc.slb.com::guthery... User unknown
----- Unsent message follows -----
Return-Path: <unix-wizards at 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 at 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 at brl.mil>
Subject: UNIX-WIZARDS Digest V7#100
To: UNIX-WIZARDS at brl.mil
Reply-To: UNIX-WIZARDS at brl.mil
Message-Id: <8906070245.aa26024 at 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 at 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 at sem.brl.mil
/* Written 1:55 pm Jun 3, 1989 by haynes at ucbarpa.Berkeley.EDU in s.cs.uiuc.edu:comp.unix.wizards */
In article <2322 at thor.acc.stolaf.edu> mike at 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 at 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 at twwells.uucp>
Subject: Re: keyscan wanted
Date: 5 Jun 89 23:59:54 GMT
Expires:
Sender:
Followup-To:
Keywords:
To: unix-wizards at sem.brl.mil
In article <607 at wn2.sci.kun.nl> medfys at wn2.sci.kun.nl (Victor Langeveld/Tjeerd Dijkstra) writes:
: In article <1006 at twwells.uucp>, bill at twwells.uucp (T. William Wells)
: writes:
: > In article <475 at wn2.sci.kun.nl> medfys at 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 at 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 at sem.brl.mil
In article <11993 at well.UUCP> Jef Poskanzer <pokey at 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 at lynx.uucp>
Subject: access()
Date: 5 Jun 89 17:30:15 GMT
To: unix-wizards at 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 at 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 at sem.brl.mil
In article <19851 at adm.BRL.MIL> cherry.STCWR at 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 at alanine.phri.nyu.edu
"The connector is the network"
-----------------------------
From: "Bruce G. Barnett" <barnett at 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 at crdgw1.crd.ge.com
Keywords: OS filenames
To: unix-wizards at sem.brl.mil
In article <9422 at alice.UUCP>, andrew at 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 at crdgw1.ge.com> a.k.a. <barnett@[192.35.44.4]>
uunet!crdgw1.ge.com!barnett barnett at crdgw1.UUCP
-----------------------------
From: Andrew Klossner <andrew at frip.wv.tek.com>
Subject: sys V.3.2 swap problem: unterminated sleep?
Date: 5 Jun 89 16:23:59 GMT
Sender: nobody at orca.wv.tek.com
To: unix-wizards at 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 at relay.cs.net) [ARPA]
-----------------------------
From: "John F. Haugh II" <jfh at rpp386.dallas.tx.us>
Subject: Re: GNU, security, and RMS
Date: 6 Jun 89 05:50:26 GMT
To: unix-wizards at sem.brl.mil
In article <2322 at thor.acc.stolaf.edu> mike at 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 at rpp386.Cactus.Org | and it's BLUE."
UucpNet : <backbone>!bigtex!rpp386!jfh +--------------------------------------
-----------------------------
From: "John F. Haugh II" <jfh at rpp386.dallas.tx.us>
Subject: Re: Getting rid of the root account
Date: 6 Jun 89 06:10:42 GMT
To: unix-wizards at sem.brl.mil
In article <1961 at ubu.warwick.UUCP> mirk at 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 at rpp386.Cactus.Org | and it's BLUE."
UucpNet : <backbone>!bigtex!rpp386!jfh +--------------------------------------
-----------------------------
From: Richard Michael Todd <rmtodd at uokmax.uucp>
Subject: Re: GNU os suggestions -- system data interfaces
Date: 5 Jun 89 22:09:37 GMT
To: unix-wizards at sem.brl.mil
In article <1344 at marvin.Solbourne.COM> dce at 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 at chinet.chi.il.us or rmtodd at uokmax.ecn.uoknor.edu
aka ...!sun!texsun!uokmax!rmtodd
"Never re-invent the wheel unnecessarily; yours may have corners."-henry at utzoo
-----------------------------
From: Andrew Klossner <andrew at frip.wv.tek.com>
Subject: Re: GNU OS suggestion -- memory "advice"
Date: 5 Jun 89 19:46:16 GMT
Sender: nobody at orca.wv.tek.com
To: unix-wizards at 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 at relay.cs.net) [ARPA]
-----------------------------
From: John F Carr <jfc at 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 at bloom-beacon.mit.edu
To: unix-wizards at sem.brl.mil
In article <3306 at cps3xx.UUCP> rang at 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 at athena.mit.edu)
-----------------------------
From: Paul Houtz <gph at hpsemc.hp.com>
Subject: Positional Parameter Settin in function
Date: 5 Jun 89 23:33:11 GMT
To: unix-wizards at 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 at hplabs.HP.COM
-----------------------------
From: Owner <donegan at stanton.uucp>
Subject: Directory Editor
Date: 5 Jun 89 00:04:06 GMT
Followup-To: poster
Keywords: directory,damaged,fix
To: unix-wizards at 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 at stanton.UUCP || donegan%stanton at UUCP
-----------------------------
From: Robert Cousins <rec at 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 at 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 at 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 at sem.brl.mil
In article <209 at sopwith.UUCP> snoopy at sopwith.UUCP (Snoopy) writes:
> In article <1989May26.224924.5293 at eci386.uucp> woods at 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 at sopwith.UUCP> snoopy at 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 at sopwith.UUCP> snoopy at 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 at smoke.brl.mil>
Subject: Re: Getting rid of the root account
Date: 6 Jun 89 15:08:25 GMT
To: unix-wizards at sem.brl.mil
In article <16638 at rpp386.Dallas.TX.US> jfh at 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 at 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 at 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 at 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 at 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 at ibm.com | might completely disagree with me. |
| Bitnet: jparnas at yktvmx.bitnet \---------------------------------------|
| Home: ..!uunet!bywater!acheron!larouch!jparnas | Phone: (914) 945-1635 |
--------------------------------------------------------------------------------
-----------------------------
From: Scott Alexander <salex at grad1.cis.upenn.edu>
Subject: Re^2: GNU, security, and RMS
Date: 6 Jun 89 17:48:32 GMT
Sender: news at SCOTTY.DCCS.UPENN.EDU
To: unix-wizards at sem.brl.mil
In article <2698 at solo1.cs.vu.nl> maart at cs.vu.nl (Maarten Litmaath) writes:
>jamesa at 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 at 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 at 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 at 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 at auspex.auspex.com>
Subject: Re: keyscan wanted
Date: 6 Jun 89 18:30:10 GMT
To: unix-wizards at 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 at auspex.auspex.com>
Subject: Re: keyscan wanted
Date: 6 Jun 89 18:33:48 GMT
To: unix-wizards at 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 at ut-emx.uucp>
Subject: Re: Re^2: GNU, security, and RMS
Date: 6 Jun 89 19:53:19 GMT
Sender: news at ut-emx.uucp
Posted: Tue Jun 6 14:53:19 1989
To: unix-wizards at 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 at 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 at 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 at sem.brl.mil
In article <1989Jun3.004854.18111 at light.uucp>,
bvs at 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 at nyu.edu
...!cmcl2!edler
(212) 998-3353
-----------------------------
From: Jan Edler <edler at 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 at sem.brl.mil
In article <17891 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>In article <11993 at well.UUCP> pokey at 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 at nyu.edu
-----------------------------
From: Dinah Anderson <dinah at shell.uucp>
Subject: Re:Getting rid of the root account (Was: GNU OS)
Date: 6 Jun 89 16:28:51 GMT
Sender: usenet at shell.com
To: unix-wizards at sem.brl.mil
In article <3, I think> jfh at 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 at shell.uucp>
Subject: Re: GNU, security, and RMS
Date: 6 Jun 89 16:33:54 GMT
Sender: usenet at shell.com
To: unix-wizards at sem.brl.mil
In article <29457 at ucbvax.BERKELEY.EDU>, haynes at 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 at sc50.uucp>
Subject: redirect stdin when using execl
Date: 6 Jun 89 14:26:11 GMT
Keywords: execl redirect stdin <
To: unix-wizards at 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 at cpsin3.cps.msu.edu>
Subject: Re: GNU OS suggestion -- memory "advice"
Date: 6 Jun 89 22:55:18 GMT
Sender: usenet at cps3xx.uucp
To: unix-wizards at sem.brl.mil
In article <3496 at orca.WV.TEK.COM> andrew at 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 at cpswh.cps.msu.edu |
+---------------------------+------------------------+
-----------------------------
From: Anton Rang <rang at cpsin3.cps.msu.edu>
Subject: Re: Getting rid of the root account
Date: 6 Jun 89 23:06:08 GMT
Sender: usenet at cps3xx.uucp
To: unix-wizards at sem.brl.mil
In article <10370 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
>In article <16638 at rpp386.Dallas.TX.US> jfh at 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 at cpswh.cps.msu.edu |
+---------------------------+------------------------+
-----------------------------
From: Anton Rang <rang at cpsin3.cps.msu.edu>
Subject: Re: security (PCs)
Date: 6 Jun 89 23:12:35 GMT
Sender: usenet at cps3xx.uucp
To: unix-wizards at sem.brl.mil
In article <19896 at adm.BRL.MIL> bzs at 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 at cpswh.cps.msu.edu |
+---------------------------+------------------------+
-----------------------------
From: Ted Lemon <mellon at zayante.pa.dec.com>
Subject: Re: GNU os suggestions -- system data interfaces
Date: 7 Jun 89 00:07:22 GMT
Sender: news at decwrl.dec.com
To: unix-wizards at sem.brl.mil
rmtodd at 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 at xanadu.com>
Subject: inode table hacking
Date: 6 Jun 89 21:24:41 GMT
Followup-To: keith at xanadu.UUCP (Keith Farrar)
Keywords: kernel, inodes, kmem
To: unix-wizards at 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 at cbnews.att.com>
Subject: Re: Positional Parameter Settin in function
Date: 6 Jun 89 22:05:50 GMT
To: unix-wizards at sem.brl.mil
# In article <570024 at hpsemc.HP.COM> gph at 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 at solbourne.com>
Subject: Re: GNU os suggestions -- system data interfaces
Date: 7 Jun 89 00:51:40 GMT
To: unix-wizards at sem.brl.mil
In article <3307 at uokmax.UUCP> rmtodd at uokmax.UUCP (Richard Michael Todd) writes:
>In article <1344 at marvin.Solbourne.COM> dce at 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 at Solbourne.COM
...!{boulder,nbires,sun}!stan!dce
-----------------------------
From: John Chambers <jc at minya.uucp>
Subject: Building a Sun boot tape.
Date: 6 Jun 89 16:05:55 GMT
To: unix-wizards at 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 at solbourne.com>
Subject: sh functions with "local variables"
Date: 7 Jun 89 03:10:48 GMT
To: unix-wizards at 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 at Solbourne.COM
...!{boulder,nbires,sun}!stan!dce
-----------------------------
End of UNIX-WIZARDS Digest
**************************
More information about the Comp.unix.wizards
mailing list