[systemd-devel] pam: Don't use loginuid [was: Re: Fix PAM module to not clobber XDG_RUNTIME_DIR with su]

Colin Walters walters at verbum.org
Wed Nov 20 16:19:23 PST 2013


On Thu, 2013-11-21 at 00:32 +0100, Lennart Poettering wrote:
> On Tue, 19.11.13 10:42, Colin Walters (walters at verbum.org) wrote:
> 
> > My patch though starts to pave the way for having XDG_RUNTIME_DIR
> > consistently point to that of the user's uid
> 
> I think this is just bogus. You used "su". 

I use pkexec, not su.  One important difference between them is
pkexec *always* clears the environment to a whitelisted set.

Please don't confuse my targeted fix with the larger "you" group
of people from the RHBZ.

> So the UID was changed and
> little else. Now you start patchign XDG_RUNTIME_DIR too, but what about
> access to X11? This kind of "mix and match" is just really really
> broken, 

I agree.  I have no intention to change pkexec to allow access to
X11. 

> For example,
> dconf requires dbus and XDG_RUNTIME_DIR to stay in sync. 

The case of dbus and XDG_RUNTIME_DIR is of course interesting because
in the user bus future, XDG_RUNTIME_DIR will give access to DBus.

But concretely right now what will happen with pkexec + app that uses
dconf is quite simple - GDBus will notice there's no
DBUS_SESSION_BUS_ADDRESS (because again, pkexec cleared it), try to
autolaunch one which will attempt to contact $DISPLAY, and *fail*.

And that's fine by me.

> PA requires
> expects XDG_RUNTIME_DIR and X11 to be ins ync.

I am not talking about making PA work or its synchronization to X11.

>  dbus mantains X11 root
> window creds, so binds things together with X11. 

I am not talking about proxying or inheriting $DISPLAY.  I
am talking about pkexec.

> So yeah, there your mix
> and match is broken: 

I'm proposing a simple goal: XDG_RUNTIME_DIR should always be that
matching the current uid.  I can't think of any case where you'd
want it otherwise.

(Really ideally this would be in the kernel - if a process with uid N
 exists, it can access /run/user/N)

> It's so entirely arbitrary switching some things over and others not. 

Again from my perspective as a pkexec maintainer, it is now totally
consistent with this patch.

> am pretty sure the only sensible thing is to say that "su" and "sudo"
> are minimal, and doesn't switch anything over but the bare minimum,
> which is the UID. It stays inside the same XDG_RUNTIME_DIR, PA, X11,
> dbus, logind session id and so on.

I'm not talking about non-environment-clearing "su/sudo".  

> And then, make "su -" and "sudo -s" switch over as much as possible,
> i.e. XDG_RUNTIME_DIR, PA, X11, dbus, logind session id.

Er...why would you have PA and X11 for "su -"?

(Now of course with the user at .service patches I was working on,
 things like libX11 pick up the address from XDG_RUNTIME_DIR, whiich
 would mean you *do* get those if you've already logged in as the
 target user)

> For that, add a new parameter to pam_systemd maybe
> "force-new-session=yes/no" or so which is set in "su -"'s PAM config
> stack, but not in "su"'s PAM config stack (luckily they are stored in
> two separate files). 

In my case, I'm happy to change pkexec to pass such a flag.

> Note however, that his will not allow people to su to another user and
> then run firefox from there. 

Yes, and I think that use case is crack; I'm not talking about fixing
it.  I care about pkexec.




More information about the systemd-devel mailing list