SUID? NOSUID?

I’m installing BackupPC from source onto DietPi v6.34.3 and I’ve run into a problem:

BackupPC requires that the CGI script BackupPC_Admin be executed as the BackupPC user (i.e., backuppc). However the main partition (mmcblk1p1) doesn’t seem to allow SUID executables!

I came to this conclusion using something similar to the troubleshooting steps described on the BackupPC FAQ:


  1. I created a simple shell script that contains only the command whoami:
dietpi@backuppc:~$ sudo cat /root/whoami.sh
#!/bin/bash

whoami ;
  1. I made the backuppc user account the owner of the script; made the script executable, and; set the Sticky Bit:
dietpi@backuppc:~$ sudo ls -l /root/whoami.sh
-rwsr-xr-x 1 backuppc backuppc 22 Jan 15 17:43 /root/whoami.sh

However: When I execute the script it reports that it is executing as the user that issued the command (i.e., root):

dietpi@backuppc:~$ sudo /root/whoami.sh
root

I’ve tried to manually override any “implied” nosuid by explicitly specifying that the main partition alllow SUID execution:

dietpi@backuppc:~$ cat /etc/fstab | grep -v '^#' | grep -v '^$'
tmpfs /tmp tmpfs size=1956M,noatime,lazytime,nodev,nosuid,mode=1777
tmpfs /var/log tmpfs size=50M,noatime,lazytime,nodev,nosuid,mode=1777
UUID=1542112e-4bd9-4f4a-9660-e9405c792736 / ext4 noatime,lazytime,rw,suid 0 1

But that didn’t change the behaviour.

What might be causing this unexpected behaviour? Ideas? Suggestion?

TIA,

FWIW: I repeated this exercise after moving the whoami.sh script to the $HOME of the user dietpi (i.e., /home/dietpi):

dietpi@backuppc:~$ echo $HOME
/home/dietpi

dietpi@backuppc:~$ pwd
/home/dietpi

dietpi@backuppc:~$ ll
total 1796
-rw-r--r-- 1 dietpi   dietpi   657309 Jun 20  2020 BackupPC-4.4.0.tar.gz
-rw-r--r-- 1 dietpi   dietpi   289549 Jun 20  2020 BackupPC-XS-0.62.tar.gz
-rw-r--r-- 1 dietpi   dietpi   883808 Oct  8 14:11 rsync-bpc-3.1.3.0.tar.gz
-rwsr-xr-x 1 backuppc backuppc     22 Jan 15 18:38 whoami.sh

The results were functionally identical (i.e., The script did not execute as the user backuppc):

dietpi@backuppc:~$ pwd
/home/dietpi

dietpi@backuppc:~$ ./whoami.sh 
dietpi

Ideas? Suggestions?

I also verified that the primary partition (mmcblk1p1) was mounted per the mount options specified in /etc/fstab:

dietpi@backuppc:~$ grep UUID /etc/fstab 
UUID=1542112e-4bd9-4f4a-9660-e9405c792736 / ext4 noatime,lazytime,rw,suid 0 1

dietpi@backuppc:~$ mount | grep mmcblk
/dev/mmcblk1p1 on / type ext4 (rw,noatime,lazytime)

I suppose that suid isn’t specified in the output above because it is the default behavior.

Am I correct about that?

TIA,

I’m installing BackupPC from source onto DietPi v6.34.3 and I’ve run into a problem:

BackupPC requires that the CGI script BackupPC_Admin be executed as the BackupPC user (i.e., backuppc). However the main partition (mmcblk1p1) doesn’t seem to allow SUID executables!

I came to this conclusion using something similar to the troubleshooting steps described on the BackupPC FAQ:


  1. I created a simple shell script that contains only the command whoami:
dietpi@backuppc:~$ sudo cat /root/whoami.sh
#!/bin/bash

whoami ;
  1. I made the backuppc user account the owner of the script; made the script executable, and; set the Sticky Bit:
dietpi@backuppc:~$ sudo ls -l /root/whoami.sh
-rwsr-xr-x 1 backuppc backuppc 22 Jan 15 17:43 /root/whoami.sh

However: When I execute the script it reports that it is executing as the user that issued the command (i.e., root):

dietpi@backuppc:~$ sudo /root/whoami.sh
root

dietpi@backuppc:~$ /root/whoami.sh 
dietpi

So I moved the whoami.sh script to the $HOME of the dietpi user account (i.e., /home/dietpi) and repeated the experiment:

dietpi@backuppc:~$ echo $HOME
/home/dietpi

dietpi@backuppc:~$ pwd
/home/dietpi

dietpi@backuppc:~$ ll
total 1796
-rw-r--r-- 1 dietpi   dietpi   657309 Jun 20  2020 BackupPC-4.4.0.tar.gz
-rw-r--r-- 1 dietpi   dietpi   289549 Jun 20  2020 BackupPC-XS-0.62.tar.gz
-rw-r--r-- 1 dietpi   dietpi   883808 Oct  8 14:11 rsync-bpc-3.1.3.0.tar.gz
-rwsr-xr-x 1 backuppc backuppc     22 Jan 15 18:38 whoami.sh

The results were functionally identical (i.e., The script did not execute as the user backuppc):

dietpi@backuppc:~$ pwd
/home/dietpi

dietpi@backuppc:~$ ./whoami.sh 
dietpi

So I’ve tried to manually override any “implied” nosuid by explicitly specifying that the main partition allow SUID execution. And then I rebooted:

dietpi@backuppc:~$ cat /etc/fstab | grep -v '^#' | grep -v '^$'
tmpfs /tmp tmpfs size=1956M,noatime,lazytime,nodev,nosuid,mode=1777
tmpfs /var/log tmpfs size=50M,noatime,lazytime,nodev,nosuid,mode=1777
UUID=1542112e-4bd9-4f4a-9660-e9405c792736 / ext4 noatime,lazytime,rw,suid 0 1

But that didn’t change the behaviour:

dietpi@backuppc:~$ grep UUID /etc/fstab 
UUID=1542112e-4bd9-4f4a-9660-e9405c792736 / ext4 noatime,lazytime,rw,suid 0 1

dietpi@backuppc:~$ mount | grep mmcblk
/dev/mmcblk1p1 on / type ext4 (rw,noatime,lazytime)

What might be causing this unexpected behaviour?

Ideas? Suggestions?

TIA!

Hi,

best to my knowledge setuid or setgid are not meant to execute the script as the user who owns it, it’S more to have the file automatically execute with the privileges of the file’s owner. It’s more to invoke file owner permission instead of executing it as the owner.

Maybe MichaIng could explain it better than I do

Right - I see your point! i.e., The script’s Effective UID is different that the Process Owner’s UID.

From Wikipedia

The effective UID (euid) of a process is used for most access checks. It is also used as the owner for files created by that process. The effective GID (egid) of a process also affects access control and may also affect file creation, depending on the semantics of the specific kernel implementation in use and possibly the mount options used.

I believe that Evi Nemeth’s books (Linux Administration Handbook [2002, 2006], and UNIX and Linux System Administration Handbook [2010]) each have a section devoted to this very topic!

I’ll have to devise a better test…

you could try runing sudo -u to have the script executed as a specific user.

What I know is that nosuid is definitely not implied for the root partition, since otherwise sudo, su and a few other commands would not work at all :wink:.

Generally, I would not use the setuid/setgid bits, if you have any chance to avoid it, it limits the way you can control it too much. Use sudo instead as Joulinar suggested and via sudoers configuration you can precisely define which user is allowed to use it for which command :slight_smile:.

Thanks for the suggestions, Everyone!

Unfortunately: BackupPC requires that the CGI script BackupPC_Admin be executed as the BackupPC user (i.e., SUID backuppc).

I’ll continue to work the problem in my spare time. And I’ll share my runbook - i.e., Instructions for for installing BackupPC from source onto DietPi - once it’s “ready for Prime Time”.

Thanks, again!