On Thu, 2013-11-21 at 00:32 +0100, Lennart Poettering wrote: > On Tue, 19.11.13 10:42, Colin Walters (walt...@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@.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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
