☰

作为普通用户，我为什么能够更改文件的所有权？

tag-icon • tag-icon linux permissions nfs chown san
作为普通用户，我为什么能够更改文件的所有权？

我有一个从 Netapp SAN 通过 NFS 安装的分区。我可以在该分区中创建文件，并且可以将这些文件 chown 给另一个用户、任何用户，甚至 root。我怎样才能做到这一点？我以为内核会阻止这样的事情发生。我今天一次又一次地这样做，在文件上使用多个用户 ID。

我无法在 /tmp 或本地安装的主目录中执行此操作。

我以前从未见过这种行为。另外，我注意到在这台机器上找不到 setcap/getcap。

我检查了我的 shell 的功能，它们都是 0：

$ echo $$
15007
$ cat /proc/15007/task/15007/status 
Name:   bash
State:  S (sleeping)
SleepAVG:       98%
Tgid:   15007
Pid:    15007
PPid:   14988
TracerPid:      0
Uid:    71579   71579   71579   71579
Gid:    10000   10000   10000   10000
FDSize: 256
Groups: 9000 10000 10001 10013 10018 10420 24611 36021 
...
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000

我在 Red Hat 5.3 虚拟机上：

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.3 (Tikanga)

运行旧内核：

$ uname -r
2.6.18-274.7.1.el5

NFS 挂载使用默认值：

$ cat /etc/fstab
...
mynetapp00:/home /mnt/home nfs defaults 0 0

对于用户身份验证，我们在 Linux 端使用 Windows Active Directory 和 ldap：

$ grep passwd /etc/nsswitch.conf 
passwd:     files ldap

我可以用 sudo 做任何事情：

User mikes may run the following commands on this host:
    (ALL) ALL

因为我是管理员之一（/etc/sudoers 的内容）：

User_Alias      ADMINS = fred, tom, mikes
ADMINS          ALL=(ALL) ALL

...但我不知道这是怎么回事，因为 sudo 不参与其中。无论如何，我能够创建一个文件并以用户“john”的身份授予它我的所有权，该用户在 /etc/sudoers 中找不到：

# grep john /etc/sudoers
# su - john
$ touch /mnt/home/blah
$ chown mikes /mnt/home/blah   
$ ls -l /mnt/home/blah
-rwxrwxrwx 1 mikes DomainUsers 0 Oct 23 19:45 /mnt/home/blah

...并且 chown 没有别名（但我们知道，因为如果 chown 是别名或其他程序，那么我也可以更改 /tmp 中的所有权）：

$ alias
alias l.='ls -d .* --color=tty'
alias ll='ls -l --color=tty'
alias ls='ls --color=tty'
alias vi='vim'
alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'
$ which chown
/bin/chown

PS我不是在开玩笑：

$ id
uid=71579(mikes) gid=10000(DomainUsers)
$ touch /mnt/home/blah
$ chown john /mnt/home/blah
$ ls -l /mnt/home/blah
-rwxrwxrwx 1 john DomainUsers 0 Oct 23 19:04 /mnt/home/blah
$ id john
uid=37554(john) gid=10000(DomainUsers)
$ chmod 755 /mnt/home/blah
chmod: changing permissions of `/mnt/home/blah': Operation not permitted
$ rm /mnt/home/blah
$ ls -l /mnt/home/blah
ls: /mnt/home/blah: No such file or directory
$ touch /tmp/blah
$ chown john /tmp/blah
chown: changing ownership of `/tmp/blah': Operation not permitted

答案1

是的，chown这是内核的权限，但请记住，NetApp 超出了内核的范围。对于本地文件系统，内核将用户 I/O 请求转换为本地硬件 I/O 操作（在存储设备上）。对于远程（例如，NFS）文件系统，内核将用户 I/O 请求转换为网络通信，要求/告诉服务器执行用户想要的操作。

无法保证服务器会按照请求执行。例如，NetApp 服务器可以配置为同时支持 Unix 样式权限和 Windows 样式权限。 Unix/Linux 客户端将看到 Unix 风格的权限（用户、组、模式，也许还有 ACL）。 Windows 客户端将看到 Windows 样式的权限（用户但不是组、属性、ACL，可能还包括扩展属性）。 NetApp 在内部存储文件属性的组合，并根据某些模糊的专有算法强制访问，因此 Unix 操作可能会因为 Unix 客户端看不到的 Windows 样式权限限制而被拒绝。

长话短说
NetApp 服务器强制执行权限。因此，NetApp 的 NFS 驱动程序可能不会编写为执行任何权限检查，而是发送全部用户向服务器发出请求。因此，允许执行的决定chown可能 100% 由 NetApp 完成。

我不知道为什么会发生这种情况。这可能是一个错误。这会让我有点惊讶，因为 NetApp 已经存在 25 年了；我希望现在就可以报告并修复这么大的错误。它可能是 NetApp 上的配置设置。这实际上没有意义，但也许服务器的管理员不太明白他在做什么（或者可能有一些模糊的策略原因为什么会这样配置）。

答案2

另一个猜测是 NFS 匿名访问直接映射到 uid 0（又名 root），因此您可以根据需要进行 chown，这可以使用 anonuid nfs 服务器配置参数并在 netapp 中使用导出策略配置来完成。

另请注意：您粘贴的 shell 输出并不能证明所有者已更改，您在运行“chown”之前没有运行“ls -l”，因此另一种可能性是您匿名访问了 NFS 导出，并且服务器配置为映射匿名访问用户名“john”，因此 chown 命令无需更改任何内容。

参考文献：

https://serverfault.com/questions/539267/nfs-share-with-root-for-anonuid-anongid

https://kb.netapp.com/app/answers/answer_view/a_id/1029865/~/how-to-create-a-root-squash-export-policy-rule-on-clustered-data-ontap-

https://linux.die.net/man/5/exports

答案3

这可能会带来一些启示。我用sshfs。它允许我使用ssh.

每当我这样做的时候。所有文件操作均由我用来挂载文件系统的远程计算机上的用户控制。所以如果我这样做：

sshsf «remote-user-name»@«remote-machine-name»:~ «local-mount-point»

然后所有操作都以远程用户身份完成。并sudo没有什么区别。

如果远程用户具有升级的权限，则任何获得挂载访问权限的本地用户都将拥有这些升级的权限。

相关内容