Your message dated Sun, 12 Aug 2018 07:34:25 +0200
with message-id <20180812053425.kjwuhfj25k3u4...@fatal.se>
and subject line Re: Fwd: Re: Debian´s change of "su" to the one in util-linux
has caused the Debian Bug report #905478,
regarding util-linux: su from util-linux: no reason why su without setting new 
environment is bad idea
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
905478: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905478
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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

--- End Message ---
--- Begin Message ---
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

--- End Message ---

Reply via email to