XFCE's use of depricated gksu

CwF · 2018-12-07 15:20:55

I migrated a debian stable stretch to buster. With the deprication gksu there is no available package in buster. So I managed to keep the prior gksu from stretch, but there are issues with this.

Prior I did not have policykit-1-gnome, installing this fixed starting gparted from xfce's default menu. A user created menu for thunar was formerly gksu, and revised to "pkexec thunar %F" works fine. Maintaing the gksu package also works, but I'm trying to eliminate gksu, so...

The default xfce menu for Root Terminal uses gksu and does work if gksu is retained, however the $PATH is the user and not roots. So far pkexec does not work for any terminals.

I'm at a loss on what to add to create a working root terminal using policykit (pkexec). As stated gparted and thunar do work after installing policykit-1-gnome yet both had policy files in /usr/share/polkit-1/actions/ prior to its install yet did not work. So I'm hesitating to try and create a policy for one of the terminal options without knowing what additional changes the -gnome package did. It would be nice if there was a policykit1-xfce or xfce-pollkit package for this?

I need to iron out my understanding of this and get the default xfce gksu uses eliminated before I start revising a dozen user scripts I have using gksu.

I realize this is a general issue first, debian buster issue second, but I'm starting with xfce questions since it appears xfce is still using gksu.

Ideas?

ToZ · 2018-12-07 16:26:36

CwF wrote:

The default xfce menu for Root Terminal uses gksu..

Actually, this isn't something that the Xfce project ships. It must be something that the distro adds. And as such, the fix would need to come from the distro.

That being said, to get pkexec to open a root terminal, create the following org.xfce.xfce4-terminal.policy file (usually in /usr/share/polkit-1/actions):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>
 
 
 
 <vendor>xfce4-terminal</vendor>
 <vendor_url>http://xfce.org/</vendor_url>
 <icon_name>utilities-terminal</icon_name>
 
 
 <action id="org.xfce.xfce4-terminal">
 
 <description>Run xfce4-terminal as root</description>
 <message>Authentication is required to run xfce4-terminal as root.</message>
 <defaults>
 <allow_any>no</allow_any>
 <allow_inactive>auth_admin</allow_inactive>
 <allow_active>auth_admin</allow_active>
 </defaults>
 <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/xfce4-terminal</annotate>
 <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
 </action>
 
</policyconfig>

The effect should be immediate. Change the menu entry and/or custom action to run "pkexec xfce4-terminal" instead of "gksu xfce4-terminal".

CwF · 2018-12-07 18:27:13

Once again, much appreciated!

golinux · 2018-12-12 17:21:30

@ToZ . . . you just answered my next question. Will try it later today. Thanks again.

golinux · 2018-12-14 06:21:02

@ToZ . . . yes, this works. Thank you. Now trying to figure out how to adapt that principle to launch a text editor as root (either mousepad or leafpad). Have plucked some examples here and there and will start experimenting tomorrow.

CwF · 2018-12-15 00:12:45

So far I've modified:
com.ubuntu.pkexec.gdebi
com.ubuntu.pkexec.synaptic
org.gnome.gparted
org.xfce.thunar
and the mentioned terminal policies

<allow_any>no</allow_any>
<allow_inactive>auth_admin</allow_inactive> foreign, ssh, vnc, etc (not vm hook)
<allow_active>yes</allow_active> no password with local kbm or vm spice

I have a vm with no,no,yes to see if I hit a snag.

Generally I think this is ok for a physically secure single user. As I dig in I'm finding no solid substitute for gksu. I use it in a few scripts that are not 'gui' apps, but buttons and launchers and have no idea what to use. I suppose better thought out groups might solve it, but years ago gksu worked and I haven't looked back, now I will have to.

For things like editing a root file, I'm in the habit of using the root thunar to navigate to the file. Opening it from there inherits root in whatever configured editor.

golinux · 2018-12-15 05:28:03

Thanks for your response.

CwF wrote:

So far I've modified:
com.ubuntu.pkexec.gdebi
com.ubuntu.pkexec.synaptic
org.gnome.gparted
org.xfce.thunar

I hadn't noticed that gparted wasn't under the system menu. More work to do. Not necessarily for the VM but for when I install to metal where it will definitely be needed.

and the mentioned terminal policies
<allow_any>no</allow_any>
<allow_inactive>auth_admin</allow_inactive> foreign, ssh, vnc, etc (not vm hook)
<allow_active>yes</allow_active> no password with local kbm or vm spice

I still don't totally understand the template for creating one of these files. But then I haven't tried very hard!

. . . I'm finding no solid substitute for gksu. I use >>>it<<< in a few scripts that are not 'gui' apps, but buttons and launchers and have no idea what to use.

I'm not understanding what >>>it<<<< refers to here. I have pkexec working in panel launchers and Thunar custom actions. Only one left is for leafpad.

For things like editing a root file, I'm in the habit of using the root thunar to navigate to the file. Opening it from there inherits root in whatever configured editor.

Yes, that is the way that I'm doing it now. But sometimes I want to alter just one file and mounting an entire directory to tweak one file seems a bit overkill.

CwF · 2018-12-15 15:27:50

Sorry, 'it' was in the context of gksu. I have a launcher that has a dozen items arranged in all text to pop up from the carrot (little arrow) and every one uses gksu. The 'button' with label domU calls virt-viewer, giving a dialog to pick any running vm, then each text line (each a launcher) that expands from the carrot is either a guestmount or virsh attach-disk command. All that needs gksu. I use Verve also for similar things also needing gksu. I think I ask here before how to give a launcher or verve permissions but we can't is (was) the answer. I think it makes sense, but a root verve would be nice.

So I'm unclear what to use in place of gksu. I've seen advice to use pkexec and create a 'gksu' alias to create the 'environment' and I can't get it to work. I've seen a few methods of using yad or zenity that calls su and will give a dialog for the password, I didn't even try that since it's extra dependencies that could (will) change, again.

I mentioned group permissions, or the power of the user 'dom0', I'm defaulting to not modifying that. So I'm left only a day ahead of you in still trying to figure out writing pkexec policies...? One for virt-viewer might be easy, guestmount maybe similar but can vary, and virsh a similar example in that the command is not what needs root, but the file it calls does.

And I aired this out knowing this is now off topic not an xfce issue!

golinux · 2018-12-15 16:24:12

I feel your pain. And many others will too. Fortunately, my usecase is much less complicated than yours. Unfortunately, I will be of no use to help you solve your issues. Thanks heavens for ToZ and others on this forum who are always so very helpful.

It's going to be trial and error for me. I'll start with org.lxde.leafpad and appropriate "leafpad" substitutions and see what explodes. LOL!

CwF · 2018-12-17 19:14:24

CwF wrote:

So I'm unclear what to use in place of gksu.... virt-viewer .., guestmount !

Ok then, gksu is purged from the system!
I made a mistake! Coming in late, I thought gksu was a good way to do things. I never knew it was a crutch. So after learning the real ways of things, after slapping myself for not knowing, now a pat on the back for knowing. Better yet, what used to be references to "gksu doit.sh" files in the command line of the launchers is now a single line. Much much cleaner. Even polkit is superfluous in this case.

Adding the URI to the virt/virsh commands solved those misuses of gksu.
Proper sudoers configuration for guestmount use by dom0 solved those, misuses.

Xfce Forum

Sub domains

#1 2018-12-07 15:20:55

XFCE's use of depricated gksu

#2 2018-12-07 16:26:36

Re: XFCE's use of depricated gksu

#3 2018-12-07 18:27:13

Re: XFCE's use of depricated gksu

#4 2018-12-12 17:21:30

Re: XFCE's use of depricated gksu

#5 2018-12-14 06:21:02

Re: XFCE's use of depricated gksu

#6 2018-12-15 00:12:45

Re: XFCE's use of depricated gksu

#7 2018-12-15 05:28:03

Re: XFCE's use of depricated gksu

#8 2018-12-15 15:27:50

Re: XFCE's use of depricated gksu

#9 2018-12-15 16:24:12

Re: XFCE's use of depricated gksu

#10 2018-12-17 19:14:24

Re: XFCE's use of depricated gksu

Board footer