Bug#884964: using "su - " in postinst causing some installs to fail
On Sat, 23 Dec 2017 at 19:42:05 +0000, Sean Whitton wrote:
> control: retitle -1 Discourage 'su -' in maintscripts, in favour of plain 'su'
Plain 'su' is also problematic, because it inherits the entire
environment, including variables like HOME, XDG_RUNTIME_DIR, XDG_*_HOME,
DBUS_SESSION_BUS_ADDRESS that make little sense to inherit across
privilege raising or dropping. A typical failure mode is to create files
in user A's directory owned by user B, which either causes a denial of
service for user A, or makes user A accidentally trust user B, neither
of which is good. That failure mode can be mitigated by software that
checks ownership of these files and directories before using them
(like dbus does when using XDG_RUNTIME_DIR, specifically to defend
against being used under su), but it seems unrealistic to assume that
everyone will always remember to include such checks.
runuser(1) might be a better thing to recommend for non-interactive use,
although that doesn't scrub the environment by default (runuser -l does),
so variables like XDG_RUNTIME_DIR can still be a problem.
If we had a reliable way to arrange for a script to be run in a
known/predictable environment without inheriting arbitrary state from
its parent, that would probably be a better solution to this than ad-hoc
privilege-dropping elsewhere in the process inheritance tree. If systemd
was mandatory, then one obvious answer would be to use systemd-run(1)
to ask systemd to run it as a child of process 1; but other init systems
are supported, so we can't rely on that.
The su(1) man page also says
The su command is used to become another user during a login session
which isn't really what's happening here (maintainer scripts aren't
necessarily run within login sessions), so perhaps this is su not being
used as intended?
Terry Roy wrote:
> The use of
> the '-' causes full login shell exec to /bin/sh which was incompatible
> with our /etc/profile.d files.
Arguably the bug here is that there was a file in /etc/profile.d that
assumed bash syntax, rather than guarding bashisms with a check for
$BASH_VERSION or similar. I would recommend changing those profile
snippets so the problematic parts only run on shells that are known to
support them (bash and maybe zsh).
For many uses of profile snippets, it would make sense to wrap them in a
guard against non-interactive shells, which also dodges any issues that
those snippets might cause in non-interactive shells.
smcv
Reply to: