gksu removed from the repo's of Ubuntu 18.04

[Pjotr]

I do wonder how many people on Mint 20.x will blindly run a commonly recommended command on the forum to fix home ownership issues sudo chown -Rc $USER:$USER $HOME and break root's ownership...

I'm not particularly bright this morning, but does this mean that that command (which I apply as a matter of course in each new install) will be harmful in Ubuntu 20.04?

[karlchen]

Hm. Seems as if the shell (/bin/bash) expands the variables $USER and $HOME to the expected values, before executing sudo.
Commandlines tested:

Code: Select all

sudo echo $USER_$USER $HOME
sudo -H echo  $USER:$USER $HOME
sudo -s echo  $USER:$USER $HOME
sudo -i echo  $USER:$USER $HOME

Results:

Code: Select all

karl@computer:~$ sudo echo  $USER:$USER $HOME
karl:karl /home/karl
karl@computer:~$ sudo -H echo  $USER:$USER $HOME
karl:karl /home/karl
karl@computer:~$ sudo -i echo  $USER:$USER $HOME
karl:karl /home/karl
karl@computer:~$ sudo -s echo  $USER:$USER $HOME
karl:karl /home/karl

[xenopeek]

Yes, the shell expands variables before executing a command. If you don't want the shell to expand variables, you must single-quote them. But then echo will just print $USER_$USER $HOME literally.

To have the shell expand the single-quoted variables after running sudo, you must single-quote the entire command and have sudo run that in a shell. So:

Code: Select all

$ sudo bash -c 'echo $USER_$USER $HOME'
root /root

[karlchen]

Hi, xenopeek.

Right. And this suggests that the commandline, which is frequently given to forum users for the purpose of re-instating their user account as the owner of everything in their home directory, sudo chown -Rc $USER:$USER $HOME, will not change its behaviour starting with Ubuntu 20.04.
The variables $USER and $HOME are expanded by the shell, before passing it to sudo.

Cheers,
Karl

[xenopeek]

The variables $USER and $HOME are expanded by the shell, before passing it to sudo.

Correct. The shell expands variables on the command line before invoking the command, unless they are single-quoted.

[smurphos]

I do wonder how many people on Mint 20.x will blindly run a commonly recommended command on the forum to fix home ownership issues sudo chown -Rc $USER:$USER $HOME and break root's ownership...

I'm not particularly bright this morning, but does this mean that that command (which I apply as a matter of course in each new install) will be harmful in Ubuntu 20.04?

Probably brighter than I was when I posed the question, as a soon as i read xenopeeks last reply I thought - Oh yeah - I knew that..

[trytip]

Well I got gksu back -
Download it here:

Code: Select all

https://pkgs.org/download/gksu

You should be aware that these .deb packes are based on Ubuntu 16.04 or Debian 9.
LM 19.x as you are aware is based on Ubuntu 18.04 and LMDE 3 is based on Debian 10. So if installing a .deb package designed for 16.04 is a concern I would understand. Just for the record though I have been running gksu on 19.x and LMDE 3 with no issues for months.

if you don't get a save to keyring or session password dialog, using gksu is no sense any longer. you might as well trick gksu to run pkexec as i do. my whole point for using gksu is that it can remember passwords, but it no longer does this.
so installing gksu (and jumping through hoops to find all the correct dependencies) gives you this password window which is basically the same as pkexec window.


if you get this windows and are able to save passwords in keyring or session, than you da man.

[majpooper]

if you don't get a save to keyring or session password dialog, using gksu is no sense any longer. you might as well trick gksu to run pkexec as i do. my whole point for using gksu is that it can remember passwords, but it no longer does this.
so installing gksu (and jumping through hoops to find all the correct dependencies) gives you this password window which is basically the same as pkexec window.
if you get this windows and are able to save passwords in keyring or session, than you da man.

No - It does not save your password.
I am not familiar pkexec - actually I never even heard of it. I want gksu because I am a leafpad txt editor fan and refuse to change - I want to use leafpad from the terminal when I want to how I want when I want to.
With 19.x I could not do

Code: Select all

gksudo leafpad

to open files and edit them but instead the 19.x way is

Code: Select all

xed admin://

which not to be too harsh - sucks - I hated it - it fails, then you have to do it again and so on. So being a creature of habit I wanted gksu back. But I get it - it's the password thing for you so this won't work.

[xenopeek]

This also works:
SUDO_EDITOR=leafpad sudoedit /dir/file

Add export SUDO_EDITOR=leafpad to your .bashrc or .profile and you can just use this:
sudoedit /dir/file

Benefit of sudoedit is your GUI editor isn't run as root. sudoedit just makes a user-writable temporary copy of the file, opens Leafpad to edit it and after Leafpad close copies the modified file back.

[majpooper]

This also works:
SUDO_EDITOR=leafpad sudoedit /dir/file

Add export SUDO_EDITOR=leafpad to your .bashrc or .profile and you can just use this:
sudoedit /dir/file

Benefit of sudoedit is your GUI editor isn't run as root. sudoedit just makes a user-writable temporary copy of the file, opens Leafpad to edit it and after Leafpad close copies the modified file back.

Hoooah ! Man I wish I would have known this back in July, August or whenever it was when I needed this - THX for better solution than adding obsolete software to solve an issue.

[Portreve]

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

I'm not sure why this is a problem. I've always followed your online instructions using sudo nano {foo}. In fact, I've never really understood why you have your directions written the way you do when one can just as easily (I'd argue even more easily) do what I do and have an end to it.

[lewtwo]

I never understood why some people seemed to think the ONLY problem this caused was editing configuration files (which is easy enough to get around).

[trytip]

I am not familiar pkexec - actually I never even heard of it. I want gksu because I am a leafpad txt editor fan and refuse to change - I want to use leafpad from the terminal when I want to how I want when I want to.
With 19.x I could not do

Code: Select all

gksudo leafpad

to open files and edit them ...

here's how to trick the system thinking you have gksu: (but you have to uninstall the old gksu packages and dependencies)

Code: Select all

sudo touch /usr/bin/gksu
sudo xed /usr/bin/gksu

paste this, save and make it executable

Code: Select all

/usr/bin/pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY HOME=$HOME PWD=$PWD $@

sudo chmod +x /usr/bin/gksu

now gksu leafpad

[robsku]

Still, what would I use to replace gksudo? I mean, I have a script that is meant to be driven from GUI, and it uses gksudo to provide GUI window for asking password, then for the rest of the commands needing root priviledges it uses plain sudo, because the sudo permissions should remain for some time without needing to ask again.

For this use case just use sudo's ASKPASS feature.

e.g. have this little script somewhere

Code: Select all

#!/bin/bash
zenity --password --title="Authenticate"

Then in your script

Code: Select all

 export SUDO_ASKPASS="/path/to/your/zenity_askpass_script"
  sudo -A whatever_the_command_is

Nice and elegant - I actually feel a bit sad I already installed lxsudo and made a gksudo symlink to it... But if that'll ever get removed or I face a Linux installation with no GUI front-end readily available, I will do this next time

[yanush]

@smurphos
zenity - nice solution but it works in shell only.
I try to use it for item in cinammone menu and it doesn't work.

Have you got an idea why ?