Control: tags 726661 + moreinfo On Thu, 13 Nov 2014 at 09:19:42 +0000, Simon McVittie wrote: > Anyone else, please reply to #726661 if discussing pam_loginuid or > the new clone (bug number to be determined) if discussing PermitRootLogin.
Here is the part of that bug specifically about pam_loginuid. I believe this regressed when https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677440 was fixed, adding pam_loginuid for the benefit of (at the time) ConsoleKit; it is also used by auditd and systemd-logind. I cannot reproduce this bug on a (somewhat outdated) jessie system with sysvinit. I would like some more information from the people who are affected by it: * Are you using a non-Debian kernel? * Does your kernel have AUDIT_LOGINUID_IMMUTABLE set in its configuration? * What init system are you using? (sysvinit? systemd? Upstart? something else?) Further discussion of possible causes, workarounds, etc. below. ---- I've added a bunch of somewhat relevant people to Cc: everyone who reported seeing this bug or similar, Laurent and Michael because they were involved in #677440 and seem to know about loginuid/audit in general, and the PAM maintainers. Summarizing for those who weren't previously in Cc, I think the steps to get this bug are something like this: * Have a non-Debian kernel configuration (?) * Run sysvinit (*not* systemd or Upstart) as pid 1 * pid 1 and other system services initially have loginuid -1, which means "undefined, not part of a login" * Be in a root shell that has been given a loginuid other than -1, either: - log in as root with a version of login, openssh-server, etc. that uses pam_loginuid; your loginuid will be 0 - log in as an ordinary user (uid 1234, say) with a version of login, openssh-server, etc. that uses pam_loginuid, and use su or sudo to get the necessary root privileges to restart openssh-server; your loginuid will be 1234 * Restart openssh-server, either manually or as a side-effect of an upgrade * Start a new parallel login via ssh, either as uid 0, 1234 or something else * cat /proc/self/loginuid Desired result (which is what I get): * New parallel login succeeds * In the new parallel login, /proc/self/loginuid equals $(id -u) What seems to be happening to the people affected by this bug, but I cannot reproduce it: * The restarted openssh-server has the same loginuid as the shell from which you started it * Transitions from loginuid == -1 to loginuid != -1 are not allowed [1] * pam_loginuid fails with: pam_loginuid(sshd:session): set_loginuid failed [1] surprises me, because this is conditional on a kernel option, AUDIT_LOGINUID_IMMUTABLE, which is designed for systemd and similar systems and doesn't seem to be set in Debian kernels according to /boot/config*... see <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=633b454>. Possible workarounds include: * Remove pam_loginuid.so from the ssh configuration (confirmed to work, but it would reopen #677440 and doesn't seem a great idea distro-wide) * Use a modern init system that starts system services via IPC to pid 1, i.e. systemd or Upstart - The restarted openssh-server has loginuid -1 - The transition from -1 to 4321 succeeds - Everything's fine * Use a Debian kernel without AUDIT_LOGINUID_IMMUTABLE (?) * Drop pam_loginuid.so from required to optional in the ssh configuration (?) It's a pity we can't enable pam_loginuid.so if and only if init is modern (systemd or Upstart). Perhaps patching it would be another option? As far as I can see, other services that use pam_loginuid would typically have the same bug, but there are mitigations: * getty/login are started by "IPC" to init (edit inittab, send signal) even under sysvinit, so they are unaffected * Display managers (gdm, lightdm etc.) are not typically restarted automatically on upgrades because that would disrupt current X sessions, so they are unaffected unless the user restarts them manually without rebooting If my assumptions about the cause are correct, then I can't see any way to get the desired result in openssh-server when run under sysvinit. Can someone else? The best I can come up with so far is to to change from the current session required pam_loginuid.so to session optional pam_loginuid.so That would mean that login to the restarted openssh-server worked, but its sessions had the wrong loginuid until the machine was rebooted. Regards, S -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
