Comment 111 for bug 1197395

(In reply to comment #42)
> Well, there is never geing to be a "fully functional" implementation of "su
> -" because it always inherits state from the session, and that state is
> quite substantial.

Care to explain what exactly is inherited through loginuid?

> I mean, you can reopen this bug as much as you want, but I fundamentally
> believe that the scheme of "su" (or "su -" if you want to nitpick), can
> never work for desktop applications.

It worked for years well enough, only having to set up xauth to let two separate environments access the same display. What made it suddenly impossible?

You've mentioned audio - couldn't it be solved by a similar authentication forwarding mechanism?

> You can lie to yourself, and claim
> D-Bus wouldn't exist and what else, but I don't see why systemd should play
> this game of pretending.

AFAIK D-Bus uses DBUS_SESSION_BUS_ADDRESS, which can be separate; org.freedesktop.DBus.GetConnectionUnixUser does not use the loginuid. What exactly is problematic about D-Bus?

> Anyway, closing again. This can never fly. And the same way as the
> destination user might or might not get access to the bus, it should also
> get or not get access to the XDG_RUNTIME_DIR. It's the same thing.

When an unprivileged-user-foo does (su - unprivileged-user-bar), the user "foo" should not be asked to give away access to all of XDG_RUNTIME_DIR. That would make (su -) a "please compromise me" command.