☰

为什么 root 用户被拒绝访问文件？

tag-icon • tag-icon permissions root chown
为什么 root 用户被拒绝访问文件？

我想了解在什么情况下可以拒绝 root 访问文件。我正在使用一台我没有配置的机器（在我的个人笔记本电脑上，我显然没有这个问题），我遇到了这个问题，可以简单地归结为：

touch test.sh &&\
echo 'echo $PATH' >> test.sh &&\
sudo sh test.sh

会出现错误：（sh: 0: Can't open test.sh带有bash: test.sh: Permission denied）bash。

  • 我试着看看我是否在 SELinux 下运行getenforce，但未找到该命令。

  • 我试过了sudo chown root test.sh，但是它给出了错误：chown: cannot access 'test.sh': Permission denied。

  • 尝试更改目录的所有权时发生了同样的事情。

我不一定要求解决整个问题，但我想了解 root 为何会被拒绝某些访问权限。

编辑

在同一台机器上，如果我创建一个本地用户（以上所有操作都是以通过共享网络登录的用户身份完成的），一切都正常。

答案1

总结如果你跑

export PATH=.:$PATH # wrong

那么你上面提到的命令集将会~~工作~~但是避免使用这个解决方案...为什么？...当你运行一个可执行文件时，给它一个完整的路径

/my/cool/binary

或相对路径

./../cool/binary # notice this begins with a ./  period slash

你可以直接控制可执行文件的来源...但是如果由于错误或某些恶意进程，你的环境变量 PATH 会被更新为在目录前面添加一个包含名称匹配的可执行文件（错误或恶意）的目录

export PATH=/wrong/dir:/hackers/own/dir:$PATH

你只需使用

myexecutable_name  # using naked binary name

你可能正在运行

/wrong/dir/myexecutable_name

当你打算跑步时

/actual/good/dir/myexecutable_name

这就是为什么生产代码或以 root 身份运行的任何内容都应该明确说明二进制文件的来源

现在回到你最初的问题...你的代码假设 PATH 包含当前目录 '.'，而它不应该包含 prod ids 或 root

export PATH=.:$PATH # wrong - bad for root or prod id yet handy for dev folks

而是使用完整路径执行...问题是，当您打算从 PATH 中定义的标准目录运行二进制文件时，您想避免运行错误的二进制文件的可能性，而该二进制文件恰好位于您当前目录中

不相信？花点时间处理关键基础设施代码，尤其是那些处于职责交叉点的代码……其中团队 B 的二进制文件正在执行团队 A 的二进制文件，你总是会看到使用的完整路径……另一个灵感是加强命名空间冲突

相关内容