[systemd-devel] Fix PAM module to not clobber XDG_RUNTIME_DIR with su

[Martin Pitt]

Hey Lennart,

Lennart Poettering [2013-11-21  0:16 +0100]:
> On Thu, 14.11.13 07:45, Martin Pitt (martin.pitt at ubuntu.com) wrote:
> 
> > Hello all,
> > 
> > pam_systemd currently causes some havoc when you run programs or
> > shells with su: it passes on the $XDG_RUNTIME_DIR from the original
> > user session, so that programs like pulseaudio or dconf end up
> > scribbling into the original user's runtime dir. This has been
> > discussed at length at [1][2] and is leading people to consider
> > workarounds like [3].
> > 
> > It seems Lennart is against giving the new user a new logind session
> > and runtime dir; I think it would be right to give it a fresh (or an
> > already existing one for the target user) runtime dir, but in either
> > case passing it the original user's runtime dir is actively wrong and
> > harmful.
> 
> Well, that's quite arbitrary. What about dbus, X11, and so on, do you
> plan to turn that off for the new session too?

At the moment, there is no dbus to turn off -- "su - otheruser" does not
take the environment from the original session (if it does, it's
misconfigured); and even if it does, it wouldn't work as otheruser 
cannot access the original user's session or user bus anyway.

As to what happens to $DISPLAY, I have no strong opinion about it. But
that's not the concern of libpam-systemd anyway.

> su is a hack, it is not clear what credentials it changes and which ones
> it doesn't.

I think people keep confusing "su" and "su -" here. The manpage says

       -, -l, --login
           Provide an environment similar to what the user would expect had the user logged in directly.

which shows the intention pretty well: It should be by and large
similar to what I get when I log into a VT. It doesn't do that now as
it doesn't get a seat and a runtime dir, but concerning credentials it
should fully switch to otheruser's uid, groups, etc. It runs a full
PAM stack after all, which should prepare the environment accordingly.
This is similar to pkexec.

"su user" is an entirely different matter, as you say. It should do
little more than calling setgid()/setuid(), so there is no hope that
this could ever do anything sensible for a program which depends on
the environment. I don't remember ever having used it. Please let's
keep it out of the discussion, since it isn't related to pam-systemd
and as you say its semantics are pretty much broken anyway.

> Quit frankly, I am pretty sure the best approach is to simply prohibit
> running graphical applications from su sessions, it's never going to
> work.

Fine for me. But trying to run them should properly fail then, not
clobber the other user's home directory and then cause failures for
the original user.

> Letting other user access some (but not all) of a private user's
> bits and pieces is never going to work if those bits and pieces are
> nowadays a mix of dconf, X11, PA, dbus, security creds, keyrings,
> yadda yada...

Exactly my point! Hence, we must *not* pass another user's runtime dir
in logind/the PAM module.

> So, what's the intention here? That XDG_RUNTIME_DIR is entirely unset
> after "su"? That sounds kinda acceptable to me.
Yes, for "su -" and pkexec. It might not work for "su" as that is
likely configured to not run PAM, see above. 

That's what my patch is doing and what would prevent the damaging of
runtime dirs. It's not what I consider ideal (I prefer Colin's
approach of giving him the *correct* user's runtime dir), but if we
can't have that, let's at least not pass the wrong one.

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20131121/d30a77f7/attachment.pgp>