DietPi utility aliases fail to work with sudo

[Stickerpants]

Fourdee note:

Implement these changes:

https://github.com/Fourdee/DietPi/issues/424#issuecomment-232934861

This is mostly for awareness, since it's a pretty minor detail. As explained in this post, it seems like aliases fail to expand when they are not the first word in a call.

As a result, attempting to call sudo dietpi-config (like it instructs you to, if not run as root) gives the error sudo: dietpi-config: command not found. Of course, we can run the scripts direct by specifying the path to the ramdisk directly via /DietPi/dietpi/dietpi-config.

There's a few options to this end - what if we put /DietPi/dietpi/ on the path? Then there's no need to deal with alias expansion.

I do recognize that this is a very minor issue - maybe the best solution here is just to strip out the messages that tell people to use sudo to run the scripts, and instead replace it with a message telling people to su instead.

[Fourdee]

@Stickerpants

what if we put /DietPi/dietpi/ on the path? Then there's no need to deal with alias expansion.

Yep, using the full path is one resolution, although, we shouldn't rely on the the user to type it, every time they want to run a DietPi script. Its a bit long :)

maybe the best solution here is just to strip out the messages that tell people to use sudo to run the scripts, and instead replace it with a message telling people to su instead.

@Stickerpants
Like this?

sudo su
dietpi-runthis

[Fourdee]

@Stickerpants

I read the link :+1: , yep, so if we add the code below to /etc/bash.bashrc, after logging back in, the space after sudo allows for other alias to be triggered.

alias sudo='sudo '

sudo dietpi-config now works.

So this will need to be patched in the patch_file.

[Stickerpants]

Yup, I do agree that aliasing sudo is likely the cleanest way to address this. Thank you @Fourdee!

[rhkean]

I think a cleaner way might be too add /DietPi/dietpi to the PATH search.

This can be done in /etc/profile as:
PATH="$PATH:/DietPi/DietPi"

Just before the export PATH statement.
Then we don't need to alias any of them

[Fourdee]

@rhkean

Then we don't need to alias any of them

Great idea :+1:.

Gutted, sudo doesn't appear to work with defined PATH:

root@DietPi:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/DietPi/dietpi

root@DietPi:~# sudo dietpi-cpuinfo
sudo: dietpi-cpuinfo: command not found

#non-sudo works fine
root@DietPi:~# dietpi-
dietpi-apt-get_update        dietpi-letsencrypt
dietpi-autostart             dietpi-logclear
dietpi-backup                dietpi-morsecode
dietpi-banner                dietpi-obtain_hw_model
dietpi-bugreport             dietpi-process_tool
dietpi-cleaner               dietpi-ramdisk
dietpi-cloudshell            dietpi-ramlog
dietpi-config                dietpi-services
dietpi-cpuinfo               dietpi-software
dietpi-cpu_set               dietpi-survey
dietpi-cron                  dietpi-sync
dietpi-external_drive_setup  dietpi-uninstall
dietpi-funtime               dietpi-update
dietpi-launcher

Ok, unless anyone has another idea or a possible fix for PATH, we'll go with the alias option to fix sudo.
I'll add to patch file. Alias also allows us to essentially control/limit what dietpi- scripts are available for the user.

[rhkean]

@Fourdee
Gutted, sudo doesn't appear to work with defined PATH:

it has to be in root's path.

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
PATH="$PATH:/DietPi/dietpi"
export PATH

Alias also allows us to essentially control/limit what dietpi- scripts are available for the user.

yeah.... good point.... you don't want an end-user running finalise like I just did. :laughing:

[rhkean]

This stackoverflow discussion appears to have the sudo PATH answers, but I won't have time to read it until this evening.

http://stackoverflow.com/questions/257616/sudo-changes-path-why

[Fourdee]

yeah.... good point.... you don't want an end-user running finalise like I just did

lol.

[rhkean]

my proposed fix is to

1. add /DietPi/dietpi to the secure_path in the sudoers file
2. add /DietPi/dietpi to the PATH in /etc/profile
3. in dietpi-services when the dietpi-* files are copied to /DietPi/dietpi directory, perform a chmod 744 /DietPi/dietpi/dietpi-* (or some variant that makes sense for limiting which scripts are executable)

this will

1. allow for sudo use
2. prevent scripts that we don't want run from getting run accidentally
3. let us avoid using hacks to circumvent the security feature

[Fourdee]

1. Yep, maybe we can pop something in /etc/sudoers.d/dietpi. I tried Defaults secure_path="/DietPi/dietpi" has no effect. Any ideas?
2. Yep.I think we should again put something in .d /etc/profile.d/dietpi
3. I can do this with DietPi-Ramdisk, create a list of scrips that we can chmod -x during boot.

[Fourdee]

@rhkean
Above commit is not final for sudo fix. I put the it in a few days ago and we can change as needed.

[rhkean]

we'll have to actually edit the /etc/sudoers file as such:

Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/DietPi/dietpi"

might need to wait for the next full image.... that file doesn't like to be edited.

[Fourdee]

@rhkean

might need to wait for the next full image.... that file doesn't like to be edited.

Yep, so i've seen visudo. I'll take a look.

[Fourdee]

from/etc/sudoers

This file MUST be edited with the 'visudo' command as root.

This is non-sense. The file can be written to directly without visudo. Even works with sudo sed:

if (( ! $(cat /etc/sudoers | grep 'secure_path=' | grep -ci -m1 '/DietPi/dietpi') )); then
    sed -i 's/:\/bin\"/:\/bin:\/DietPi\/dietpi\"/' /etc/sudoers
fi

[Stickerpants]

The reason why it says "must" is mostly a "don't shoot yourself in the foot" scenario - visudo syntax checks /etc/sudoers to ensure that everything is correct before allowing you to save and exit.

This is to prevent you from locking yourself out by breaking sudo - imagine if you did sudo vim /etc/sudoers, and then broke it without having direct access to root.

[Fourdee]

@Stickerpants

The reason why it says "must" is mostly a "don't shoot yourself in the foot" scenario
This is to prevent you from locking yourself out by breaking sudo

Aha, now it makes sense. A end-user countermeasure to prevent breaking Sudo. Thanks for the info :+1:

I'll make sure to test the pattern match patch for /etc/sudoers on all devices prior to release.

[rhkean]

@Fourdee
Even works with sudo sed

I'd be interested to know how you got sed to edit a file with -r--r----- permissions. :laughing:

[Fourdee]

I'd be interested to know how you got sed to edit a file with -r--r----- permissions. :laughing:

Yep, I ran sudo as root :wink:

Its ok though, i got reported for trying another user lmao

testuser@DietPi:~$ sudo sed -i 's/:\/bin\"/:\/bin:\/DietPi\/dietpi\"/' /etc/sudoers
[sudo] password for testuser:
testuser is not in the sudoers file.  This incident will be reported.

[Fourdee]

Ok, so there is a risk with users running sudo dietpi-update on this.
I'll revert the changes back to alias for now.

I'll also move this ticket to another milestone (https://github.com/Fourdee/DietPi/milestone/25) so we can implement these changes during the next major image release.

Notes:

• Remove all alias from /etc/bash.bashrc
• Add dietpi path to sudoers

if (( ! $(cat /etc/sudoers | grep 'secure_path=' | grep -ci -m1 '/DietPi/dietpi') )); then
    sed -i 's/:\/bin\"/:\/bin:\/DietPi\/dietpi\"/' /etc/sudoers
fi

• Add dietpi path to /etc/profile

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
PATH="$PATH:/DietPi/dietpi"
export PATH

• In dietpi-ramdisk apply chmod -x to scripts we dont want users to run.

[Fourdee]

This appears to be working fine, with a underpriv user and:

sudo dietpi-config
sudo dietpi-update

/etc/bash.bashrc
alias sudo='sudo '

Marking as closed.