kdesudo and the config problem

[Jonathan Thomas]

Hello,

In my opinion, we should definitely move away from having applications
that need their GUIs run as root to perform authorized actions. Polkit
is The Way Forward(tm) in regards to this. The idea behind Polkit is
that you have a small, non-gui helper application for performing
actions that require admin authorization, communicating with the GUI
over DBUS.

Already, we have both QApt (and by extension the Muon Suite) as well
as the Usb Creator KDE frontend as examples of this paradigm. (Some
upstream stuff has also migrated to this, including various parts of
KDE's System Settings as well as K3b's KCM Module.

What we need to do is to create a list of applications where launching
a GUI with root is necessary for a particular usecase, and see what
needs to be done for Polkit integration.

Using kdesudo's rdepends gives us a good start:
  update-manager-kde - Runs entirely as root
  libmuonprivate1 - Used to invoke software-properties-kde
  kubuntu-desktop - Included as part of the seed
  apturl-kde - Unsure
  kubuntu-active - Included as part of the seed
  hplip-gui - Runs as root
  gdebi-kde - Runs as root, deprecated in Kubuntu w/
qapt-deb-installer as a replacement, using Polkit
  kubuntu-full - Included as part of the seed
  kubuntu-desktop - Included as part of the seed

Additionally, the usecase of saving a file in a directory the user
does not have permissions for seems to be the biggest driver for
running a GUI as root. The way to solve this would be to add a Polkit
helper in to the kfile stuff in kdelibs. I do not know how much of a
hassle this would be, as I do not know if the kfile save api is
asynchronous currently. (It would need to be, as it requires
communicating with the helper over DBus.)

This is only taking KDE software in to consideration, however. For the
issue of GTK application theming, we would have to rely on the wider
OSS community to cooperate in a shift towards Polkit for the "just use
polkit for everything" approach to work as a solution.

Anyways, file saving in KDE aside, it doesn't look like it would take
too much effort to at least kick kdesudo off the CD by default. (Or at
least remove the need for kdesudo with our default sofware set) I
think it's something we should definitely invest in.


On Sat, May 12, 2012 at 12:15 PM, Harald Sitter <apachelogger at ubuntu.com> wrote:
> lo'
>
> https://bugs.launchpad.net/ubuntu/+source/kdesudo-kde4/+bug/632503
>
> Let me quickly outline how user (kde) configuration work with kdesudo.
> They do not.
> The entire idea is that kdesudo makes applications use the target
> users home rather than the invokees. otherwise running `kdesudo kate`
> would write a config that is only writable/readable by root into the
> users home making kate when invoked the regular way unable to save
> data.
> But! KDE software also stores theming data in config files (widget
> style, fonts, colors ...) which then leads to inconsistent appearance
> of applications running using kdesudo. Incidentally enough that is why
> one is supposed to use gksu/kdesudo with gui apps ;).
>
> This is a long standing complaint with users of kdesudo and AFAIK we
> never actually discussed what we want to (not) do about it. Suppose it
> is time ;)
>
> You might be able to imagine that since the problem is caused by the
> very core idea of kdesudo working around it would be a right pain in
> the booty. In particular applications/kdelibs needs to have a runtime
> theme override (runtime being data that is already in memory, for
> example as envrionment variables). I reckon GTK3 has the very same
> thing with theme configs being stored in X11 from what I understand.
> Since I don't see Qt/KDE moving to an X11 bound way of defining the
> theme (portability and whatnot) the only way to achieve this would be
> to define other means for settings transfer (e.g. dbus) coming with
> equally invasive code changes. This however also affects kdesu and
> thus all that rubbish can be done upstream.
>
> The question is whether that is even worth thinking about.
>
> I for one do not think so, particularly since running most apps using
> kdesudo is a bad idea to begin with. Also one would have to define
> where to draw the line, because I can totally imagine people asking
> for kdesudo kate to use the settings of the user adding a whole new
> layer of problems. Should an app really need to run as root the app
> developer can probably make theme transfer work individually (e.g.
> have a host app that exports the data via dbus and invoke kdesu(do)
> from that host app, the rootified app then reads the data from dbus).
>
> Thoughts?
>
> HS
>
> --
> kubuntu-devel mailing list
> kubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel