Running GUI applications as root in BunsenLabs

johnraff · 2018-01-30 09:21:16

^yup

qcgxr · 2018-01-30 18:53:51

> File Manager as Root: drop

Oh, I vote not to drop the root FM. I don't always have Thunar open, so opening it as user in order to open it as root just add an unnecessary step. But if it's just me, I can deal with it.

Head_on_a_Stick · 2018-01-30 19:52:10

qcgxr wrote:

> File Manager as Root: drop
Oh, I vote not to drop the root FM.

johnraff's suggestion is that people who want to use thunar (our default file manager) as root can open thunar as their normal user and then right-click in the chosen directory and select "open as root" from thunar's menu.

So the plan is to shift the option from the openbox menu to thunar's internal menu.

This is because thunar is the only file manager that supplies the files needed for `pkexec` to work and so if we had a "root file manager" entry in the openbox menu then it wouldn't work if thunar was switched out for something else.

qcgxr · 2018-01-31 00:27:59

So the plan is to shift the option from the openbox menu to thunar's internal menu.
This is because thunar is the only file manager that supplies the files needed for `pkexec` to work and so if we had a "root file manager" entry in the openbox menu then it wouldn't work if thunar was switched out for something else.

Yeah, I got that. My point was that, assuming one wants to open a root instance yet does not already have Thunar open, opening Thunar first as user just in order then to open another instance as root adds several clicks and an additional window that was perhaps not needed by the user. I imagine I'm not the only one who would miss the convenience of the menu entry or the *.desktop links picked up by dmenu, rofi, etc.

But I understand if the decision is to remove them. I just wanted to give my vote.

For anyone who wants the convenience that was provided by gksudo, extending pkexec seems trivial. For instance, I copied /usr/share/polkit-1/actions/org.xfce.thunar.policy to /usr/share/polkit-1/actions/com.mate.caja.policy (the name was a guess but doesn't seem to matter) and replaced all instances of thunar with caja. This worked perfectly. Similar copy/paste efforts worked for creating org.bunsenlabs.text-editor.policy and org.bunsenlabs.file-manager.policy. As far as I can tell, the only important detail in the *.policy files is the location of the binary.

Last edited by qcgxr (2018-01-31 00:28:49)

johnraff · 2018-02-01 06:12:32

@qcgxr yes it's quite easy to add polkit policies in the way you say, or by .pkla files under /etc/polkit1/localauthority.
It would also be very easy for a user to add a menu entry or keyboard shortcut which called 'pkexec thunar'.

What we don't know at this point is whether the fact that other file managers than Thunar have not provided polkit policies is because the developers have not yet got round to it, or because the GUI is not safe to run with root permissions. The same applies to text editors.

So individuals are free (and encouraged) to set up their systems how they want, and running e.g. geany as root might well be OK, but BunsenLabs need to take a step back and not give new users the wrong idea over what is considered "safe practice".

johnraff · 2018-02-01 06:21:20

Still wavering over whether it would be fair to throw people newly arrived from Windows or Mac into a nano (still less vim) interface when they want to edit a system file. If even the keyboard shortcuts Ctrl+S and Ctrl+Q worked it wouldn't be so bad, and the useful help at the bottom of the nano screen displays Ctrl as ^.

At least we might have

# set editor used by sudoedit
#export VISUAL=bl-text-editor

in ~/.xsessionrc as a lifebelt?

johnraff · 2018-02-03 00:53:01

To summarize, what we seem to be looking at now is this:

Openbox Menu > System >
Synaptic Package Manager: pkexec synaptic
File Manager as Root: drop
Text Editor as Root: drop
Login Settings: x-terminal-emulator -e sh -c 'sudoedit /etc/lightdm/lightdm-gtk-greeter.conf; sudoedit /etc/lightdm/lightdm.conf; sleep 3'
Gparted: pkexec gparted
Edit Debian Alternatives: galternatives

Thunar's right-click context menu

Open root terminal here: drop
Open as root (directory): pkexec thunar %f
(Since this menu is specific to thunar there is no need to generalize to bl-file-manager.)
Open as root (file): x-terminal-emulator -e sh -c 'sudoedit %f; sleep 3'

bl-printing-pipemenu
Configure Printers: system-config-printer

bl-obthemes
(unused) gksudo call: ignore for now

And, my suggestion, in ~/.xsessionrc, this comment:

# set editor used by sudoedit
#export VISUAL=bl-text-editor

So people can escape from nano/vim to a GUI editor if they want.

This means the default 'edit as root' option for files in Thunar will be less user-friendly than before.

It also means that to get thunar as root you either have to open a non-root Thunar and right-click a directory "open as root", or else Alt+F2 and 'pkexec thunar'.

Is everyone able to live with this?

Head_on_a_Stick · 2018-02-03 10:15:45

The suggestions are all very "correct" and I do agree with them in principle but I think the majority of users will probably just

sudo geany $file

if they don't like the terminal editor option.

It is probably worth noting that because we are based on Debian stable it should almost never be necessary to edit system files.

johnraff · 2018-02-04 07:19:13

Head_on_a_Stick wrote:

It is probably worth noting that because we are based on Debian stable it should almost never be necessary to edit system files.

I don't know if you might want to reconsider that statement.
While our users will not have to struggle with the kind of bugs introduced by an Arch upgrade, many of the files under /etc are meant to be edited by system administrators to suit the needs of a particular setup. Things like keyboard layout, network settings, boot options come to mind for a start.

The suggestions are all very "correct" and I do agree with them in principle but I think the majority of users will probably just
sudo geany $file
if they don't like the terminal editor option.

Yes, I'm afraid of that too. Making things too locked-down will just encourage people to take shortcuts, in the same way long secure passwords get written down.

We could after all add pkexec permissions for bl-text-editor and hope for the best.
This, as /usr/share/polkit-1/actions/org.bunsenlabs.pkexec.policy, works:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/software/polkit/policyconfig-1.dtd">
<policyconfig>
  <vendor>BunsenLabs</vendor>
  <vendor_url>https://www.bunsenlabs.org/</vendor_url>

  <action id="org.bunsenlabs.pkexec.bl-text-editor">
    <description>Run BunsenLabs default text editor as root</description>
    <message>Authentication is required to run bl-text-editor as root</message>
    <icon_name>accessories-text-editor</icon_name>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_admin</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/bl-text-editor</annotate>
    <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
  </action>

</policyconfig>

The org.freedesktop.policykit.exec.allow_gui key is deprecated, but for that matter, even without having such a .policy file, this works too:

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY bl-text-editor

Just passing the DISPLAY and XAUTHORITY variables is enough.

Last edited by johnraff (2018-02-04 07:20:24)

Head_on_a_Stick · 2018-02-04 11:57:12

johnraff wrote:

Head_on_a_Stick wrote:
It is probably worth noting that because we are based on Debian stable it should almost never be necessary to edit system files.
I don't know if you might want to reconsider that statement

Not at all, the configurations to which you refer are all things that should be done by the installer anyway (or just after installation) and then left alone afterwards.

The beauty of being based on Debian stable is that we do not have to worry about updating configuration files until the next release

johnraff wrote:

even without having such a .policy file, this works too:
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY bl-text-editor
Just passing the DISPLAY and XAUTHORITY variables is enough.

I can't reproduce that here (under QEMU):

empty@virtbl:~ $ pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY bl-text-editor                                                                           
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authentication is needed to run `/usr/bin/env' as the super user
Authenticating as: empty,,, (empty)
Password: 
polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
==== AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized

This incident has been reported.
127|empty@virtbl:~ $

johnraff wrote:

We could after all add pkexec permissions for bl-text-editor and hope for the best.

I think that may be the pragmatic option here.

johnraff · 2018-02-05 02:14:41

Head_on_a_Stick wrote:

johnraff wrote:
Head_on_a_Stick wrote:
It is probably worth noting that because we are based on Debian stable it should almost never be necessary to edit system files.
I don't know if you might want to reconsider that statement
Not at all, the configurations to which you refer are all things that should be done by the installer anyway (or just after installation) and then left alone afterwards.
The beauty of being based on Debian stable is that we do not have to worry about updating configuration files until the next release

Let's not pursue this, but just let me put on record that I completely disagree with the assertion you seem to be making that normal users (well, sysadmins to be precise) should never need to edit any files outide of $HOME.

johnraff wrote:

even without having such a .policy file, this works too:
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY bl-text-editor
Just passing the DISPLAY and XAUTHORITY variables is enough.

I can't reproduce that here (under QEMU):

empty@virtbl:~ $ pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY bl-text-editor                                                                           
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authentication is needed to run `/usr/bin/env' as the super user
Authenticating as: empty,,, (empty)
Password: 
polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
==== AUTHENTICATION FAILED ===

Hmm, wonder what the problem could be there... The online documentation suggested that "allow_gui" was basically passing those two variables, and other users found that line worked.

But anyway,

johnraff wrote:
We could after all add pkexec permissions for bl-text-editor and hope for the best.
I think that may be the pragmatic option here.

Perhaps, reluctantly, we should ship that .policy file for bl-text-editor. (Did it work OK for you btw?)

If there was a huge outcry to also restore a generic "file manager as root" option, we could in theory add a similar <action> for bl-file-manager, but let's leave that for now. It could always be added later via a package upgrade.

johnraff · 2018-02-07 07:53:36

Anyway, that polkit file added to bunsen-configs 9.3.1-1.
I still have to update the Openbox and Thunar right-click menus though.

EDIT: done in bunsen-configs 9.3.2-2.

Last edited by johnraff (2018-02-07 08:16:13)

#21 2018-01-30 09:21:16

Re: Running GUI applications as root in BunsenLabs

#22 2018-01-30 18:53:51

Re: Running GUI applications as root in BunsenLabs

#23 2018-01-30 19:52:10

Re: Running GUI applications as root in BunsenLabs

#24 2018-01-31 00:27:59

Re: Running GUI applications as root in BunsenLabs

#25 2018-02-01 06:12:32

Re: Running GUI applications as root in BunsenLabs

#26 2018-02-01 06:21:20

Re: Running GUI applications as root in BunsenLabs

#27 2018-02-03 00:53:01

Re: Running GUI applications as root in BunsenLabs

#28 2018-02-03 10:15:45

Re: Running GUI applications as root in BunsenLabs

#29 2018-02-04 07:19:13

Re: Running GUI applications as root in BunsenLabs

#30 2018-02-04 11:57:12

Re: Running GUI applications as root in BunsenLabs

#31 2018-02-05 02:14:41

Re: Running GUI applications as root in BunsenLabs

#32 2018-02-07 07:53:36

Re: Running GUI applications as root in BunsenLabs

Board footer