Bug#81396: root shell fscked after upgrade to woody
I don't report a bug due to misconfiguration. Let's see if what you
see applies, though.
Matt Zimmerman wrote:
> First, "man su" to find out where su(1) is getting its environment from.
> Searching for 'environment' on that man page, you can find this:
> The current environment is passed to the new shell. The
> value of $PATH is reset to /bin:/usr/bin for normal users,
> or /sbin:/bin:/usr/sbin:/usr/bin for the super user. This
> may be changed with the ENV_PATH and ENV_SUPATH defini-
> tions in /etc/login.defs. When using the -m or -p options,
> the users environment is not changed.
> 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,
exa@borg:~$ cat /etc/login.defs | grep ENV
# Three items must be defined: MAIL_DIR, ENV_SUPATH, and ENV_PATH.
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
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
> "man telnetd". Find out where telnetd is supposed to be getting its
> environment from. Traditionally, telnetd has called login(1) to complete the
> login process, but it sounds like that may have changed, or different options
> are being used. I don't run telnetd (and neither should you), so I can't walk
> you through this step as I don't have the package installed.
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.
> Those are the major components that you're dealing with. Investigate the
> problem step by step, testing each component individually, and determine which
> component is causing the problem. If the problem appears to be caused by a
> software bug, isolate the smallest possible test case, and report a bug against
> the package which contains the buggy component. Optionally, you may
> investigate further, fix the problem, and include a patch.
Really? Unfortunately Matt the components don't really include telnetd.
> 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.
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara