sudo vs. gksudo

[GS3]

sudo vs. gksudo: A mistake I have committed more than once and I see others have too. Never had that problem in Windows. Why is it necessary in Linux to have Sudo and Gksudo at all? Why could I not just call the program directly and have it ask for whatever permissions, credentials or whatever it needs? It seems to me that if the command I just gave is wrong the computer should be able to not carry it out or, at least, warn me. Computers are supposed to help us, not test our knowledge by exploding into a fireball if we made a mistake.

[karlchen]

Hello, GS3.

Linux Mint and Windows are different operating systems. They sometimes use different approaches to accomplish the same task.
Windows has got its UAC dialogue.
Linux Mint still has sudo/gksudo. This is true up to and including Mint 18.3.

The rule when to use sudo and when to use gksudo is pretty simple: You run terminal commands with root privileges by prefixing sudo to the commandline. You run graphical applications with root privileges by prefixing gksudo to the commandline.

Starting with Mint 19, which is based on Ubuntu 18.04, there will be no more gksudo. Instead something which has been there for quite a while now will start taking over, pkexec. pkexec permits a more finegrained approach to granting root privileges when needed than gksudo does. So on Mint 19, you will have to use sudo and pkexec.
Maybe in the foreseeable future pkexec will completely replace not only gksudo, but also sudo; don't know to be honest.

About testing your knowledge:
Any operating system follows its own rules. Windows does, Linux Mint does. Without having a sound understanding of the handling rules, you will not be able to make use of any operating system and run into severe trouble sooner or later. Forget about the marketing slogans suggesting that operating system xyz could be used intuitively. Intuition comes with knowledge and experience. Without them there will be no intuition. This does not only apply to computers.

Cheers,
Karl

[Flemur]

sudo vs. gksudo: A mistake I have committed more than once and I see others have too.

The "rule" is generally: use sudo for bash commands, and gksudo for programs with GUIs - although sometimes it's hard to tell in advance. When in doubt, use gksudo (try "gksudo ls"). FWIW, I sort of consider it a bug that "sudo" sometimes changes ownership of user's (config) files to 'root'.

Never had that problem in Windows.

IIRC, with windows regular users can mess with system files but *nobody* can remove certain files w/o jumping thru hoops (that "locked" nonsense).

Why is it necessary in Linux to have Sudo and Gksudo at all? Why could I not just call the program directly and have it ask for whatever permissions, credentials or whatever it needs?

Some of them do do that - the "mint*" programs, I think. (First you start them, then they ask for password ). But you're supposed to have some idea of the difference between "user" stuff (under $HOME) and "system" stuff, which can affect all users - so in a way it's a left-over from linux where, in the old days, you might have a dozen people using the same physical computer.

It seems to me that if the command I just gave is wrong the computer should be able to not carry it out or, at least, warn me. Computers are supposed to help us, not test our knowledge by exploding into a fireball if we made a mistake.

Fireballs are pretty cool, but all I ever get are boring messages, like

Code: Select all

$ rm /usr/bin/zip
rm: remove write-protected regular file '/usr/bin/zip'? y
rm: cannot remove '/usr/bin/zip': Permission denied

[Flemur]

Instead something which has been there for quite a while now will start taking over, pkexec. pkexec permits a more finegrained approach to granting root privileges when needed than gksudo does.

More convoluted crapware from "freedesktop.org":

Code: Select all

$ pkexec rm a
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authentication is needed to run `/bin/rm' as the super user
Authenticating as: <username>,,, (<username>)
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.

"No session for cookie"!?!?! Reported!?!? Oh noes, those things sound scary!
(Fortunately that error message is itself an error (it's freedesktop!), and nothing is reported to anybody.)

+++
https://linux.die.net/man/1/pkexec

Required Authorizations
To require another authorization, it can be specified using the org.freedesktop.policykit.exec.path annotation on an action (See the section called "EXAMPLE" for details).
Example

To specify what kind of authorization is needed to execute the program /usr/bin/pk-example-frobnicate as another user, simply write an action definition file like this

Code: Select all

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE policyconfig PUBLIC
     "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
     "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
    <policyconfig>
...dozens of lines of bs....

"Simply write an action definition file" - "where none used to be needed", so to speak.

More here: https://askubuntu.com/questions/287845/ ... ure-pkexec

[JerryF]

If I may interject:

How does the File Manager open up as root in the following example? sudo or gksudo

Shutter_002.jpg

[karlchen]

Flemur,

on Ubuntu 18.04 / Mint 19, the terminal commands are still invoked with root permissions by prefixing sudo. Hence your rm commandline will still be sudo rm a. Only the graphical applications now make use of pkexec (policykit) more consistently than they did in the past.
Though, in case you can be bothered to check the commandlines behind the launchers of synaptic and gparted e.g. you may detect that they have been invoked using pkexec for quite a while already.
About policykit being convoluted: Some changes are for the better, some may turn out to be changes for the worse. I had not given any judgement. In particular I had not talked about increased complexity.

Cheers,
Karl

[trytip]

you know that error message in synaptic (synaptic:16174): GLib-CRITICAL **: g_child_watch_add_full: assertion 'pid > 0' failed which is been around since 2011 ? maybe one day linux will have spring cleaning and wash away benign and useless old information. these small error messages are annoy me irate . do developers not see these? sometimes they remove key factors of function or cosmetic like the quick filter in synaptic. can developer explain why this option is removed ?
now they want limit root access?

[karlchen]

Though it is not really related to the original question asked by the OP, let me answer on the last part of this passage:

sometimes they remove key factors of function or cosmetic like the quick filter in synaptic. can developer explain why this option is removed ?

I cannot tell why; but here is how to make the quick search filter return to Synaptic i:nstead

Code: Select all

sudo apt-get update
sudo apt-get install apt-xapian-index

(You are free to use Synaptic itself in order to install apt-xapian-index).

[thx-1138]

If I may interject:

How does the File Manager open up as root in the following example? sudo or gksudo
Shutter_002.jpg

Jerry, see below how the steps are taking place, with gksu 'calling' sudo, 'advancing' from user to root...

Code: Select all

$ ps aux | grep caja
thx-1138   1420   0.3  1.0 1264316 83772 ? Sl 18:23  0:58 caja
thx-1138   10379  0.4  0.2 339608  23092 ? Sl 23:53  0:00 gksu caja 'file:///home/thx-1138/testfolder'
root       10380  0.0  0.0 70080   4524  ? Ss 23:53  0:00 /usr/bin/sudo -H -S -p GNOME_SUDO_PASS -u root -- caja file:///home/thx-1138/testfolder
root       10385  0.3  0.5 698824  45288 ? Sl 23:53  0:00 caja file:///home/thx-1138/testfolder

[MrEen]

If I may interject:

How does the File Manager open up as root in the following example? sudo or gksudo
Shutter_002.jpg

Hi JerryF. I can say that in the case of Xfce, it uses gksu. Here's the relevant section of ~/.config/Thunar/uca.xml:

Code: Select all

<action>
	<icon>stock_open</icon>
	<name>Open as Root</name>
	<unique-id>1502318062643004-2</unique-id>
	<command>gksu Thunar %F</command>
	<description>Open the folder with administration privileges</description>
	<patterns>*</patterns>
	<directories/>
</action>

[thx-1138]

.............................................

...let's put the fun back into computing
espeak -s 125 -v en+whisperf "p k exec sucks" && xmessage 'This incident has been reported!' && cowthink -f daemon 'Oh Noes!'

[JerryF]

...
Hi JerryF. I can say that in the case of Xfce, it uses gksu. Here's the relevant section of ~/.config/Thunar/uca.xml:

Code: Select all

<action>
	<icon>stock_open</icon>
	<name>Open as Root</name>
	<unique-id>1502318062643004-2</unique-id>
	<command>gksu Thunar %F</command>
	<description>Open the folder with administration privileges</description>
	<patterns>*</patterns>
	<directories/>
</action>

Thanks! I'm going to check Cinnamon's Nemo File Manager next.

[altair4]

If I may interject:

How does the File Manager open up as root in the following example? sudo or gksudo
Shutter_002.jpg

Hi JerryF. I can say that in the case of Xfce, it uses gksu. Here's the relevant section of ~/.config/Thunar/uca.xml:

Code: Select all

<action>
	<icon>stock_open</icon>
	<name>Open as Root</name>
	<unique-id>1502318062643004-2</unique-id>
	<command>gksu Thunar %F</command>
	<description>Open the folder with administration privileges</description>
	<patterns>*</patterns>
	<directories/>
</action>

And in Mint 19 XFCE it opens with pkexec:

<action>
<icon>folder</icon>
<name>Open as Root</name>
<unique-id>1528305263281731-2</unique-id>
<command>pkexec thunar %F</command>
<description>Open the folder with administration privileges</description>
<patterns>*</patterns>
<directories/>
</action>