Bug 249217 - kauth helpers create .kde and .config in /
Summary: kauth helpers create .kde and .config in /
Status: RESOLVED FIXED
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Dario Freddi
URL:
Keywords:
: 280433 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-08-27 13:47 UTC by oneforall
Modified: 2013-07-23 06:38 UTC (History)
32 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.11.0


Attachments
set enviroment variable HOME for helper if not set (1.01 KB, patch)
2013-01-08 16:27 UTC, Misha Labjuk
Details

Note You need to log in before you can comment on or make changes to this bug.
Description oneforall 2010-08-27 13:47:40 UTC
Version:           unspecified (using KDE 4.5.0) 
OS:                Linux

Hi, Its been happening for a long time but I could never find out what was the cause till today. kauth is making those 2 off of / .kde and .config. When I do the Adjust date/time root password way .

Reproducible: Always

Steps to Reproduce:
right click the clock on the panel(or from the settings ) Adjust date/time . then adjust the time , so apply. close (I have to use cancel no ok) filing a bug about that also and 1 more :) then I go look at / konsole ls -a / . I actually first discovered in in mc .  

Actual Results:  
same as above

Expected Results:  
for it to use /root/.kde{config}
Comment 1 Christoph Feck 2010-08-27 17:25:05 UTC
I did not understand the issue. Could you clarify?
Comment 2 Christoph Feck 2010-08-27 17:26:40 UTC
Seeing that you filed multiple bugs about KAuth apparently not working, maybe it is a setup problem. If you compile KDE yourself, you have to make sure you setup KAuth correctly. It isn't easy, but maybe Dario can guide you.
Comment 3 George Kiagiadakis 2010-08-28 11:14:15 UTC
His problem, as he described it in irc and I can confirm it, is that when the kauth helper is launched, the directories /.kde and /.config are created. /.kde contains an empty tree structure similar to ~/.kde and /.config contains a Trolltech.conf with the following contents:

[Qt%20Plugin%20Cache%204.6.false]
usr\lib\kde4\plugins\kauth\backend\kauth_backend_plugin.so=40603, 0, x86_64 linux g++-4 full-config, 2010-08-02T18:09:15
usr\lib\kde4\plugins\kauth\helper\kauth_helper_plugin.so=40603, 0, x86_64 linux g++-4 full-config, 2010-08-02T18:09:15

This is absolutely wrong, Trolltech.conf should be created in /root/.config/ and .kde should not be created at all (as it is not used).
Comment 4 oneforall 2010-08-28 16:43:34 UTC
thanks   George Kiagiadakis , I can't think of any simpler way to describe it :)
Comment 5 Markus 2010-10-07 06:21:29 UTC
I can confirm this issue too...
building KDE 4.5.2 on Slackware 13.1 i do also get .kde and .config off the /root directory after using kauth for example to setup date&time.

.config appears when the password dialog pops up and .kde is created after authentification is done.
Comment 6 David Faure 2010-10-12 18:52:23 UTC
Could be related to bug 233892.
Comment 7 zless 2011-03-06 16:16:51 UTC
I confirm this /.config/Trolltech.conf issue myself on Kubuntu 10.10 and KDE 4.6.1.

I could find a way to tell what makes it appear.
Comment 8 Anton Barkovsky 2011-03-27 20:17:25 UTC
I have this bug on Arch with KDE 4.6.1
BTW, 'Adjust Date and Time' behaves strangely. After I change settings here, click 'apply', enter root's password and press 'ok' after that, an error message popups: "Unable to authenticate/execute the action: 6,"
Comment 9 yar 2011-03-30 21:12:02 UTC
*** This bug has been confirmed by popular vote. ***
Comment 10 Andrew Trabo 2011-04-27 20:42:50 UTC
/.config folder appears after 'kdesu systemsettings'. KDE 4.6.2
Comment 11 Andrew 2011-05-29 20:31:17 UTC
In my case (Kubuntu 10.10 & 11.04) there were some stale and lost (not belonging to any package) plugins in /usr/lib64/kde4/plugins/kauth. So I just did rm -rf /usr/lib64/kde4/plugins/kauth and the /.config/Trolltech.conf stopped getting created.
Comment 12 Marius Cirsta 2011-06-08 22:49:00 UTC
 I've got this bug as well after updating KDE and other packages. It's really not nice... 
 I've also got some .kde in root also.
Comment 13 Alvaro Manuel Recio Perez 2011-07-15 09:31:06 UTC
This bug is still present in KDE 4.6.5 in Kubuntu 11.04.
Comment 14 zless 2011-07-15 09:40:40 UTC
Also in 4.7 RC 2
Comment 15 Egor Y. Egorov 2011-08-02 09:27:08 UTC
Same on 4.7
Found out that the process /usr/lib64/kde4/libexec/kcmkdmhelper create the file /.config/Trolltech.conf
Perhaps, HOME environment variable is not set for this process
Comment 16 Egor Y. Egorov 2011-08-02 10:16:53 UTC
I did the following:
1. # mv /usr/lib64/kde4/libexec/kcmkdmhelper /usr/lib64/kde4/libexec/kcmkdmhelper_
2. # cat > /usr/lib64/kde4/libexec/kcmkdmhelper
#!/bin/bash                                                                                                                                  
echo Home is \"$HOME\" >> /tmp/kcmkdmhelper.log                                                                                              
export HOME=/tmp                                                                                                                             
exec /usr/lib64/kde4/libexec/kcmkdmhelper_
3. # chmod 777 /usr/lib64/kde4/libexec/kcmkdmhelper
4. Make https://bugs.kde.org/show_bug.cgi?id=249217#c8

In result:
1. # cat /tmp/kcmkdmhelper.log 
Home is ""
2. .config was created in /tmp
Comment 17 Egor Y. Egorov 2011-08-03 03:33:17 UTC
Patch to qt-core (I'm using Gentoo). Solve this problem for me.

diff -uNr qt-everywhere-opensource-src-4.7.3_orig/src/corelib/io/qfsfileengine_unix.cpp qt-everywhere-opensource-src-4.7.3/src/corelib/io/qfsfileengine_unix.cpp
--- qt-everywhere-opensource-src-4.7.3_orig/src/corelib/io/qfsfileengine_unix.cpp	2011-03-30 12:19:08.000000000 +0700
+++ qt-everywhere-opensource-src-4.7.3/src/corelib/io/qfsfileengine_unix.cpp	2011-08-03 10:12:25.000000000 +0700
@@ -53,6 +53,7 @@
 
 #include <sys/mman.h>
 #include <stdlib.h>
+#include <unistd.h>
 #include <limits.h>
 #if defined(Q_OS_SYMBIAN)
 # include <sys/syslimits.h>
@@ -625,7 +626,28 @@
     QString home = rootPath();
 #else
     QString home = QFile::decodeName(qgetenv("HOME"));
-    if (home.isNull())
+
+    if (home.isEmpty())
+    {
+#if !defined(QT_NO_THREAD) && defined(_POSIX_THREAD_SAFE_FUNCTIONS) && !defined(Q_OS_OPENBSD)
+        int size_max = sysconf(_SC_GETPW_R_SIZE_MAX);
+        if (size_max == -1)
+            size_max = 1024;
+        QVarLengthArray<char, 1024> buf(size_max);
+#endif
+	struct passwd *pw = 0;
+	uid_t user_id = getuid();
+        pw = getpwuid(user_id);
+#if !defined(QT_NO_THREAD) && defined(_POSIX_THREAD_SAFE_FUNCTIONS) && !defined(Q_OS_OPENBSD)
+        struct passwd entry;
+        getpwuid_r(user_id, &entry, buf.data(), buf.size(), &pw);
+#else
+        pw = getpwuid(user_id);
+#endif
+        home = QFile::decodeName(QByteArray(pw->pw_dir));
+    }
+
+    if (home.isEmpty())
         home = rootPath();
 #endif
     return home;
Comment 18 Egor Y. Egorov 2011-08-03 03:50:26 UTC
I'm post this patch here: https://bugreports.qt.nokia.com/browse/QTBUG-4862
Comment 19 Egor Y. Egorov 2011-08-03 06:57:40 UTC
New path. In previous versions there was no difference if a variable HOME="", or not set.

diff -uNr qt-everywhere-opensource-src-4.7.3_orig/src/corelib/io/qfsfileengine_unix.cpp qt-everywhere-opensource-src-4.7.3/src/corelib/io/qfsfileengine_unix.cpp
--- qt-everywhere-opensource-src-4.7.3_orig/src/corelib/io/qfsfileengine_unix.cpp	2011-03-30 12:19:08.000000000 +0700
+++ qt-everywhere-opensource-src-4.7.3/src/corelib/io/qfsfileengine_unix.cpp	2011-08-03 13:33:47.000000000 +0700
@@ -53,6 +53,7 @@
 
 #include <sys/mman.h>
 #include <stdlib.h>
+#include <unistd.h>
 #include <limits.h>
 #if defined(Q_OS_SYMBIAN)
 # include <sys/syslimits.h>
@@ -624,8 +625,28 @@
 #if defined(Q_OS_SYMBIAN)
     QString home = rootPath();
 #else
-    QString home = QFile::decodeName(qgetenv("HOME"));
-    if (home.isNull())
+    QByteArray home_ba = qgetenv("HOME");
+    if (home_ba.isNull())
+    {
+#if !defined(QT_NO_THREAD) && defined(_POSIX_THREAD_SAFE_FUNCTIONS) && !defined(Q_OS_OPENBSD)
+        int size_max = sysconf(_SC_GETPW_R_SIZE_MAX);
+        if (size_max == -1)
+            size_max = 1024;
+        QVarLengthArray<char, 1024> buf(size_max);
+#endif
+        struct passwd *pw = 0;
+        uid_t user_id = getuid();
+        pw = getpwuid(user_id);
+#if !defined(QT_NO_THREAD) && defined(_POSIX_THREAD_SAFE_FUNCTIONS) && !defined(Q_OS_OPENBSD)
+        struct passwd entry;
+        getpwuid_r(user_id, &entry, buf.data(), buf.size(), &pw);
+#else
+        pw = getpwuid(user_id);
+#endif
+        home_ba = QByteArray(pw->pw_dir);
+    }
+    QString home = QFile::decodeName(home_ba);
+    if (home.isEmpty())
         home = rootPath();
 #endif
     return home;
Comment 21 Martin von Gagern 2011-08-03 09:21:34 UTC
So basically Qt devs say that an empty HOME variable is a bug and should be fixed instead of worked around. Question is, why is HOME empty in this instance. Unfortunately I can't reproduce comment #0 as I'm not allowed to set the clock at all. Someone who can might have a beter chance identifying the relevant code. An "strace -ff" would be a good start, I guess.
Comment 22 Egor Y. Egorov 2011-08-03 09:50:13 UTC
Try
systemsettings->Login screen->Togglle 'Use anti-aliasing for fonts'->Apply
PS. A you using kdm?
Comment 23 Eugeny Shkrigunov 2011-08-03 17:01:08 UTC
Yeah, the developers of Qt is very arrogant. I also sent them future request, which was immediately labeled "Invalid", but in the next release they proudly announced this functionality: how smart they are and no one else had not occurred.
Comment 24 Egor Y. Egorov 2011-08-04 09:56:59 UTC
all environment variables of this proccess:

DBUS_STARTER_ADDRESS=unix:path=/var/run/dbus/system_bus_socket,guid=732aaea3fff822f69f8b4fe300000018                                         
PWD=/                                                                                                                                        
DBUS_STARTER_BUS_TYPE=system                                                                                                                 
SHLVL=1                                                                                                                                      
_=/usr/bin/env 

Can be help.
Comment 25 Egor Y. Egorov 2011-08-04 12:33:35 UTC
Found out that the processes that create these files, run through a D-Bus as a service.

ls -l /usr/share/dbus-1/system-services/org.kde.kcontrol.kcm*
-rw-r--r-- 1 root root 104 Июл 27 14:40 /usr/share/dbus-1/system-services/org.kde.kcontrol.kcmclock.service
-rw-r--r-- 1 root root 134 Авг  4 19:24 /usr/share/dbus-1/system-services/org.kde.kcontrol.kcmkdm.service
-rw-r--r-- 1 root root 117 Июл 27 11:30 /usr/share/dbus-1/system-services/org.kde.kcontrol.kcmremotewidgets.service

Thus, it is D-Bus does not set the HOME.
As a workaround you can edit the file services as follows:

# cat /usr/share/dbus-1/system-services/org.kde.kcontrol.kcmkdm.service
[D-BUS Service]
Name=org.kde.kcontrol.kcmkdm
Exec=/bin/bash -c 'export HOME=~ ;  exec /usr/lib64/kde4/libexec/kcmkdmhelper'
User=root

Similarly for other services
Comment 26 Egor Y. Egorov 2011-08-05 03:10:36 UTC
Or patch for D-Bus:


diff -uNr dbus-1.4.12_orig/bus/activation-helper.c dbus-1.4.12/bus/activation-helper.c
--- dbus-1.4.12_orig/bus/activation-helper.c	2011-02-25 19:25:30.000000000 +0600
+++ dbus-1.4.12/bus/activation-helper.c	2011-08-05 09:58:10.000000000 +0700
@@ -368,6 +368,11 @@
 
 #ifndef ACTIVATION_LAUNCHER_DO_OOM
   /* replace with new binary, with no environment */
+
+  struct passwd *pw = 0;
+  pw = getpwnam(user);
+  _dbus_setenv ("HOME", pw->pw_dir);
+
   if (execv (argv[0], argv) < 0)
     {
       dbus_set_error (error, DBUS_ERROR_SPAWN_EXEC_FAILED,
Comment 27 Egor Y. Egorov 2011-08-05 04:14:57 UTC
A better way:


diff -uNr dbus-1.4.12_orig/bus/activation-helper.c dbus-1.4.12/bus/activation-helper.c
--- dbus-1.4.12_orig/bus/activation-helper.c	2011-02-25 19:25:30.000000000 +0600
+++ dbus-1.4.12/bus/activation-helper.c	2011-08-05 11:05:17.000000000 +0700
@@ -344,6 +344,7 @@
                       "cannot setuid user %i", pw->pw_uid);
       return FALSE;
     }
+  _dbus_setenv ("HOME", pw->pw_dir);
 #endif
   return TRUE;
 }
Comment 28 Oswald Buddenhagen 2011-08-05 06:00:56 UTC
on first sight, comment 27 looks like the right thing to do. please report this to d-bus upstream (check for existing reports first, as usual).
Comment 29 Egor Y. Egorov 2011-08-05 08:02:52 UTC
I think that should fix Qt, and no dbus. So, before you create a bug, I would talk to freedesktop mailing list on this topic. Unfortunately, I do not speak English, so I have a time-consuming. Could you do it? In the end, to have Discussions attract developers and Qt. I doubt that I will be able more efficiently to maintain dialogue. Anyway, cause problem is clear, and I believe that in the end will be taken the right decision.
Comment 30 Martin von Gagern 2011-08-05 09:02:53 UTC
Comment #27 works for me. KDM login used to create /.config on my system, with the fix it creates /root/.config instead, which is at least an improvement.

(In reply to comment #29)
> I think that should fix Qt, and no dbus.

I disagree. There might be many apps that expect a sane $HOME, so fixing dbus will fix them all, but changing Qt won't. Plus, the fix in dbus is much easier, as the passwd data is guaranteed to be available inside that switch_user function.

> Could you do it?

I'd be willing to open a dbus bug report for this. If dbus devs think that some discussion is necessary, they can still start that on the mailing list. But my hope would be that they simply accept your patch without too much trouble.

One question that remains is whether /root is a good place for a dbus service to write to. Perhaps kcmkdmhelper should override HOME to /var/run/kcmkdm or something like this before initializing the QT stuff. After all, these files aren't really related to root as a user. But otoh, there shouldn't be a real user logging in as root on a regular basis, so I'm not sure I care.
Comment 31 Egor Y. Egorov 2011-08-05 09:22:10 UTC
> I disagree. There might be many apps that expect a sane $HOME, so fixing dbus
will fix them all, but changing Qt won't.

Maybe you're right.

> I'd be willing to open a dbus bug report for this.

It would be great. When you create a bug, give a link to it here please.
Comment 32 Martin von Gagern 2011-08-05 11:57:48 UTC
(In reply to comment #31)
> When you create a bug, give a link to it here please.

Sure: https://bugs.freedesktop.org/show_bug.cgi?id=39857
Comment 33 Oswald Buddenhagen 2011-08-11 08:10:41 UTC
thinking about this again, i'm not positive that this should be considered a bug in d-bus. after all, the helpers are running only as root because there is no adequate "system" user. consequently, they should not expect a properly set up user session environment. however, qt definitely can expect it, because if you *are* using user-specific stuff, you also need to provide the environment. consequently, the right fix should be adding this setup to the polkit-kde helper base (somewhere near the top of main()).
Comment 34 Egor Y. Egorov 2011-08-11 08:41:05 UTC
I remain of the opinion that it is, nevertheless, bug in Qt. Or, indeed, Qt is not suitable for the implementation of system services. In this case you should either implement assistants not on Qt (unlikely), or use the workaround as <a href="show_bug.cgi?id=249217#c25">comment #25</a>
Comment 35 Simon McVittie 2011-08-18 13:34:56 UTC
(In reply to comment #33)
> thinking about this again, i'm not positive that this should be considered a
> bug in d-bus.

I agree, and I closed the D-Bus bug as NOTABUG: dbus-daemon-launch-helper starts system services with a minimal environment, consistent with the behaviour of both systemd and Upstart.

> they should not expect a properly set up user session environment.

Yes, anything started by D-Bus system activation is a system-level service, so they shouldn't expect a session at all: if they need to write out persistent state, they should really put it in /var/lib/kauth or /var/cache/kauth or something, rather than in root's home directory.

> however, qt definitely can expect it, because if
> you *are* using user-specific stuff, you also need to provide the
> environment.

(In reply to comment #21)
> So basically Qt devs say that an empty HOME variable is a bug and should be
> fixed instead of worked around.

For a GUI application I would agree, and for a user-specific session service (Telepathy, notification daemon, KWallet...) I would agree, but this is a system service, and system services have different constraints and expectations.

(In reply to comment #30)
> One question that remains is whether /root is a good place for a dbus service
> to write to. Perhaps kcmkdmhelper should override HOME to /var/run/kcmkdm or
> something like this before initializing the QT stuff. After all, these files
> aren't really related to root as a user.

I agree, /root is the wrong place anyway.

(In reply to comment #3)
> the directories /.kde and /.config are created. /.kde
> contains an empty tree structure similar to ~/.kde

I'd personally say that creating ~/.kde "eagerly" (i.e. when there's nothing to write there yet) is a bug, but YMMV. (I'm a D-Bus developer, not a KDE developer.)

> and /.config contains a
> Trolltech.conf with the following contents:
> 
> [Qt%20Plugin%20Cache%204.6.false]
> usr\lib\kde4\plugins\kauth\backend\kauth_backend_plugin.so=40603, 0, x86_64
> linux g++-4 full-config, 2010-08-02T18:09:15
> usr\lib\kde4\plugins\kauth\helper\kauth_helper_plugin.so=40603, 0, x86_64 linux
> g++-4 full-config, 2010-08-02T18:09:15

I'd personally say that this is a bug too - caches shouldn't be in ~/.config (if it had been written into ${XDG_CACHE_HOME:~/.cache} that wouldn't actually help you here, although you could have XDG_CACHE_HOME=/var/cache/kauth or something).
Comment 36 Simon McVittie 2011-08-18 13:41:09 UTC
(In reply to comment #35)
> consistent with the behaviour of both systemd and Upstart

I should probably mention why this is significant, for the benefit of people with less involvement in D-Bus: it's partly because they're init systems and D-Bus service activation is essentially a mini-init-system, but mainly because D-Bus can be configured in any of these ways, which should all basically work the same:

* launch system services via dbus-daemon-launch-helper (traditional setup,
  used in e.g. Debian and older Fedora)

* launch system services via systemd (current Fedora does this)

* launch system services via Upstart (with patches applied, currently
  Ubuntu-specific)

systemd doesn't set $HOME for services, and Lennart (who is also a D-Bus maintainer) has confirmed on https://bugs.freedesktop.org/show_bug.cgi?id=39857 that that was a deliberate design decision. Upstart doesn't seem to set $HOME for services either, which I assume is also a deliberate design decision.
Comment 37 George Kiagiadakis 2011-08-18 14:40:46 UTC
(In reply to comment #35)
> (In reply to comment #3)
> > the directories /.kde and /.config are created. /.kde
> > contains an empty tree structure similar to ~/.kde
> 
> I'd personally say that creating ~/.kde "eagerly" (i.e. when there's nothing to
> write there yet) is a bug, but YMMV. (I'm a D-Bus developer, not a KDE
> developer.)

I also agree with this. But afair there is a reason why this has not been fixed in years. Does anybody remember why?

> > and /.config contains a
> > Trolltech.conf with the following contents:
> > 
> > [Qt%20Plugin%20Cache%204.6.false]
> > usr\lib\kde4\plugins\kauth\backend\kauth_backend_plugin.so=40603, 0, x86_64
> > linux g++-4 full-config, 2010-08-02T18:09:15
> > usr\lib\kde4\plugins\kauth\helper\kauth_helper_plugin.so=40603, 0, x86_64 linux
> > g++-4 full-config, 2010-08-02T18:09:15
> 
> I'd personally say that this is a bug too - caches shouldn't be in ~/.config
> (if it had been written into ${XDG_CACHE_HOME:~/.cache} that wouldn't actually
> help you here, although you could have XDG_CACHE_HOME=/var/cache/kauth or
> something).

Agreed as well, but unfortunately this is a Qt thing... Can we get this fixed in Qt5?

Maybe we can also fix Qt to skip cache if $HOME and/or $XDG_CACHE_HOME are not set, which will remove the need for kauth helpers to write something in $HOME, and in combination with a patch that skips creating .kde if it is not needed, problem solved! I think this is something that we should pursue for Qt5/KDE Frameworks 5. Writing daemons with Qt and KDE core libraries should be a valid use case.
Comment 38 Oswald Buddenhagen 2011-08-18 15:16:51 UTC
(In reply to comment #37)
> (In reply to comment #35)
> > I'd personally say that creating ~/.kde "eagerly" (i.e. when there's nothing to
> > write there yet) is a bug, but YMMV.
> 
> I also agree with this. But afair there is a reason why this has not been fixed
> in years. Does anybody remember why?
> 
bug 233892 claims to be fixed. though according to my own comment, the fix may cause collateral damage unless something else changed as well.

> > I'd personally say that this is a bug too - caches shouldn't be in ~/.config
> 
> Agreed as well, but unfortunately this is a Qt thing... Can we get this fixed
> in Qt5?
> 
is it reported upstream? please ensure there is a task and let me know of it.

> Maybe we can also fix Qt to skip cache if $HOME and/or $XDG_CACHE_HOME are not
> set,
>
that sounds reasonable. though i think it would make more sense to give auth helpers a (shared) persistent HOME so they *can* do caching (which is a startup performance thingie).
Comment 39 George Kiagiadakis 2011-08-19 11:31:43 UTC
(In reply to comment #38)
> (In reply to comment #37)
> > (In reply to comment #35)
> > > I'd personally say that creating ~/.kde "eagerly" (i.e. when there's nothing to
> > > write there yet) is a bug, but YMMV.
> > 
> > I also agree with this. But afair there is a reason why this has not been fixed
> > in years. Does anybody remember why?
> > 
> bug 233892 claims to be fixed. though according to my own comment, the fix may
> cause collateral damage unless something else changed as well.

Oh, it seems to be fixed indeed. I just tested it with the kdm kcm module and /.kde wasn't created.

> > > I'd personally say that this is a bug too - caches shouldn't be in ~/.config
> > 
> > Agreed as well, but unfortunately this is a Qt thing... Can we get this fixed
> > in Qt5?
> > 
> is it reported upstream? please ensure there is a task and let me know of it.

I checked for a bug and didn't find it, so I opened a new one:
https://bugreports.qt.nokia.com/browse/QTBUG-21030
Comment 40 Christoph Feck 2011-08-25 11:59:53 UTC
*** Bug 280433 has been marked as a duplicate of this bug. ***
Comment 41 Ralf Jung 2012-03-06 12:30:18 UTC
This bug is still present and still needlessly creating a .config folder in /.

If I got that right, the correct place to set a home directory for the AUTH helper would be in kdelibs/kdecore/auth/kauthhelpersupport.cpp, at the beginning of helperMain. That's the function creating the QCoreApplication, so it can make sure the environment is right before Qt starts living.

Alternatively, was there any work on making it possible to use a QCoreApplication without HOME being set?
Comment 42 Juan Orti 2012-10-19 14:09:48 UTC
I'm experiencing this bug in Fedora 17 with KDE 4.9.2
Comment 43 Misha Labjuk 2013-01-08 16:27:57 UTC
Created attachment 76310 [details]
set enviroment variable HOME for helper if not set

This patch works for me.
Set HOME variable to user default if not set.
Comment 44 Ralf Jung 2013-01-08 16:39:18 UTC
Shouldn't this rather use "geteuid" instead of "getuid"? Otherwise, one may end up with root-owned files in ~/.config, which should not be the case.
Or does dbus somehow also change the RUID of a process when making it root?
Comment 45 Simon McVittie 2013-01-08 17:31:14 UTC
> Or does dbus somehow also change the RUID of a process when making it root?

System services activated by dbus-daemon-launch-helper run with euid and ruid both set to the User from the .service file. (See bus/activation-helper.c in dbus.git for the code - it runs as root and calls setuid(), which has the special behaviour that when called by root, it sets the EUID, RUID, saved user ID, and other miscellaneous things like the Linux filesystem UID.)

For best security, if these helper processes are designed to be run as root from dbus-daemon-launch-helper (or the equivalent code in systemd and Upstart) and are not designed to be installed setuid root, then they should probably check on startup that they have euid = ruid = 0, and refuse to do anything otherwise.

If they're designed to be installed setuid, then they should already have a documented set of security assumptions, which should include not trusting the real uid or any environment variables they are given.
Comment 46 Misha Labjuk 2013-01-08 17:43:05 UTC
(In reply to comment #44)
> Shouldn't this rather use "geteuid" instead of "getuid"?
No, because helpers did not suid program.
Comment 47 Michael Palimaka 2013-01-29 16:44:31 UTC
Can anybody comment on the attached patch? If it looks alright, I will push it to reviewboard.
Comment 48 Ralf Jung 2013-01-29 16:51:53 UTC
Why don't you just push it to reviewboard right now? After all, getting feedback on a patch is what it is designed for ;-)

Not knowing all this policykit stuff, I can only comment on the genreal C++ side:
I'd make the "char *home" and "const char *" (GCC should warn about this, but maybe this needs -Wextra or something).
Comment 49 Andreas K. Huettel 2013-05-26 19:34:22 UTC
https://reviewboard.kde.org/r/110655/
Comment 50 Andreas K. Huettel 2013-07-22 22:34:01 UTC
> Git commit 68175df8d48031e6310a8d4dc3ae7bad6b74e541 by Andreas K. Huettel, on behalf of Andreas K. Huettel (dilfridge).
> Committed on 21/07/2013 at 14:44.
> Pushed by huettel into branch 'KDE/4.11'.
> 
> Make sure HOME is never unset, to prevent creation of files in /
> REVIEW: 110655
> FIXED-IN: 4.11.0

Somebody please resolve the bug, I dont have permission (yet?) to do it.