Bug 351805

Same problem here after upgrading from Kubuntu 15.04 to Kubuntu 15.10 (prerelease) on 2015-09-09. Version of libkf5wallet-bin package is 5.13.0-0ubuntu2.

I have the same problem. It appears when I substitute the graphics driver Noveau with the driver of NVIDIA (355.06). If I install the Noveau driver back, the error message appears no more.

I have thew same issue. Switching from my laptop's nvidia gpu to the intel one removes this error message. 

I also do not have the local config file kwalletd5rc

Well, this is a WTF kind of bug, in my opinion!

Hey Harald, any idea of how switching the graphics driver can affect the wallet. 
(/me scratching my head)

But, why should I get this message? Since I am running in a VM, I should not be running the NVIDIA driver, should I? Is there a way I can check?

If I create the folder "/.config" (under root dir) with permissions 777, the error message disappears. Nothing is written in that directory, though. 

So, it seems that writeability of the .config directory is wrongly checked under filesystem root rather than under users home directory.

Correlation doesn't imply causation. I'd suspect that the two presented origins of the issue (installing new packages and removing packages) probably also forced an upgrade of one or more frameworks packages and that in turn somehow broke the config path resolution. Alas, I can't seem to reproduce this on a new install of the daily kubuntu image.

So. What we need here is substantially more information. Namely:
- /var/log/apt output of actions that caused the bug. 
- syslog output if anything pertaining to kwallet shows up
- journald output if anything pertaining to kwallet shows up (probably would be on the sddm service)
- ~/.xsession-errors right after the problem happened

Best guess right now is that the kwalletd was stared without the HOME env set, so that's why it would have the silly path.

For me, this no longer appears on fresh installs of Kubuntu Beta-2 RC images.

(In reply to Marco Parillo from comment #8)
> For me, this no longer appears on fresh installs of Kubuntu Beta-2 RC images.

That was premature. It has come back.

I have upgradeded from Kubuntu 15.04 to 15.10 yesteday and got the same error.

For me this looks like a shell script error. E.g.:

HOME=$(some | invalid | command | sequence)
KWALLET_CONF="/$HOME/.config/kwalletd5rc" # results into ""//.config/kwalletd5rc"

I also made an investigation about which process spawns the message:
elvenfighter ~ $ ps -eo pid,ppid,args | grep -i kwallet
 1196  1174 [kwalletd] <defunct>
 1197  1174 /usr/bin/kwalletd5 --pam-login 17 21
 1788  1197 /usr/bin/kdialog --title kwalletd5 --msgbox Configuration file "//.config/kwalletd5rc" not writable. Please contact your system administrator.
 1793     1 /usr/bin/kwalletd --pam-login 17 20
 2489  2442 grep --color=auto -i kwallet
 
elvenfighter ~ $ ps -o pid,ppid,args -p 1174
  PID  PPID COMMAND
 1174  1022 /usr/lib/x86_64-linux-gnu/sddm/sddm-helper --socket /tmp/sddm-auth950d1696-1757-4438-91c7-c06607824e4e --id 1 --start /usr/

Created attachment 94821 [details]
Screenshot

This may be related to the KDE wallet migration wizard?  From journalctl:

org.kde.kwalletd5[1416]: Setting useNewHash to true
org.kde.kwalletd5[1416]: Wallet new enough, using new hash
org.kde.kwalletd5[1416]: fsize:  2918082162  encrypted.size():  86560  blksz:  8
org.kde.kwalletd5[1416]: Application ' "KDE Wallet Migration Agent" ' using kwallet without parent window!
org.kde.kwalletd5[1416]: Setting useNewHash to true
org.kde.kwalletd5[1416]: Wallet new enough, using new hash
org.kde.kwalletd5[1416]: Migration failed.
org.kde.kwalletd5[1416]: Migration wizard returned an error or has been canceled. The migration agent will resume upon next daemon start
org.kde.kwalletd5[1416]: Migration agent stop.



sddm[1099]: Checking for pam module
sddm[1099]: Got pam-login
sddm[1099]: kwalletd: Waiting for hash on 17-
sddm[1099]: kwalletd: waitingForEnvironment on: 21
sddm[1099]: kwalletd: Couldn't accept incoming connection
sddm[1099]: Hash or environment not received

What I think is going on:
 * PAM starts kwalletd5
 * kwalletd5 starts migration wizard
 * migration wizard has no $HOME set yet
 * error

It would appear this happens only when there is an existing kwallet4 which it tries to migrate.

The main problem is that kwalletd5 gets the environment (including $HOME) from ksmserver, which is started *after* PAM and the migration wizard is started from PAM. Then it all explodes.

Actually, now that I have looked at the code, there is something else going wrong.

>sddm[1099]: kwalletd: waitingForEnvironment on: 21
>sddm[1099]: kwalletd: Couldn't accept incoming connection
>sddm[1099]: Hash or environment not received

The scenario described in my previous comment should not happen because kwalletd is blocked waiting for ksmserver to send the environment vars (including $HOME). But according to your output, kwalletd failed to accept the incoming client connecting to that socket and therefore couldn't read and set the environment. That is the actual problem. Why that happens, I wouldn't know though.

Is there something in syslog maybe? About socket operation not being permitted?

There is nothing regarding sockets in my syslog.

I found only these:
$ sudo cat /var/log/syslog.1 | grep sddm
Oct  5 17:46:09 localhost systemd[1]: Started Session 1 of user sddm.
Oct  5 17:46:23 localhost sddm[1028]: Oops, secure memory pool already initialized
Oct  5 17:46:30 localhost sddm[1028]: Checking for pam module
Oct  5 17:46:30 localhost sddm[1028]: Got pam-login
Oct  5 17:46:30 localhost sddm[1028]: kwalletd: Waiting for hash on 17-
Oct  5 17:46:30 localhost sddm[1028]: kwalletd: waitingForEnvironment on: 20
Oct  5 17:46:30 localhost sddm[1028]: kwalletd: client connected
Oct  5 17:46:30 localhost sddm[1028]: kwalletd: client disconnected
Oct  5 17:46:35 localhost sddm[1028]: Checking for pam module
Oct  5 17:46:35 localhost sddm[1028]: Got pam-login
Oct  5 17:46:35 localhost sddm[1028]: kwalletd: Waiting for hash on 17-
Oct  5 17:46:35 localhost sddm[1028]: kwalletd: waitingForEnvironment on: 21
Oct  5 17:46:35 localhost sddm[1028]: kwalletd: Couldn't accept incoming connection
Oct  5 17:46:35 localhost sddm[1028]: Hash or environment not received
...
Oct  6 22:35:23 localhost sddm[1037]: Oops, secure memory pool already initialized
Oct  6 22:35:31 localhost sddm[1037]: Checking for pam module
Oct  6 22:35:31 localhost sddm[1037]: Got pam-login
Oct  6 22:35:31 localhost sddm[1037]: kwalletd: Waiting for hash on 17-
Oct  6 22:35:31 localhost sddm[1037]: kwalletd: waitingForEnvironment on: 20
Oct  6 22:35:31 localhost sddm[1037]: kwalletd: client connected
Oct  6 22:35:31 localhost sddm[1037]: kwalletd: client disconnected

Or what should I look for?

Try "grep -i denied"

This only happens for me when logging in using the proprietary nvidia driver, but If I use autologin with  SDDM, I do not see the error message.

Also note my system is an optimus laptop, and the message does not occur using the Intel gpu.

If you're using autologin, it will not start kwallet at all, therefore you will not get any error.

Graphics drivers are completely unrelated and (should) have no influence whatsoever.

(In reply to Martin Klapetek from comment #19)

> Graphics drivers are completely unrelated and (should) have no influence
> whatsoever.

Agreed, but I can reproduce it consistently.

For what it's worth I'm also using the nvidia driver and have the error on every single login. I did however just resolve the error by purging the pam-kwallet5 package on kubuntu 15.10. I don't know enough to explore what in this package is causing the issue but the issue did return upon reinstalling the package.

@Harald - can you check if the nvidia package does anything to the pam?

Can you guys check your installed libpam-* packages? Do you have any i386 on x86_64 machine?

Additionally, can someone please try editing /etc/pam.d/sddm* and comment out (prepend with #) the lines with "auth optional pam_kwallet.so" and a bit lower "session optional pam_kwallet.so" and leave only the pam_kwallet5.so and see what that does?

Commenting out the two pam_kwallet.so did not changed anything to the issue. No i386 libpam package is present on my system.

I should also mention that I also have an nvidia card with latest driver (355), although I don't know if it's related.

(In reply to Martin Klapetek from comment #22)
> @Harald - can you check if the nvidia package does anything to the pam?
> 
> Can you guys check your installed libpam-* packages? Do you have any i386 on
> x86_64 machine?

I am on 32-bit.

> Additionally, can someone please try editing /etc/pam.d/sddm* and comment
> out (prepend with #) the lines with "auth optional pam_kwallet.so" and a bit
> lower "session optional pam_kwallet.so" and leave only the pam_kwallet5.so
> and see what that does?

It made no visible difference. I still see the dialog (perhaps twice; maybe it is the same one re-appearing). Note that I also saw a gnome keyring in addition to both kwallet and kwallet5, though I do not remember installing any gnome apps.

I tried commenting  out pam_kwallet.so and the gnome_keyring lines last night and it had no effect on the error message. commenting out pam_kwallet5.so of course eliminated the error though. I see no signs of an i386 package. I tried switching to the open source driver instead of the proprietary nvidia driver and strangely enough like Clay said the error does not appear.

Ok, thanks guys, that eliminates the possibility of kwallet4 and kwallet5 conflicting.

The nvidia correlation is strange and I'm sorry for dismissing it so quickly, but it appears to have an effect.

@Matt - by switching you mean uninstalling the binary nvidia driver? Or simply changing it in xorg.conf?

I used the driver manager gui on kubuntu for it. I believe it completely uninstalls and reinstalls drivers when switching but I'm not entirely sure.

Hahaha, I'm also using the Nvidia driver.  How absurd!

Oddly enough this indeed is 100% reproducible with nvidia drivers installed. I doubt this has to do with the driver itself but rather with the nvidia GL libs doing fun stuff to memory and/or changing startup speed sufficiently to cause/avoid a timing problem.

This is a grotesquely disheartening bug that I just spent half a day on and I am still not sure it is fixed because of how fiddly this is to test. Also... bloody modset, what is this? the 80's?

Random findings:

a) compile flags matter.  while the kubuntu build runs into the config problem, a master build with -DCMAKE_BUILD_TYPE=Debug does not (kubuntu uses -DCMAKE_BUILD_TYPE=None -DCMAKE_BUILD_TYPE=Debian, whatever that means).

b) the toWalletPipe[0] has the same fd number in both modules for some reason, envSocket OTOH does not. this might be nothing. just an observation

c) the failure point is in kwalletd's main.cpp waitForEnvironment; specifically accept() errors out  with EINVAL which can be "Socket is not listening for connections, or addrlen is invalid (e.g., is negative).". and indeed addrlen isn't initialized properly...

d) in the pam's start_kwallet failing to create the pipes doesn't cause a return of the function, it supposedly should though. not related to the problem at hand

All that said this seems to fix it, but I have to do some additional testing

diff --git a/src/runtime/kwalletd/main.cpp b/src/runtime/kwalletd/main.cpp
index 39b5ae9..e790afe 100644
--- a/src/runtime/kwalletd/main.cpp
+++ b/src/runtime/kwalletd/main.cpp
@@ -82,8 +82,8 @@ static int waitForEnvironment()
     printf("kwalletd5: waitingForEnvironment on: %d\n", socketfd);
 
     int s2;
-    socklen_t t;
     struct sockaddr_un remote;
+    socklen_t t = sizeof(remote);
     if ((s2 = accept(socketfd, (struct sockaddr *)&remote, &t)) == -1) {
         fprintf(stdout, "kwalletd5: Couldn't accept incoming connection\n");
         return -1;

https://git.reviewboard.kde.org/r/125717

Git commit f1e6b9d168281196010c44af2eae4587c1d2d088 by Harald Sitter.
Committed on 21/10/2015 at 05:38.
Pushed by sitter into branch 'master'.

initialize socket size with correct value

to quote man 2 accept:
> The addrlen argument is a value-result argument: the caller must
> initialize it to contain the size (in bytes) of the structure pointed
> to by addr; on return it will contain the actual size of the peer
> address.

If addrlen is not correct we may get EINVAL on trying to connect to the
environment socket which in turn results in a broken environment of the
daemon when started through pam as it will inherit the DM environment.
This doesn't have to happen, it does however reproducibly with nvidia-352
on Kubuntu 15.10. Why or how nvidia plays into this is not entirely clear,
best bet is that it simply is a coincidence where nvidia would have
something allocated in the memory beforehand and since the addrlen
stack variable was not explicitly initialized to anything it would could
potentially be negative (EINVAL condition) or wrong such that it meets
an internal error check within accept().

CHANGELOG: Fixed KWallet configuration file warnings on login
FIXED-IN: 5.16
REVIEW: 125717

M  +1    -1    src/runtime/kwalletd/main.cpp

http://commits.kde.org/kwallet-framework/f1e6b9d168281196010c44af2eae4587c1d2d088

My wallet's working just fine now.  Brilliant debugging, thank you!

Several startups with no error message so far. Nice work.

We've been hitting this in Fedora 23 validation testing too:

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

for us it seems to be an arch thing; it's reliably reproducible with the 32-bit image, not with the 64-bit image. I'm testing the fix now.

This fix resolved my issue just in time with the final 15.10 Kubuntu release candidate. Perhaps coincidentally, it also resolved this wontfix: https://bugs.kde.org/show_bug.cgi?id=344600&list_id=1305547