[Bug 1781418] Re: User not being initialized correctly on login

[TJ]

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 at 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 at 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 at .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.

-- 
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to kwallet-pam in Ubuntu.
https://bugs.launchpad.net/bugs/1781418

Title:
  User not being initialized correctly on login

To manage notifications about this bug go to:
https://bugs.launchpad.net/lightdm/+bug/1781418/+subscriptions