http://bugzilla.opensuse.org/show_bug.cgi?id=1209741 http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c19 --- Comment #19 from Joe S <jmscdba@gmail.com> --- Hi Fabian,
pam_cifscreds' design won't work anymore unless pam_systemd can somehow transfer the session keyring to systemd --user, which is currently just not possible. The design of kernel keyrings does not allow it.
Auth is performed by the DM service (sddm) but the keyring used by the DE session is created by the systemd-user service.
There are 2 problems going on here and it seems that people are getting them confused. I am not ignoring your comment and don't disagree with it, but, PLEASE put it aside for a second and hear me out. In the current TW config ( before you have added pam_keyinit.so to systemd-user ). I have a configuration which I came up with where cifscreds AND pam_cifscreds are BOTH working! Therefore, it is incorrect to say that it is not possible because it is working right now. :-) The problem with that configuration is that I am modifying pam config files which I really shouldn't be modifying. However, when I remove my custom changes and am just using the default pam config files, then after logging in if you do cifscreds add -u joe FILESERVER you get the following warning: Warning: you have no persistent session keyring. cifscreds keys will not persist after this process exits. See pam_keyinit(8). So the default pam config is broken. That's why I submitted this bug report. The reason it is broken is because of what you stated about the login now being done by systemd-user and your fix of adding pam_keyinit.so to systemd-user does in fact fix THAT issue but in doing so creates a NEW but related problem. After making that change to systemd-user to add pam_keyinit.so you can now login and run cifscreds add -u joe FILESERVER and it does not complain about not having a persistent session keyring and it does store the credentials and you can access the shares. BUT, that creates a NEW problem. Now my custom pam config which used pam_cifscreds to add the login to the keyring so you do not have to do cifscreds add -u joe FILESERVER after logging in no longer works. I have tried adding those custom tweaks to systemd-user which I really thought would work but it does not. I have also played around with them in sddm but that didn't work either. I believe that the reason my custom config works is because it is basically creating a keyring "at or near enough to the end" of the login process such that everything works, similar to how if after logging in you can run keyctl session to start a new session and then cifscreds will also work. So it IS possible to make BOTH cifscreds and pam_cifscreds work, but, it requires hacking the pam config files which people should not be modifying, hence, my desire to find a solution which does not modify those files. The PAM manual for pam_keyinit.so says This module is intended primarily for use by login processes. Be aware that after the session keyring has been replaced, the old session keyring and the keys it contains will no longer be accessible. This module should not, generally, be invoked by programs like su, since it is usually desirable for the key set to percolate through to the alternate context. The keys have their own permissions system to manage this. I have a theory that pam_keyinit.so is included in too many places in the default pam config files and often with revoke and/or force and that the real issue is that because it is being called in so many places, when pam_cifscreds add the keys they are later lost because a pam_keyinit.so call later in the process replaces the keyring. That theory seems to be confirmed by the fact that I do have a WORKING pam config with both cifscreds and pam_cifscreds working but it is only possible because I modified pam config files which I should not be modifying. Does that make sense ? -- You are receiving this mail because: You are on the CC list for the bug.