Re: su

[Greg Wooledge <greg@wooledge.org>]

On Wed, Sep 06, 2023 at 05:09:29AM +0200, Michel Verdier wrote:
> On 2023-09-05, Greg Wooledge wrote:
> 
> > You used "su" to become root, I believe.  Unfortunately, beginning
> > with Debian 9, "su" with no arguments and no configuration doesn't
> > behave the way it used to behave.  Specifically, it no longer sets the
> > PATH variable properly.  And so you get the above results.
> >
> > See <https://wiki.debian.org/NewInBuster#Changes> for the options
> > available to you.  If you wish to continue using su, I strongly recommend
> > creating a /etc/default/su file.
> 
> I have no /etc/default/su and never need one. According to the man page
> su also reads /etc/login.defs. To get root env she only needs to use:
> "su -"

How *incredibly* Red Hat.  Really, it just sickens me that this is the
answer accepted by so many people.

Do you want a *specific* reason why this answer is crap?  OK, here's my
reason.

Let's say you've downloaded a program in source code form from the Internet.
You unpack it, and read the installation instructions.  Then you end up
running some combination of "./configure" and "make", or maybe "cmake",
or something like that.  Then, when all that fun stuff is done, it's time
to install your new program into the system directories so it can be used.

To perform that installation, you run "su", which gives you a root shell,
and then you do something like "make install".

But the Red Hat answer says you should use "su -" instead, to become root.
What happens now?  You've created a login shell.  Now you're no longer
in the directory where your source code was extracted and compiled.
You're in root's $HOME directory.  So "make install" fails.

You could use a "cd" command to get to the source code.  But "cd -" won't
work, because the previous working directory is not known to the root
login shell.  The root login shell has intentionally discarded everything
from your previous shell, including the old working directory's name.
So you can't "cd -", but instead, you have to re-type the entire path to
the source code directory.  Or copy and paste it out of your shell prompt,
if that's still visible on the screen, and if it happens to contain the
entire path.

Wouldn't it be *nicer* if su simply WORKED?!

You can make su work by creating a ONE-LINE CONFIGURATION FILE.

Just put "ALWAYS_SET_PATH yes" into /etc/default/su and the problem
is FIXED.  "su" will work properly again!

> su also reads /etc/login.defs

Yes, it does.  And when the buster problem was first noted, some people
discovered that putting ALWAYS_SET_PATH yes into /etc/login.defs would
fix su.  This was actually published on the Debian wiki as well, as it
was the first known fix for the broken su.

Unfortunately, this fix has an undesired side effect.  It causes console
logins to print an error message, because the ALWAYS_SET_PATH line in
/etc/login.defs is not known to login(1), but only to su(1).

This error doesn't actually *hurt* anything, but it's really annoying.
And scary, for people who don't know where it's coming from.

Putting the configuration in /etc/default/su is a *better* solution,
because it works, and doesn't cause logins to print a confusing error
message.

Unfortunately, Debian DOESN'T CREATE THIS FILE BY DEFAULT.  People are
scared to create it themselves, because people have been "trained"
by years of Linux distribution handholding that if a program has
a configuration file, that file will *exist*, and will have helpful
comments in it, and they only have to find the file and edit it.
The idea of *creating* a configuration file that's missing is terrifying
for some people.

That's why I put the extra advice "(create it)" on the wiki.  I know
it won't be strong enough advice to overcome everyone's fears, but I do
hope it's enough to encourage people who are on the fence to be brave.
To reassure them that yes, we know Debian screwed up, and yes, we know
the file *should* be there, and it's not, but that's OK.  You can make
it yourself.