User not being initialized correctly on login

[Tobias Knöppler]

As of lately, something about the login session breaks horribly when logging in via Lightdm/Slick-Greeter. I'm not quite certain what causes the issue, however here are the symptoms:

* The user when logged in, seems not be in any group except for its main group (e.g. `groups` yields just `username`). This is not the case when checking groups in TTY, after starting the X-server from TTY or when executing `sudo -u <username> groups`.
* Login works (with the described symptoms), but when trying to log out after having logged in from the greeter, the DM just restarts and apparently creates a new session (without requesting my password, so that the keyring needs to be manually unlocked)
* On every login attempt there seems to occur the following error in /var/log/auth.log:

```
Jul 12 16:20:32 GlaDOS dbus-daemon[1231]: [system] Rejected send message, 2 matched rules; type="method_ca
ll", sender=":1.220" (uid=1000 pid=11258 comm="lightdm --session-child 13 22 " label="unconfined") interfa
ce="org.freedesktop.login1.Manager" member="ReleaseSession" error name="(unset)" requested_reply="0" desti
nation="org.freedesktop.login1" (uid=0 pid=1267 comm="/lib/systemd/systemd-logind " label="unconfined")
Jul 12 16:20:32 GlaDOS lightdm: pam_systemd(lightdm:session): Failed to release session: Access denied
```
* Executing the command from the error message (`lightdm --session-child 13 22`) produces the following errors:
```
Error reading from daemon: Bad file descriptor
Error reading from daemon: Bad file descriptor
Error reading from daemon: Bad file descriptor
Error reading from daemon: Bad file descriptor
Error reading from daemon: Bad file descriptor
Error reading from daemon: Bad file descriptor
Error reading from daemon: Bad file descriptor
Error reading from daemon: Bad file descriptor
Error reading from daemon: Bad file descriptor
Error reading from daemon: Bad file descriptor
Failed to start PAM: System error
```

Things I have tried so far:
- `apt install --reinstall --purge slick-greeter lightdm*`
- `apt install --reinstall --purge dbus dbus-x11 dbus-user-session`

My System:

Architecture: amd64
System: Ubuntu 18.04 Budgie 64bit
Desktop-Manager: Budgie-Desktop
Session: budgie-desktop
Greeter: Slick-Greeter

I'm thankful for any clues on how to further debug these issues. I don't even know when they started - maybe an package update is to blame, but the only possibly relevant updates I have found in /var/log/apt/history.log are related to the graphics driver/libraries. I'll attach the latest apt history anyways.

[Tobias Knöppler (thecalcaholic)]

I found the solution here: https://unix.stackexchange.com/questions/454593/groups-not-registering-in-x
It seems to be caused by an update to libpam-kwallet5.
Uncommenting the following lines in /etc/pam.d/lightdm resolved the issue:

```
auth optional pam_kwallet.so
auth optional pam_kwallet5.so
```

I'm not sure whether the package maintainer of libpam-kwallet or the package maintainer of lightdm might have to add this change to their packages - or if it maybe only affects old installations.

[fossfreedom (fossfreedom)]

Simon

Copied you on this one. Is this potentially as a result of the recent CVE upload to Libpam... Sounds like a real regression.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[MibuKyoshiro (n-xbuntu-v)]

I can confirm *commenting out* (and not the reverse) these lines in /etc/pam.d/lightdm fixes the problem:

auth optional pam_kwallet.so
auth optional pam_kwallet5.so

Cheers.

[Tobias Knöppler (thecalcaholic)]

@MibuKyoshiro True, sorry I seem to have been overly tired when writing this. I'm correcting it in my original comment.

[Tobias Knöppler (thecalcaholic)]

Except I can't, so it has to stay there. Hopefully everybody who runs into this reads on...

[MibuKyoshiro (n-xbuntu-v)]

:D
Well I most certainly hope people can *think* when they see the lines are active by default.

Good luck to anyone who's trying to fix this bug !
Cheers.

[Martin Weis (martin-weis-newsadress)]

Switched to gdm for now, which does not have this behaviour.

`journalctl |grep lightdm`
reveals these messages between cycles:

~~~
Aug 23 20:27:41 systemname systemd[1824]: pam_unix(systemd-user:session): session closed for user lightdm
Aug 23 20:27:41 systemname systemd[1]: Removed slice User Slice of lightdm.
Aug 23 20:27:44 systemname lightdm[1504]: ** (lightdm:1504): WARNING **: Session pid=6321: Error reading from session: Interrupted system call
Aug 23 20:27:44 systemname lightdm[1504]: Failed to write utmpx: Permission denied
Aug 23 20:27:44 systemname lightdm[10528]: pam_unix(lightdm:session): session closed for user username
Aug 23 20:27:44 systemname dbus[1117]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.132" (uid=1000 pid=10528 comm="lightdm --session-child 12 21 ") interface="org.freedesktop.login1.Manager" member="ReleaseSession" error name="(unset)" requested_reply="0" destination="org.freedesktop.login1" (uid=0 pid=1096 comm="/lib/systemd/systemd-logind ")
Aug 23 20:27:44 systemname lightdm[10528]: pam_systemd(lightdm:session): Failed to release session: Access denied
Aug 23 20:27:44 systemname lightdm[10528]: pam_kwallet(lightdm:session): pam_kwallet: pam_sm_close_session
Aug 23 20:27:44 systemname lightdm[10528]: pam_kwallet5(lightdm:session): pam_kwallet5: pam_sm_close_session
Aug 23 20:27:44 systemname lightdm[10528]: pam_kwallet(lightdm:setcred): pam_kwallet: pam_sm_setcred
Aug 23 20:27:44 systemname lightdm[10528]: pam_kwallet5(lightdm:setcred): pam_kwallet5: pam_sm_setcred
Aug 23 20:27:44 systemname lightdm[6321]: pam_kwallet5(lightdm:session): pam_kwallet5: Impossible to write walletKey to walletPipe
Aug 23 20:27:44 systemname lightdm[1504]: ** (lightdm:1504): WARNING **: Error getting ConsoleKit session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files
Aug 23 20:27:46 systemname lightdm[11277]: pam_kwallet(lightdm-greeter:setcred): (null): pam_sm_setcred
Aug 23 20:27:46 systemname lightdm[11277]: pam_kwallet5(lightdm-greeter:setcred): (null): pam_sm_setcred
Aug 23 20:27:46 systemname lightdm[11277]: pam_unix(lightdm-greeter:session): session opened for user lightdm by (uid=0)
Aug 23 20:27:46 systemname systemd[1]: Created slice User Slice of lightdm.
Aug 23 20:27:46 systemname systemd[11281]: pam_unix(systemd-user:session): session opened for user lightdm by (uid=0)
Aug 23 20:27:46 systemname systemd-logind[1096]: New session c3 of user lightdm.
Aug 23 20:27:46 systemname systemd[1]: Started Session c3 of user lightdm.
Aug 23 20:27:46 systemname lightdm[11277]: pam_kwallet(lightdm-greeter:session): (null): pam_sm_open_session
Aug 23 20:27:46 systemname lightdm[11277]: pam_kwallet(lightdm-greeter:session): pam_kwallet: open_session called without kwallet_key
Aug 23 20:27:46 systemname lightdm[11277]: pam_kwallet5(lightdm-greeter:session): (null): pam_sm_open_session
Aug 23 20:27:46 systemname lightdm[11277]: pam_kwallet5(lightdm-greeter:session): pam_kwallet5: open_session called without kwallet5_key
Aug 23 20:27:47 systemname lightdm[11331]: pam_succeed_if(lightdm:auth): requirement "user ingroup n...

[Mekk (marcin-kasperski)]

I faced this problem on two different machines (both lightdm + plasma desktop, on both I happily used this combination on Ubuntu 16.04 but once I upgraded to 18.04, or soon afterwards, I lost all my groups).

Switched to sddm on both, it helped. So mayhaps lightdm should be dropped or downgraded, the issue is fairly critical (usb doesn't work, sudo has issues, pluggable devices don't work).

Picture in my case:

- after lightdm login

   $ id
   uid=1000(marcin) gid=1000(marcin) groups=1000(marcin)

- after sddm login

 $ id
   uid=1000(marcink) gid=1000(marcink) groups=1000(marcin),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),109(netdev),113(lpadmin),128(sambashare),147(lxd),999(docker)

[Mekk (marcin-kasperski)]

Some other notes:

https://unix.stackexchange.com/questions/458194/missing-groups-at-each-startup/

and horrible unconclusive Fedora bugreport:

https://bugzilla.redhat.com/show_bug.cgi?id=1581495

[Christof Köhler (ckoe-ubuntu)]

Hello,

I had this problem on 16.04 after a normal maintenance "apt dist-upgrade" and it caused quite some confusion. A big Thank You to the people who published the workaround.

I sincerely hope this regression in a LTS release gets fixed soon.

[TJ (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 [e-mail] 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 [e-mail]" 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.

I...

[TJ (tj)]

After the package upgrade to libpam-kwallet 4:5.12.7 from bionic-proposed the issue has gone away. That seems to be due to commit 8da1a470 included in this version:

commit 8da1a47035fc92bc1496059583772bc4bd6e8ba6
Author: Maximiliano Curia <email address hidden>
Date: Fri May 4 22:06:06 2018 +0200

    Avoid giving an stderr to kwallet

    Summary:
    The fixes for CVE-2018-10380 introduced a regression for most users not
    using kde, and some for kde sessions. In particular the reorder of the
    close calls and creating a new socket caused that the socket is always
    assigned the file descriptor 2, aka stderr.

    BUG: 393856

    Test Plan: It works

    Reviewers: #plasma, aacid

    Reviewed By: aacid

    Subscribers: asturmlechner, rdieter, davidedmundson, plasma-devel

    Tags: #plasma

    Differential Revision: https://phabricator.kde.org/D12702

[ZdravkoG (zdravko-g)]

Hi everyone,

I have similar problems. Updating to libpam-kwallet packages (libpam-kwallet-common, libpam-kwallet4 and libpam-kwallet5) to version 4:5.12.7-0ubuntu0.1 from proposed repository didn't solve anything for me. Probably the problem solving is still in progress or may be never started (officially).

Here I want to ask somebody from Canonical to assign this bug! So, final solution (official) to be available soon (on regular bionic-update).

[TJ (tj)]

ZdravkoG:

After the package upgrades did you reboot before testing? I've not been able to reproduce it since whereas before the upgrade it would happen 100% of the time.

[ZdravkoG (zdravko-g)]

Hi @tj,

Yes, I initially have try logout/login (I think should be enough) - no result. After that full reboot - same thing.
So, currently command 'id' give me result:
uid=1000(zdravko) gid=1000(zdravko) групи=1000(zdravko)
that's all.

I can't see in this thread more deep discussions about what is going on. What is the actual reason. I take a look on the link in Your post #14. There is not clear description, again. Only strange standard error stream descriptor close is pointed as a reason. There are also other possible 'gaps' (not pointed there) - relying that buffer sized to length of c-string can safely keep all string (together with the terminator!, which will be there as result of 'strcpy()'). But this doesn't mater.
Do You think that pointed there is enough for fixing the trouble?

[H Geerts (hgeerts)]

Upgrading libpam-kwallet5 to 4:5.12.7-0ubuntu0.1 and a reboot fixed this problem on my machine.
Thanks for linking this to #1784964 TJ.

[ZdravkoG (zdravko-g)]

I don't know why this happens, but seems to be something broken by the way and update didn't fix anything in my case. There are still 2 calls to 'setgroups(0, NULL)', one for libpam-kwallet and another for pam_kwallet5 after my user and group are already set. Of course, this drops all supplementary groups. Maybe I miss something. The only workaround is commenting out both libraries in lightdm config.

But this is only some workaround, no final fix! Would be fine needed changes to be made in corresponding modules and after that... everything done.

[Robert Chalmas (robert-chalmas)]

Similarly to comment #15: updating libpam-kwallet-common, libpam-kwallet4 and libpam-kwallet5 to version 4:5.12.7-0ubuntu0.1 from proposed repository and rebooting didn't change anything for me.

Only the workaround on comment #5 is currently useful, but I don't know which other problems it may cause...

As an additional test, I uncommented again the 2 "pam_kwallet" lines in /etc/pam.d/lightdm, rebooted, and the problems reappeared.

[Norbert (nrbrtx)]

Have just went to this bug while trying to solve PAM warnings problem on my AskUbuntu question ( https://askubuntu.com/q/1096931/66509 ).
So I have installed all mentioned package with:

    sudo apt-get install libpam-winbind libpam-kwallet4 libpam-kwallet5

and got the result - my user is listed only in its group.

Fixed this problem by removing both kwallet packages:

    sudo apt-get purge libpam-kwallet4 libpam-kwallet5

Please do something on packages level (for example decline to install both kwallet packages in the same time).

[Corey Schuhen (cschuhen)]

I had the same issue. Even with libpam-kwallet5 to version 4:5.12.7-0ubuntu0.1.

However, removing libpam-kwallet4 then rebooting appears to have resolved the issue.

[Joachim Fagerholm (joachim-fagerholm)]

Seems this was my problem too. What I noticed was that docker suddenly could not be run except as root. And none of the usual remedies for that had any effect. Luckily KDEwallet started demanding a login at the same time which pointed me to this bug. Tobias advice above fixed the problem so I think that confirms the diagnosis. Kubuntu 18.04 with KDE Plasma 5.12.7, KDE Frameworks 5.44.0 and Qt 5.9.5.

[Scarlett Gately Moore (scarlettmoore)]

This bug is very old, if it is still an issue please update the bug with information from a supported release.