gksu removed from the repo's of Ubuntu 18.04

[Pjotr]

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 ?

That works partly and with hiccups (three or four times I had to enter my password).... And it launches Libre Office Writer instead of Mousepad.

Edit: if I install Gedit first in Xubuntu, then it does work with Gedit. Apparently Mousepad (and Leafpad) need adjustments....

[Flemur]

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

I get a popup telling me that firefox is already running.

running.jpg

[altair4]

I betcha this will work though :

Code: Select all

sudo nano /etc/default/grub

[Pjotr]

Gedit appears to be the key.... If I install Gedit in Xubuntu 18.04 Bionic, I can use Gedit exactly like in Ubuntu 18.04 Bionic:

Code: Select all

sudo apt-get install gedit

Code: Select all

gedit admin:///etc/default/grub

Works fine, but we need gksu/gksudo to trigger a warning.... That'll decrease the confusion.

[xenopeek]

With gedit, pluma and xed the admin:// paths work on Ubuntu 18.04. All editions of Linux Mint 19 use xed.

mousepad likely doesn't have gvfs support? Try frowning real hard at it

In any case, this is just one of the ways to open system configration files for editing from the terminal. For example EDITOR=mousepad sudoedit /etc/fstab works perfectly. Add EDITOR=mousepad to ~/.bashrc and it is just sudoedit /etc/fstab. It's even shorter to type than gksudo mousepad /etc/fstab

[Cosmo.]

Some of them will be jumping to conclusion that they should just try sudo if gksudo doesn't work.

I do not follow this objection. We see wrong usage of sudo since years. We even see advices, where hardly more than the wrong usage is presented. This all on systems, where gksudo is available. And we will see the wrong usage also in the future -- with and without the change.

An alias for gksu)do would surely help to prevent countless complaints, that the new system is allegedly broken.

[Portreve]

I've never personally used gksudo or any of its related components. On any system I've ever run, it's either been (for the most part) sudo, or on a few distros log in as root and do tasks that way.

Honestly, gksudo and a number of other little things are the kind of stuff I've really never understood why people use. Another example is leafpad. Any time I have to modify anything, it's always been "sudo nano ..." and when I've asked around, it's like people think you have to have all kinds of claptrap set up just to do this simple stuff, or basic command line-level maintenance.

[Flemur]

Honestly, gksudo and a number of other little things are the kind of stuff I've really never understood why people use.

Like I said above, I use gksudo to launch gparted and synaptic from my fluxbox keyboard shortcuts. It's just an easy way.

But for editing system text files:

Code: Select all

sudo vi file

[Voltron]

This raises a question. Now, when I use Backups (deja-dup) to backup all users' home directories on a system, via "gksudo deja-dup-preferences," I get prompted for the admin/root password. And, after typing that in, I can backup all users' home directories, graphically. In Ubuntu 18.04, how will I modify the Backups (deja-dup) launcher, to accomplish this same thing?

[xenopeek]

Isn't it that by default users have read access to each other's home directories? Shouldn't need to run the backup program as root with write access to your entire operating system for that. Or you could add their groups to your account so you have full access. Or see if Deja Dup supports pkexec or otherwise add a rule like was done above for gedit. The Deja Dup developers would likely add something like that to support this case, if they haven't already.

[Cosmo.]

Shouldn't need to run the backup program as root with write access to your entire operating system for that.

For home I agree. But there are also other cases. With Back in Time you can for example backup things, which belong to root; this is especially of interest for contents of /etc. BiT needs write access for the backed up folders, otherwise it cannot restore a backup. BiT creates for this purpose a second launch entry in the menu for running it as root. - Saying that: BiT doesn't seem to be affected by this change, as it uses polkit to run the program as root. But for other backup programs this can possibly be a problem.

[xenopeek]

But for other backup programs this can possibly be a problem

Taking a quick look at Deja Dup on Ubuntu 18.04 you can see it depends on polkit and indeed has a policy file for restoring files to system locations. I seriously doubt this is going to be an issue for any backup program that is actively maintained. Like I said before, polkit has been around for many years and many programs were already supporting it even if the Debian and Ubuntu didn't fully integrate it yet.

[Cosmo.]

I did not look at Deja Dup, as I have no need for a second backup solution. But after your examination we can now say, that at least those 2 programs give no problem. Leaves perhaps LuckyBackup, which is AFAIK not more actively developed. But I do not think, that any abandoned software is a valid argument against the change.

[Penn]

all use pkexec now

Maybe I missed something in this thread but why can't pkexec be used in place of gksudo or gksu? Such as

Code: Select all

pkexec xed /path/to/file

Also, I thought "gksu" changes permissions the same way "sudo" does but "gksudo" doesn't?

[altair4]

Also, I thought "gksu" changes permissions the same way "sudo" does but "gksudo" doesn't?

One is a symbolic link to the other:

ls -al /usr/bin/gksudo
lrwxrwxrwx 1 root root 4 Oct 2 2012 /usr/bin/gksudo -> gksu

And no it does not - did not - change permissions the way sudo does - um - I mean did:

tester@gort:~$ gksu -d gedit /etc/fstab
No ask_pass set, using default!
xauth: /tmp/libgksu-lpzlnM/.Xauthority
STARTUP_ID: gksu/gedit '|etc|fstab'/702-0-gort_TIME29838040
cmd[0]: /usr/bin/sudo
cmd[1]: -H
cmd[2]: -S
cmd[3]: -p
cmd[4]: GNOME_SUDO_PASS
cmd[5]: -u
cmd[6]: root
cmd[7]: --
cmd[8]: gedit
cmd[9]: /etc/fstab
buffer: -GNOME_SUDO_PASS-
brute force GNOME_SUDO_PASS ended...
Yeah, we're in...

It does did invoke sudo but there's the whole .Xauthority thingy and all them switches like -H that Flemur mentioned above and such.

[Voltron]

Isn't it that by default users have read access to each other's home directories? Shouldn't need to run the backup program as root with write access to your entire operating system for that. Or you could add their groups to your account so you have full access. Or see if Deja Dup supports pkexec or otherwise add a rule like was done above for gedit. The Deja Dup developers would likely add something like that to support this case, if they haven't already.

Thanks for the response, xenopeek. You are correct, in your assumption; however, as the administrator of family members' computers, I have changed the default permissions and removed everyone's read access to other users' home folders, for privacy considerations. There certainly may be another method of doing this but, this is why I have been using deja-dup, as root, to backup all users' home folders, in one single backup process. I will plead ignorance, as I do not know how to use pkexec, to allow deja-dup to backup all users' home folders, as I currently do, within 16.04.

[xenopeek]

I did some further testing on Ubuntu 18.04 pre-release to answer a reddit thread. The file managers Nautilus, Nemo, Caja and Thunar all work with admin:// paths, as do the text editors Gedit, Xed and Pluma. Opening an admin:// path in one of these file managers and then opening a text file from there with one of these text editors propagates the elevated privileges. You can also use admin:// paths as command line arguments to these programs.

For text editors that don't support it, like Nano or KDE's Kate or Xfce's Mousepad (latter two as examples; neither of those are used on Linux Mint), you can likely use sudoedit. sudoedit makes a user writable copy of a file, opens it with the user's preferred text editor and only after the file is closed uses elevated privileges to move the copied file back to the original location. For example:

• sudoedit /etc/fstab by default edits with Nano
• EDITOR=mousepad sudoedit /etc/fstab edits with Mousepad for a single command
• or you can set the environment variable SUDO_EDITOR=/usr/bin/kate -b to edit with Kate by default instead of Nano (the -b option is specific for Kate, to make the editor wait for the file to be closed before returning; for Gedit and Xed use -w instead)

Strangely, Dolphin and Kate don't seem to support either gvfs or polkit or offer an alternative (that I could easily discover). kdesudo is not available either and pkexec doesn't work with either program. So KDE users seem to have to use sudoedit. For them probably a convenient idea is to set up SUDO_EDITOR=/usr/bin/kate -b in their .bashrc.

As for other commands one would want to run with elevated privileges, like the backup of all user home directories (please share others!), that likely needs an additional short configuration file for pkexec if it isn't already available.

[trytip]

the whole point for me is to have gksu save my password in keyring or session, i use save for session. using admin: or pkexec asks for password every instance. i shouldn't have to resort to a password keeping daemon for that. taking away the liberty to use ROOT apps is a step forward into cornering the user. Plasma has already removed the ability to open dolphin and kwrite as ROOT seems to me this is a trend into slowly removing access to under the hood apps and having the user become oblivious of what's going on system wide.

pretty soon you won't be allowed to see your root partition just like android and with microsoft at the door developing kali i can only imagine linux becoming another totalitarian operating system controlled by systemd.

[aes2011]

For Kate in Kubuntu 18.04, one can open a file such as /etc/gtk-3.0/settings.ini without any extra steps, make whatever changes are needed and then, on trying to save the file, the user is prompted for the user's password.

[xenopeek]

Thanks for sharing! Not that we have a KDE edition but it's great this will "just work" for those that want to use KDE on Linux Mint 19.