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 ?