Control: severity -1 serious On Sun, 28 Dec 2014 18:29:57 +0100 Christian Kastner <[email protected]> wrote: > > The question is why the PAM stack is processed twice. Perhaps there is > > some way to inhibit the second invocation, although I am not familiar > > enough with systemd/logind to know what to change. > > Thanks to grawity's help on IRC, who indicated that this second PAM > session should be opened in the backround, similar to cron, I noticed > that the PAM configuration for systemd-user @includes common-session, > whereas cron's configuration @included common-session-noninteractive. > > Using common-session causes the breakage in libpam-mount quoted above, > and I assume in other libpam-* modules as well (see eg #572292 when this > was changed in cron). > > Changing systemd-user's PAM config to use common-session-noninteractive > resolves the above issue (and actually another, yet unreported, one in > libpam-mount).
I've raised the severity of this bug (more on that far below), as quoting the original reporter: On Fri, 21 Feb 2014 03:31:06 -0500 Jeremy Salwen <[email protected]> wrote: >> [...] it would properly mount my home directory, but failed to >> unmount it when I logged out. This is a security issue, as it >> leaves encrypted drives vulnerable. It defeats the purpose of pam_mount when mounted devices are not unmounted at logoff, and in the case of encrypted devices, this can indeed be a security issue. I've now run a few tests with other libpam-* packages, namely packages which also use PAM session management (most libpam-* packages are just for auth), and which were simple to test. * libpam-ck-connector: just prints an error: "cannot determine display-device" * libpam-script: Scripts are executed twice. Depending on the script, this could be a major issue * libpam-ssh: Apparently aborts the second session due to lack of a controlling tty Some other modules which use PAM session management, but which I haven't tested, are libpam-krb5, libpam-ldap, libpam-pgsql. I'm sure there are many more. The eventual severity of this bug is of course ultimately at the discretion of the maintainers, but I hope the above is convincing enough to keep it at serious. This would make the bug RC, but the second patch I submitted to this bug [1] should provide a solution to the above issues without (TTBOMK) introducing any new side effects to whatever systemd-user does. If this second PAM session via systemd-user is indeed intended to be merely a background thing, them common-session-noninteractive should be the way to go anyway. But I'm not familiar enough with systemd to make that call. Regards, Christian [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739676#28 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
