Wow, this list is great! I'll include my original post at the end of this
message, but basically the problem was that when anyone would telnet onto a
particular host, $USER would be set to root. This wouldn't happen with either
rsh or rlogin, and it didn't matter where they telnetted from or what shell
they used.
Many thanks to:
Arthur Darren Dunham <add@is.rice.edu>
Nelson Jose dos Santos Ferreira <Nelson.Ferreira@inesc.pt>
"Richard C. Mills" <rmills@atl1.america.net>
"Mark `Hex' Hershberger" <mah@eecs.tulane.edu>
Rasana Atreya <atreya@library.ucsf.edu>
"Karl E. Vogel" <vogelke@c17mis.region2.wpafb.af.mil>
I'll include part of Arthur Dunham's response since it was very succinct:
>That's because root restarted inetd rather than sending a HUP to reread
>the inetd.conf file. inetd inherited all the environment variables
>(including $USER) and is passing them on to the children.
Sure enough, according to the date of inetd from ps, it had recently been
restarted, I'm assuming by the other admin since I didn't do it. :-)
Thanks again,
Sean
-----Original message below
Hi all. Sun is stumped on this one, so I thought I'd run it by all of you.
Here's the uname info from the host in question:
SunOS bird 5.5 Generic sun4m sparc SUNW,SPARCstation-20
What's happening is that when anyone telnets to the above host, the $USER
variable gets set to root. At the same time, 'whoami' returns the correct
username. As you can imagine, this is causing some interesting permission
problems.
If a user su's to someone else, then does an su back to his or herself, $USER
does not change, but an 'su -' correctly resets $USER.
This only happens with telnet; rsh and rlogin do not have this problem. Also,
it does not matter where a user telnets from. A user coming in via SunOS,
Solaris, Win95 telnet, and Hummingbird Exceed telnet all exhibit this problem.
It also does not matter which login shell is used. Sh, csh, and tcsh all do
this.
The in.telnetd permissions are set correctly, and it is not a wrapper. I've
also done a cmp with this in.telnetd and another 2.5 machine which does not
have this problem, and the files are the same.
Unfortunately, changing the login sequence to either rsh or rlogin is not an
option.
Thanks in advance, and I'll summarize.
-- ============================================================================= Sean Ward, Systems Bum +1-303-401-1530 voice Amgen Boulder +1-303-938-6244 fax 3200 Walnut St. seanw@amgen.com Boulder, CO 80301 USA ...uunet!amgen!seanw "Hopelessly lost, but making good time..." - Letterman =============================================================================
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:54 CDT