Comment 96 for bug 1197395

I explicitly chose to bind this to loginuid rather than anything else. People shouldn't fool themselves in assuming that "su" would get them a completely new session that has all properties of the destination user rather than the source user. THis is technically not possible, and if it would be implemented would even kinda defeat the point of su.

For example, people probably want DISPLAY= to be the old one so that their root program they started with su an run on X11. OTOH the home directory should probably be the one of the destination user afterwards, but the current directory the one of the source user. The audit trail should be the one of the old user, but $PATH of the new user. And so on and so on.

So people want a weird mix of things from the old and the new user session, and even worse, people want different things from the old and from the new session. For example, PA now places its socket in XDG_RUNTIME_DIR, and so does dconf. But apparently this bug report is a complaint that dconf should be the one of the new user. THis would break audio of however, which probably should be the one of the original user.

So, we should not pretend we could make "su" work properly for the general case, or that we could find a way that makes this work for everybody.

When we decided to base our systemd XDG_RUNTIME_DIR logic on the audit login session id (if it is available) is the thinking that "su" should be minimal in its effect, and almost everything that is not explicitly detached from the old session should continue to be from the old session. i.e. the default should be not to detach rather than to detach.

If you want a fully detached text session then use "ssh localhost" or so, which virtualizes everything.

So really, I see little to fix here in systemd. I believe basing this on loginuid is the right thing. And if the trade-off is between breaking PA and breaking dconf my choice is to stick to what makes sense on logical level.