gksu removed from the repo's of Ubuntu 18.04

[Pjotr]

Unpleasant news: gksu has been removed from the repo's of Ubuntu Bionic:
https://jeremy.bicha.net/2018/04/18/gks ... om-ubuntu/

For Mint 19, this'll also affect Synaptic, GParted, Mints Update Manager, etc. And for editing system config files, it almost feels as if we're being pushed towards abusing "sudo".

[xenopeek]

You're mistaken; this is in fact good and welcome news! It should be celebrated that Ubuntu (finally) reached this milestone.

gksu hasn't been maintained for many years and was only left to rot in the Ubuntu repository because some programs unfortunately still depended on it. Such programs have been migrating to PolKit's pkexec. Your examples of Synaptic, GParted and Update Manager all use pkexec now (if they didn't already before). PolKit allows for finer level of control than was possible with gksu. No longer does the entire program need to run as root.

In short; removing gksu doesn't meaningfully affect users of Ubuntu or Linux Mint, aside from making their systems safer.

As for editing system configuration files: aside from pkexec, gvfs now has builtin support for admin:// paths that automatically invoke PolKit as needed. So you can open Nautilus and press Ctrl+L and type the path admin:///etc/default to open the /etc/default directory with required elevated privileges. Opening a file from there with Gedit also opens that file with required elevated privileges. From the command line you can also use the admin:// paths so you could do gedit admin:///etc/default/grub to directly open /etc/default/grub for editing with Gedit. I guess that admin:// paths should also work with Linux Mint's developed software on Linux Mint 19 but I haven't tested that yet.

[Cosmo.]

Why is this a problem?

With the default menu entries in Cinnamon synaptic and gparted get called via xxx-pkexec, MintUpdate simply via mintupdate. There is no gksu in game, and how should this be used at all, as the root password is empty, in Ubuntu since ever, in Mint since 18.2?

The only thinkable need for gksu is if you want to launch a graphical program in the context of a different user account of the system, but I cannot remember having any need for this in years.

Besides that: gksu is a frontend, either for sudo or for su; this is configurable. In difference what the user might expect the used default frontend for gksu is sudo. So with the default frontend (and I assume, that very most user do not even know about this and how to change it) the "missing" gksu does not miss anything.

And for editing system config files, it almost feels as if we're being pushed towards abusing "sudo".

As far as I can see, (nearly) all helpers advice "gksudo xed file_name" (or similar) to open a system file with elevated rights. I cannot remember having read "gksu ..." since a very long time. Why should we get pushed to (ab)use sudo? If something like nano should get needed, gksu would be in any case the wrong command. So I do not see a possible abuse and the need for gksu.

[xenopeek]

gksudo comes from the gksu package. Neither gksu nor gksudo will be available on Ubuntu 18.04 and that is a good thing.

[Cosmo.]

I didn't know, that gksudo is also affected. But OK, what we need to do is to accommodate to admin:///. I can imagine, that this method is (besides enhanced safety) also more comfortable. It would be nice, if there would a way to enter this prefix via a shortcut, toolbar icon or a context menu (but with my clipboard manager I will get something similar also).

[altair4]

We don't need no stinkin' gksu.

We Linux desktop users have an understandable feeling of superiority over those poor Windows and macOS users. You can't feel superior if you are part of the majority. Removing gksu and making all of those HowTo's out there that specify it's use useless is just a way to remove the wheat from the chaff.

In your face Windows.

EDIT: Some moderator keeps changing the last sentence of my post. I keep restoring it. Rather than this deteriorate into a I know what you are but what am I kind of thing they deleted it entirely. That was probably best since the modification by the moderator wasn't the least bit funny.

[Flemur]

As for editing system configuration files: aside from pkexec, gvfs now has builtin support for admin:// paths that automatically invoke PolKit as needed.

None of the stuff you listed works for me (Xfce Mint18.3). Is it supposed to work now or not?

Code: Select all

$ gparted-pkexec
...
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.

Whether they call themselves "org.freedesktop" or "freedesktop.org", they sure crank out some nasty software:

https://bugs.debian.org/cgi-bin/bugrepo ... bug=841878

[Flemur]

I didn't know, that gksudo is also affected.

$ ls -l /usr/bin/gksudo
lrwxrwxrwx 1 root root 4 Dec 24 2014 /usr/bin/gksudo -> gksu

[chrisuk]

As for editing system configuration files: aside from pkexec, gvfs now has builtin support for admin:// paths that automatically invoke PolKit as needed.

None of the stuff you listed works for me (Xfce Mint18.3). Is it supposed to work now or not?

Code: Select all

$ gparted-pkexec
...
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.

Whether they call themselves "org.freedesktop" or "freedesktop.org", they sure crank out some nasty software:

https://bugs.debian.org/cgi-bin/bugrepo ... bug=841878

If it helps (which I'm guessing it might not), all that @xenopeek mentioned works as described on a Debian Stretch based Distro running XFCE (I'm not on anything Ubuntu-based ATM)

[Sir Charles]

The recommended way of performing operations that require elevated permissions using a GUI is by using the gvfs admin backend, which is available in both Ubuntu 18.04 LTS and 17.10, by using the admin:// prefix.
gksu Removed From Ubuntu, Here's The Recommended Replacement

(gparted-pkexec works here:LM 18.3 Xfce)

[altair4]

@Flemur,

I can reproduce that error:

tester@vmin183xfce ~ $ gparted-pkexec
==== AUTHENTICATING FOR com.ubuntu.pkexec.gparted ===
Authentication is required to run the GParted Partition Editor
Authenticating as: tester,,, (tester)
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.

I induced that error by going into Settings > Session and Startup > Application Autostart > and disabled PolicyKit Authorization Agent.

You might want to see if it was disabled somehow.

[xenopeek]

As for editing system configuration files: aside from pkexec, gvfs now has builtin support for admin:// paths that automatically invoke PolKit as needed.

None of the stuff you listed works for me (Xfce Mint18.3). Is it supposed to work now or not?

With "now" I meant Ubuntu 18.04 / Linux Mint 19, if that wasn't clear from context. I'm not sure if it should all already work on Ubuntu 16.04 / Linux Mint 18.3.

Ubuntu 18.04 / Linux Mint 19 will use Polkit, just like other distros already do, and on earlier versions of Ubuntu and Linux Mint gksu remains in use.

I meant to say many programs and distros have had PolKit support for many years. Not all programs of course; Ubuntu would have had their good reasons for not switching to PolKit earlier. Linux Mint have also done work over the last year to convert the last few programs that need elevated privileges to support PolKit.

[Flemur]

I use gksudo in my fluxbox menus and key-definitions.

This seems to work well as a replacement:

Edit: it didn't work right. See correction
$ cat bin/Gksudo

Code: Select all

#!/bin/sh
#
# Use this when gksu goes away.
#
# BZZZZT wrong: xfce4-terminal --command="sudo -H $* " --geometry=40x8
#
xfce4-terminal --command="sudo -H -i -u root bash -c '$*' " --geometry=40x8 

Tested with

Code: Select all

Gksudo thunar /path

and changed a bunch of thunar settings and still owned all my stuff in $HOME.

[altair4]

Although you mitigated the use of sudo with the -H switch it points out the issue Pjotr made in his original post:

And for editing system config files, it almost feels as if we're being pushed towards abusing "sudo".

In Ubuntu 18.04 this runs fine:

Code: Select all

sudo gedit /etc/fstab

Well ... it doesn't run fine ... it does run and I am able to edit the file but with it are the risks of using sudo this way.

[xenopeek]

Using sudo gedit /etc/fstab runs the entire gedit process as the root user, with full system wide privileges.

As noted you can do it instead with the gvfs admin:// paths:
gedit admin:///etc/fstab

Or in Nautilus press Ctrl+L and type the admin:// path and then any text file opened from there opens for editing in Gedit.

Or using sudoedit, which make a temporary copy of the file and opens the editor with that, only using elevated privileges for it moving the edited file back to original location afterwards:
EDITOR=gedit sudoedit /etc/fstab
You can put EDITOR=gedit in your ~/.bashrc for convenience so you just run: sudoedit /etc/fstab. xed on Linux Mint 18.2 and 18.3 also works well with sudoedit thanks to JosephM.

All three methods run the gedit process as yourself, not as the root user.

[JeremyB]

I just use pkexec gedit followed by the filename after using https://raw.githubusercontent.com/hotic ... dit.policy
I just copied the org.gnome.gedit.policy to /usr/share/polkit-1/actions/
I modified the file so it also worked with xed

[altair4]

Using sudo gedit /etc/fstab runs the entire gedit process as the root user, with full system wide privileges.

As noted you can do it instead with the gvfs admin:// paths:
gedit admin:///etc/fstab

Or in Nautilus press Ctrl+L and type the admin:// path and then any text file opened from there opens for editing in Gedit.

Or using sudoedit, which make a temporary copy of the file and opens the editor with that, only using elevated privileges for it moving the edited file back to original location afterwards:
EDITOR=gedit sudoedit /etc/fstab
You can put EDITOR=gedit in your ~/.bashrc for convenience so you just run: sudoedit /etc/fstab. xed on Linux Mint 18.2 and 18.3 also works well with sudoedit thanks to JosephM.

All three methods run the gedit process as yourself, not as the root user.

What part of my post did you not understand. Your entire explanation is something the new user would have to search to find. He may know sudo because he's seen it and probably used it before. That was the point of Pjotr's comment. He may know gksu because it's in many HowTo's. That ws the point of my original post.

[xenopeek]

Clearly the part you think I didn't understand, I didn't understand.

There will undoubtedly be a period of adjustment for people that use gksudo and sudo only because they saw it somewhere. Some of them will be jumping to conclusion that they should just try sudo if gksudo doesn't work. Fair assessment. Might many of them post on the forum instead, with posts like "this gksudo command I read it that topic doesn't work! what do I do now?" That should pass by quickly though.

The above are alternative methods for command line users. Perhaps there should be an alias for gksudo / gksu that informs the user that is no longer supported. GUI users can continue to use the existing options in file managers for opening files in system directories for editing.

[Pjotr]

gedit admin:///etc/default/grub works fine in Ubuntu Bionic, but in Xubuntu Bionic mousepad admin:///etc/default/grub doesn't (yet?).... I still haven't tested Lubuntu.

My main concern is indeed this period of upheaval and the many problems with existing how-to's that contain gksudo. It would certainly be a great help if gksudo would generate a warning, preferably with an instruction for an alternative. Otherwise, I'm afraid a massive abuse of sudo will occur....

[kukamuumuka]

gedit admin:///etc/default/grub works fine in Ubuntu Bionic, but in Xubuntu Bionic mousepad admin:///etc/default/grub doesn't.... I haven't tested Lubuntu yet.

How about xdg-open admin:///etc/default/grub ?