Bug 351805

Summary: Configuration file "//.config/kwalletd5rc" not writable. Please contact your system administrator.
Product: [Frameworks and Libraries] frameworks-kwallet Reporter: Marco Parillo <marco_parillo>
Component: generalAssignee: Harald Sitter <sitter>
Status: RESOLVED FIXED    
Severity: normal CC: adamw, aroth, clay, kdelibs-bugs, kirill.bogdanenko, lari.natri, laurent, matt.kde526, miabraha, mklapetek, mrboese, orjol, rafaelalcantaraperez, rdieter
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Kubuntu   
OS: Linux   
URL: http://cdimage.ubuntu.com/kubuntu/daily-live/20150825.1/wily-desktop-i386.iso
Latest Commit: Version Fixed In: 5.16
Attachments: Screenshot

Description Marco Parillo 2015-08-26 14:02:22 UTC
On a fresh install of Kubuntu 15.10 Beta 1 RC 1, I get a strange dialogue box.

Reproducible: Always

Steps to Reproduce:
1. Install Kubuntu 15.10 Beta 1 RC 1
2. Install other desired software (sudo apt update && sudo apt install rekonq oxygen-cursor-theme -y)
3. Reboot
4. Sign into desktop

Actual Results:  
Receive Dialogue box: Configuration file "//.config/kwalletd5rc" not writable. Please contact your system administrator.

Expected Results:  
No dialogue box.

I do not even have the file that is not writeable. I only have:
mparillo@mparillo-virtual-machine:~$ ls .config/kwal*
.config/kwalletrc

Is this the normal permissions for .config?
drwx------ 10 mparillo mparillo  4096 Aug 26 09:54 .config
Comment 1 Lari Natri 2015-09-09 20:11:19 UTC
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.
Comment 2 Orjol 2015-09-16 21:11:49 UTC
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.
Comment 3 Clay Weber 2015-09-18 00:35:42 UTC
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
Comment 4 Valentin Rusu 2015-09-19 19:24:52 UTC
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)
Comment 5 Marco Parillo 2015-09-19 21:44:47 UTC
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?
Comment 6 Lari Natri 2015-09-20 17:46:33 UTC
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.
Comment 7 Harald Sitter 2015-09-21 11:41:55 UTC
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.
Comment 8 Marco Parillo 2015-09-24 15:50:18 UTC
For me, this no longer appears on fresh installs of Kubuntu Beta-2 RC images.
Comment 9 Marco Parillo 2015-09-25 12:28:41 UTC
(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.
Comment 10 Kyrylo Bohdanenko 2015-09-27 18:34:25 UTC
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/
Comment 11 Michael 2015-10-02 23:47:23 UTC
Created attachment 94821 [details]
Screenshot
Comment 12 Michael 2015-10-06 05:57:25 UTC
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
Comment 13 Martin Klapetek 2015-10-06 14:03:32 UTC
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.
Comment 14 Martin Klapetek 2015-10-06 15:50:04 UTC
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?
Comment 15 Kyrylo Bohdanenko 2015-10-06 21:05:47 UTC
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?
Comment 16 Martin Klapetek 2015-10-07 15:28:43 UTC
Try "grep -i denied"
Comment 17 Clay Weber 2015-10-16 00:47:33 UTC
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.
Comment 18 Clay Weber 2015-10-16 00:50:56 UTC
Also note my system is an optimus laptop, and the message does not occur using the Intel gpu.
Comment 19 Martin Klapetek 2015-10-16 01:01:15 UTC
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.
Comment 20 Clay Weber 2015-10-16 01:15:36 UTC
(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.
Comment 21 Matt 2015-10-16 01:31:32 UTC
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.
Comment 22 Martin Klapetek 2015-10-16 16:46:35 UTC
@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?
Comment 23 laurent 2015-10-16 17:51:09 UTC
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.
Comment 24 Marco Parillo 2015-10-16 18:45:11 UTC
(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.
Comment 25 Matt 2015-10-16 20:42:39 UTC
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.
Comment 26 Martin Klapetek 2015-10-16 20:46:45 UTC
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?
Comment 27 Matt 2015-10-16 22:18:59 UTC
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.
Comment 28 Michael 2015-10-17 21:29:35 UTC
Hahaha, I'm also using the Nvidia driver.  How absurd!
Comment 29 Harald Sitter 2015-10-19 14:39:47 UTC
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;
Comment 30 Harald Sitter 2015-10-20 06:52:35 UTC
https://git.reviewboard.kde.org/r/125717
Comment 31 Harald Sitter 2015-10-21 05:38:58 UTC
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
Comment 32 Michael 2015-10-22 11:39:01 UTC
My wallet's working just fine now.  Brilliant debugging, thank you!
Comment 33 Matt 2015-10-22 18:58:13 UTC
Several startups with no error message so far. Nice work.
Comment 34 Adam Williamson 2015-10-24 01:36:41 UTC
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.
Comment 35 Marco Parillo 2015-10-24 10:02:43 UTC
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