-1

Suppose the following directory structure:

-rwxr-xr-x 1 root   root       script
-rw-r--r-- 1 root   root       owned_by_root

Suppose also that script is a simple shell script with the following contents:

#!/usr/bin/bash

echo "Appending $2 to $1..."
echo -n "$2" >> $1

and that owned_by_root is an empty file.

As owned_by_root is clearly owned by the root user, and as the write flag is set only for the owning user, the following obviously fails when executed under a non-root account:

user@machine 
$ ./script ./owned_by_root "Hi"

Now, if I set the SUID bit of the script file, like so:

sudo chmod u+s ./script

(resulting in the permissions bits of script being -rwsr-xr-x), to my surprise,

user@machine 
$ ./script ./owned_by_root "Hi"

still fails, with ./script: line 4: owned_by_root: Permission denied.

It was my impression that setting the SUID bit on the script executable would lead to any 3rd party user account being able to append to ./owned_by_root.

SUID is usually explained by the /etc/passwd//usr/bin/passwd dynamic, whose permission bits match those of owned_by_root and script, respectively. There must be something I'm missing/misunderstanding.

bool3max
  • 2,748
  • 5
  • 28
  • 57

1 Answers1

0

It appears that Linux ignores the SETUID bit on shebang (#!) scripts. This can be confirmed by adding a sleep command to the script and inspecting the process table in the meantime:

$ ps aux | grep -i script

user   1271826  0.0  0.0  10084  2796 pts/4    S+   18:20   0:00 /usr/bin/bash ./script owned_by_root Hello

By observing the first column it is apparent that the bash process is running under the same user who initially executed the script.

The same is not true for compiled programs, which /usr/bin/passwd is.

bool3max
  • 2,748
  • 5
  • 28
  • 57