Bug#81396: root shell fscked after upgrade to woody
On Sun, Jan 07, 2001 at 04:38:10AM +0200, Eray Ozkural (exa) wrote:
> > Then, read /etc/login.defs. Note the values of the ENV_PATH and ENV_SUPATH
> > options. These are used by login(1) and su(1). Test login(1) and su(1) and
> > make sure they are doing what you expect. If they aren't, find out why. If
> > they are behaving contrary to their documentation, file a bug. If they are,
> > continue.
> >
>
> exa@borg:~$ cat /etc/login.defs | grep ENV
> # Three items must be defined: MAIL_DIR, ENV_SUPATH, and ENV_PATH.
> #ENV_TZ TZ=CST6CDT
> #ENV_TZ /etc/tzname
> ENV_HZ HZ=100
> #ENV_HZ HZ=1024
> ENV_SUPATH PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin
> ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
> #ENVIRON_FILE
>
> See Matt? This isn't the source of the problem. I didn't even touch it.
> Let's go on, sure. I'll try to overlook your insults and get to solve the
> problem.
>
> I checked it and it seems that I can login on this box (woody) directly
> with the SU path when I login from the console as root. But on borg
> which I observed the bug, when I login as root I only get the ENV_PATH
I didn't claim that you changed it. You didn't demonstrate any knowledge of
how it is SUPPOSED to work before claiming that something was broken. Did you
test login and su manually as I suggested? It doesn't look like it. Start
with the simplest test and work your way up to the point where you see the
problem. It sounds like things work correctly when you use su (though you
should test that further); if login did not work, that would narrow the
possibilities very much.
Follow my instructions before claiming that I haven't led you to the source.
> I used telnet to demonstrate how it looks to a normal root login. We use
> telnet here because this is a diverse university network; we can't force
> people to run ssh and any moron could go root on this machine if he really
> wanted to. No tight physical security either. We trust each other here.
Well, if you don't have control over superuser access to the box, who knows
what has changed. The problem could be that someone has rooted the box and
installed a trojan version of login that doesn't set up the environment
properly. How can you make claims that this isn't a misconfiguration when you
have no change control?
Environment variables, apparently, are the least of your worries.
> Really? Unfortunately Matt the components don't really include telnetd.
In your test case, you used telnetd. It may be that the problem exists when
you use other methods, but you haven't shown any transcripts of that.
> > Thank you for attending UNIX System Administration 101, followed by a brief
> > introduction to deductive problem solving. Now please stop reporting bugs
> > against general, and subscribe to a UNIX help mailing list.
>
> Why are you pretending that this is an FAQ. This happened twice on systems
> that I used, and was caused by an upgrade. I marked it important not because
> it is difficult to solve, but because it would apparently disrupt operation
> in a bad way. If you have a valid reason, you may decrease the priority to
> normal but otherwise stop ranting and try to help solving it.
It's not a FAQ, it's a problem. But you haven't taken any real steps toward
trying to define the problem beyond claiming IT DOESN'T WORK and asking
debian-devel to fix your system. Nobody here has the resources that you do for
solving this problem. Specifically, you have administrative access to the
system involved, and you can do the work to track it down. If you're not
willing to do that, why should we all try to guess for you?
--
- mdz
Reply to: