Debian Bug report logs - #905478
util-linux: su from util-linux: no reason why su without setting new environment is bad idea

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <Martin@Lichtvoll.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: util-linux: su from util-linux: no reason why su without setting new environment is bad idea

Date: Sun, 05 Aug 2018 09:57:28 +0200

Package: util-linux
Version: 2.32-0.4
Severity: normal

Dear Andreas, Maintainer,

the change to 'su' from 'util-linux' broke an important workload for me:

My backup script, running as root, needs access to the SSH agent running
as user in order to backup remote machines. It needs root access for doing
BTRFS-Snapshots – I could change that to sudo - and also for writing out
the data with correct ownership preserved. It uses some commands that are
in 'sbin' directories.

Thus I set the PATH manually in the script initially, as your explaination
which I appreciate was not available at the time the change happened. But
then I left that 'su' without setting new environment open, which broke
apt on installing a new package, since dpkg did not find ldconfig and another
command, since 'sbin' related directories where not in PATH.

I wonder what else may break for other users.

Meanwhile you described the change:

> util-linux (2.32-0.4) unstable; urgency=medium
>
> The util-linux implementation of /bin/su is now used, replacing the
> one previously supplied by src:shadow (shipped in login package), and
> bringing Debian in line with other modern distributions. The two
> implementations are very similar but have some minor differences (and
> there might be more that was not yet noticed ofcourse), e.g.
>
> - new 'su' (with no args, i.e. when preserving the environment) also
>   preserves PATH and IFS, while old su would always reset PATH and IFS
>   even in 'preserve environment' mode.
> - su '' (empty user string) used to give root, but now returns an error.
> - previously su only had one pam config, but now 'su -' is configured
>   separately in /etc/pam.d/su-l
>
> The first difference is probably the most user visible one. Doing
> plain 'su' is a really bad idea for many reasons, so using 'su -' is

I read this here and elsewhere. Everytime with one thing common:

Bad idea, should never do it. But *no reasons*.

Not enough for me as a user and admin to make an informed decision about it.

> strongly recommended to always get a newly set up environment similar
> to a normal login. If you want to restore behaviour more similar to
> the previous one you can add 'ALWAYS_SET_PATH yes' in /etc/login.defs.
> -- Andreas Henriksson <[…]>  Fri, 03 Aug 2018 10:52:22 +0200

No reasons, no insight on why I should change the way I do things regarding
those backup scripts.

Also… I tried out sudo… and it does not preserve environment variables for
SSH Agent. Is it really that unusual to use a SSH Agent running in a user
session from a root session? What is really the issue with that? Root could
do it anyway.

So I´d really appreciate some more on explaining the reasons behind the
change, why it is a bad idea of using "su" without initializing new
environment – not even the "su" manpage mentions something about it,
it appears to be highly outdated anyway (July 2014). I may ask on
'util-linux' mailing list about that.

And hints on migrating workloads that depended on this behavior.

I think that would be beneficial to have before a Debian stable release,
but maybe my idea on how many users rely on the old behavior does not match
the fact and I may be one of the only users who accessed an SSH agent from
a root session.

I have a slight idea on how to rewrite the whole script to run as user,
using "setpriv" to do the actions it needs to do as root, but before I do
that: Why would it be better? Most of the stuff it needs to do as root.

Thanks,
Martin


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-rc5-tp520-btrfstrim+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages util-linux depends on:
ii  fdisk          2.32-0.3
ii  libaudit1      1:2.8.3-1+b1
ii  libblkid1      2.32-0.3
ii  libc6          2.27-5
ii  libmount1      2.32-0.3
ii  libpam0g       1.1.8-3.7
ii  libselinux1    2.8-1+b1
ii  libsmartcols1  2.32-0.3
ii  libsystemd0    239-7
ii  libtinfo6      6.1+20180714-1
ii  libudev1       239-7
ii  libuuid1       2.32-0.3
ii  login          1:4.5-1.1
ii  zlib1g         1:1.2.11.dfsg-1

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools          4.1-2
ii  kbd                 2.0.4-4
ii  util-linux-locales  2.32-0.3

-- no debconf information

Message #10 received at 905478@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin@lichtvoll.de>

To: 905478@bugs.debian.org

Cc: "Theodore Y. Ts'o" <tytso@mit.edu>, control@bugs.debian.org

Subject: Fwd: Re: Debian´s change of "su" to the one in util-linux

Date: Mon, 06 Aug 2018 10:39:54 +0200

severity 905478 wishlist
thanks

Dear Andreas, dear Ted.

Andreas, Ted provided an explanation that I can go with. I understand 
that you wrote quite something in NEWS.Debian already. I lower the 
priority of the report to wishlist. It may still help to explain it to 
users a bit more carefully. But as I know some of the reasons now, I am 
fine with it either way.

I bet I will go with configuring sudo to take over SSH agent environment 
variables to the root session. As this is on my laptop, I think I 
configure sudo to demand to root password instead of the user´s one.

----------  Weitergeleitete Nachricht  ----------

Subject: Re: Debian´s change of "su" to the one in util-linux
Date: Sonntag, 5. August 2018, 17:05:57 CEST
From: Theodore Y. Ts'o <[…]>
To: Martin Steigerwald <[…]>
Cc: util-linux@vger[…]

On Sun, Aug 05, 2018 at 10:35:34AM +0200, Martin Steigerwald wrote:
> Now people say, including Debian maintainer of util-linux, in above 
> NEWS  file entry: Using "su" without initializing new environment is a 
> bad idea and should never be done. For many reasons. However, nowhere 
> I saw these reasons actually mentioned. That is not enough for an 
> informed decision about it. I already opened a bug report for util-
> linux package about no concrete reasons provided:
> 
> util-linux: su from util-linux: no reason why su without setting new 
> environment is bad idea
> https://bugs.debian.org/905478

The reason why preserving the environment across a su or a sudo can be
dangerous is that environments that are meant for use by an
unprivileged process might not be appropriate at all when running as
root.  There are lots of potential reasons why.  Here are some:

* The PATH might include the current directory, and so a script
  running as root might accidentally get the wrong/unexpected binary.
  This could lead to a security breach.

* Some environment variables might cause debugging or logging
  information to go to a specified file.  If a malicious user can
  control that environment variable, bad things can happen when the
  user is running as their own uid.  But even *worse* things can
  happen if the user is running as root.

So the basic security principle here is that scripts should be tested
and run using a single runtime environment.  If the Administrators
Alice and Bob have different environment variables set in their dot
files, then some administrative script might behave differenly
depending on whether Alice or Bob runs the script.  And worse, maybe
Charlie has a third set of environment variables that might cause the
script to do something catastrophically wrong.

So for that reason, it makes sense that a "sudo" or "su" command
should default to something safe.  

> And then: How to implement a backup script that needs root access for 
> most operations, but also requires access to SSH agent from a user 
> setup? Dig out the environment variables of the SSH agent myself? Let 
> the script run as a user and use "setprivs" that is mentioned as 
> recommend in the "su" manpage, yet is in a different package 
> altogether and not part of "util-linux".

You might want to look at the man page for sudo, and its configuration
files, especially sudoers.  It has a *huge* amount of fine-grained
controls over which environment variables should be reset, and which
ones which should be preserved, and whether or not a particular user
should be trusted to override environment variable processing on the
command line.

You can do this on a per-command or per-user basis, and you can do
things like allow some kinds to not require typing a password if it is
a "safe" thing for some set of users to do (perhaps with some controls
over time of day, or what environment variables can be manipulated,
etc.)

Cheers,

						- Ted

-------------------------------------------------------------
-- 
Martin

Message #17 received at 905478@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin@lichtvoll.de>

To: 905478@bugs.debian.org

Cc: "Theodore Y. Ts'o" <tytso@mit.edu>

Subject: Re: Fwd: Re: Debian´s change of "su" to the one in util-linux

Date: Mon, 06 Aug 2018 10:41:21 +0200

Martin Steigerwald - 06.08.18, 10:39:
> severity 905478 wishlist
> thanks

Sorry, I missed using Bcc instead of Cc for bug-control. Please drop 
bug-control from Cc in case you reply.

-- 
Martin

Message #22 received at 905478@bugs.debian.org (full text, mbox, reply):

From: Andreas Henriksson <andreas@fatal.se>

To: Martin Steigerwald <martin@lichtvoll.de>

Cc: 905478@bugs.debian.org, "Theodore Y. Ts'o" <tytso@mit.edu>

Subject: Re: Fwd: Re: Debian´s change of "su" to the one in util-linux

Date: Wed, 8 Aug 2018 21:58:02 +0200

Control: tags -1 + moreinfo

Hi Martin Steigerwald,

On Mon, Aug 06, 2018 at 10:39:54AM +0200, Martin Steigerwald wrote:
> Dear Andreas, dear Ted.
> 
> Andreas, Ted provided an explanation that I can go with. 

I quickly skimmed the upstream thread.

> I understand that you wrote quite something in NEWS.Debian already. I
> lower the priority of the report to wishlist. It may still help to
> explain it to users a bit more carefully. But as I know some of the
> reasons now, I am fine with it either way.

I only documented changed behavior in NEWS. I have no intention to
document long-standing best practises in detail in that file as it does
not belong in a NEWS file. I quickly mentioned 'su' vs 'su -' as a hint
for people to read up as many people still seem to be unknowing of the
difference. I think a better place to document this is as Ted already
suggested in some generic handbook.

> 
> I bet I will go with configuring sudo to take over SSH agent environment 
> variables to the root session. As this is on my laptop, I think I 
> configure sudo to demand to root password instead of the user´s one.

IMHO sudo should always be preferred over su anyway (but I even left
that detail out of the NEWS file as I didn't think it belonged there
either).
FYI debian installer will lock your root account if you leave the root
password field empty and install+configure sudo for your user. Please
lock your root account today and stop using su. If you think it's
annoying to type sudo in front of every command, use sudo -i.
Please feel free to try to convince debian-boot that the root-password
prompt in d-i should be changed to 'expert' level (and thus not shown by
default) to promote this behavior even more (similar to how ubuntu
already does).

Please summarize (in 2 or less sentences or I won't have time to read)
what you still thinks needs to be done in util-linux package to close
this bug report! As things currently stand I'm leaning towards tagging
this wontfix and close the bug report because u-l is IMO not the place
to document generic sysadmin best practises.

Regards,
Andreas Henriksson

Message #29 received at 905478@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin@lichtvoll.de>

To: Andreas Henriksson <andreas@fatal.se>

Cc: 905478@bugs.debian.org, "Theodore Y. Ts'o" <tytso@mit.edu>

Subject: Re: Fwd: Re: Debian´s change of "su" to the one in util-linux

Date: Thu, 09 Aug 2018 21:10:57 +0200

tags 905478 - moreinfo
thanks

Andreas Henriksson - 08.08.18, 21:58:
> Control: tags -1 + moreinfo
[…]
> On Mon, Aug 06, 2018 at 10:39:54AM +0200, Martin Steigerwald wrote:
[…]
> > I understand that you wrote quite something in NEWS.Debian already.
> > I lower the priority of the report to wishlist. It may still help to
> > explain it to users a bit more carefully. But as I know some of the
> > reasons now, I am fine with it either way.
> 
> I only documented changed behavior in NEWS. I have no intention to
> document long-standing best practises in detail in that file as it
> does not belong in a NEWS file. I quickly mentioned 'su' vs 'su -' as
> a hint for people to read up as many people still seem to be
> unknowing of the difference. I think a better place to document this
> is as Ted already suggested in some generic handbook.

Thing is here: It breaks existing workloads. And I have the gut feeling, 
not *just* mine. So no matter what long-standing, under-communicated, 
probably mostly undocumented best practices are in place in your 
opinion, it IMO is likely to produce an uproar with users once next 
Debian version is released.

Anyway, I won´t be who may be addressed by this kind of uproar… and I am 
not responsible for taking care of your well-being or the well-being of 
anyone who may be addressed by it. I just think, providing some 
practical hints could help to smooth the transition for all those who 
used "su" for decades.

> > I bet I will go with configuring sudo to take over SSH agent
> > environment variables to the root session. As this is on my laptop,
[…]
> Please summarize (in 2 or less sentences or I won't have time to read)

I am not responsible for how much time you have.

> what you still thinks needs to be done in util-linux package to close
> this bug report! As things currently stand I'm leaning towards
> tagging this wontfix and close the bug report because u-l is IMO not
> the place to document generic sysadmin best practises.

Well, I´d at least include some practical hints in next Debian release 
notes about this. This might also be a better place than within util-
linux. So maybe reassigning to release notes would do. It could also be 
in README.Debian of util-linux of course

For example how to make available certain environment variables via 
other means:

% cat /etc/sudoers.d/defaults 
Defaults        env_keep+=SSH_AUTH_SOCK

(edited with visudo -f)



[moved downwards]
> […] Please lock your root account today and stop using su. […]

I do not intend to lock the root account, I see no reason to. Instead I 
did the following on my laptop:

Defaults        rootpw
Defaults        timestamp_timeout=0.5

I know this may not be suitable for different scenarios.

(So at least there is some documentation that may ease migration for 
people who used "su" for decades, at least in this bug report.)

Ciao,
-- 
Martin

Message #36 received at 905478@bugs.debian.org (full text, mbox, reply):

From: "Theodore Y. Ts'o" <tytso@mit.edu>

To: Martin Steigerwald <martin@lichtvoll.de>

Cc: Andreas Henriksson <andreas@fatal.se>, 905478@bugs.debian.org

Subject: Re: Fwd: Re: Debian´s change of "su" to the one in util-linux

Date: Thu, 9 Aug 2018 20:06:44 -0400

On Thu, Aug 09, 2018 at 09:10:57PM +0200, Martin Steigerwald wrote:
> 
> Thing is here: It breaks existing workloads. And I have the gut feeling, 
> not *just* mine. So no matter what long-standing, under-communicated, 
> probably mostly undocumented best practices are in place in your 
> opinion, it IMO is likely to produce an uproar with users once next 
> Debian version is released.

Lots of changes break workloads.  The question is how common is a
particular change.  Heck, people tolerate random perl and pythons
scripts breaking when new versions are released, and that's
considered... OK.

Given that other Linux distributions have been using the "new" su, I
very much doubt that many people will notice.  For that matter, I set
my PATH in .bashrc, so the PATH is *always* reset in a new shell, and
in fact, I make sure I know I'm root so my .bashrc sets the prompt
like this:

<tytso.root@cwcc> {/usr/projects/e2fsprogs/e2fsprogs}   (next)
1130# 

(And in fact it does this whether I use su or sudo su.  So I didn't
notice at all.)

Anyway, it's ultimately going to be up to Andreas as the Maintainer,
but perhaps you should try to craft some suggested changes to the
News.Debian.gz file, keeping in mind needs to be *short*.  You may
find that it is harder than it seems to write something that is
generally applicable and useful for most users.

> For example how to make available certain environment variables via 
> other means:
> 
> % cat /etc/sudoers.d/defaults 
> Defaults        env_keep+=SSH_AUTH_SOCK

This doesn't belong in documentation for util-linux, and is
*extremely* specific to what you are trying to do.

As it turns out, I do something very differnt which is my .bashrc will
run ~/.ssh-setup, which looks for existing ssh-agents or gpg-agents,
and if it one doesn't exist, it will start one, e.g.:

   ssh-add -l >& /dev/null
   if test $? = 2 ; then
	echo "Starting gpg-agent...."
	/bin/rm -rf /tmp/ssh-$USER
	gpg-agent --daemon --enable-ssh-support --sh  > $HOME/.gpg-agent-info
	. $HOME/.gpg-agent-info 2>&1 > /dev/null
   fi

(This is only part of a 40+ line script; just to give you a flavor.)

So there lots and lots of different ways of solving these sorts of
problems, depending on what sort of requirements you might have.
(Mine are designed to work in a very large set of environments, not
all of them running Debian, and for that matter, not all of them are
running Linux....)

We can't really give these sorts of tips in the util-linux
Documentation.

Cheers,

					- Ted

Message #41 received at 905478@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin@lichtvoll.de>

To: "Theodore Y. Ts'o" <tytso@mit.edu>

Cc: Andreas Henriksson <andreas@fatal.se>, 905478@bugs.debian.org

Subject: Re: Fwd: Re: Debian´s change of "su" to the one in util-linux

Date: Fri, 10 Aug 2018 13:00:03 +0200

Hi Ted.

Theodore Y. Ts'o - 10.08.18, 02:06:
> On Thu, Aug 09, 2018 at 09:10:57PM +0200, Martin Steigerwald wrote:
> > Thing is here: It breaks existing workloads. And I have the gut
> > feeling, not *just* mine. So no matter what long-standing,
> > under-communicated, probably mostly undocumented best practices are
> > in place in your opinion, it IMO is likely to produce an uproar
> > with users once next Debian version is released.
> 
> Lots of changes break workloads.  The question is how common is a
> particular change.  Heck, people tolerate random perl and pythons
> scripts breaking when new versions are released, and that's
> considered... OK.
> 
> Given that other Linux distributions have been using the "new" su, I
> very much doubt that many people will notice.  For that matter, I set

I agree to disagree here. There is no point continuing the argument, as 
we both have no statistics. Maybe only a few will notice, maybe more 
will notice… I don´t really know.

> Anyway, it's ultimately going to be up to Andreas as the Maintainer,
> but perhaps you should try to craft some suggested changes to the
> News.Debian.gz file, keeping in mind needs to be *short*.  You may
> find that it is harder than it seems to write something that is
> generally applicable and useful for most users.

As Andreas already told he is not interested into adding anything more 
to the NEWS.Debian file I think its pointless to do so.

> > For example how to make available certain environment variables via
> > other means:
> > 
> > % cat /etc/sudoers.d/defaults
> > Defaults        env_keep+=SSH_AUTH_SOCK
> 
> This doesn't belong in documentation for util-linux, and is
> *extremely* specific to what you are trying to do.

I meant this more like an example.

> As it turns out, I do something very differnt which is my .bashrc will
> run ~/.ssh-setup, which looks for existing ssh-agents or gpg-agents,
> and if it one doesn't exist, it will start one, e.g.:

I would not do this for the root user. I so not think it is wise to run 
a ssh-agent or gpg-agent as root. To avoid that is the whole point of my 
change to tell sudo to take over the environment for the SSH agent of 
the user. I don´t even know why I would like searching for any running 
SSH agent. I choose to have it use exactly the one of the user I run the 
sudo command as, instead of second guessing.

> So there lots and lots of different ways of solving these sorts of
> problems, depending on what sort of requirements you might have.
> (Mine are designed to work in a very large set of environments, not
> all of them running Debian, and for that matter, not all of them are
> running Linux....)
> 
> We can't really give these sorts of tips in the util-linux
> Documentation.

Probably not in NEWS.Debian, but I thought about README.Debian or 
Releasenotes… anyway… of course it is up to Andreas. 

Or in upstream documentation. Karel even started to implement 
whitelisting certain environment variables in su :).

Anyway, I have holidays. I have found a solution that works for me. I 
don´t have the impression of a lot of willingness to accept a patch for 
upstream documentation at the moment. So for now I am done with it.

Thanks.
-- 
Martin

Message #46 received at 905478@bugs.debian.org (full text, mbox, reply):

From: "Theodore Y. Ts'o" <tytso@mit.edu>

To: Martin Steigerwald <martin@lichtvoll.de>

Cc: Andreas Henriksson <andreas@fatal.se>, 905478@bugs.debian.org

Subject: Re: Fwd: Re: Debian´s change of "su" to the one in util-linux

Date: Fri, 10 Aug 2018 10:45:09 -0400

On Fri, Aug 10, 2018 at 01:00:03PM +0200, Martin Steigerwald wrote:
> > As it turns out, I do something very differnt which is my .bashrc will
> > run ~/.ssh-setup, which looks for existing ssh-agents or gpg-agents,
> > and if it one doesn't exist, it will start one, e.g.:
> 
> I would not do this for the root user. I so not think it is wise to run 
> a ssh-agent or gpg-agent as root. To avoid that is the whole point of my 
> change to tell sudo to take over the environment for the SSH agent of 
> the user. I don´t even know why I would like searching for any running 
> SSH agent.

Starting a ssh-agent in practice never happens for the root user.
There's an ssh-agent or a gpg-agent running before I su or sudo as
root, so that part of the script never runs.  The reason why searching
for an SSH agent makes sense is for when I ssh into my desktop, and I
want to use the pre-existing ssh-agent running on my desktop.

Cheers,

						- Ted

Message #51 received at 905478-done@bugs.debian.org (full text, mbox, reply):

From: Andreas Henriksson <andreas@fatal.se>

To: 905478-done@bugs.debian.org

Cc: Martin Steigerwald <martin@lichtvoll.de>, "Theodore Y. Ts'o" <tytso@mit.edu>

Subject: Re: Fwd: Re: Debian´s change of "su" to the one in util-linux

Date: Sun, 12 Aug 2018 07:34:25 +0200

There doesn't seem to be any interest in persuing this anymore, so
closing.

There's no actual problem description or even suggestions of what to fix
/in/ util-linux. The bug report title basically translates to "please
educate me", but there doesn't seem to be any interest in listening to
the advice given. While it might indeed be useful to have a more
elaborate explanation on why using 'su' and preserving the environment
is hazardous, that belongs to something like debian-handbook (and
finding a contributor willing to work on it). The bug tracking system is
not a user support forum. There's also several things suggested that
others have said that are plain false. All in all, I don't think there's
any value in keeping this open.

Regards,
Andreas Henriksson

Send a report that this bug log contains spam.