v.wales%ucla-locus@sri-unix.UUCP (10/24/83)
From: Rich Wales <v.wales@ucla-locus>
The "su" command in 4.1BSD does not change the value of the USER envi-
ronment variable. This seems strange, especially since "su" does change
the HOME and SHELL variables to values appropriate for the new user.
(1) Can anyone think of a good reason why the USER value should not be
changed by "su"?
(NOTE: I fully realize that no one should depend on the USER value
as a reliable user identification, since anyone can change their
USER value to anything at all. Hence, no flames about system secur-
ity, please!)
(2) Does "su" change the USER value in other versions of UNIX, such as
4.2 or System V?
-- Rich Wales <wales@UCLA-LOCUS>gwyn%brl-vld@sri-unix.UUCP (10/25/83)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> There is no USER environment variable in UNIX System V. The closest thing there is LOGNAME, which is perhaps used by some PWB stuff. I don't really see the need for such an environment variable; perhaps someone could enlighten me?
mrose.uci-750a%rand-relay@sri-unix.UUCP (10/25/83)
From: Marshall Rose <mrose.uci-750a@rand-relay>
Well, (it's my opinion that) $USER is a convenient method to
determine who you want to say you logged in as. Under 4.1a, for
example, if you use a /dev/ptyxx to give a process its own
control-terminal, it doesn't have an entry in /etc/utmp. Hence,
things like getlogin() may not work as expected. In cases like
this, $USER is real useful as a pointer to who you logged in as.
Granted, you can easily change it, so it's not a guaranteed method.
It also seems to me that when something runs under cron, it doesn't
have a $USER. This makes it real easy for a script (e.g., .cshrc)
to tell when it's running under the restricted cron environment.
For example, I have several maintenance logins that I and others
use quite heavily. We each have our own preferred aliases, etc.,
etc., so we each would want to have a copy of our own .cshrc in
place for these logins. Instead, we use this, which does the
obvious things and we all live in pseudo-harmony.
printenv USER >& /dev/null
if ($status != 0) then
set path=(/bin /usr/ucb /usr/bin /usr/uci .)
goto crontab
endif
if (-r ~/.$USER) then
source ~/.$USER
else
if (~$USER/.cshrc != ~/.cshrc) source ~$USER/.cshrc
endif
umask 0022
crontab:
Granted, there are lots of ways of doing this, but it works well
for our purposes.
/mtrdave@utcsrgv.UUCP (Dave Sherman) (10/27/83)
su should *not* change the USER environment variable, thank you.
That variable is used for mail and news postings. If I temporarily
want to be someone else for access purposes, I still want my articles
and messags to come from me. If you are really "changing into" the
other person (e.g., you physically have gone away and that other
physical person is using the terminal), then "login" is more
appropriate than "su" anyway.
Dave Sherman
Toronto
--
{cornell,decvax,ihnp4,linus,utzoo,uw-beaver}!utcsrgv!lsuc!davesmb@ulysses.UUCP (Steven Bellovin) (10/29/83)
There's a philosophical question that has to be resolved first: is the purpose of 'su' to let you "become" the other user, or is it to extend your permission while retaining your identity. If you're trying to become someone else, then USER should be changed; if not, then it should be left alone. I tend to subscribe to the second view. Back in the mists of time, when I was modifying ucbmail to work with MMDF, I used USER to generate the 'From' line, but the real uid to generate a 'Sender' line. That seemed to work out best, under the circumstances.
twltims@watmath.UUCP (Tracy Tims) (10/31/83)
There are three things I commonly want to do:
1) Perform a "layered login". This is in all ways like a login
except that when I log out the other user comes back. (Yes,
I know how to do this.)
2) Become someone that I am authorized to become for purposes of
mail, news, rogue, etc. I still want my own shell and env-
ironment, but I want certain environment variables changed
consistently to reflect a new "identity".
3) Assume ONLY the file access permissions of someone else. I
still want my own environment.
I think there should be a set of related commands providing these
functions in some easy to understand way. It's a pain when using
someone elses UNIX system to have to spend time figuring out what the
local brand of 'su' does.
Tracy Tims {linus,allegra,decvax,utcsrgv}!watmath!twltims
The University of Waterloo, 519-885-1211 x2730wan@gatech.UUCP (11/01/83)
The 'login' program does all sorts of wondrous things, one of which is
to change the /etc/utmp (on Berkeley) entry for that terminal. I have
had that bite me (while letting friends "use" my terminal). They would
do 'csh' and then 'login' ('csh' execs 'login', thereby killing the
original shell if you don't watch it). Well, whenever people did a 'w'
to see who was on, they would see the new person in my terminal slot.
When they terminated their new shell, I was back to my original login
shell, but any program which calls the 'getlogin' routine sees the other
individual. Needless to say, you can get caught ('passwd', for instance,
calls 'getlogin' to figure out which password to change, etc.) unawares.
I'm not sure, but other versions of 'login' must do that as well (unless
they can check to see if their parent is 'init' and not change anything
for non-top-level logins).
Also, if 'login' is setuid to root (it is on our system), it chowns the
terminal to the new person that you are logging in as. After you exit
that login session, the original owner cannot change the terminal device
mode (i.e., with 'chmod' or 'mesg')!
--
Peter N Wan
MAIL : School of ICS, Georgia Tech, Atlanta, Georgia 30332
BELL : (404) 894-3658 [office] / (404) 894-3152 [messages]
UUCP : ...!{akgua,allegra,emory,rlgvax,sb1,ut-ngp,ut-sally}!gatech!wan
ARPA : wan.gatech@CSNet-Relay CSNET : wan@gatechbob%ucla-locus@sri-unix.UUCP (11/01/83)
From: Bob English <bob@ucla-locus> Do you really know how to do a "layered login"? If you invoke login from the shell, it will overwrite /etc/utmp and the other person will appear to be you forever more. This is particularly interesting when you log on as who ( or date or whatever). --bob-- P.S. This is the case for 4.1bsd and v7. If someone has fixed this, I wouldn't mind hearing about it.
thomas@utah-gr.UUCP (Spencer W. Thomas) (11/02/83)
Re: using "login" to gain permissions. This is a very bad idea. We have for a long time had login mode 500, owned by root. It is very easy for someone to push a shell, login as, say, "who" (most systems seem to have a who login), then exit the shell, leaving the user entry in /etc/utmp as "who". Thus, all his connect time gets charged to overhead (assuming you are doing accounting, of course), and in any case, you can't tell what person is REALLY logged in there. =Spencer
guy@rlgvax.UUCP (Guy Harris) (11/02/83)
In USG UNIX, "login" is no longer a real command (it lives in /etc) and the
shell does not recognize it as a special command. This may have been done
for the reasons mentioned; i.e., it monkeys with the who table entry. The
"su" command in USG UNIX has an option to act like what you usually want
when you do a "login" command; i.e., it forks off a new shell and runs it
with argv[0] == "-su", so it thinks it's a login shell and runs /etc/profile
and the user's .profile. It does not, however, change the LOGNAME environment
variable (serves the same function as USER), which makes it a pain to use
"su" to read the mail sent to pseudo-users like "adm" without having to log
in as "adm" (or worse, pseudo-users like "uucp" who don't have a normal login
shell). Of course, since USG "mail" has a forwarding facility you're probably
supposed to forward their mail to a real person and not use "su" for this.
Guy Harris
{seismo,inhp4,allegra}!rlgvax!guymsm@syteka.UUCP (Michael S. Maiten) (11/02/83)
One technique that I use when I need different access permissions is to have
a setuid/setgid shell file which, after checking the real userid against
an access list, will exec a program which sets the real uid/gid to the
effective uid/gid and execs its argument. Using csh, this means that I can
have multiple jobs running shells, each with different access permissions
(Of course, the setuid/gid shells must be set up in advance).
I can then just move between them as needed. This method saves typing
in passwords (as with su) and having .logins, etc executed.
Michael S. Maiten
Silicon Gulch, California
<...!{ucbvax!menlo70,decvax}!sytek!msm>bob%ucla-locus@sri-unix.UUCP (11/09/83)
From: Bob English <bob@ucla-locus> There are many ways of preventing people from putting semi-random garbage in /etc/utmp. The simplest way that I know of is to make login a simple executable file rather than a set-uid program. If you want to keep people from fooling themselves, make login mode 700. I'm not sure that a layered login is a good idea (it invites look-alikes), but I would be interested in knowing how it was done if someone has actually done it. One possibility is to have login fork off the shell (rather than execing) and clean up when the shell exits. This is what init does now for login. --bob--