Comment # 24 on bug 1209741 from Joe S

Hi Fabian and Franck,

> Could you share these modifications (sorry if you already did and I missed
> them) ?

I do you one better because I debugged the problem with the default
configuration and have come up with fixes which do not require me to hack the
pam config files which users should not be modifying.

To review....the first issue is that the in the default configuration if you
run cifscreds add -u joe FILESERVER after logging into KDE you get the warning
about no persistent session.

This issue is occurred when the change was was made to switch to systemd for
the session.   Fabian explained this when he said

    "The session itself (plasmashell, krunner, all processes started by those)
     are actually children of the systemd user instance, which is in turn a 
     system service."

To fix that issue systemd-user needs to create the session using pam_keyinit.

So the first patch is to

  cp /usr/lib/pam.d/systemd-user to /etc/pam.d/systemd-user

and them modify /etc/pam.d/systemd-user to add the following as the last line

  session  optional pam_keyinit.so revoke force debug

Ideally the distro will fix this in /usr/lib/pam.d/systemd-user as Fabian has
discussed so that the end user will not need to do this.

The NEW systemd-user would look like

auth     required pam_deny.so

account  include  common-account

session  required pam_selinux.so close
session  required pam_selinux.so nottys open
session  required pam_loginuid.so
session  include  common-session

session  optional pam_keyinit.so revoke force debug  ### NEW LINE ADDED


So that change should have been made when the switch to systemd was done.

However, that is only part of the change.

Since systemd-user is now starting the session and has pam_keyinit, we need to
also modify /etc/pam.d/sddm because it also has pam_keyinit in it ( which would
have been for the configuration BEFORE the switch to systemd ).

If that is not removed then you have the situation which I suspect was
happening where pam_keyinit was called multiple times with force and revoke and
the session key lost the prior values.

As per the pam_keyinit docs, it is designed to be called by the login process
and the current setup is calling it multiple times during the login process
causing the loss of the keys.

So the second part of the fix is to remove pam_keyinit.so from /etc/pam.d at
the same time that it is added to /usr/lib/pam.d/systemd-user ( or the copy in
/etc/pam.d/systemd-user that I used for testing ).

That is the end of the default config changes to resolve the issues.

The last part is to configure pam_cifscreds and that should now be done in the
/etc/pam.d/sddm config file.

Here is the new /etc/pam.d/sddm file

#%PAM-1.0
auth     requisite      pam_nologin.so
auth     include        common-auth

#
# The next line is added so that the users login credentials can be cached
# to allow accessing cifs multiuser mount points without having to call
# cifscreds -u add joe FILESERVER after every GUI login
#
auth optional pam_cifscreds.so debug  

account  include        common-account
password include        common-password
session  required       pam_loginuid.so
session  include        common-session

#
# This line should be DELETED ( I commented it out for now ) because
# the keyring initialization should now be done in systemd-user since
# systemd is being used for the login process.
#
# session  optional       pam_keyinit.so revoke force

#
# This line is added so that and is part of the credential storing in the 
# keyring created
#
session optional pam_cifscreds.so debug host=DADPC



The systemd-user changes and the remove of pam_keyinit.so should be part of the
default pam configuration AFTER the switch is/was made to use systemd.

The pam_cifscreds additional lines should NOT be part of the default pam config
but would be added by the admin when they want to use cifs multiuser mount
points.


After debugging and finding this solution, I updated my TW environment to the
latest TW snapshot which was 20230329 and confirmed that everything is still
working.

With this setup, you "could" issue cifscreds add -u ? FILESERVER after login
and not have any issues with a missing persistent keyring, HOWEVER, you do NOT
need to because if you include the pam_cifscreds.so configuration in
/etc/pam.d/sddm
then it will store your login credentials in the keyring and you will be able
to access the cifs multiuser mount points that are defined in /etc/fstab.

So it seems that all that needs to occur are for a TW build to include the fix
to the default pam config to ADD pam_keyinit.so in /usr/lib/pam.d/systemd-user
and to DELETE pam_keyinit.so from the /etc/pam.d.sddm file.

Since systemd-user is now handling the login and using pam_keyinit.so to create
the keyring I would also HIGHLY recommend that the following files also be
modified to remove pam_keyinit.so, otherwise the keyring gets created and
revoked multiple times during the login process and key values are lost.

The other files are which should also be modified to remove pam_keyinit.so now
that systemd and systemd-user are doing the login and creating the session
keyring are:

/etc/pam.d/sddm-autologin
/etc/pam.d/sddm-greeter  

/usr/lib/xdm
/usr/lib/xdm-np

Fabian, I do not have the knowledge for how to submit those changes for the
distro's default pam config but I believe my explanation of what needs to be
done and why the current config is pretty clear.

Can you PLEASE assist with submitting these changes OR could you PLEASE assist
in helping to determine who this needs to be assigned to that could help with
their submission?

I am available and happy to help with any questions.

Thank you for helping to work though this issue.