Unix-Wizards-Request@BRL.ARPA (12/04/87)
UNIX-WIZARDS Digest Thu, 03 Dec 1987 V4#090
Today's Topics:
Re: Wierd 3b inode problem with news.
setpgrp() bug?
Re: setpgrp() bug?
Re: termcaps vs terminfo
Re: login prompt not staying set
Re: Request for human interface design anecdotes
Re: Setting process groups
Re: //host vs "mount point"
Re: The whole prompt string thing (was: PS1 and the bourne shell...)
Re: more rm insanity
Re: Bug in Ultrix2.0?
Re: POSIX execlfd and execvfd proposal
globbing in the shell (Was Re: more rm insanity)
leaving users out of login group
Re: Need a XENIX VT100 emulator
Re: Posting easily-exploited security holes
sendmail alias strangeness
-----------------------------------------------------------------
From: Jim Hanko <hanko@edge.uucp>
Subject: Re: Wierd 3b inode problem with news.
Date: 24 Nov 87 17:02:15 GMT
Keywords: SysV bugs
To: unix-wizards@SEM.BRL.MIL
In article <993@edge.UUCP> hanko@edge.UUCP (Jim Hanko) writes:
>In article <325@boole.acc.virginia.edu> slb@boole.acc.virginia.edu writes:
>> .... So, it seems to me that the problem could only arise when
>>there were exactly enough inodes left between the starting point and the
>>end to fill the cache (any less and you'd reset the starting point, any
>>more and there'd be one to find on the next search) the last time around.
>>But it doesn't seem as though this could arise often enough to account
>>for how often I see it. What am I missing? ...
>
> ( vigorous hand waving in lieu of explanation )
After further reflection, I believe I can explain more clearly.
1) The relevant features of the ialloc() algorithm are:
- A cache of NICINOD (100) free inodes is maintained.
- When the cache becomes empty, a linear scan through the inode
table is performed to find free inodes.
- When the cache becomes full (due to file deletions), a new
(relatively random) scan point is established, based on the
last freed inode.
- The bug occurs when the scan takes exactly the last NICINOD
free inodes in the table.
2) On a 'normal' file system, file creations and deletions are not well
correlated, and occur with approximately equal frequency. Therefore,
the cache usually contains sufficient free inodes, and the scan is
rarely necessary. When it is, typically one short scan from a random
point usually takes care of it. Therefore, the bug almost never
shows up in this type of file system.
3) A 'net news' file system experiences repeated episodes where many
new files are created at once (new articles arrive), intermixed with
episodes where many files are deleted at once (articles expire,
packed news files deleted). If enough new files are created at once,
relative to the number of free inodes, the likelyhood becomes high
that a scan from any random point in the table will reach the end.
Normally, it will then resume at the beginning. However, on average,
1% of the time (i.e. 1/NICINODE scans) the bug will strike instead.
If it doesn't, the periods of file deletion will establish a new
(somewhat) random starting point, creating a new opportunity for the
bug to appear during the next file creation binge.
Therefore, If you don't have a source license and can't install the fix I
posted in an earlier article, I can only suggest that you keep a large
number of free inodes in your 'net news' file system. This will reduce, but
not eliminate, the probability of the bug affecting you.
---
Jim Hanko ...{mot|ism780|oliveb}!edge!hanko
Edge Computer,
Scottsdale AZ
--
-----------------------------
From: Brian Chapman <chapman@sco.COM>
Subject: setpgrp() bug?
Date: 1 Dec 87 09:24:59 GMT
Keywords: BSD setpgrp kill
To: unix-wizards@brl-sem.arpa
In article <1261@saturn.ucsc.edu> haynes@ucscc.UCSC.EDU (Jim Haynes) writes:
< Incidentally, there's a security hole connected with setpgrp()
< in that the system doesn't check whether the pgrp number you
< proffer is already in use by somebody else. So with a little
< cleverness you can attach to the pgrp of someone else's process
< and proceed to kill it.
<
< haynes@ucscc.ucsc.edu
< haynes@ucscc.bitnet
< ..ucbvax!ucscc!haynes
Humm, are you talking about BSD or SYS V?
I have SYS V manuals and kernel source right here handy
and there is nothing obviously wrong.
SYSTEM V setpgrp() takes no arguments and sets the process
group number equal to the pid. Elsewhere in the kernel the
definition of a process group leader is the process where
p->p_pid == p->p_pgrp.
So, you cannot get in someone elses process group as long as
the group leader is alive. OK... what if the leader is
dead (the user nohuped some processes and logged out).
I looked at exit() and right in the loop where the
children are given to proc 1 there is a check for
if(p->p_pid == q->p_pgrp) q->p_pgrp = 0;
where p is the process dieing and q is the pointer
that is looping through the proc table.
So, you cannot get into a process group as long as the
process group leader is alive and if the group leader
dies then the process group is dissolved.
Well, I looked at kill just for good measure. The
arguments of 0 "kill my process group" and the
arguments < 0 for killing some process group == abs(arg)
all check that the uid/ruid of the user is either
0 or equal to the p_uid/p_suid of the process.
So even if I missed something in the process group stuff
it doesn't look like kill() would do anything for you.
All this would lead me to believe that you are talking
about BSD. But then I _know_ you administer BSD systems!
-- Brian Chapman (ucsc alum)
-----------------------------
From: Ron Natalie <ron@topaz.rutgers.EDU>
Subject: Re: setpgrp() bug?
Date: 2 Dec 87 20:33:05 GMT
Keywords: BSD setpgrp kill
To: unix-wizards@brl-sem.arpa
What process groups do in system V and BSD are completely different.
The bug only applies to the BSD tty driver.
-Ron
-----------------------------
From: Martin Zam <zam@mhuxu.uucp>
Subject: Re: termcaps vs terminfo
Date: 1 Dec 87 18:52:11 GMT
To: unix-wizards@SEM.BRL.MIL
Look up the man page for "tic".
-----------------------------
From: rjd@occrsh.ATT.COM
Subject: Re: login prompt not staying set
Date: 1 Dec 87 19:13:00 GMT
Nf-ID: #N:occrsh.ATT.COM:142700001:000:2032
Nf-From: occrsh.ATT.COM!rjd Dec 1 13:13:00 1987
To: unix-wizards@SEM.BRL.MIL
> The manual pages for sys V unix state that the prompt you get to
> log in comes from a field in gettydefs. In customizing my 3B2, I
> edited the login field of this file that originally said "login:"
> I changed the prompt to something different, but this new prompt
> will only show up on the first login attempt. If this login fails
> for some reason, the prompt goes back to "login:" even though I
> have edited out every occurence of this prompt in /etc/gettydefs.
As it should be. First a lesson on the sequence of events up to
the point in question that happen when a user logs in:
1) /etc/getty is the first program run on a port (started by /etc/init
according to the information in /etc/inittab). It sets up the
initial port protocol (as defined in gettydefs) and gives the
login message (also specified in gettydefs).
2) Once a user (or whatever) responds to that, possibly customized,
login prompt, the getty performs an exec of the form:
login <your response to the getty login: prompt>
3) The login program then searches the /etc/passwd file to see if the
login exists and if so, if it has a password. If it does not exist
or does and has a password, the program prompts for it.
4) Now here's the part you are interested in: If the login does not
exist and anything is entered or if the login exists, is passworded,
and the incorrect password is entered, the *login* program prints the
"Login incorrect" message and then RE-PROMPTS FOR THE LOGIN ID with
its own prompt, which is "login:"....
So your solution is to either modify the /bin/login program with your
new prompt or have the login program terminate after an incorrect attempt
(maybe by picking a short timeout interval for getty, which does not
sound like a very good method to me.)
If you enter a "control-d" at this /bin/login login: prompt, it will
exit and return you to init, which will start up the getty running at
the protocols set up in gettydefs, thus reprinting the /etc/gettydefs
login prompt.
Randy
-----------------------------
From: Brandon Allbery <allbery@ncoast.uucp>
Subject: Re: Request for human interface design anecdotes
Date: 2 Dec 87 00:01:21 GMT
Followup-To: comp.unix.wizards
To: unix-wizards@SEM.BRL.MIL
As quoted from <10515@brl-adm.ARPA> by dsill@NSWC-OAS.arpa (Dave Sill):
+---------------
| >It is trivial to say "ln /bin/cat /bin/type"; why don't we do it?
|
| One reason is that linking `type' to `cat' doesn't create a man page
| for `type'.
+---------------
....but once you bring man pages into it, we got far worse problems than
cryptic commands and typos in * commands!
--
Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu
{hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery
Moderator of comp.sources.misc
-----------------------------
From: Duncan McEwan <duncan@comp.vuw.ac.nz>
Subject: Re: Setting process groups
Date: 2 Dec 87 03:39:08 GMT
To: unix-wizards@SEM.BRL.MIL
In article <910@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes:
>In article <1765@unc.cs.unc.edu>, southard@unc.cs.unc.edu writes:
>> How can I determine what process group id's are not in use?
>
>The only way, as far as I know, to determine what process groups are in
>use is a ps-like program which scans the process table.
>
Although the man page doesn't say so, killpg(2) behaves like kill(2)
when given signal 0 as its second argument. That is, it checks if you
would be able to send a signal to the given process group. So if you
get the error ESRCH back from a "killgp(pgrp, 0)" you know that there
are no processes in that process group. Not that this info is
particularly useful here - Der Mouse's suggestion of adhering to the
convention of using the process group leader's pid is more sensible
than something like
for (i = 1; i <= 32767; i++)
if (killpg (i, 0) < 0 && errno == ESRCH)
break
...
BTW, while I was playing around with this, I noticed that the man page
for setpgrp(2) does not say it is an error to put yourself in an existing
process group. A quick look at the 4.3bsd code shows it isn't (it makes
no checks regarding the process group). Not that this causes any harm
anyway - if you try to killpg a process group containing processes that
don't belong to you, only your own get killed (unless you happen to
be superuser - something to be said for being careful with programs that
run with uid 0 and use killpg).
One other thing I noticed was that on our pyramid running OSx 4.0,
killpg returns no error if it could kill any of the processes in the
process group. On a VAX running 4.3bsd it returns EPERM if there are
any that it couldn't kill. Is OSx's behaviour a hangover from it's
4.2 origins, or is it a Pyramid `enhancement' to the way 4.3 works.
The Pyramid behaviour seems more useful to me.
Duncan
Domain: duncan@comp.vuw.ac.nz Path: ...!uunet!vuwcomp!duncan
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: Re: Setting process groups
Date: 2 Dec 87 22:06:46 GMT
To: unix-wizards@brl-sem.arpa
In article <13102@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes:
>Although the man page doesn't say so, killpg(2) behaves like kill(2)
>when given signal 0 as its second argument.
(Both routines use the same code. It is indeed undocumented.)
>BTW, while I was playing around with this, I noticed that the man page
>for setpgrp(2) does not say it is an error to put yourself in an existing
>process group.
.TH SETPGRP 2 "May 9, 1985"
...
.TP 15
[ESRCH]
The requested process does not exist.
.TP 15
[EPERM]
The effective user ID of the requested process is different
from that of the caller and the process is not a descendent
of the calling process.
.SH "SEE ALSO"
getpgrp(2)
So it is implicit in the section listing for `EPERM'.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: "Timothy R. Giebelhaus" <giebelhaus@hi-csc.uucp>
Subject: Re: //host vs "mount point"
Date: 2 Dec 87 06:05:00 GMT
To: unix-wizards@brl-sem.arpa
In article <35000@sun.uucp>, brent%terra@Sun.COM (Brent Callaghan) writes:
> Another good reason for "just another directory" is that it leaves
> open the possibility of having nodes other than host names under
> the directory. Consider the following:
>
> /host/<hostid> - file systems on other hosts
> /home/<userid> - users home directories
> /src/<version> - other source trees
>
> There's not always a need to know the host on which a file
> resides. There are good reasons for hiding this information
> e.g. because you don't know the disk partition a file is in
> the administrator can relocate disk partitions freely.
> Similarly a /home directory allows a user to move to another host
> and have his/her home directory mounted automatically.
But the // directory is just another directory. It is simply a
directory above the / directory. The only things special about it
is I cannot reference a remote // directory (I can only reference
the / directory and below) and the // name its self. I can put
links in or anything I want.
I'm a bit confused about how the /home directory works. We have
about 30 suns and I have been trying to figure out how to arrange
the cross mounts and such. We have four servers and each server
has at least one partition of user files. I can't figure out
how to get the path to the home directory look the same for all
people no matter what server they log in on and still make it so
I can move them from server to server without them knowing.
What I am doing now is making links from a /udd directory. All users
have a link in the /udd directory to either //host/user/user-name
on the apollo or /n/host-name/user-name. host-name is the name of
the host, but it is the directory (partition) on that host with the
user files in it. I have some steps so that the loss of the /udd dir
is not so bad like putting the /n/host-name/user-name in the /etc/passwd
file and keeping replicas of the /udd dir.
I'm still not happy with this though. Is there a better way?
P.S.
About my previous message, I do know the lock protocol is seperate from
nfs. I meant to say it was added for use with nfs, not a part of nfs
which could not be seperated. I'll put more effort in remaining clear
in the future.
--
---------------------------------
UUCP: {uunet, ihnp4!umn-cs}!hi-csc!giebelhaus
ARPA: hi-csc!giebelhaus@umn-cs.arpa
Nobody I know admits to sharing my opinions. I don't even have a pet.
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: Re: //host vs "mount point"
Date: 2 Dec 87 09:47:09 GMT
To: unix-wizards@SEM.BRL.MIL
In another article whose referent has been deleted, Doug Gwyn gives
the following example:
>> grep -i gwyn /n/ucbvax/n/monet/etc/passwd
>> should work, but I doubt that
>> grep -i gwyn //ucbvax//monet/etc/passwd
>> would.
In article <9446@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew
Klossner) writes:
>What you really want (at least in the environment I work in) is
> grep -i gwyn //monet/etc/passwd
>All hosts reside in the same flat name space....
This one is too easy. There are places that, for administrative
reasons (read `paranoia and/or pinheadedness' :-) ), *require*
such indirection. (I am not claiming that UCB is one such.)
Incidentally, I think the Internet growth has shown why flat name
spaces are bad.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Ke Kupua <matt@oddjob.UChicago.EDU>
Subject: Re: //host vs "mount point"
Date: 2 Dec 87 15:21:37 GMT
To: unix-wizards@brl-sem.arpa
In article <9591@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
) Incidentally, I think the Internet growth has shown why flat name
) spaces are bad.
grep -i gwyn //edu//berkeley//monet/etc/passwd
??
chuckle, snort.
Matt
-----------------------------
From: Doug Gwyn <gwyn@brl-smoke.arpa>
Subject: Re: The whole prompt string thing (was: PS1 and the bourne shell...)
Date: 2 Dec 87 07:00:14 GMT
To: unix-wizards@SEM.BRL.MIL
In article <305@caus-dp.UUCP> marcos@caus-dp.UUCP (Marcos R. Della) writes:
>... There are lots of interesting ideas and designs, but so far,
>nothing is working on this little problem. Has anyone out there actually
>done this and gotten it to work?
Dammit, didn't you read my posting? We do this all the time here.
I explained what is required and don't feel like repeating myself.
-----------------------------
From: Randy Orrison <randy@umn-cs.cs.umn.EDU>
Subject: Re: The whole prompt string thing (was: PS1 and the bourne shell...)
Date: 2 Dec 87 21:49:09 GMT
Posted: Wed Dec 2 15:49:09 1987
To: unix-wizards@SEM.BRL.MIL
In article <6773@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <305@caus-dp.UUCP> marcos@caus-dp.UUCP (Marcos R. Della) writes:
>>... There are lots of interesting ideas and designs, but so far,
>>nothing is working on this little problem. Has anyone out there actually
>>done this and gotten it to work?
>
>Dammit, didn't you read my posting? We do this all the time here.
>I explained what is required and don't feel like repeating myself.
Come on people, settle down. The problem is obvious:
Marcos has an older version of the bourne shell.
Marcos: YOU CAN'T DO IT. Get a newer version of sh or get ksh or
get csh.
Doug: SETTLE DOWN. The poor guy doesn't know why what everyone
says works won't work for him. Give him a break.
I haven't heard anyone talking about versions of sh or ksh here. What versions
of each are needed to do these things? Obviously, all versions don't do command
evaluation or variable substitution when displaying the prompt.
-randy
--
Randy Orrison, University of Minnesota School of Mathematics | May the smiley
UUCP: {ihnp4, seismo!rutgers, sun}!umn-cs!randy | O__\,
ARPA: randy@ux.acss.umn.edu BITNET: randy@umnacca | O /'
Disclaimer: No one is silly enough to pay me to do this. | be with you!
-----------------------------
From: Doug Gwyn <gwyn@brl-smoke.arpa>
Subject: Re: The whole prompt string thing (was: PS1 and the bourne shell...)
Date: 3 Dec 87 06:30:57 GMT
To: unix-wizards@SEM.BRL.MIL
In article <3045@umn-cs.cs.umn.edu> randy@umn-cs.UUCP (Randy Orrison) writes:
>I haven't heard anyone talking about versions of sh or ksh here. What versions
>of each are needed to do these things? Obviously, all versions don't do command
>evaluation or variable substitution when displaying the prompt.
You do NOT need for the shell to do tricks while printing the value of PS1,
although if your shell does that then it can be used to do what was requested.
Any shell that supports shell functions will support user definition of a
command to be used instead of the built-in "cd", that will not only perform
cd but also update PS1. UNIX System V shells starting with Release 2.0 have
such support. For such a function to also be called "cd", so you can't
forget to use the new function and mistakenly invoke just the built-in,
you need a shell that permits functions to redefine builtin names; the UNIX
System V shells do not permit this. However, if you have a valid source
license you can obtain the BRL version of the SVR2 Bourne shell, which has
this and much more.
-----------------------------
From: Doug Gwyn <gwyn@brl-smoke.arpa>
Subject: Re: more rm insanity
Date: 2 Dec 87 07:08:22 GMT
To: unix-wizards@brl-sem.arpa
In article <1890@celtics.UUCP> roger@celtics.UUCP (Roger B.A. Klorese) writes:
>Because, unless one knows and fully understands that globbing is done by
>the shell and not the program, one would expect, as with other operating
>systems...
I guess this adds support to the notion that the normal UNIX shell
interface is not suitable for naive users. Back when I was first
learning to use UNIX, nobody considered it unreasonable to read
the UNIX tutorial contained near the beginning of the user documents
that came with the system. I'm sure that the notion that * and ?
were processed by the shell was made clear there. In fact that is
a key "win" of UNIX over OSes that make applications deal with
globbing.
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: Re: more rm insanity
Date: 2 Dec 87 10:13:06 GMT
To: unix-wizards@SEM.BRL.MIL
>In article <9555@mimsy.UUCP> I asked:
>>Why is it that people have so much trouble figuring out how to remove
>>files whose names start with `-'?
In article <1890@celtics.UUCP> roger@celtics.UUCP (Roger B.A. Klorese) writes:
>one [might] expect, as with other operating systems, that the process is:
>
>- pick up the command and its options from the entered command
>- pick up the filenames to which the command is to be applied from the
> supplied filenames, expanding wildcards if necessary
Even if naive users do hold this (incorrect) belief, why, after
discovering the file called `-b' in the current directory and trying
to `rm -b' and then `rm -*' and `?b', do these people not think
`grr, what a stupid rm, it expands the ?b and *then* looks to see
if it has an option ... how do I tell the <censored> thing not to
do that?' Experience tells me that they *do* think this, which
makes it the basic problem worse yet. In an attempt to get them
to learn something about the system, I sometimes answer with this:
0. Every file has more than one name. Tell me another name
for the file `-b' in your current directory.
It has yet to work, so I expand a bit:
1. Where is your home directory?
After a small delay, I usually get the answer `~'.
2. Now what is another name for the file `-b' in your
home directory?
Sometimes I have to supply the answer for this, too:
3. One is ~/-b. Notice anything special about this name
versus that other one?
Most of them catch on at this point, but sometimes it takes two
more questions:
4. What is the first character of each of those two names?
5. What character precedes rm options?
At the end of the six-questions game, they have all figured it
out. Do they learn something? I wish I could tell. . . .
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: "Richard A. O'Keefe" <ok@quintus.uucp>
Subject: Re: more rm insanity
Date: 2 Dec 87 23:41:30 GMT
To: unix-wizards@SEM.BRL.MIL
In article <1890@celtics.UUCP> roger@celtics.UUCP (Roger B.A. Klorese) writes:
> >Because, unless one knows and fully understands that globbing is done by
> >the shell and not the program, one would expect, as with other operating
> >systems...
>
In article <6774@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> In fact that is a key "win" of UNIX over OSes that make applications deal
> with globbing.
Have you ever used TOPS-10? That was a system where globbing was done by
the program, not the shell. Result? No two programs had exactly the
same syntax for file names (some would let you quote strange characters
by writing octal, some wouldn't, some allowed directories, some didn't,
&c &c). And of course user-programs and commands HAD to use different
syntax... Doug Gwyn is absolutely right: doing file-name expansion in
the shell so that EVERY command does it EXACTLY the same way is wonderful.
If rm did its own wild-carding, you'd STILL have the "rm *" problem
(after all, someone might *mean* that) and you'd have the additional
problem of not being quite sure what wild-carding it accepted. (Ever
tried a System V where some utilities did Berkeleyish ~user expansion,
but nothing else did? Uniformity!)
Here is another good way to lose files: restore a tar tape into the
wrong directory. Wild-cards? What wild-cards? It's a really good
way to lose files, because it looks as though you still have them...
With respect to the author of PDTAR, sometimes absolute file names
are exactly the right thing to have on a tar tape.
-----------------------------
From: Doug Gwyn <gwyn@brl-smoke.arpa>
Subject: Re: Bug in Ultrix2.0?
Date: 2 Dec 87 07:30:14 GMT
To: unix-wizards@brl-sem.arpa
In article <10617@brl-adm.ARPA> "oread::barbanis"@CS-UMASS.arpa writes:
>However, it does not work on Sun Unix 4.2, not even if you are the
>superuser (no, it is not NFS; I tried it on the server). Unlink
>returns [EPERM] if you try it on a directory. So what's wrong?
Systems that have a decent rmdir() system call do not need to allow
unlink() to succeed on a directory. Apparently Sun is in this category.
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: Re: Bug in Ultrix2.0?
Date: 2 Dec 87 09:53:29 GMT
To: unix-wizards@brl-sem.arpa
In article <10617@brl-adm.ARPA> "oread::barbanis"@CS-UMASS.arpa writes:
>... unlink(2) is supposed to unlink a (full) directory *if* you are
>the superuser, and that's the way it works on Ultrix. (It's in the
>manual, too... :-) ) However, it does not work on Sun Unix 4.2...
Clearly Sun decided it was a bad feature and deleted it.
Then again, Sun does not have 4.1BSD compatibility code in their
kernels....
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Ron Natalie <ron@topaz.rutgers.EDU>
Subject: Re: Bug in Ultrix2.0?
Date: 2 Dec 87 20:36:53 GMT
To: unix-wizards@brl-sem.arpa
Unlike older UNICES and SYSTEM V, the BSD directories are managed by
atomic system calls that any user can execute. Other UNIX systems
require you to run setuid root programs that very carefully use
mknod, link, and unlink to set up the directories and their . and
.. entries.
-Ron
-----------------------------
From: Karl Kleinpaste <karl@mumble.cis.ohio-state.EDU>
Subject: Re: POSIX execlfd and execvfd proposal
Date: 2 Dec 87 13:34:25 GMT
Sender: news@tut.cis.ohio-state.EDU
To: unix-wizards@brl-sem.arpa
weiser.pa@Xerox.COM writes:
you
simply may not know ahead of time that the program you are running
will want to figure out where it is running from. A /dev scheme
will work ok, or a new system call "givemeanfdfromwhereIam
running".
One of the research versions of UNIX at Murray Hill supports this.
It's implemented as an ioctl(2) (or was it an fcntl(2)?) against a
file descriptor. This can be used in conjunction with /proc; you open
the /proc/pid special file for the process you want to see (using
atoi(getpid()) should do the trick to look at yourself), then issue
this ioctl() against that file descriptor; you get back a file
descriptor pointing to the original binary which was exec'd.
This is used in a debugger, where you give it the pid of the currently-
existing process to debug; the debugger opens /proc/that-pid, then
gets a hold of the symbol table for that program by using this new
ioctl. The debugger never needed to know the name of the program file
being debugged, and the debugged program doesn't need to be a child of
the debugger, either.
I believe this was discussed in one of the papers in the Oct 1984 Bell
Labs Tech. Journal.
-=-
Karl
-----------------------------
From: Barry Margolin <barmar@think.COM>
Subject: globbing in the shell (Was Re: more rm insanity)
Date: 2 Dec 87 18:08:56 GMT
Sender: usenet@think.uucp
To: unix-wizards@SEM.BRL.MIL
In article <6774@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In fact that is a key "win" of UNIX over OSes that make applications deal with
>globbing.
Ahah, now you've hit one of my favorite complaints about Unix.
I do NOT think it is such a win that wildcard expansion is done by the
shell, at least not when it is done in the haphazard style that Unix
shells use. It assumes that all commands take filenames as arguments,
and that any argument with wildcard characters is supposed to be a
filename.
A very common counterexample is grep. Its first argument will often
contain wildcard characters, for example
grep "foo.*bar" <files>
I wonder how many new users get screwed when they forget to quote the
first argument and it says "No match" so they assume that none of the
files contain the pattern (I think the Bourne shell "solved" this
problem by making unmatched tokens expand into themselves, but the C
shell just aborts the line). Other commands may want to take
wildcards, although not necessarily to match filenames; for example
who bar*
should list all the logged-in users whose names begin with "bar"
(equivalent to "who | grep '^bar'").
It should be up to the command to decide the appropriate context for
treating arguments as pathnames and performing wildcard expansion.
This way, a command that knows it is dangerous, such as rm, can check
whether it was called with a wildcard and perhaps be more careful. On
Multics, the delete command does exactly this, querying "Are you sure
you want to 'delete **' in <directory>?" unless -force is specified.
Globbing in the shell also severely limits the syntax of commands; I
will admit that this could be seen as a benefit, because it forces
conformity, but sometimes a minor syntax change can be useful. For
example, there's no way to write a version of the cp or mv commands
that takes an alternating list of source and destination pathnames,
where the source pathnames are permitted to have wildcards. You also
can't do something like Multics's
rename foo.** foo.bar.==
(the == is replaced by whatever the ** matched) without writing a
complicated script that used grep and sed on the output of ls.
Finally, even when an argument is a pathname, it is sometimes not
allowed to be multiple files. For example, diff takes pathnames, but
it requires exactly two of them, and ar allows only one archive
pathname to be specified. On Multics, a command with a syntax like
this can check whether the argument contains wildcards and complain.
Diff can check that it received exactly two pathnames, but it won't
know whether this is simply because one wildcard happened to match
exactly two files (maybe this was intentional on the user's part, but
maybe it wasn't), and ar will simply treat the extra arguments as
member files.
So does this mean that globbing MUST be done by the commands
themselves? Well, yes and no. This is how it is done on Multics,
although the actual matching is done by a system call for filenames
(for efficiency, since Multics directories are not directly readable
by user-mode code, so it saves lots of data copying) and by a library
subroutine for non-filenames. Some more modern systems allow commands
to provide information to the command processor that tell it how to do
the automatic parsing; in this case, this data would specify which
arguments are pathnames that allow wildcards, and the command
processor would automatically perform the expansion in the right
cases.
---
Barry Margolin
Thinking Machines Corp.
barmar@think.com
seismo!think!barmar
-----------------------------
From: Christopher Lott <cml@tut.cis.ohio-state.EDU>
Subject: leaving users out of login group
Date: 2 Dec 87 21:11:12 GMT
To: unix-wizards@SEM.BRL.MIL
Hello,
I work at OSU, and we've run into the problem of maintaining group and
passwd files that seem to grow exponentially at the beginning of each
academic quarter... I'm sure you know how that goes.
My question: Has anyone tried leaving users _out_ of their login
group in /etc/group to reduce the size of the group file?
Example: I am cml@tut.cis.ohio-state.edu. My passwd line on tut:
cml:0MUsin/l3Py6g:3029:10:Christopher Lott....
I am in group 10. I also appear in the group file:
staff:*:10:.........,cml,........
Can I take myself out of the staff line in the group file
without breaking anything?
I removed myself from the group file some time ago. So far, I have
noticed no differences. Please note that I am asking with reference
to pyramids and suns (running yp).
Thanks in advance for any and all help. I try to keep up with news,
so either posting or direct reply is fine.
ChrisL...
------
Christopher Lott, Department of Computer and Information Science
The Ohio State University; 2036 Neil Avenue Columbus OH 43210
cml@ohio-state.{arpa,csnet} or ...!cbosgd!osu-cis!cml
Preferred: cml@cis.ohio-state.edu
-----------------------------
From: Tim O'Reilly <tim@ora.uucp>
Subject: Re: Need a XENIX VT100 emulator
Date: 2 Dec 87 22:51:43 GMT
Keywords: xenix, vt100
To: unix-wizards@SEM.BRL.MIL
In article <9936@brl-adm.ARPA> V2002A%TEMPLEVM.BITNET@wiscvm.wisc.EDU writes:
> I have a user who wants to convert from MS-DOS to XENIX.
> Our problem is that he currently uses SMARTERM 220 to communicate
> with our PDP-11/44. It's an MS-DOS VTxxx emulator/comm package.
> Can anyone reccommend a similar XENIX package for less than
> $175.
Try calling Century Software in Salt Lake City: 801-268-3088.
Their product, TERM, is very good, and in your approximate
price range, I think.
--
Tim O'Reilly (617) 527-4210
O'Reilly & Associates, Inc., Publishers of Nutshell Handbooks
981 Chestnut Street, Newton, MA 02164
UUCP: uunet!ora!tim ARPA: tim@ora.uu.net
-----------------------------
From: John Chambers <jc@minya.uucp>
Subject: Re: Posting easily-exploited security holes
Date: 3 Dec 87 01:37:14 GMT
To: unix-wizards@brl-sem.arpa
In article <6305@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon Allbery) writes:
>
> Wonderful idea, by the way -- don't you get a warm glow from having posted
> an easily-exploited security hole to the Net? Please be more circumspect
> next time.
No, no, no!!! I get real exasperated by all the people who think that
system managers (like me) should be kept in the dark about security holes.
I want to hear all about them. How the @#$^% do you think I can plug
them, if I don't learn about them? Huh?
A couple weeks ago, I startled some folks around where I'm working now
by typing six chars on a logged-in terminal, and getting a super-user
prompt. It was the first time I'd ever typed anything at that machine.
I then explained to the machine's manager (who was watching, horrified)
just what they were doing wrong. I got a few points from that one. The
method I used was mentioned in unix.wizards a couple years back. I would
like to hear some more good ways of earning points.....
--
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
-----------------------------
From: Mike Khaw <mkhaw@teknowledge-vaxc.arpa>
Subject: sendmail alias strangeness
Date: 3 Dec 87 02:15:27 GMT
Posted: Wed Dec 2 18:15:27 1987
To: unix-wizards@brl-sem.arpa
Today one of our systems people just added a number of aliases to
/usr/lib/aliases, ran newaliases, and all of a sudden sendmail no
longer recognizes some of the old mail aliases. /usr/lib/sendmail -bv
thinks these aliases are OK, but if I try to telnet to port 25 to talk
to the smtp server and use "rcpt to:" it comes back with "User unknown".
I wrote the following short program, which verified that the "broken"
aliases are in fact in the aliases dbm file, and are what we think
they should be:
#include <stdio.h>
#include <dbm.h>
#define MAXKEY 20
main()
{
datum key,
content;
char inbuf[MAXKEY + 1];
dbminit("/usr/lib/aliases");
while (printf("key? "), gets(inbuf) != NULL)
{
key.dptr = inbuf;
key.dsize = strlen(inbuf) + 1;
content = fetch(key);
if (content.dptr == NULL)
printf("oops\n");
else
printf("%s:\"%s\"\n", key.dptr, content.dptr);
}
}
What's going on? (This is Ultrix 1.2 / VAX; sendmail identifies itself as
version 4.12/4.7)
Thanks,
Mike Khaw
--
internet: mkhaw@teknowledge-vaxc.arpa
usenet: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
-----------------------------
End of UNIX-WIZARDS Digest
**************************jpn@teddy.UUCP (John P. Nelson) (12/08/87)
Why did a UNIX-WIZARDS digest get posted to USENET? I thought that the USENET <--> ARPA-MAILING-LIST gateway prevented digests from getting forwarded to USENET? All the articles in the digest were OLD, and had already been distributed as individual articles! The article reached here via the following Path: teddy!panda!husc6!cmcl2!brl-adm!adm!Unix-Wizards-Request@BRL.ARPA Could someone please look into this, and prevent it in the future?