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}
I did not understand the issue. Could you clarify?
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.
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).
thanks George Kiagiadakis , I can't think of any simpler way to describe it :)
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.
Could be related to bug 233892.
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.
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,"
*** This bug has been confirmed by popular vote. ***
/.config folder appears after 'kdesu systemsettings'. KDE 4.6.2
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.
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.
This bug is still present in KDE 4.6.5 in Kubuntu 11.04.
Also in 4.7 RC 2
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
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
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;
I'm post this patch here: https://bugreports.qt.nokia.com/browse/QTBUG-4862
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;
Qt-developers answer: https://bugreports.qt.nokia.com/browse/QTBUG-4862?focusedCommentId=160557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-160557
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.
Try systemsettings->Login screen->Togglle 'Use anti-aliasing for fonts'->Apply PS. A you using kdm?
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.
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.
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
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,
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; }
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).
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 #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.
> 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.
(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
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()).
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>
(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).
(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.
(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.
(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).
(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
*** Bug 280433 has been marked as a duplicate of this bug. ***
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?
I'm experiencing this bug in Fedora 17 with KDE 4.9.2
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.
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?
> 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.
(In reply to comment #44) > Shouldn't this rather use "geteuid" instead of "getuid"? No, because helpers did not suid program.
Can anybody comment on the attached patch? If it looks alright, I will push it to reviewboard.
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).
https://reviewboard.kde.org/r/110655/
> 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.