Comment 13 for bug 1781418

I added an additional log report to the function drop_privileges() since that contains a call to setgroup(0, NULL) which, if called as the user, would have the effect of removing all the supplementary groups.

diff --git a/pam_kwallet.c b/pam_kwallet.c
index 07b357d..147f129 100644
--- a/pam_kwallet.c
+++ b/pam_kwallet.c
@@ -361,6 +361,7 @@ static int drop_privileges(struct passwd *userInfo)
     * aren't root, so don't bother checking the return value, this
     * is just done as an optimistic privilege dropping function.
     */
+ syslog(LOG_ERR, "%s uid=%d gid=%d drop_privileges(uid=%d, gid=%d) calling setgroups(0, NULL)", logPrefix, getuid(), getgid(), userInfo->pw_uid, userInfo->pw_gid);
     setgroups(0, NULL);

     //Change to the user in case we are not it yet

Built the libraries and installed them and found that the problem wasn't occurring and the new syslog message was showing the correct current UID of 0 when setgroup() was called.

Then I managed to reproduce it and found this syslog message is NOT appearing, meaning drop_privileges() isn't being called. I then searched /var/log/auth.log and discovered that when this issue is present pam_kwallet is failing to access the user's pam_kwallet sockets:

lightdm: pam_kwallet(lightdm:session): pam_kwallet: pam_sm_open_session
lightdm: pam_kwallet(lightdm:session): pam_kwallet: final socket path: /run/user/1000/kwallet.socket
lightdm: pam_kwallet(lightdm:session): pam_kwallet-kwalletd: Couldn't listen in socket
lightdm: pam_kwallet(lightdm:session): pam_kwallet: Impossible to write walletKey to walletPipe
lightdm: pam_kwallet5(lightdm:session): pam_kwallet5: pam_sm_open_session
lightdm: pam_kwallet5(lightdm:session): pam_kwallet5: final socket path: /run/user/1000/kwallet5.socket
lightdm: pam_kwallet5(lightdm:session): pam_kwallet5-kwalletd: Couldn't listen in socket
lightdm: pam_kwallet5(lightdm:session): pam_kwallet5: Impossible to write walletKey to walletPipe

But then, after several "systemctl restart lightdm" where these failures didn't occur and the groups still weren't being set I stopped lightdm and switched to a console log-in.

That suffered the same problem; I used "systemctl status" and saw that despite stopping the GUI session there was still a user@1000.service with several of the GUI user services still running, one of which was named "(sd-pam)" - which I supposed was systemd related.

I did "systemctl stop user@1000.service" and then killed the current tmux/login session with "tmux kill-session -t 3" (3 being the remaining tmux session).

Upon log-in to the console the supplementary groups are set.

Returning to "sd-pam" I found the following helpful explanation:

https://unix.stackexchange.com/questions/213334/why-add-parentheses-around-a-process-name#278876

  * (sd-pam) is the special case

    If we spawn a unit with a non-empty 'PAMName=', we fork off a child-process inside the unit,
    known as '(sd-pam)', which watches the session. It waits for the main-process to exit and then
    finishes it via pam_close_session(3).

The service /lib/systemd/system/user@.service template sets PAMName=systemd-user and launches "systemd --user" in the user slice.

In my duplicate report Bug #1784964 I theorised originally that a recent systemd update was responsible. Based on my debugging so far with pam_kwallet the two may be interacting somehow.