[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#81396: root shell fscked after upgrade to woody

Hi Matt!!

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

exa@borg:~$ cat /etc/login.defs  | grep ENV
# Three items must be defined:  MAIL_DIR, ENV_SUPATH, and ENV_PATH.
#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

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
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo

Reply to: