In fact, the author of the change, Lennart Poettering, says nothing about wanting to have a login, much less a 'clean' one. They have login functionality already. He only mentions that the way su provides the user a shell as the super-user is 'very unclear' and 'weakly defined', and thus the tool has a 'broken concept'.
The reason this was even written was a bug that systemd introduced. As i'm sure you're well aware, $XDG_RUNTIME_DIR is an environment variable used by the XDG base directory specification to specify a directory that the user's applications can write state to, and is destroyed on termination of the session. The pam_systemd plugin apparently fails to do this because it tries to create a new session when they're already running in a session.
As i'm also sure you're aware, 'su' is not intended to be a login program. That's what login is for. What Poettering was confused about is defined by the source code for su, in su-common.c of util-linux:
"Run a shell with the real and effective UID and GID and groups of USER, default `root'."
And that seems to be what 'su' does. Hmm.... yeah, this is definitely a very unclear and weakly defined concept. I can see now why Poettering had to implement a new tool for systemd to fix a bug with pamd_systemd not being able to create a session, and the user not knowing how to use the xdg-support pam plugin. Stupid UNIX!
As to another user's comment about how 'su' works: if you use it without the login-simulation feature, it only changes HOME and SHELL (and USER and LOGNAME if not becoming superuser). With login-simulation, it changes HOME, SHELL, USER, LOGNAME, PATH, leaves TERM alone, and deletes all other environment variables.
This is seen as a bug, which I can understand, if you're running 'su' in a complicated new system with new features which need special care to support. In such a case one would normally patch the application to include support and not reinvent the wheel, but that requires working with other people, which isn't really systemd's strong suit.
In effect, something su was doing broke whatever infosec voodoo systemd was trying to do to keep track of "sessions".
Part of this was what path that xdg variable got set to, so in their infinite visdom the systemd devs decided to clear it whenever su was run.
This in turn lead to various programs curbstomping user files as root (in particular Gnome ones, surprise surprise).
At this point in time it seems like one would do best to stay well away from anything related to Systemd, Gnome, Freedesktop and Fedora. The mixing of roles in those groups is downright worrying (i wonder how many times i have seen someone use a Gnome blog to port straight RH/Fedora news, even though the latter surely has their own blogging facilities).
In fact, the author of the change, Lennart Poettering, says nothing about wanting to have a login, much less a 'clean' one. They have login functionality already. He only mentions that the way su provides the user a shell as the super-user is 'very unclear' and 'weakly defined', and thus the tool has a 'broken concept'.
The reason this was even written was a bug that systemd introduced. As i'm sure you're well aware, $XDG_RUNTIME_DIR is an environment variable used by the XDG base directory specification to specify a directory that the user's applications can write state to, and is destroyed on termination of the session. The pam_systemd plugin apparently fails to do this because it tries to create a new session when they're already running in a session.
Oh hey, look. There's a PAM module that handles setting this variable, too. https://apps.ubuntu.com/cat/applications/raring/libpam-xdg-s...
As i'm also sure you're aware, 'su' is not intended to be a login program. That's what login is for. What Poettering was confused about is defined by the source code for su, in su-common.c of util-linux:
"Run a shell with the real and effective UID and GID and groups of USER, default `root'."
And that seems to be what 'su' does. Hmm.... yeah, this is definitely a very unclear and weakly defined concept. I can see now why Poettering had to implement a new tool for systemd to fix a bug with pamd_systemd not being able to create a session, and the user not knowing how to use the xdg-support pam plugin. Stupid UNIX!
As to another user's comment about how 'su' works: if you use it without the login-simulation feature, it only changes HOME and SHELL (and USER and LOGNAME if not becoming superuser). With login-simulation, it changes HOME, SHELL, USER, LOGNAME, PATH, leaves TERM alone, and deletes all other environment variables.
This is seen as a bug, which I can understand, if you're running 'su' in a complicated new system with new features which need special care to support. In such a case one would normally patch the application to include support and not reinvent the wheel, but that requires working with other people, which isn't really systemd's strong suit.