Pass HOME environment variable through to the client

[tstarling]

To fix debconf-kde-helper error dialog:
https://bugs.launchpad.net/ubuntu/+source/kde-runtime/+bug/1851573

I reproduced the bug on Ubuntu 22.04. I tested the patch by applying it to the OS package (1.2.5-2ubuntu2), rebuilding and installing. I confirmed that it fixed the bug.

[hughsie]

I don't think the users home is a very good idea to include -- the home directory should be untouched by a system daemon.

[ximion]

Why would a system daemon running as root ever want to write (!!) into the user's home directory, or even read from it?
That really feels like wrong behavior, and I'd rather make debconf not do that than working around it in PackageKit.

[tstarling]

It's not running as root for me. pk-debconf-helper is installed as a systemd user service with unit file /lib/systemd/user/pk-debconf-helper.service. packagekitd is running as root but it activates the user service via dbus.

[tstarling]

How about if I wrap it with if (getuid()) ?

[ximion]

I think we should rather prevent the debconf-kde-helper from trying to write a configuration file at all - it does not create one explicitly AFAIR, so we'd have to prevent the implicit creation of one.
But I'll need to read through that bug report in detail again to see what you found out already.

Wit h this patch, you are definitely passing the current user's home to the binary running as root, which then sends it back to the user-mode helper, which isn't great.

[hughsie]

which isn't great

I think it's most unexpected from a security audit point of view too.

[tstarling]

How exactly is debconf-communicate started? pk_client_create_helper_argv_envp() is creating argument and environment arrays for debconf-communicate, and I can see with ps that debconf-communicate is running as non-root. So I figured that the environment is just for debconf-communicate. You are saying that this environment also affects some other wrapper?

To fix the bug in debconf-kde-helper I think the only solution would be putenv("HOME=..."), with the home directory fetched from getpwent(). It's not possible to use KDE libraries without accessing the home directory. The configuration file is the only thing it's loudly complaining about, but strace shows it is trying to read 40 files from //.local and //.config.

[hughsie]

It's not possible to use KDE libraries without accessing the home directory

Something is very wrong with the design then.

[markcapella]

So why was this closed? "Advanced users can work around the issue" seems unsatisfying.

[tstarling]

So why was this closed? "Advanced users can work around the issue" seems unsatisfying.

I (the author) closed it because the comments above made it clear that there was no prospect of the patch being merged.

The bug is a result of switching from a Gnome-based desktop to a KDE-based desktop and continuing to use the Gnome-based tools. The simplest workaround is to not do that. Uninstall gnome-software and use plasma-discover instead.

[markcapella]

Heh, now that's the honest answer. Sadly I'm conditioned to think of your update tool as more "official" than Discover as I adopt Plasma.

Is there any thought to guarding the 'update-manager' to message out early to the user in the KDE-based desktop?

[tstarling]

I'm just a user, it's not my update tool. Actually, I'm not even a user anymore, since I uninstalled it. This was my first and presumably last PackageKit PR. Feel free to suggest whatever solution you like in a separate bug report.