3 ms·

RE: "vs. doing the work to write a PAM module that behaves in the required manner." - That's easy, the functionality necessary to create a clean login in a cont

RE: "vs. doing the work to write a PAM module that behaves in the required manner." - That's easy, the functionality necessary to create a clean login in a container is beyond the scope of what PAM does.

peterwwillis 11y ago
Define clean login? I'm not aware of such a spec. 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-support/ 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.
- digi_owl 11y ago
  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).
simoncion 11y ago
You see peterwwillis's reply to your comment? That's the sort of meaty discussion I was looking for. Your post -while better than your first- is the sort of content-light, platitude-heavy post that I most often see from folks who have taken a side in a tech holy war but are not otherwise really involved. [0] I would very much like to engage you in a real technical discussion. I'm eager to learn new things! > [T]he functionality necessary to create a clean login in a container is beyond the scope of what PAM does. Given that I use a PAM module that takes the login password that I keyed in, calls out to cryptsetup using that password to unlock an encrypted volume, creates the mountpoint for that volume, mounts it, then -when I've logged out- (optionally) kills any processes of mine that may still be running, then reverses those mount and unlock operations, I'm not convinced that your claim is true. Please convince me otherwise! :D [0] Why is it the most frequent? I don't know for sure, but I suspect that the adage "It's easy to have opinions, but much harder to have informed opinions." would be applicable.

peterwwillis 11y ago

Define clean login? I'm not aware of such a spec. 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-support/ 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.

digi_owl 11y ago
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).

simoncion 11y ago

You see peterwwillis's reply to your comment? That's the sort of meaty discussion I was looking for. Your post -while better than your first- is the sort of content-light, platitude-heavy post that I most often see from folks who have taken a side in a tech holy war but are not otherwise really involved. [0] I would very much like to engage you in a real technical discussion. I'm eager to learn new things! > [T]he functionality necessary to create a clean login in a container is beyond the scope of what PAM does. Given that I use a PAM module that takes the login password that I keyed in, calls out to cryptsetup using that password to unlock an encrypted volume, creates the mountpoint for that volume, mounts it, then -when I've logged out- (optionally) kills any processes of mine that may still be running, then reverses those mount and unlock operations, I'm not convinced that your claim is true. Please convince me otherwise! :D [0] Why is it the most frequent? I don't know for sure, but I suspect that the adage "It's easy to have opinions, but much harder to have informed opinions." would be applicable.