Finally finding some time to get back to writing here - yes, I do think it is incorrect behaviour.

Shortly:
If you really feel the need to keep "su" clean, I propose, to resolve this, additional PAM modules that could be attached to "su" and "su-l" events through configuration.

Back to discussion:
I see most critical issues in following situations:
- systems where you cannot install things like ssh - any way to achieve the same result as earlier anymore?
- quite obvious information leak - how can one create a clean environment e.g. for a temporary server than communicates with outside world, with a script now? Especially using a user that has a nologin shell?

(In reply to comment #31)
> gedit just won't save its settings, and that's it.

Way to show scorn! Eristic classes maybe?

It is not "oh, it's just gedit" - almost everything now uses gconf / dconf for settings (and otherwise), including practically all of the GUI and also some command-line tools. It breaks old scripts - simple use of gsettings does not work either as was already shown. Combining this fact with little information about what environment variables programs use (look those up e.g. for gedit while it's mentioned) means we're back to the "diagnose a not working black box" tile.

(In reply to comment #29)
> 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.

This is wrong from the starting point - *YOU* don't want people get a completely new session. If it was impossible I wouldn't become myself after ssh'ing into a server but rather some mutilated root offspring, because that's what's running the server daemon. I see no reason to not let people get exactly what ssh is giving them (auditing? - read on).

Also, why would it "kinda defeat the point of su"? What is THE point of su? If you would be so kind to enlighten me.

> OTOH the home directory should probably be the one of the destination user
> afterwards, but the current directory the one of the source user.

Isn't this was is happening now?

> The audit trail should be the
> one of the old user, but $PATH of the new user. And so on and so on.

This idea of auditing is coarse-grained. Finer auditing could be made through permanent process parent tagging (PPPID, different from casual PPID) - if a process was forked off some other it is permanently tagged as it's child even if it forks and PPID changes to 1. The PPPID would disappear only when all of its forks die.

If such auditing was implemented there would be no reason to keep and secure explicit loginuid since it's equivalent could be derived from the permanent-process-parent chain. What I wouldn't give to have SUCH auditing - many times have I wondered what other process forked off a process that is now PPID 1.

This idea is also quite similar to CGroups which are already implemented, so it might not have to be written from scratch.

> 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.

If it's like that, it won't work anyway, because most new sessions don't have appropriate rights to interact with an old session's socket! Quit thinking "su" is used only for getting super-user rights. Even the first example in this bug report is otherwise.

> 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.

Once again - have you identified THE general case? I say, general case is generalising individual cases. How is it then that the *previous* "general case" worked fine with everyone? Please, if the idea ain't broken, don't fix it.

And we should by all means try to make "su" do the most - it's all about getting most of automatisation! Setting even a few variables every single time one is logging in isn't really getting along with the DRY principle, does it?

> 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.

So maybe create some additional PAM modules based on people's needs and therefore those could be easily detached and attached?

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

This is not always applicable, especially in the world of embeded.