| Summary: | pam-kwallet fails to send hash to kwalletd | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | Orion Poplawski <orion> |
| Component: | kwallet | Assignee: | Michael Leupold <lemma> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | CC: | afiestas, goeran, kevin.kofler, rdieter, sudhir |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
This occurs when using sddm-0.9.0-2.20141007git6a28c29b.fc21 , and grep kwalet /etc/pam.d/sddm: -auth optional pam_kwallet.so -session optional pam_kwallet.so in case it matters. Orion, in looking closer today, I noticed the startkde snippet: # At this point all the environment is ready, let's send it to kwalletd if running if test -n "$PAM_KWALLET_LOGIN" ; then env | socat STDIN UNIX-CONNECT:$PAM_KWALLET_LOGIN fi but we lacked any dependencies to ensure socat was present at runtime, does installing socat help? In my case, it does not, since I'm using NFS $HOME, and get errors reported about lack of permissions (appended below). Dec 05 09:39:39 host kdm[11969]: :0[11969]: Couldn't create directory: /Users/rdieter/.kde because: 13-Permission denied Dec 05 09:39:39 host kdm[11969]: :0[11969]: Couldn't open file: /Users/rdieter/.kde/share/apps/kwallet/kdewallet.salt because: 13-Permission denied Dec 05 09:39:39 host kdm[11969]: :0[11969]: kwalletd: Couldn't create or read the salt file Dec 05 09:39:39 host kdm[11969]: :0[11969]: pam_kwallet(kdm:auth): pam_kwallet: Fail into creating the hash re-assigning to afiestas for feedback. while we're at it, due to the socat snippet in startkde, does that imply that pam_kwallet cannot work outside of plasma (e.g., to auto-open kwallet in a gnome session)? 2 confirmations that installing socat fixes things, I'm still curious about comments/suggestions about handling nfs $HOME and/or non-plasma environments though. feel free to poke me in #kde , #kde-devel , #fedora-kde on freenode. I'm not sure I diagnosed this properly initially. My question now is, if pam_kwalletd passed in the hash to kwalletd, why does kwalletd need to read the environment? I suspect it doesn't. Rex - pam-kwallet should be executing kwalletd as the user, so I don't see why it couldn't access the home directory. Unless using kerberos? I'm naively assuming pam modules run in the context of the DM user (for kdm, that user is root). So, this is still a problem, and with pam_kwallet5 as well (since the code is nearly identical). We can't be mucking in the nfs home directory as root. This looks like an excellent use-case for XDG_RUNTIME_DIR env var (and can fallback to using the legacy path under ~/.kde if it's not available) Per http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html "$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, ...) should be stored. The directory MUST be owned by the user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700." Hi, kdelibs (version 4 and earlier) is no longer maintained since a few years. KDE Frameworks 5 or 6 might already have resolved this bug. If not, please re-open against the matching framework if feasible or against the application that shows the issue. We then can still dispatch it to the right Bugzilla product or component. Greetings Christoph Cullmann |
pam-kwallet is starting kwalletd but is failing to pass the hash to it. From kwalletd main.cpp: hash = waitForHash(); if (hash == NULL || waitForEnvironment() == -1) { I see kwalletd stuck in waitForEnvironment(), presumably because hash == NULL. (gdb) bt #0 0x00007f5f48f38400 in __accept_nocancel () at /lib64/libpthread.so.0 #1 0x00007f5f4a667dd0 in waitForEnvironment() () at /usr/src/debug/kde-runtime-4.14.2/kwalletd/main.cpp:77 #2 0x00007f5f4a668067 in checkPamModule(int, char**) (argc=argc@entry=4, argv=argv@entry=0x7fff94baf978) at /usr/src/debug/kde-runtime-4.14.2/kwalletd/main.cpp:135 #3 0x00007f5f4a66813d in kdemain(int, char**) (argc=4, argv=0x7fff94baf978) at /usr/src/debug/kde-runtime-4.14.2/kwalletd/main.cpp:147 #2 0x00007f5f4a668067 in checkPamModule (argc=argc@entry=4, argv=argv@entry=0x7fff94baf978) at /usr/src/debug/kde-runtime-4.14.2/kwalletd/main.cpp:135 135 if (hash == NULL || waitForEnvironment() == -1) { (gdb) print hash $2 = <optimized out> I don't know if any compiler optimization could conceivable cause waitForEnvironment() to be called without hash == NULL. I'm also not sure why waitForEnvironment() is called by kwalletd if it called with --pam-login, but I suppose that's not a big issue. I think we need some more debugging from pam-kwallet and/or kwalletd as to what is going wrong. Version-Release number of selected component (if applicable): pam-kwallet-0-0.6.20140508git49a5bc0.fc21.x86_64 Reproducible: Always