通常のユーザーとして、ファイルの所有権を変更できるのはなぜですか？
NetappSANからNFSマウントされたパーティションがあります。そのパーティションにファイルを作成し、それらのファイルを別のユーザー、任意のユーザー、さらにはrootにchownすることができます。どうすればそうできますか？カーネルはそのようなことを防ぐだろうと思いました。ファイルで複数のユーザーIDを使用して、これを今日何度も繰り返しました。
/ tmpまたはローカルにマウントされているホームディレクトリではこれを実行できません。
私はこれまでこの振る舞いを見たことがありません。また、このマシンにはsetcap/getcapがないことに注意してください。
シェルの機能を確認しましたが、すべて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
私はRedHat5.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側でLDAPを備えたWindows ActiveDirectoryを使用しています。
$ grep passwd /etc/nsswitch.conf
passwd: files ldap
私はSudoとして何かをすることができます：
User mikes may run the following commands on this Host:
(ALL) ALL
私はADMINS（/ etc/sudoersのコンテンツ）の1人だからです：
User_Alias ADMINS = fred, tom, mikes
ADMINS ALL=(ALL) ALL
...しかし、須藤が関与していないので、それがどのようにゲルマインであるかはわかりません。いずれにせよ、ファイルを作成して、/ etc/sudoersにないユーザー「john」としての所有権を与えることができました。
# 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
P.S.冗談じゃないよ：
$ 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
はい、chownはカーネルの範囲ですが、NetAppはカーネルの手の届かないところにあることに注意してください。ローカルファイルシステムの場合、カーネルはユーザーI/O要求をローカルハードウェアI/O操作（ストレージデバイス上）に変換します。リモート（NFSなど）ファイルシステムの場合、カーネルはユーザーI/O要求をネットワーク通信に変換し、サーバーにユーザーが望むことを実行するように要求します。
サーバーが要求どおりに動作するという保証はありません。たとえば、NetAppサーバーは、Unixスタイルのアクセス許可とWindowsスタイルのアクセス許可を同時にサポートするように構成できます。 Unix/Linuxクライアントには、Unixスタイルのアクセス許可（ユーザー、グループ、モード、場合によってはACL）が表示されます。 Windowsクライアントには、Windowsスタイルのアクセス許可（ユーザーは表示されますが、グループ、属性、ACL、および拡張属性は表示されません）が表示されます。 NetAppは、ファイルプロパティの組み合わせを内部的に保存し、いくつかの曖昧な独自のアルゴリズムに基づいてアクセスを強制します。そのため、Unixクライアントが認識できないWindowsスタイルのアクセス許可制限のために、Unix操作が拒否される場合があります。
TL; DR
NetAppサーバーは権限を適用します。したがって、NetAppのNFSドライバーは、アクセス許可チェックを実行せずに、allユーザー要求をサーバーに送信するように作成されている可能性があります。したがって、chownの実行を許可する決定は、おそらくNetAppで100％行われています。
なぜそうなるのかわかりません。バグかもしれません。 NetAppは25年前から存在しているので、それは私を少し驚かせるでしょう。これほど大きなバグが報告され、修正されることを期待しています。 NetAppの構成設定である可能性があります。それは実際には意味がありませんが、サーバーの管理者が自分のしていることを完全に理解していない可能性があります（または、サーバーがこのように構成される理由が不明な場合があります）。
これはいくつかの光を当てるかもしれません。 sshfsを使用します。これにより、sshを使用してリモートマシンからファイルシステムをマウントできます。
私がこれをするときはいつでも。すべてのファイル操作は、ファイルシステムのマウントに使用したリモートマシン上のユーザーによって管理されます。だから私がそうするなら：
sshsf «remote-user-name»@«remote-machine-name»:~ «local-mount-point»
その後、すべての操作はリモートユーザーとして実行されます。そして、Sudoは何の違いもありません。
リモートユーザーが昇格された特権を持っている場合、マウントにアクセスするローカルユーザーは、これらの昇格された特権を持ちます。
もう1つの推測は、NFS匿名アクセスがuid 0 -aka root-に直接マップされるため、好きなようにchownすることができます。これは、anonuid nfs server configパラメーターを使用して、netappでエクスポートポリシーconfigを使用して実行できます。
もう1つの注意：貼り付けたシェル出力は所有者が変更されたことを証明しません。「chown」を実行する前に「ls-l」を実行していません。したがって、NFSエクスポートに匿名でアクセスし、サーバーが匿名でマップするように構成されている可能性があります。ユーザー名「john」へのアクセス。したがって、chownコマンドは何も変更する必要がありませんでした。
参照：
https://serverfault.com/questions/539267/nfs-share-with-root-for-anonuid-anongid