我创建了这个简单的脚本来允许用户在他的主目录中删除网络服务器创建的文件,而不需要给他“su”。两个脚本都设置为 "chmod 4750" .
最疯狂的是,它们曾经有效,但现在却无效了。这是脚本:
#!/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
最佳答案
https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts 上有一个非常全面的答案
底线是反对它的主要观点有两个:
- 内核打开文件以查找应执行哪个解释器与解释器打开文件以读取脚本之间的竞争条件。
- 在没有进行适当检查的情况下执行许多外部程序的 Shell 脚本可能会被骗去执行错误的程序(例如使用恶意的 PATH),或者以错误的方式扩展变量(例如变量值中有空格),并且通常它有更少的控制它执行的外部程序如何处理输入。
从历史上看,原始 Bourne shell 中有一个著名的错误(至少在 4.2BSD 上,这是我实际看到的),它允许任何人通过创建一个名为 -i
的符号链接(symbolic link)来获得交互式根 shell。到 suid shell 脚本。这可能是禁止这样做的最初触发因素。
编辑:回答“我该如何修复”- 配置 sudo
允许用户以用户身份仅执行这些脚本 root
, 也许使用类似 https://stackoverflow.com/a/4598126/164137 中的技巧找到原始用户的名称并在他们自己的主目录上强制操作,而不是让他们传入任何任意输入(即在他们当前的状态下,您在问题中包含的脚本中没有任何内容阻止 user1
执行脚本并传递他们 users2
的目录,或与此相关的任何目录)
关于bash - 为什么我的 setuid root bash shell 脚本不起作用?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/33565729/