sudo -u 有缺陷的文件权限答案

【问题标题】：sudo -u flawed file permissionssudo -u 有缺陷的文件权限
【发布时间】：2017-06-30 13:52:24
【问题描述】：

我在 Lubuntu 16.04 上使用 Bash。 LTS，但我不确定这对这个问题是否很重要。

我注意到，当我以标准用户身份创建文件时，该文件具有 664 权限。但是当我是root用户并通过-u参数为同一个用户执行相同的命令时，它有644个权限，所以该组的写权限丢失了。

我认为这是一个缺陷，因为 sudo 联机帮助页明确指出：

     -u user, --user=user
             Run the command as a user other than the default target user (usually root).  The user may be either a user name or a
             numeric user ID (UID) prefixed with the ‘#’ character (e.g.  #0 for UID 0).  When running commands as a UID, many
             shells require that the ‘#’ be escaped with a backslash (‘\’).  Some security policies may restrict UIDs to those
             listed in the password database.  The sudoers policy allows UIDs that are not in the password database as long as the
             targetpw option is not set.  Other security policies may not support this.

现在我知道 -u 参数的行为与预期的行为不同，我的问题是：

我如何确保在 root shell 中启动的命令能够完全像从另一个用户的 shell 中执行一样执行？

备注：我知道我可以通过修改umask 来解决这个问题，但这并不能保证我的行为在任意数量的其他情况下都不会有所不同。

【问题讨论】：

" 的执行与从另一个用户的 shell 执行时完全一样吗？" -- 执行该用户的 shell。例如“sudo -u user sh -c 'some command'”。请注意，每个用户都指定了自己的 shell。 getent passwd user了解详情
有趣的是，这不起作用 - 文件权限仍然是 644
Stack Overflow 是一个编程和开发问题的网站。这个问题似乎离题了，因为它与编程或开发无关。请参阅帮助中心的What topics can I ask about here。也许Super User 或Unix & Linux Stack Exchange 会是一个更好的提问地点。
我不明白为什么这个问题应该是题外话。是的，它也可能适用于其他一些交换站点，因为在多个交换站点之间接受的主题集的交集是非空的。就您提供的链接而言，这个问题确实涵盖了脚本上下文中的特定编程问题以及程序员常用的软件工具，并且是软件开发独有的实用，可回答的问题。另外，不求调试帮助，明显不是功课，可以复现，不求书本工具。
我真的很高兴你问了这个问题@Wanderer，我刚刚从一本书中了解了文件权限，并且在尝试不同的事情时遇到了相同类型的问题。快疯了。不得不登录另一个用户而不是使用sudo -u <username> mkdir 执行命令来获得我想要的权限，这太荒谬了。

标签： linux bash shell sudo

【解决方案1】：

看起来umask取决于shell是否是交互式：

$ umask
0002
$ sudo -u $USER bash -c umask
0022
$ sudo -u $USER bash -ic umask
0002

这似乎来自/etc/bashrc，它仅适用于umask 002

这不是登录 shell，
UID 大于或等于 200，并且
用户名等于组名，

或来自/etc/profile，如果满足最后两个条件，则应用umask 002。我不确定是否有其他东西覆盖了这一点，因为shopt login_shell 打印的 shell 是否是交互式的都是一样的，而且 UID 也是一样的。

可以获取用户的默认shellthusly：

$ getent passwd $USER | cut --delimiter=: --fields=7
/bin/bash

组合它们：

$ sudo -u $USER $(getent passwd $USER | cut --delimiter=: --fields=7) -ic umask
0002

【讨论】：

对我来说，这行不通：使用您的组合命令，我总是得到umask 0022，无论是从标准用户 shell 还是 root shell 启动，所以它确实与我想要实现的目标相反。此外，如果在 root shell 中启动，我会收到一个错误：bash: /root/.bashrc: Permission denied
好吧，$USER 如果您在 root shell 中运行它，则评估为“root”，因此您必须将 both 的出现替换为您的用户重新有兴趣获得预期的结果。
那么您的系统似乎出了点问题 - 以普通用户身份运行 Bash 永远不应该尝试阅读 /root/.bashrc。
我正在新设置的虚拟机中进行实验以排除这种可能性。我正在做的是：打开一个终端，现在我是标准用户。使用标准用户名而不是$USER 执行命令。然后sudo su 得到一个root shell。以同样的方式执行命令。在新安装的操作系统上，仅此而已。
如果某个 shell 尝试读取 /root/.bashrc，而它不应该出现另一个问题（可能在 unix.SE 或 superuser.SE 上）。运行非 root shell 时不应该发生这种情况。而且我无法在 Fedora 25 桌面上重现这个问题。

【解决方案2】：

一个显示预期行为的漂亮而干净的解决方案是这样的：

sudo su <username> -c '<any commands>'

【讨论】：