SUMMARY When I've logged in to Plasma 5.14.3 from lightdm 1.28.0-2 in Fedora 29, I saw the following messages related to pam-kwallet 5.14.3-1 in the journal. pam_kwallet5(lightdm:auth): (null): pam_sm_authenticate pam_kwallet5(lightdm:setcred): pam_kwallet5: pam_sm_setcred pam_kwallet5(lightdm:session): pam_kwallet5: pam_sm_open_session pam_kwallet5: final socket path: /run/user/1000/kwallet5.socket pam_kwallet5-kwalletd: Couldn't listen in socket pam_kwallet5(lightdm:session): pam_kwallet5: Couldn't fork to execv kwalletd The same messages occurred with Plasma/pam-kwallet 5.13.5 and earlier versions. The kwallet was not unlocked when logging in likely related to those errors "Couldn't listen in socket" and "Couldn't fork to execv kwalletd". When I started kwalletmanager and clicked open, a pop up window asked for the password. STEPS TO REPRODUCE 1. Set lightdm as the display manager in Fedora 29 by sudo systemctl start lightdm or sudo systemctl enable lightdm 2. Log into Plasma from lightdm 3. journalctl -b 4. start kwalletmanager 5. click open OBSERVED RESULT The errors "Couldn't listen in socket" and "Couldn't fork to execv kwalletd" occurred in the journal messages when logging into Plasma. kwallet was not unlocked when logging in. EXPECTED RESULT The errors above do not occur. kwallet is unlocked when logging in. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 29 (available in About System) KDE Plasma Version: 5.14.3 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.1 ADDITIONAL INFORMATION The "Couldn't fork to execv kwalletd" error messages are in pam_kwallet.c at lines 536 and 549 while the "Couldn't listen in socket" message is at line 431. https://cgit.kde.org/kwallet-pam.git/tree/pam_kwallet.c?h=Plasma/5.14 The error "pam_kwallet5-kwalletd: Couldn't listen in socket" was noted for Fedora at https://bugzilla.redhat.com/show_bug.cgi?id=1581495 I couldn't find the error "Couldn't fork to execv kwalletd" mentioned in that entry. The lightdm-1.28.0-2.fc29 was made to address this and an issue with the gnome keyring not being opened when starting gnome. The errors above still occurred with the lightdm-1.28.0-2.fc29 update.
I think I have the same error. It's happening for quite some time already after I changed my user password and of course I changed also kwallet password to be the same. I'm not sure it was the cause, maybe I updated packages at the same time and this is just a coincidence. After logging into plasma after opening Chromium or when wi-fi is trying to connect, dialog box pops up asking for my password. If enter the same password and kwallet unlocks. Plasma 5.14.3, but I believe it happened with previous versions as well. lightdm 1.28.0-1. Arch linux. ноя 23 08:39:34 stone0495 systemd[1]: session-c1.scope: Killing process 780 (lightdm) with signal SIGTERM. ноя 23 08:39:34 stone0495 systemd[1]: session-c1.scope: Killing process 791 (lightdm-webkit2) with signal SIGTERM. ноя 23 08:39:34 stone0495 systemd[1]: session-c1.scope: Killing process 811 (WebKitNetworkPr) with signal SIGTERM. ноя 23 08:39:34 stone0495 systemd[1]: session-c1.scope: Killing process 813 (WebKitWebProces) with signal SIGTERM. ноя 23 08:39:34 stone0495 systemd[1]: Stopping Session c1 of user lightdm. ноя 23 08:39:34 stone0495 lightdm[780]: pam_unix(lightdm-greeter:session): session closed for user lightdm ноя 23 08:39:34 stone0495 lightdm[983]: pam_kwallet5(lightdm:setcred): pam_kwallet5: pam_sm_setcred ноя 23 08:39:34 stone0495 lightdm[983]: pam_unix(lightdm:session): session opened for user shohov by (uid=0) ноя 23 08:39:34 stone0495 kernel: audit: type=1006 audit(1542955174.763:126): pid=983 uid=0 old-auid=4294967295 auid=1000 tty=(none) old-ses=4294967295 ses=4 res=1 ноя 23 08:39:34 stone0495 systemd-logind[393]: New session 4 of user shohov. ноя 23 08:39:34 stone0495 systemd[1]: Started Session 4 of user shohov. ноя 23 08:39:34 stone0495 lightdm[983]: pam_kwallet5(lightdm:session): pam_kwallet5: pam_sm_open_session ноя 23 08:39:34 stone0495 lightdm[989]: pam_kwallet5: final socket path: /run/user/1000/kwallet5.socket ноя 23 08:39:34 stone0495 lightdm[989]: pam_kwallet5-kwalletd: Couldn't listen in socket ноя 23 08:39:34 stone0495 systemd[1]: Stopped Session c1 of user lightdm. ноя 23 08:39:34 stone0495 lightdm[983]: pam_kwallet5(lightdm:session): pam_kwallet5: Couldn't fork to execv kwalletd ноя 23 08:39:34 stone0495 systemd-logind[393]: Removed session c1. ноя 23 08:39:34 stone0495 systemd[948]: Started D-Bus User Message Bus.
I seem to be able to reproduce this on Arch Linux
The same issue in Gentoo: lightdm 2.0.6 kwallet-pam - 5.15.1 pam - 1.3.1 plasma-workspace - 5.15.1 plasma-framework - 5.55.0 PAM files: 1. lightdm ----------- auth include system-local-login -auth optional pam_gnome_keyring.so -auth optional pam_kwallet5.so account include system-local-login password include system-local-login -password optional pam_gnome_keyring.so use_authtok session include system-local-login -session optional pam_gnome_keyring.so auto_start -session optional pam_kwallet5.so auto_start 2. system-local-login --------------------- auth include system-login account include system-login password include system-login session include system-login 3. system-login --------------- auth required pam_tally2.so onerr=succeed auth required pam_shells.so auth required pam_nologin.so auth include system-auth account required pam_access.so account required pam_nologin.so account include system-auth account required pam_tally2.so onerr=succeed password include system-auth session optional pam_loginuid.so session required pam_env.so session optional pam_lastlog.so silent session include system-auth session optional pam_motd.so motd=/etc/motd session optional pam_mail.so 4. system-auth -------------- auth required pam_env.so auth required pam_unix.so try_first_pass likeauth nullok auth optional pam_permit.so account required pam_unix.so account optional pam_permit.so password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 password required pam_unix.so try_first_pass use_authtok nullok sha512 shadow password optional pam_permit.so session required pam_limits.so session required pam_env.so session required pam_unix.so session optional pam_permit.so session optional pam_loginuid.so -session optional pam_systemd.so
The same issue still persists. Actually I have never been able to use pam-kwallet properly. The system is still Gentoo, though some of the versions are a lot more recent: lightdm 1.30.0 kwallet-pam - 5.17.2 pam - 1.3.1 plasma-workspace - 5.17.2 plasma-framework - 5.63.0 PAM files are the same as in my previous post. The errors are like as in @Dmitry's logs... I added some extra debug code in the pam_kwallet.c to get some extra info: lightdm[940510]: pam_kwallet5(lightdm:auth): (null): pam_sm_authenticate lightdm[940510]: pam_kwallet5(lightdm:setcred): pam_kwallet5: pam_sm_setcred lightdm[940510]: pam_kwallet5(lightdm:session): pam_kwallet5: pam_sm_open_session lightdm[940567]: pam_kwallet5: final socket path: /run/user/501/kwallet5.socket lightdm[940567]: pam_kwallet5-kwalletd: Couldn't listen in socket because: 95-Operation not supported lightdm[940510]: pam_kwallet5(lightdm:session): pam_kwallet5: Couldn't fork to execv kwalletd (default state of the switch) because of status: 256-1 I am not an expert in sockets coding and operations, but it seems there is a problem with the socket usage at listen(envSocket, 5) level - with this error 95. Besides the forked child at start_kwallet(...) obviously exits with error because of this(256 is the status value and the 1 is the WEXITSTATUS(status)) The folder /run/user/501 has the appropriate user permissions Anyone of the developers? Do you need more debug info? This is already a year old problem that has not been still resolved :(
I have the issue too also on Gentoo ное 20 01:05:28 lightdm[11976]: pam_kwallet5(lightdm:session): pam_kwallet5: pam_sm_close_session ное 20 01:05:28 lightdm[11976]: pam_kwallet5(lightdm:setcred): pam_kwallet5: pam_sm_setcred ное 20 01:05:28 org.kde.kwalletd5[794]: kwalletd5: Checking for pam module ное 20 01:05:28 lightdm[13224]: pam_kwallet5(lightdm-greeter:setcred): (null): pam_sm_setcred ное 20 01:05:28 lightdm[13224]: pam_kwallet5(lightdm-greeter:session): (null): pam_sm_open_session ное 20 01:05:28 lightdm[13224]: pam_kwallet5(lightdm-greeter:session): pam_kwallet5: open_session called without kwallet5_key ное 20 01:05:32 lightdm[13247]: pam_kwallet5(lightdm:auth): (null): pam_sm_authenticate ное 20 01:05:32 lightdm[13224]: pam_kwallet5(lightdm-greeter:session): pam_kwallet5: pam_sm_close_session ное 20 01:05:32 lightdm[13224]: pam_kwallet5(lightdm-greeter:setcred): pam_kwallet5: pam_sm_setcred ное 20 01:05:32 lightdm[13247]: pam_kwallet5(lightdm:setcred): pam_kwallet5: pam_sm_setcred ное 20 01:05:32 lightdm[13247]: pam_kwallet5(lightdm:session): pam_kwallet5: pam_sm_open_session ное 20 01:05:32 lightdm[13254]: pam_kwallet5: final socket path: /run/user/1000/kwallet5.socket ное 20 01:05:32 lightdm[13254]: pam_kwallet5-kwalletd: Couldn't listen in socket ное 20 01:05:32 lightdm[13247]: pam_kwallet5(lightdm:session): pam_kwallet5: Couldn't fork to execv kwalletd
I finally got it to work. I haven't found out the reason why the call to listen fails with EOPNOTSUPP, but I changed the code of both kwallet-pam and kwalletd to use a named pipe to pass the environment variables. Hence there is no call to listen any more. I don't know if this is a real solution because it's not clear to me why the developers decided to use a socket instead of a pipe, but maybe there is some reason I don't see. Anyway here are the diffs: kwalletd main.cpp: https://pastebin.com/Y2gvuqQx pam_kwallet.c: https://pastebin.com/g5knsLHS pam_kwallet_init: https://pastebin.com/n3KGSb5J
(In reply to stefano.aloe2 from comment #6) > I finally got it to work. (...) I changed the code of both kwallet-pam and > kwalletd to use a named pipe to pass the environment variables. I applied your patches and can confirm that they are also working on my machine (Arch Linux x86_64). Thanks!
Don't use pastebin for patches. Either attach it, or - much better - create a phabricator diff.
Any reasons nobody has tried to mainline the patches that do -in fact- fix this issue? even if they were presented in the right way, this issue could be fixed by just those simple patches being applied, or similar versions of them.
The patches are wrong, they change the behaviour of two things that are not released in sync (kwalletd and pam-kwallet), so they would break every single user for a while until everyone was using the new version, doesn't seem like a reasonable solution. Maybe instead of putting pressure here you'll could put pressure in https://github.com/canonical/lightdm/issues/134
(In reply to Albert Astals Cid from comment #10) > The patches are wrong, they change the behaviour of two things that are not > released in sync (kwalletd and pam-kwallet), so they would break every > single user for a while until everyone was using the new version, doesn't > seem like a reasonable solution. > > Maybe instead of putting pressure here you'll could put pressure in > https://github.com/canonical/lightdm/issues/134 Ah. Fair. Well, this same error appears if you use KWallet on literally anything other than SDDM, so it's 100% not only a lightdm error Just trying to use startx, and configuring /etc/pam/login to open KWallet, it fails with this exact error. Same on GDM, or anything *but* SDDM. This feels like a KWallet error for sure. I'll chime in there, though :)
(In reply to David Rubio from comment #11) > (In reply to Albert Astals Cid from comment #10) > > The patches are wrong, they change the behaviour of two things that are not > > released in sync (kwalletd and pam-kwallet), so they would break every > > single user for a while until everyone was using the new version, doesn't > > seem like a reasonable solution. > > > > Maybe instead of putting pressure here you'll could put pressure in > > https://github.com/canonical/lightdm/issues/134 > > Ah. Fair. > Well, this same error appears if you use KWallet on literally anything other > than SDDM, so it's 100% not only a lightdm error > Just trying to use startx, and configuring /etc/pam/login to open KWallet, > it fails with this exact error. Same on GDM, or anything *but* SDDM. This > feels like a KWallet error for sure. > > I'll chime in there, though :) Oh. I read the bug report now. Well, one question would be why it doesn't work with startx either, even if PAM is configured to open the wallet.
(In reply to David Rubio from comment #11) > (In reply to Albert Astals Cid from comment #10) > > The patches are wrong, they change the behaviour of two things that are not > > released in sync (kwalletd and pam-kwallet), so they would break every > > single user for a while until everyone was using the new version, doesn't > > seem like a reasonable solution. > > > > Maybe instead of putting pressure here you'll could put pressure in > > https://github.com/canonical/lightdm/issues/134 > > Ah. Fair. > Well, this same error appears if you use KWallet on literally anything other > than SDDM, so it's 100% not only a lightdm error > Just trying to use startx, and configuring /etc/pam/login to open KWallet, > it fails with this exact error. Same on GDM, or anything *but* SDDM. This > feels like a KWallet error for sure. > > I'll chime in there, though :) It worked fine with gdm last time i tried.
(In reply to David Rubio from comment #12) > (In reply to David Rubio from comment #11) > > (In reply to Albert Astals Cid from comment #10) > > > The patches are wrong, they change the behaviour of two things that are not > > > released in sync (kwalletd and pam-kwallet), so they would break every > > > single user for a while until everyone was using the new version, doesn't > > > seem like a reasonable solution. > > > > > > Maybe instead of putting pressure here you'll could put pressure in > > > https://github.com/canonical/lightdm/issues/134 > > > > Ah. Fair. > > Well, this same error appears if you use KWallet on literally anything other > > than SDDM, so it's 100% not only a lightdm error > > Just trying to use startx, and configuring /etc/pam/login to open KWallet, > > it fails with this exact error. Same on GDM, or anything *but* SDDM. This > > feels like a KWallet error for sure. > > > > I'll chime in there, though :) > > Oh. I read the bug report now. Well, one question would be why it doesn't > work with startx either, even if PAM is configured to open the wallet. I've no idea and no interest in debugging that. If you're interested, ask yourself who is loading pam_kwallet5.so before X starts? When sddm it's sddm, when gdm it's gdm, when lightdm is lightdm, if you're not using any of those, who is doing it?
(In reply to Albert Astals Cid from comment #14) > (In reply to David Rubio from comment #12) > > (In reply to David Rubio from comment #11) > > > (In reply to Albert Astals Cid from comment #10) > > > > The patches are wrong, they change the behaviour of two things that are not > > > > released in sync (kwalletd and pam-kwallet), so they would break every > > > > single user for a while until everyone was using the new version, doesn't > > > > seem like a reasonable solution. > > > > > > > > Maybe instead of putting pressure here you'll could put pressure in > > > > https://github.com/canonical/lightdm/issues/134 > > > > > > Ah. Fair. > > > Well, this same error appears if you use KWallet on literally anything other > > > than SDDM, so it's 100% not only a lightdm error > > > Just trying to use startx, and configuring /etc/pam/login to open KWallet, > > > it fails with this exact error. Same on GDM, or anything *but* SDDM. This > > > feels like a KWallet error for sure. > > > > > > I'll chime in there, though :) > > > > Oh. I read the bug report now. Well, one question would be why it doesn't > > work with startx either, even if PAM is configured to open the wallet. > > I've no idea and no interest in debugging that. If you're interested, ask > yourself who is loading pam_kwallet5.so before X starts? When sddm it's > sddm, when gdm it's gdm, when lightdm is lightdm, if you're not using any of > those, who is doing it? Usually to use PAM with startx (as far as I'm aware) you have to load it before X starts, which might be an issue here if kwallet5 requires X (anything special that makes it require such?)
Created attachment 134311 [details] patch to solve the listen problem
The previous patch I had posted was actually a quick fix, since, as I wrote, I didn't really find out the cause of the problem with listen. However, upon further inspection, it turned out that the problem was caused by closing all the file descriptors greater than 2 before calling socket. By adding some debug code I found out that the socket was given file descriptor 3, and calling getsockopt with SO_TYPE on this fd always returned 2, which is SOCK_DGRAM, regardless of which type of socket was required in the call to socket. I don't know the reason for this behavior, the only thing I noticed is that when execute_kwallet is called the file descriptor 3 is indeed assigned to another socket, but I've no clue on the origin of this socket. Since we don't want kwallet to inherit irrelevant file descriptors from his parent, I replaced the call to close with a call to fcntl, which sets the FD_CLOEXEC flag. This solves the problem and should prevent undesired fd inheritance as well.
I would really appreaciate if you could send a merge request via https://invent.kde.org/plasma/kwallet-pam https://community.kde.org/Infrastructure/GitLab#Submitting_a_merge_request
fwiw we have a positive downstream test report: https://bugs.gentoo.org/717606#c5
stefano.aloe2@gmail.com I see you don't want to go to the proper channel to get your patch reviewed and merged. Can we at least get a name to attach to the code? (When we review it and find it to be correct?)
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwallet-pam/-/merge_requests/2
Sorry for the huge delay. I was extremely busy in the last month and in the end I just forgot to send a merge request. I'm not really familiar with git, but I should have allowed collaboration on my request, or at least I hope so, since I'm still very busy and probably I won't be able to work again on this before March.
Git commit 8f899902e6a3be8ad4948eb1ebdf679186aa20a7 by Stefano Aloé. Committed on 17/01/2021 at 22:16. Pushed by aacid into branch 'master'. Avoid socket listening error Closing all file descriptor above 3 is causing problem to socket() and listen(). Setting FD_CLOEXEC on them solves the problem and should have exactly the same behavior. M +4 -2 pam_kwallet.c https://invent.kde.org/plasma/kwallet-pam/commit/8f899902e6a3be8ad4948eb1ebdf679186aa20a7
Git commit 06cd94634feb70dfa7e2f8695b97317cb2ebe44c by Albert Astals Cid, on behalf of Stefano Aloé. Committed on 19/01/2021 at 22:05. Pushed by aacid into branch 'Plasma/5.20'. Avoid socket listening error Closing all file descriptor above 3 is causing problem to socket() and listen(). Setting FD_CLOEXEC on them solves the problem and should have exactly the same behavior. (cherry picked from commit 8f899902e6a3be8ad4948eb1ebdf679186aa20a7) M +4 -2 pam_kwallet.c https://invent.kde.org/plasma/kwallet-pam/commit/06cd94634feb70dfa7e2f8695b97317cb2ebe44c
Git commit 82a93cca1da4d2a4eeb450804c4895f43053d1f1 by Albert Astals Cid, on behalf of Stefano Aloé. Committed on 19/01/2021 at 22:06. Pushed by aacid into branch 'Plasma/5.18'. Avoid socket listening error Closing all file descriptor above 3 is causing problem to socket() and listen(). Setting FD_CLOEXEC on them solves the problem and should have exactly the same behavior. (cherry picked from commit 8f899902e6a3be8ad4948eb1ebdf679186aa20a7) M +4 -2 pam_kwallet.c https://invent.kde.org/plasma/kwallet-pam/commit/82a93cca1da4d2a4eeb450804c4895f43053d1f1