The switch_user function in the activation-helper will not set the HOME environment variable. Some processes might expect that to be set, and will either fail or make some incorrect assumptions. For example, KDM currently will create a directory /.config as it falls back to / as the HOME for root. This issue has been discussed to some length on the corresponding KDE bug report https://bugs.kde.org/show_bug.cgi?id=249217 I believe that setting the HOME is safe, as that information is available to the subprocesses in any case, and as the passwd database is considered a safe source of information, so it should be impossible to taint that value. I cannot think of any other reason not to export that variable, so please export it.
Created attachment 49952 [details] [review] Proposed fix In https://bugs.kde.org/show_bug.cgi?id=249217#c27 Egor Y. Egorov proposed this simple fix, which works for me as well. Please consider it for inclusion in the next dbus release.
(In reply to comment #0) > The switch_user function in the activation-helper will not set the HOME > environment variable. Some processes might expect that to be set, and will > either fail or make some incorrect assumptions. I personally think those processes are wrong, particularly if they're system services - system services shouldn't make these assumptions about their environment - but if it was just D-Bus that was involved here, I wouldn't object to setting $HOME. However, does systemd set $HOME? Does Upstart, in Ubuntu's patch-set? If either of those doesn't, then changing the activation-helper doesn't help you on systems where the init system is used instead (and it just makes it more likely that people not using systemd/Upstart will write things that rely on the activation helper's behaviour). > I believe that setting the HOME is safe, as that information is available to > the subprocesses in any case, and as the passwd database is considered a safe > source of information, so it should be impossible to taint that value. This is reasonable reasoning, though, and it doesn't "cost" much to set $HOME; so if this brings us into alignment with systemd and Upstart, I'd be OK with that. If we do that, we should probably set USER and LOGNAME, too. Perhaps also SHELL and/or PATH? Regarding the corresponding KDE bug report, I personally think Qt should cope, and the Qt bug shouldn't have been closed as invalid. Or, if Qt is unsuitable for use in system services, then the KDE system services shouldn't use it (but I don't think that's what anyone wants). For comparison, GLib's g_get_home_dir() prefers the passwd entry, and only looks in the environment if that doesn't exist, in a deliberate break from Unix tradition (see its documentation for rationale).
(In reply to comment #2) > This is reasonable reasoning, though, and it doesn't "cost" much to set $HOME; > so if this brings us into alignment with systemd and Upstart, I'd be OK with > that. I've had a look at the sources. > does systemd set $HOME? Yes: http://cgit.freedesktop.org/systemd/tree/src/nspawn.c?id=47675042c2622b96590c89d610b529e09099ce26#n830 > Does Upstart, in Ubuntu's patch-set? Apparently not: http://bazaar.launchpad.net/~upstart-devel/upstart/trunk/view/1321/init/job_process.c#L503 > If either > of those doesn't, then changing the activation-helper doesn't help you on > systems where the init system is used instead (and it just makes it more > likely that people not using systemd/Upstart will write things that rely > on the activation helper's behaviour). So in other words, you say that either both dbus and upstart need adding of HOME, or KDE or Qt need to avoid relying on its existence, right? > Regarding the corresponding KDE bug report, I personally think Qt should cope, > and the Qt bug shouldn't have been closed as invalid. Or, if Qt is unsuitable > for use in system services, then the KDE system services shouldn't use it (but > I don't think that's what anyone wants). Would you be willing to argue this directly with the respective devs? Perhaps come up with at least a clear piece of reliable documentation as to what is intended behaviour. At the moment I fail to completely see the connection between all these components (kde, qt, dbus, upstart), so I wouldn't be well suited to pass those messages around from one dev to the other, without any well-foundet opinion of my own. Perhaps you'd also want to discuss on some kind of mailing list, as https://bugs.kde.org/show_bug.cgi?id=249217#c29 suggested.
the qt bug stays invalid (consider this an authoritative response). i wouldn't know what upstart's or systemd's implementations have to do with that. if they are replicating d-bus functionality, then they should also replicate the bugfixes to it. anyway, i added another comment to the kde bug. executive summary: i wouldn't consider it wrong to reject this bug.
In systemd we made the decision to explicitly unset $HOME if it set. By default system services will be started with an almost empty environment: only $PATH will be set, and potentially LANG/LC_xxx. I think it is a bad idea to fake the user-specific environment variables for system services.
(In reply to comment #5) > In systemd we made the decision to explicitly unset $HOME if it set. OK, I think you're right (particularly since this means D-Bus, systemd and Upstart all agree). NOTABUG. (In reply to comment #3) > http://cgit.freedesktop.org/systemd/tree/src/nspawn.c?id=47675042c2622b96590c89d610b529e09099ce26#n830 This does set $HOME, but is not in fact how systemd starts services; it's a chroot-like tool. (In reply to comment #2) > Regarding the corresponding KDE bug report, I personally think Qt should > cope, and the Qt bug shouldn't have been closed as invalid. Or, if Qt is > unsuitable for use in system services, then the KDE system services > shouldn't use it (but I don't think that's what anyone wants). This... or, the KDE system service in question can work around Qt by setting HOME (if unset) in its main(), before it first enters Qt code.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.