Why do my setuid root bash shell scripts not work?

问题:

I created this simple script to allow the user to remove files created by the web server in his home directory without giving him "su". Both scripts are set with "chmod 4750".

The craziest thing is that they DID work and now they don't. Here's the scripts:

#!/bin/bash

# Ask for directory to delete
echo "Enter the file or directory you would like to delete, the assumed path is    /home/user"

read DIRECTORY

rm -rf /home/user/"$DIRECTORY"

echo "Deleting /home/user/$DIRECTORY ..."

exit 0

2:

#!/bin/bash

# Reset permissions
echo "Resetting the ownership of the contents of /home/user to user."

chown -R user /home/user

exit 0

I will make them a little more advanced and work for multiple users but right now I cannot even get the simple version to work. It works when run as root of course. It used to work when run as user 'user' but now it doesn't. I get this:

user@dev:/home/user$ delete.sh
Enter the file or directory you would like to delete, the assumed path is /home/user/[your input]
test-dir
rm: cannot remove ‘/home/user/test-dir/test-file’: Permission denied
Deleting /home/user/test-dir ...

and

chown: changing ownership of ‘/home/user/test-dir’: Operation not permitted

What can possibly be the problem?

-rwsr-x--- 1 root user 291 Nov  6 05:23 delete.sh
-rwsr-x--- 1 root user 177 Nov  6 05:45 perms.sh

回答1:

There is a pretty comprehansive answer at https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts

Bottom line is that there are two main points against it:

1. A race condition between when the Kernel opens the file to find which interpreter it should execute and when the interpreter opens the file to read the script.
2. Shell scripts which execute many external programs without proper checks can be fooled into executing the wrong program (e.g. using malicious PATH), or expand variables in a broken way (e.g. having white space in variable values), and generally it has less control on how well the external programs it executes handle the input.

Historically, there was a famous bug in the original Bourne shell (at least on 4.2BSD, which is where I saw this in action) which allowed anyone to get interactive root shell by creating a symlink called -i to a suid shell script. That's possibly the original trigger for this being prohibited.

EDIT: To answer "How do I fix it" - configure sudo to allow users to execute only these scripts as user root, and perhaps use a trick like in https://stackoverflow.com/a/4598126/164137 to find the original user's name and force operation on their own home directory, instead of letting them pass in any arbitrary input (i.e. in their current state, nothing prevents user1 from executing the scripts and passing them users2's directory)