Question

我创建了这个简单的脚本，允许用户删除主服务器中的Web服务器创建的文件而不给他“su”。这两个脚本都设置为"chmod 4750"。

最疯狂的是他们DID工作，现在他们没有。这是脚本：

#!/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

我会让它们更高级，为多个用户工作但是现在我甚至无法使简单版本工作。当然以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 ...

和

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

可能是什么问题？

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

Answer 1

https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts

有一个非常全面的答案

底线是反对它的两个要点：

内核打开文件以查找应执行哪个解释器以及解释器打开文件以读取脚本之间的竞争条件。
在没有正确检查的情况下执行许多外部程序的Shell脚本可能被欺骗执行错误的程序（例如使用恶意PATH），或者以破碎的方式扩展变量（例如，在变量值中具有空格），并且通常它具有更少的控制它执行的外部程序处理输入的程度。

从历史上看，最初的Bourne shell中存在一个着名的bug（至少在4.2BSD上，这是我在行动中看到的），它允许任何人通过创建一个名为-i的符号链接来获得交互式root shell一个suid shell脚本。这可能是被禁止的原始触发器。

编辑：要回答“如何修复” - 配置sudo以允许用户仅以用户root执行这些脚本，并且可能使用https://stackoverflow.com/a/4598126/164137中的技巧在他们自己的主目录中找到原始用户的名称和强制操作，而不是让他们传递任何任意输入（即在当前状态下，没有任何阻止user1执行脚本并传递它们users2' s目录）

为什么我的setuid root bash shell脚本不起作用？

1 个答案: