Comment # 6 on bug 1209741 from 
Thanks Fabian and Valentin for your research and efforts, I really appreciate
it!

(In reply to Valentin Lefebvre from comment #5)

> key sessions are managed by the module pam_keyinit.so already mentioned. But
> when you log from a GUI, dbus-daemon will change the session user keyring.
> Each Display Manager (gdm for gnome, sddm for KDE, etc...) will used
> systemd-user in the PAM stack. This is why, the login session keyring is
> different from the condole login to the gui login.
> It was previously discussed here [2], by our previous pam maintainer.

Thanks for that very detailed explanation.

> To fix that, you can add the module pam_keyinit.so to revoke the key
> settings manage by d-bus in pam.d/systemd-user.
> I made a test and it looks to work in session from GUI login. Can you
> confirm if it works for you also ?

I performed the test, with one change.   Instead of modifying
/usr/lib/pam.d/systemd-user, I copied it to /etc/pam.d/systemd-user and then
made the change there.

After logging out and back in, the keyring is there and cifscreds can add to
it which is the good news.

I don't know if you caught this from my bug report but this all used to work
and sometime roughly 9 months or so ago it was broken.

Today I dug out the oldest ISO I could find for TW and it was for 2021-02-15
and I created a new VM for testing and installed that build! :-)

After the install completed, I added the CIFS mounts to /etc/fstab and mounted
the shares.

Then on my joe user, with NO changes to pam configs ( or anything else ) I ran 
cifscreds add -u joe fileserver to add the credentials and then the files on
those CIFS mounts worked fine.

So clearly something since that point in time was changed which broke all this.

2021-02-15 predates lots of things a short list is....

   Is before the usr-bin merges
   It is using kernel 5.10.16.1
   There is no /usr/lib/pam.d the files are in /usr/etc/pam.d and /etc/pam.d

systemd-user was only in /etc/pam.d and looked like this

  account  include common-account

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

NOTE That it did NOT contain pam_keyinit.so and yet the secondary keyring was
created properly and cifscreds worked!

This reinforces the point that "something" in the login stock was broken since
then which is the root cause of this issue since it used to work fine.






The other part of this all though is that there is another module pam_cifscreds
which when added to the pam configuration will cache the Linux users
credentials during the login eliminating the need to even use cifscreds.

When I replaced my Windows server with a Linux server running TW, once I setup
Samba on the Linux Server and all the users using the same smb passwords as
they use on Windows, the switch was completely transparent to the Windows
clients, their drives are mapped and everything works flawlessly.

I am still somewhat shocked that there does not appear to be a simple way for a
Linux client to connect to that same Linux server's samba shares and use their
Linux credentials in the same way the Windows clients can.

cifscreds allows you to do this BUT is dependent on pam_keyinit.so creating the
keyring and requires the users to do it each time.

pam_cifscreds.so caches up the credentials at login and therefore the users
don't have to do it.


Your proposed solution ( which seems like the right answer to the initial
problem ) makes sense to me, however for some reason now pam_cifcreds.so does
not appear to allow having it auto cache the credentials even if I add the
correct additional entries to the systemd-user file which we added the
pam_keyinit.so too.

In my testing I think that the reason is because pam_cifscreds is somehow now
storing the cached credentials in the _ses keyring instead of the _uid_ses.1000
keyring.

Is there a better way to have a Linux client use cached credentials to access a
remote Samba share so that they don't have to enter their password again after
logging in ?

Thanks for those links.

From your second link it says:

    IIRC the usual advice by Lennart is to use the user-wide @u keyring instead
    of session keyrings. (Programs searching in @s should automatically find
    credentials added to @u, as pam_keyinit creates the link by default.)

   A few years ago I have asked one affected kernel subsystem (cifs) to allow
   using @u. They had no interest in doing so. I have since then decided to
   just give up on being able to use cifs -o multiuser. (See also: GitHub
   issue regarding AFS PAGs.)

It seems to me like, if cifs used @u and pam_keyinit_so and pam_cifscreds all
used @u then all of these problems would go away.

You are receiving this mail because: