Running GUI applications as root in BunsenLabs

Head_on_a_Stick · 2017-12-10 16:36:58

Alternative thread title:

I got 99 problems but `pkexec` ain't one

Background: see https://forums.bunsenlabs.org/viewtopic … 184#p65184

There are three possible ways of running GUI ("point-and-click") applications as root in the BunsenLabs destop:

The good: `pkexec foo`
The bad: `gksu foo`
The ugly: `sudo foo`

The third method is absolutely contraindicated and should never be used because of the fundamentally insecure nature of the X server: `sudo` is intended for the command-line and so confers too many privileges on any program that is started under it's aegis.

The second method is what we actually use in the BunsenLabs menu for the official release but the `gksu` command is now considered obsolete[1] and suffers in a similar, albeit reduced, way to the `sudo` alternative.

The first method is the "approved" technique: it is what is employed in synaptic & gparted's .desktop files and so clearly has Debian's official support.

However, johnraff has noted that:

johnraff wrote:

'pkexec lxappearance' fails

[ibid.]

This is because gparted and synaptic both have specific allowances in the form of /usr/share/polkit-1/actions/com.ubuntu.pkexec.{gparted,synaptic}.policy

So if we wanted to allow other applications to run as root then they will also need matching .policy files.

For the record, I think this would be a bad idea.

I do not think we should encourage running GUI applications as root and I would prefer that only gparted & synaptic are "allowed" to do that.

Furthermore, the "root file manager" and "root terminal" menu options are carbuncles in need of excision (IMO).

Does anybody have any other thoughts on this matter?

Any and all debate is welcomed

[1] https://bugs.debian.org/cgi-bin/bugrepo … bug=867236

Head_on_a_Stick · 2017-12-10 17:55:31

Also:

johnraff wrote:

That raises the related case of how to set root's graphic theming, hence the need for lxappearance to work as root sometimes.

Sorry to sound like a broken record here but again: I _do not_ agree that users should be able to easily set root's GUI preferences.

However, if that is what is wanted then I would recommend this method instead:

# GTK2:
sudo cp ~/.gtkrc-2.0 /root
sudoedit /root/.gtkrc-2.0

# GTK3:
sudo mkdir -p /root/.config/gtk-3.0
sudo cp ~/.config/gtk-3.0/settings.ini /root/.config/gtk-3.0
sudoedit /root/.config/gtk-3.0/settings.ini

With this for the "root terminal":

sudo -i

And this for "root file manager":

sudo ranger # not much safer though — commando line ftw!

johnraff · 2017-12-11 06:28:42

Thank you for raising this!

There are a number of things mixed in here, on several of which I have comments to make
(not all disagreeable by any means ).
There is scope for getting some useful changes in before the Helium release, I think.

But I'll wait a bit to see what our other members have to say...

Steve · 2017-12-11 07:23:46

How often would one use GUI as root though?, i suppose it depends on what people are doing. I only ever use a gui as root for gparted and a handful of times for lightdm greeter settings. I have in the past used file manager as root but have since learned to just use the terminal to work in root and also use terminal programs like cfdisk - gdisk etc, but that is my preference and i suppose others prefer GUI.

unklar · 2017-12-11 10:34:54

Head_on_a_stick wrote:

I do not think we should encourage running GUI applications as root and I would prefer that only gparted & synaptic are "allowed" to do that.

+1 on my part

I am an advocate of two passwords of the system. One for the user and one for root. That's what I learned.
That's why I consider it sufficient to use the package management and the disk management (GUI) with it (sudo ).

hhh · 2018-01-25 20:26:37

I frequently open Thunar as root. I don't use the right-click menu though, I use a run dialog and enter 'gksu thunar'. pkexec thunar works also, so all is well.

johnraff · 2018-01-28 09:45:31

OK let's get this moving...

First up: gksu is out! We can all agree on that - it's obsolete, unsafe and will likely disappear from Debian before long.

pkexec is OK, but, without editing or adding policykit files, only gparted, synaptic and thunar can be thus launched with root permissions. I think we can follow HoaS's advice not to extend that list, while keeping reasonable usability.

There are two places in the BunsenLabs GUI where "launch as root" options appear (using gksu/gksudo atm):
1) The openbox menu
2) Thunar's right-click menu

john@bunsen1:/data/john/git/bunsen/bunsen-configs$ grep -Eri '(gksu|gksudo)' .
./skel/.config/openbox/menu.xml:                        gksudo synaptic
./skel/.config/openbox/menu.xml:                        gksudo bl-file-manager
./skel/.config/openbox/menu.xml:                        gksudo bl-text-editor
./skel/.config/openbox/menu.xml:                        gksudo bl-text-editor /etc/lightdm/lightdm-gtk-greeter.conf /etc/lightdm/lightdm.conf
./skel/.config/openbox/menu.xml:                        gksudo gparted
./skel/.config/openbox/menu.xml:                        gksudo galternatives
./skel/.config/Thunar/uca.xml:    <icon>gksu-root-terminal</icon>
./skel/.config/Thunar/uca.xml:    <command>sh -c &apos;cd %f;gksudo x-terminal-emulator&apos;</command>
./skel/.config/Thunar/uca.xml:    <command>gksudo &quot;bl-file-manager %f&quot;</command>
./skel/.config/Thunar/uca.xml:    <command>gksudo &quot;bl-text-editor %f&quot;</command>

So, in the OB menu, we have:
gksudo synaptic
gksudo gparted
gksudo bl-file-manager
gksudo galternatives
gksudo bl-text-editor
gksudo bl-text-editor /etc/lightdm/lightdm-gtk-greeter.conf /etc/lightdm/lightdm.conf
(There is no "root terminal" entry in the menu btw.)

gksudo synaptic/gparted can be replaced with pkexec synaptic/gparted

While pkexec thunar works, the generic pkexec bl-file-manager will not (unless we configure polkit so).
The problem comes when people change bl-file-manager to something other than thunar: pkexec will probably not work.
I would go with HoaS's suggestion to remove the entry, but I do think that file-manager-as-root is more convenient for many people than using a terminal, and for clumsy typists less error-prone. (There is more to safety than defense against malevolent hackers!) What can we offer non-thunar users? Maybe it will have to be on a case-by-case basis, depending on what file manager they chose, and what alternative options it might offer.

galternatives does not need gksu: if launched as a normal user it opens its own password window to gain root powers. Let's just assume it's been done in a secure way.

OK finally text editor as root. I've tried sudoedit per HoaS's advice, and yes it works, but just like sudo it needs to be launched from a terminal in order to enter the password. This won't work from a menu, unless a terminal is first launched. (gmrun is a good way to test if a menu entry will work.) For GUI editor users, this works, though opening a terminal just to enter the password feels clunky:

x-terminal-emulator -e sh -c 'VISUAL=bl-text-editor sudoedit /etc/apt/sources.list; sleep 3'

The generic "text editor as root" entry was a recent addition and could just go. I personally found it convenient because geany will remember the recently opened files and save me the remembering and typing of long filepaths. I can set it up for myself though...
btw should we set one of the environment variables SUDO_EDITOR, VISUAL, EDITOR somewhere (system? user config?)? Or just in the command itself, as above?

--------------------------------------------------------------------
Now, the thunar right-click menu:
cd %f; gksudo x-terminal-emulator
gksudo bl-file-manager %f
gksudo "bl-text-editor %f

...out of time: tomorrow.

Head_on_a_Stick · 2018-01-28 14:00:19

johnraff wrote:

I do think that file-manager-as-root is more convenient for many people than using a terminal, and for clumsy typists less error-prone. (There is more to safety than defense against malevolent hackers!)

I'm not sure I agree with that analysis, see this (highly amusing) post by @GarryRicketson over at fdn for a counter-argument:

http://forums.debian.net/viewtopic.php?p=664692#p664692

[joke]Is BunsenLabs currently parrot-proof? 8o[/joke]

But seriously, both pcmanfm & spacefm don't have any .pkla files shipped with them so presumably the developers (or maintainers) don't want them to be run as root.

I suppose we could have a "thunar as root" entry that is removed if thunar isn't bl-file-manager, is that feasible?

johnraff wrote:

should we set one of the environment variables SUDO_EDITOR, VISUAL, EDITOR somewhere (system? user config?)?

No, I don't think so.

Our stock desktop uses the alternatives system rather than VISUAL, PAGER, BROWSER or whatever so I think we should leave those unset.

johnraff wrote:

(There is no "root terminal" entry in the menu btw.)

No there is not, I don't know why I thought there was

This works though:

<item label="Terminal as root"><action name="Execute"><command>x-terminal-emulator -e sudo -i</command></action></item>

Single-line xml stanzas ftw! 8o

Head_on_a_Stick · 2018-01-28 21:17:35

Also:

johnraff wrote:

x-terminal-emulator -e sh -c 'VISUAL=bl-text-editor sudoedit /etc/apt/sources.list; sleep 3'

To edit the sources I would recommend the `apt` command:

x-terminal-emulator -e sh -c 'sudo apt edit-sources'

Do we really need a "root editor" menu entry?

If we don't have one then newcomers to GNU/Linux will probably just use

sudo bl-text-editor $file

instead, which isn't ideal.

EDIT: system files can be edited with geany if thunar is run as root and used to open the files.

Last edited by Head_on_a_Stick (2018-01-28 21:22:17)

martix · 2018-01-28 21:27:15

Head_on_a_Stick wrote:

johnraff wrote:
I do think that file-manager-as-root is more convenient for many people than using a terminal, and for clumsy typists less error-prone. (There is more to safety than defense against malevolent hackers!)
I'm not sure I agree with that analysis

Well, I use file manager as root sometimes and for me it's surely more convenient than the command line for certain tasks. In this case I simply start the file manager from terminal. I noticed lately though that I use the command line much more often than two-three years ago. The more I use it, the more I like it.

johnraff · 2018-01-29 04:40:42

martix wrote:

I noticed lately though that I use the command line much more often than two-three years ago. The more I use it, the more I like it.

This is the case for most users I think. But I don't think we should be forcing new BL users to the terminal before they're ready, if there is a reasonable alternative.

johnraff · 2018-01-29 05:35:51

Head_on_a_Stick wrote:

johnraff wrote:
I do think that file-manager-as-root is more convenient for many people than using a terminal, and for clumsy typists less error-prone. (There is more to safety than defense against malevolent hackers!)
I'm not sure I agree with that analysis, see this (highly amusing) post by @GarryRicketson over at fdn for a counter-argument:
http://forums.debian.net/viewtopic.php?p=664692#p664692

Sorry, but I can't take too seriously the opinions of someone who posts:

debian forum member wrote:

GUI's are terrible

That attitude doesn't get you anywhere.

And not everyone using Linux "wants to learn to administer a Unix server, or Unix like server" - some people just prefer to do their work on a decent OS.

Last edited by johnraff (2018-01-29 05:38:30)

brontosaurusrex · 2018-01-29 06:44:29

At the end of the day they are the same thing (gui and cli) , that is telling the computer (over a specific abstraction layer) what to do.

johnraff · 2018-01-29 06:51:05

file-manager-as-root
I have no problem removing that from the main menu. (I thought I was saying that above, really, just with some regrets for non-Thunar users.) Personally, I never just open an FM as root right off: I navigate to the place I'm interested in as a normal user, and then if I want a root FM I use Thunar's right-click "Open as root" on a certain directory.

Of course, once you've opened an FM as root, you can then navigate anywhere you want, and open any file for editing as root, for that matter...

terminal-emulator-as-root
On reflection, I don't think there's ever any time when this is more convenient than just "open terminal here" followed by using sudo as needed! Let's take it out.

text-editor-as-root
This might be the trickiest one.

Head_on_a_Stick wrote:

johnraff wrote:
x-terminal-emulator -e sh -c 'VISUAL=bl-text-editor sudoedit /etc/apt/sources.list; sleep 3'
To edit the sources I would recommend the `apt` command:
x-terminal-emulator -e sh -c 'sudo apt edit-sources'

That was just meant as an example.
sources.list was the first system file that came to mind.
But,

If we don't have [a "root editor" menu entry] then newcomers to GNU/Linux will probably just use
'sudo bl-text-editor $file' instead, which isn't ideal.
EDIT: system files can be edited with geany if thunar is run as root and used to open the files.

Indeed they can - I was just thinking about that. How secure would 'pkexec thunar ...invoking... geany' be? Possibly better than 'sudo bl-text-editor'?
Your suggestion of sudoedit sounds a bit safer to be honest, and if such an entry was available in Thunar's right-click menu as "edit this file as root" then perhaps fewer people would resort to the nastier hacks...

Head_on_a_Stick wrote:

johnraff wrote:
should we set one of the environment variables SUDO_EDITOR, VISUAL, EDITOR somewhere?
No, I don't think so. Our stock desktop uses the alternatives system rather than VISUAL, PAGER, BROWSER or whatever so I think we should leave those unset.

man sudoedit wrote:

The editor specified by the policy is run to edit the temporary
files. The sudoers policy uses the SUDO_EDITOR, VISUAL and
EDITOR environment variables (in that order). If none of
SUDO_EDITOR, VISUAL or EDITOR are set, the first program listed
in the editor sudoers(5) option is used.

When I tried it without setting an envvar I got nano, which is my alternative setting for "editor".
While I'm OK with nano in a terminal if necessary, sudoedit would then offer no advantage over 'sudo nano', at least on a trusted-users system. The 'editor' alternative has to be a terminal app, no?

Setting VISUAL to bl-text-editor does allow sudoedit to use geany (or whatever). We could, for example, set it in ~/.xsessionrc where it would be ignored in non-X sessions, and could still be overruled by SUDO_EDITOR, or edited by the user.

[RANT]Anyway, I'm sorry, but I want my GUI EDITOR. I don't care what you geeks say, I want my familiar syntax highlighting, file history, the whole interface that I've learned. And I'm not going to learn VIM or EMACS. They're just too powerful, complex and alien to my needs. I'm not going to devote months of my life to learn keyboard combinations that I might use twice a year. Anyway, I hate typing. When I went to college, typing was something you learned if you wanted to become a secretary. It wasn't for scientists or engineers. I've speeded up a little bit, but I still can't type without looking at the keyboard. Point and click is much faster for me in some situations, and I want to have that option available too. I fondly imagine there might be other BunsenLabs users who don't want to live in a keyboard+console world all the time. If that's not the case, then maybe the whole system needs a radical rethink, and I might not have much more to offer...[/RANT]

johnraff · 2018-01-29 07:19:40

Found a couple more places where gksu is used:

bunsen-pipemenus/bin/bl-printing-pipemenu: menuItem 'Configure Printers' 'gksudo system-config-printer'
bunsen-utilities/bin/bl-obthemes: gksudo -m "$TXT" "$CMD"

I'm not sure if system-config-printer needs to be run as root at all. The .desktop file just uses the plain command, and I've not had any trouble getting my own printer to work. (I'm not even in the lpadmin group, which I thought might be needed.) Anyway, let's just drop that gksudo and see if we get any complaints!

blobthemes: That gksu call is used to get root permission to overwrite a system file (lightdm greeter). That particular option is disabled at the moment anyway, but the generic case - of opening an X window for password input so that a script running without a controlling terminal can perform system tasks - still remains. Maybe pkexec can be persuaded to perform this function?

Head_on_a_Stick · 2018-01-29 08:11:56

johnraff wrote:

terminal-emulator-as-root
On reflection, I don't think there's ever any time when this is more convenient than just "open terminal here" followed by using sudo as needed!

Well, that would depend on users being aware that a "true" root shell needs either

sudo su -

or (more succinctly)

sudo -i

And there is also the fancy new machinectl(1) option:

<command>x-terminal-emulator -e machinectl shell</command>

machinectl(1) wrote:

When using the shell command without arguments, (thus invoking the executed shell or command on the local host), it is in many ways similar to a su(1) session, but, unlike su, completely isolates the new session from the originating session, so that it shares no process or session properties, and is in a clean and well-defined state. It will be tracked in a new utmp, login, audit, security and keyring session, and will not inherit any environment variables or resource limits, among other properties.

https://manpages.debian.org/stretch/sys … e_Commands

All three are better than `sudo su`, which is what most will use to effect a root shell.

But yes, there is no pressing "need" for a root terminal menu option and I agree that we can leave that out.

johnraff wrote:

Head_on_a_Stick wrote:
system files can be edited with geany if thunar is run as root and used to open the files.
Indeed they can - I was just thinking about that. How secure would 'pkexec thunar ...invoking... geany' be?

I was looking at that last night and geany is opened as root (with the Raleigh theme applied) but I was unable to determine how

johnraff wrote:

better than 'sudo bl-text-editor'?

Yes, I think so.

johnraff wrote:

Setting VISUAL to bl-text-editor does allow sudoedit to use geany (or whatever). We could, for example, set it in ~/.xsessionrc where it would be ignored in non-X sessions, and could still be overruled by SUDO_EDITOR, or edited by the user.

OK, sounds good.

I will test in QEMU later...

johnraff wrote:

[RANT][/RANT]

Yes, I quite agree — BunsenLabs needs to strike a balance here and we need to accommodate those who prefer GUIs just as much as those who prefer the command-line.

Please continue to "fight the corner" for the GUI fans, I think everybody knows where my preferences lie ]:D

tknomanzr · 2018-01-29 18:13:17

^ Which brings us back to what I think our design philosophy should be for Bunsenlabs and to hopefully alleviate the concerns of those who feel like we are pushing into a desktop/de direction.

My philosophy and vision for Bunsenlabs have always been to build great CLI tools, THEN if we feel like they need a GUI, write a GUI around the tool. Avoid massive dependency chains as much as possible and keep stuff lightweight and modular. I would not want a user to ever feel like they are being forced into a way of doing things. While I encourage anyone who wants to use Linux to learn the terminal (mostly because terminal skills are highly transferable from one distro to another), I also remember a time when I was absolutely dependent on Synaptic to install stuff, etc.

I know, slightly OT but I wanted to reiterate it.

johnraff · 2018-01-30 02:16:57

tknomanzr wrote:

Avoid massive dependency chains as much as possible and keep stuff lightweight and modular.

Definitely! One of our goals is that people can cherry-pick BL packages if they don't want the whole thing.

I would not want a user to ever feel like they are being forced into a way of doing things.

This too. CrunchBang featured "tweakability" and I think we all want to continue that tradition here.

johnraff · 2018-01-30 04:46:56

This is an important topic, and it looks to me that we can end up with a better user interface as a result of the discussion.

So, to condense it all a bit, how would this be?

Install leafpad (small install, reason explained below).
In ~/.xsessionrc: 'export VISUAL=leafpad'

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

why leafpad?

sudoedit's procedure - copy sysfile to userspace, edit as user, overwrite sysfile - does seem safer than invoking an arbitary X app as root. However, while it looks like the best option atm, it's not 100% user-friendly.
With VISUAL=bl-text-editor the default editor will be geany, which has some issues:
*) Sometimes it reports the tmp file it should be editing as "missing", and the terminal window has already closed. I don't know what's happening here, but if you call the above menu item a second time it works OK.
*) Geany does tabs, so if two files are called 'sudoedit file1 file2' ( as in the Login Settings menu item ) then they'll both be opened. Unfortunately, sudoedit won't finish its work till geany is closed, so if it is already running with other open tabs then everything has to be closed.

Three options (#2 chosen for now):

EDIT: Considering how easy it is to open bl-file-manager bl-text-editor as root via thunar, I'm now leaning towards option 1) as maybe being a bit "cleaner"?

1) Leave VISUAL unset, so sudoedit would use whatever had been chosen as 'editor': nano for some, vim for others. That works fine, but some new users might not enjoy having to edit files in a terminal editor.

2) Set VISUAL=leafpad; leafpad will only open one file at a time. 'sudoedit this_file that_file' doesn't work though. It should, according to 'man sudoedit', and works with nano too - the files are dealt with one at a time. Anyway, leafpad skips the first file and displays only the second. A workaround is to call sudoedit separately for each file, which is what I did above.

3) Set VISUAL=bl-text-editor and just accept geany's quirks.

The final 'sleep 3' in the sudoedit lines is to display any messages in the terminal before closing.

So leafpad is a somewhat unsatisfactory compromise between nano and geany. This all feels a bit hacky, and Thunar users still have the option of opening a root window and double-clicking any file: whatever app is chosen by the file associations mechanism will be launched as root.

Last edited by johnraff (2018-02-01 06:01:12)

Head_on_a_Stick · 2018-01-30 09:15:45

johnraff wrote:

Considering how easy it is to open bl-file-manager bl-text-editor (sorry, jr) as root via thunar, I'm now leaning towards option 1) as maybe being a bit "cleaner"?

Yes, I agree, option number 1 would be my preference.

johnraff wrote:

Thunar users still have the option of opening a root window and double-clicking any file: whatever app is chosen by the file associations mechanism will be launched as root

Well, we have to draw a line somewhere, remember the old saying:

Doug Gwyn wrote:

Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.

Ultimately, all we can do is offer the best guidance and hope the user follows it 8)

Last edited by johnraff (2018-02-01 06:03:39)

#1 2017-12-10 16:36:58

Running GUI applications as root in BunsenLabs

I got 99 problems but `pkexec` ain't one

#2 2017-12-10 17:55:31

Re: Running GUI applications as root in BunsenLabs

#3 2017-12-11 06:28:42

Re: Running GUI applications as root in BunsenLabs

#4 2017-12-11 07:23:46

Re: Running GUI applications as root in BunsenLabs

#5 2017-12-11 10:34:54

Re: Running GUI applications as root in BunsenLabs

#6 2018-01-25 20:26:37

Re: Running GUI applications as root in BunsenLabs

#7 2018-01-28 09:45:31

Re: Running GUI applications as root in BunsenLabs

#8 2018-01-28 14:00:19

Re: Running GUI applications as root in BunsenLabs

#9 2018-01-28 21:17:35

Re: Running GUI applications as root in BunsenLabs

#10 2018-01-28 21:27:15

Re: Running GUI applications as root in BunsenLabs

#11 2018-01-29 04:40:42

Re: Running GUI applications as root in BunsenLabs

#12 2018-01-29 05:35:51

Re: Running GUI applications as root in BunsenLabs

#13 2018-01-29 06:44:29

Re: Running GUI applications as root in BunsenLabs

#14 2018-01-29 06:51:05

Re: Running GUI applications as root in BunsenLabs

#15 2018-01-29 07:19:40

Re: Running GUI applications as root in BunsenLabs

#16 2018-01-29 08:11:56

Re: Running GUI applications as root in BunsenLabs

#17 2018-01-29 18:13:17

Re: Running GUI applications as root in BunsenLabs

#18 2018-01-30 02:16:57

Re: Running GUI applications as root in BunsenLabs

#19 2018-01-30 04:46:56

Re: Running GUI applications as root in BunsenLabs

#20 2018-01-30 09:15:45

Re: Running GUI applications as root in BunsenLabs

Board footer