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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to 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
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
