What is the replacement of kdesudo and gksu in Buster?

[Leoncio]

Kdesudo and gksu are not anymore in Buster. How are we supposed to open a graphical application when it is called from another graphical application like a file manager or the system menu?

[Dai_trying]

You could try pkexec, the man page contains some good information.

[Leoncio]

pkexec fails to find the program; it seems it ignores the $PATH variable, exactly the same as lxqt-sudo.
If I specify the path of the program it asks for the root password, but it answers with "==== AUTHENTICATION FAILED ===". I have checked with the su command and my root password works fine.
Even if I solved the problem with the password, I'm afraid I will still have the problem with pkexek ignoring $PATH. like with lxqt-sudo.

[wizard10000]

disclaimer: Not recommended or supported

I run Unstable and just installed gksu and its dependency from Oldstable and gksu works just fine.

[CwF]

I suppose it depends on the particular desktop and programs, but pkexec is working fine for me. For xfce I made up a 'root bar' that hides and pops up to give launchers for root terminal, thunar, and synaptic. All work from the bar without any password. With a root terminal available I never bother using a password at all. That can be set in the policy files. I did steal the gksu terminal icon, I like it. I converted to this in late stretch, and busters since work the same. Things like gparted, gdebi, bleachbit, usbview, and others are also working fine. Any past solution will need help again in the future, as far I I know pkexec is the future.

[Leoncio]

Buster is the stable version of Debian ans stable means STABLE; without the small problems we could find in in Testing or Sid. Debian should not have released a new stable release without a straightforward replacement of kdesudo and gsudo. This is UNACCEPTABLE.

[L_V]

pkexec command is not really expected to be used by users.
pkexec is used by the system to launch applications which rights are managed by policykit.

Code: Select all

 grep 'action id' /usr/share/polkit-1/actions/* | awk -F'=' '{print $2}'

Could you please give only one exeample to explain why you need to open a file manager as root user (assuming you understand the risks) ?

[Head_on_a_Stick]

Buster is the stable version of Debian ans stable means STABLE; without the small problems we could find in in Testing or Sid. Debian should not have released a new stable release without a straightforward replacement of kdesudo and gsudo. This is UNACCEPTABLE.

What is UNACCEPTABLE is the granting of superuser permissions to entire graphical user interfaces.

The development trend now is to use pkexec to open the GUI as a normal user and only run the actual code needed to perform the operation as root.

For example, to edit a system file use

Code: Select all

gedit admin:///full/path/to/file

^ That will open a copy of the file in gedit (as the normal user) and only invoke root (via gvfs & polkit) to save the file.

[Leoncio]

Could you please give only one exeample to explain why you need to open a file manager as root user (assuming you understand the risks) ?

I did not say that I needed to open a file manager as root user. But now that you mention it: I do not need to open a file manager as root user. In fact I do not need a file manager at all, since everything I do with a file manager I could do it from the command line. In fact, most of the tasks in linux can be done from the command line. Even burning a CD/DVD can be done with commands and 38564923 parameters So, nobody need K3B. I do want to open a file manager and yes, sometimes also as root, to make my life easier because, and this is very important, computers (and machines in general) must adapt to humans, not the other way round. This is something that old-school linux users will never understand.

What I asked is about running graphical programs as root from a graphical program. For example, I may be in a file manager, maybe as a normal user and I may want to edit a configuration from /etc. I may use nano, and many times I do use it, but I may want to use a more friendly graphical editor as root. Another problem is the menu entries that run commands as root. Right now my menu entry of synaptic use kdesudo, and if I rename /usr/bin/kdesudo the synaptic item disappears from the menu and the update-menus command won't help. If running graphical program as root is a security hazard, running a so critical program as a package manager with an outdated program as kdesudo might be a bomb. That's why I said that that Buster should have been shipped with an alternative (a safe one) to kdesudo. The lxqt-sudo program is supposed to be an alternative (but I don't know if it is safe) but it ignores the $PATH environment variable so, it is of little use.

Trying to be constructive: would this command be safe?

Code: Select all

SUDO_ASKPASS=/usr/bin/ssh-askpass sudo -A synaptic

The same for other graphical programs, like gparted, gsmartcontrol or thunar.
If this were safe a tiny bash script would solve this.

[Leoncio]

The development trend now is to use pkexec to open the GUI as a normal user and only run the actual code needed to perform the operation as root.

For example, to edit a system file use

Code: Select all

gedit admin:///full/path/to/file

^ That will open a copy of the file in gedit (as the normal user) and only invoke root (via gvfs & polkit) to save the file.

How can that be used to run gparted, gsmartcontrol, synaptic, thunar and others?

Would this be a safe option for that?

Code: Select all

SUDO_ASKPASS=/usr/bin/ssh-askpass sudo -A "command-to-be-run"

[sunrat]

stevepusser wrote a root actions menu for Dolphin if that's what you need. The rest of the topic may also be of interest.
viewtopic.php?f=10&t=142601&start=30#p704052

[L_V]

I may be in a file manager, maybe as a normal user and I may want to edit a configuration from /etc.

This is the only one concrete example I required to illustrate.
Then try to open '/etc/apt/sources.list' in kate or kwrite from Dolphin as user.
After modification of this file, you can save it: your password is requested if you are declared as sudoers: is it a problem ? How often do you need this kind of operation ?
Personally, to edit a simple system configuration file, I create an alias with sudo as prefix.

Code: Select all

alias nanosl='sudo nano /etc/apt/sources.list'

No password is requested if you correctly configure visudo.

Alias of functions can be declared in '~/.bash_aliases' for bash (or '~/.zaliases' for zsh)

[Deb-fan]

What Wizard10000 said, though plenty of other relevant advice-info here too. Was going to suggest lxqt-sudo but it's not working out well for you. Agree this should've been addressed more quickly and conveniently for typical desktop nixers. Seems like a lot of aggravation and pita for very little realistic gain. This change prompting people to implement all manner of dirty hacks, ie: set-up to launch xyz-prog w/o password or whatever else. That's a worthless 2 cents regardless, shrugs.

Also just cause it's on my mind, someone mentioned using visudo. Also not that they weren't correct-etc. Far as I know the correct approach now is to do that type of thing creating files in /etc/sudoers.d, so they stay neat and clean and aren't overwritten upon updates. Rather than editing the sudoers file anymore. Personally planning to continue using gksu/do for awhile yet.

[wizard10000]

...Personally planning to continue using gksu/do for awhile yet.

Same.

I don't *need* to run graphical applications as root and in the enterprise I wouldn't attempt something like this but on my home machine I can do pretty much whatever I want and what I want is an easy path to running a few pointy clicky applications I need as root - such as spacefm, lxtask, geany, gparted, bleachbit and synaptic.

I'm reasonably security-conscious. I don't run a display manager because the only one that *doesn't* run X under the root account is GDM and I'm allergic to GDM

But - on my own machines I'm not ready to give up gksu.

[Leoncio]

Then try to open '/etc/apt/sources.list' in kate or kwrite from Dolphin as user.
After modification of this file, you can save it: your password is requested if you are declared as sudoers: is it a problem ? How often do you need this kind of operation ?

In my system if I open a text file I'm not allowed to write, kate will not ask me for a password; it will just refuse to write it. And I can use sudo without problems from the command line. Maybe I need to modify sodoers? This is what I have in sudoers after the user name: ALL=(ALL) ALL

And there are files that can not even be read by normal users, for example sudoers.

And again: right now synaptic, when run from the menu, is being run using the outdated and non maintained kdesudo that I had before upgrading to Buster because Buster was released without a replacement of kdesudo.

Is there any security problem running graphical programs with this?

Code: Select all

SUDO_ASKPASS=/usr/bin/ssh-askpass sudo -A "command-to-be-run"