When invoking su while being root to become another user then doing a log out, pam_session_close is called from unprivileged code causing the call to fail. This causes systemd to leave empty cgroup sessions. Reproducible: Always Steps to Reproduce: 1. (As root) su <user> 2. logout Actual Results: su[23487]: pam_unix(su:session): session closed for user code su[23487]: pam_systemd(su:session): Failed to lock runtime directory: Access denied su[23487]: pam_close_session: System error Expected Results: pam_unix(su:session): session closed for user code su[30872]: pam_systemd(su:session): Moving remaining processes of user session 36c of code into control group /user/code/master. While systemd isn't in the tree, some users are working to putting it in there, besides i made a test with sys-auth/pam_mount who is in the tree and is facing the same bug as referenced in the URL: su[16358]: pam_unix(su:session): session opened for user code by code(uid=1000) su[16358]: pam_mount(mount.c:68): fsck from util-linux-ng 2.18 su[16358]: pam_mount(mount.c:68): /dev/sda1: limpio, 271/2240224 ficheros, 8576435/8960000 bloques (comprobación en el siguiente montaje) su[16358]: pam_unix(su:session): session closed for user code su[16464]: pam_mount(spawn.c:102): error setting uid to 0 su[16465]: pam_mount(spawn.c:102): error setting uid to 0 su[16358]: pam_mount(mount.c:64): umount messages: su[16358]: pam_mount(mount.c:68): umount: only root can unmount /dev/sda1 from /mnt/data su[16358]: pam_mount(mount.c:722): unmount of /dev/sda1 failed su[16358]: pam_close_session: System error One solution for this bug is using the su implementation that comes with coreutils who doesn't have this issue, while the other fix is to patch su from the sys-apps/shadow package moving the privilege change code after the fork in the child process.
Created attachment 255455 [details, diff] sys-apps/shadow-4.1.4.2-r6 patch to drop privileges in a more appropiate place This patch moves the privilege change code ater the fork in the child code following the same logic of the coreutils and Mac OS implementations of su.
Given we don't actively support systemd, please report this to the shadow project, we'll pick it up after a bump. Seriously, we have enough at hour hands to fix other problems with packages that we _do_ have in tree, I don't want to start messing with patches for packages we don't support.
It seems that su is also causing problems for programs in the portage tree, like pam_mount. Using pam_mount with su, you will get the same error messages because pam_mount can not unmount sessions running with user privileges, only with root privileges. Here is the log: Apr 13 15:59:17 su[28611]: command: 'umount' '/home/test' Apr 13 15:59:17 su[29731]: pam_mount(misc.c:38): set_myuid<pre>: (ruid/rgid=1096/53, e=1096/53) Apr 13 15:59:17 su[29731]: pam_mount(spawn.c:128): error setting uid to 0 Apr 13 15:59:17 su[28611]: pam_mount(mount.c:64): umount messages: Apr 13 15:59:17 su[28611]: pam_mount(mount.c:68): umount: /home/test is not in the fstab (and you are not root) Apr 13 15:59:17 su[28611]: pam_mount(mount.c:720): unmount of homes failed Other distributions reported the exact same problem with su and pam_mount (e.g. Debian Bug #580434). Please apply the attached patch, it works perfect!
Can the status of this bug be changed to something more appropriate since it wasn't really "RESOLVED"? Also, systemd is now in portage, and will be unmasked once openrc is bumped.
not until there is movement upstream
Fixed in shadow-4.1.5.
