Bug#81396: root shell fscked after upgrade to woody

[Matt Zimmerman <mdz@debian.org>]

On Sun, Jan 07, 2001 at 12:04:14AM +0200, Eray Ozkural (exa) wrote:

> This is how it looks like
> 
> exa@borg:~$ telnet borg
> Trying 139.179.21.143...
> Connected to borg.cs.bilkent.edu.tr.
> Escape character is '^]'.
> Debian GNU/Linux woody borg.cs.bilkent.edu.tr
> login: root
> Password: 
> root@borg:~# echo $PATH
> /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
> root@borg:~# su
> root@borg:~# echo $PATH
> /sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin
> root@borg:~# exit
> exit
> root@borg:~# exit
> logout
> Connection closed by foreign host.
> exa@borg:~$ 
> 
> How should I debug this?

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,
continue.

"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.

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.

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.

-- 
 - mdz