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 <[email protected]> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
