Open samuelsadok opened 6 years ago
I don't have any idea what might causing this problem. I also have no idea how systemd interacts with pam. (sidenote: I don't use systemd on any of my machines)
We may return PAM_SESSION_ERR
in a few cases when opening a session. For example, if pam_e4crypt
fails retrieving the keys or looking up the user. We log an error-message in each of those cases, but it may still be eaten up somewhere along the way.
I'm kinda busy right now and I'll probably be until the end of January, so I'll have little opportunity to set up a testing-VM with some systemd-based system and debug the issue. Maybe you could run an authentication command (e.g. spawn a session) with a gdb
attached?
Does PAM load all modules up front and then just call the
pam_sm_open_session
functions in order?
This shouldn't really matter since only code which is actually run might cause this kind of problem, assuming that a missing symbol or failure to load a module would yield another error message.
Also note that this module is rather experimental and that at we have a pending PR (#28) which may alter the behaviour of this module in a breaking way.
Ok so the solution turned out to be using the user keychain instead of the session key chain.
This is what my /etc/pam.d/system-login
looks like now:
[...]
session required pam_keyinit.so force revoke
session optional pam_e4crypt.so keyring=@u
[...]
Maybe you wanna mention this in the readme.
The original issue was caused like this:
Authentication phase: pam_e4crypt
succeeds
Session spawn phase:
pam_systemd
notifies systemd-logind
about the new sessionsystemd-logind
sees that this is the first session of this user and thus tries to set up a couple of things such as systemd user services. To this end it spawns another session.pam_e4crypt
's pam_sm_open_session
is executed the second session, however the data from the authentication step (pam_e4crypt_key_data
) is not available here. For some reason systemd-logind silences the output of pam_e4crypt
. Since I had the module required
, the rest of the pam_systemd
failed.pam_e4crypt
was executed for the first session, where it succeeded.My first reaction was to make the module optional
, but apparently session keys are not inherited like that. This way the systemd user daemon can create a session but not access configurations in $HOME. The user keychain in contrast is the same in all of the user's sessions.
Also note that this module is rather experimental and that at we have a pending PR (#28) which may alter the behaviour of this module in a breaking way.
As long as I have my salts backed up, experimental is fine for me :) And yes I saw that PR.
Huh. Sounds like a systemd-bug (or another unfortunate "intended behaviour") to me. I'll pick up work on pam_e4crypt
soon and at least add something to the README.
Some part of the PAM open-session step fails on my system if (and only if) I enable pam_e4crypt. The weird part is that the error occurs before pam_e4crypt is executed.
Good session start No
session [...] pam_e4crypt.so
was enabled.journalctl
:Bad session start
session required pam_e4crypt.so debug
was appended to the end of/etc/pam.d/system-login
(I know the debug option has no effect).journalctl
:Both tests were done immediately after a fresh reboot.
The end effect of this is that the user services don't start.
Any ideas why this might happen? Has anyone seen this before? A Google search turned this up, but the main thing I learned from that is that PAM's error message is useless. Does PAM load all modules up front and then just call the
pam_sm_open_session
functions in order?