为什么我的 setuid root bash shell 脚本不起作用？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/33565729/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why do my setuid root bash shell scripts not work?
提问by Bob
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".
我创建了这个简单的脚本，以允许用户删除 Web 服务器在其主目录中创建的文件，而无需给他“su”。两个脚本都设置为"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:
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:
我会让它们更高级一些并为多个用户工作，但现在我什至无法让简单的版本工作。当然，它在以 root 身份运行时有效。它曾经在以用户“用户”身份运行时可以工作，但现在不行了。我明白了：
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
回答by Amos Shapira
There is a pretty comprehansive answer at https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts
https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts有一个非常全面的答案
Bottom line is that there are two main points against it:
最重要的是，有两个要点反对它：
- 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.
- 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.
- 内核打开文件以查找应执行的解释器与解释器打开文件以读取脚本之间的竞争条件。
- 在没有适当检查的情况下执行许多外部程序的 Shell 脚本可能会被愚弄执行错误的程序（例如使用恶意的 PATH），或者以破坏的方式扩展变量（例如变量值中有空格），并且通常它对如何执行的控制较少它执行的外部程序处理输入。
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 -ito a suid shell script. That's possibly the original trigger for this being prohibited.
从历史上看，原始 Bourne shell 中有一个著名的错误（至少在 4.2BSD 上，这是我在那里看到的），它允许任何人通过创建一个调用-isuid shell 脚本的符号链接来获得交互式 root shell 。这可能是被禁止的最初触发因素。
EDIT: To answer "How do I fix it" - configure sudoto allow users to execute only these scripts as user root, and perhaps use a trick like in https://stackoverflow.com/a/4598126/164137to 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 user1from executing the scripts and passing them users2's directory)
编辑：回答“我如何修复它” - 配置sudo为仅允许用户以 user 身份执行这些脚本root，并且可能使用https://stackoverflow.com/a/4598126/164137 中的技巧来查找原始用户名并强制操作它们自己的主目录，而不是让它们传入任何任意输入（即在它们的当前状态下，没有什么可以阻止user1执行脚本并传递它们users2的目录）
