bp@pixar.UUCP (06/11/87)
[ In <7430@elsie.UUCP> Arthur Olson (ado@elsie) wrote about the built-in ]
[ login command passing the umask to a new login because there's no umask() ]
[ call in 4.3 /bin/login ]
In 4.3, the built-in login command of the shells does indeed pass the umask
to the new login, but this is hardly the only bug born of the built-in
login command: It'll pass resource limits (as in vlimit() and the csh limit
command), and lots of other process information. Sites that are concerned
with security simply chmod /bin/login to 744, so that the built-in login
command won't work and the user must exit the shell to get a new login.
Bruce Perens
{ucbvax,sun}!pixar!bpmichaud@decvax.UUCP (Jeff Michaud) (06/13/87)
Protecting /bin/login from execute by world (other) is a good idea. Back at U. of NH, I discovered by accident that if I ran /bin/login directly (not "exec" it, which the builtin shell command "login" does) and logged into an account with no password (they had a captive account which ran /bin/who), when /bin/login exited the entry in the /etc/utmp kept the new login name. Then (I don't know if it is true anymore) mail used to use the /etc/utmp entry (given by: who am i) instead of by uid (given by: whoami). An even worse problem is you can really screw up the script utility by: % script Script Started in-script% /bin/login who ..... in-script% ^D What ends up happening is that /bin/login makes the entry in /etc/utmp, but only the init process clears it. So on your pty you had in script, utmp says "who" is logged on. For some reason, nobody could use "script" after that, until the system was rebooted. Jeff michaud@decvax.dec.com ...!decvax!michaud ps: no .sigjfdkdfjk file yet
rjd@tiger.UUCP (06/16/87)
> Back at U. of NH, I discovered by accident that if > I ran /bin/login directly (not "exec" it, which the > builtin shell command "login" does) and logged into > an account with no password (they had a captive > account which ran /bin/who), when /bin/login exited > the entry in the /etc/utmp kept the new login name. > > Then (I don't know if it is true anymore) mail used > to use the /etc/utmp entry (given by: who am i) > instead of by uid (given by: whoami). Interesting, AT&T Sys V, release 2.0 and 3.0 's mail command uses your LOGNAME variable as a first choice as your ID when sending mail. (Probably and unimportant bug...) rjd
francus@cheshire.columbia.edu (Yoseff Francus) (06/18/87)
In article <142700003@tiger.UUCP> rjd@tiger.UUCP writes: > >> Back at U. of NH, I discovered by accident that if >> I ran /bin/login directly (not "exec" it, which the >> builtin shell command "login" does) and logged into >> an account with no password (they had a captive >> account which ran /bin/who), when /bin/login exited >> the entry in the /etc/utmp kept the new login name. >> >> Then (I don't know if it is true anymore) mail used >> to use the /etc/utmp entry (given by: who am i) >> instead of by uid (given by: whoami). > > Interesting, AT&T Sys V, release 2.0 and 3.0 's mail command uses your >LOGNAME variable as a first choice as your ID when sending mail. (Probably >and unimportant bug...) > >rjd Actually the LOGNAME bug was fairly serious. LOGNAME is a shell variable which can normally be changed by a user. A user could chang their LOGNAME variable and then send mail as someone else. On Sys V if you look at /etc/profile you will notice that in many cases after LOGNAME is set it is made into a readonly variable. There are ways around this too, but enough said. yoseff ****************************************************************** yf In Xanadu did Kubla Khan a stately pleasure dome decree But only if the NFL to a franchise would agree.
allbery@ncoast.UUCP (06/20/87)
As quoted from <4705@columbia.UUCP> by francus@cheshire.columbia.edu (Yoseff Francus): +--------------- | In article <142700003@tiger.UUCP> rjd@tiger.UUCP writes: | >> Back at U. of NH, I discovered by accident that if | >> I ran /bin/login directly (not "exec" it, which the | >> builtin shell command "login" does) and logged into | >> an account with no password (they had a captive | >> account which ran /bin/who), when /bin/login exited | >> the entry in the /etc/utmp kept the new login name. | > Interesting, AT&T Sys V, release 2.0 and 3.0 's mail command uses your | >LOGNAME variable as a first choice as your ID when sending mail. (Probably | >and unimportant bug...) +--------------- This is especially dumb considering that System V fixed the "login" bug mentioned above (since the process ID of the process group leader is saved, /bin/login can check to see if it's being run by a non-login shell). ++Brandon -- Copyright (C) 1987 Brandon S. Allbery. Redistribution permitted only if the redistributor permits further redistribution. (Stargate take heed!) ---- Moderator for comp.sources.misc and comp.binaries.ibm.pc ---- Brandon S. Allbery {decvax,cbosgd}!cwruecmp!ncoast!allbery aXcess Company {ames,mit-eddie,talcott}!necntc!ncoast!allbery 6615 Center St. #A1-105 necntc!ncoast!allbery@harvard.HARVARD.EDU Mentor, OH 44060-4101 +01 216 974 9210 (also eddie.MIT.EDU)
rjd@tiger.UUCP (06/23/87)
> >> Then (I don't know if it is true anymore) mail used > >> to use the /etc/utmp entry (given by: who am i) > >> instead of by uid (given by: whoami). > > > > Interesting, AT&T Sys V, release 2.0 and 3.0 's mail command uses your > >LOGNAME variable as a first choice as your ID when sending mail. (Probably > >and unimportant bug...) > > > >rjd > > Actually the LOGNAME bug was fairly serious. LOGNAME is a shell > variable which can normally be changed by a user. A user could chang > their LOGNAME variable and then send mail as someone else. On Sys V > if you look at /etc/profile you will notice that in many cases > after LOGNAME is set it is made into a readonly variable. There are ways > around this too, but enough said. > > yoseff Even more interesting, as the Unix Sys V /etc/profile on my system did not come with LOGNAME set to readonly (and I had not thought of it until you mentioned it). The only mention of LOGNAME in my /etc/profile is to merely export it (this will change!). rjd