sudo -u 有缺陷的文件权限
sudo -u flawed file permissions
我在 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
参数的行为与预期的行为不同,我的问题是:
我如何确保在根 shell 中启动的命令得到执行完全,因为它会从另一个用户的 shell 中执行]?
备注:我知道我可以通过修改 umask
来解决这个问题,但这并不能保证我的行为在任意数量的其他情况下都没有差异。
看来 umask 取决于 shell 是否 interactive:
$ 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 也相同。
可以得到用户默认的shell thusly:
$ getent passwd $USER | cut --delimiter=: --fields=7
/bin/bash
合并它们:
$ sudo -u $USER $(getent passwd $USER | cut --delimiter=: --fields=7) -ic umask
0002
显示预期行为的一个漂亮而干净的解决方案是:
sudo su <username> -c '<any commands>'
我在 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
参数的行为与预期的行为不同,我的问题是:
我如何确保在根 shell 中启动的命令得到执行完全,因为它会从另一个用户的 shell 中执行]?
备注:我知道我可以通过修改 umask
来解决这个问题,但这并不能保证我的行为在任意数量的其他情况下都没有差异。
看来 umask 取决于 shell 是否 interactive:
$ 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 也相同。
可以得到用户默认的shell thusly:
$ getent passwd $USER | cut --delimiter=: --fields=7
/bin/bash
合并它们:
$ sudo -u $USER $(getent passwd $USER | cut --delimiter=: --fields=7) -ic umask
0002
显示预期行为的一个漂亮而干净的解决方案是:
sudo su <username> -c '<any commands>'