☰

一般ユーザーとしてファイルの所有権を変更できるのはなぜですか？

tag-icon • tag-icon linux permissions nfs chown san
一般ユーザーとしてファイルの所有権を変更できるのはなぜですか？

Netapp SANでNFS経由でパーティションをマウントしました。そのパーティションにファイルを作成し、そのファイルを他のユーザー、すべてのユーザー、さらにはrootに権限を付与できます。どうすればいいですか？私はカーネルがこれが起こるのを防ぐと思いました。私は今日もファイルに複数のユーザー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

私は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が関係していないので何が起こっているのかわかりません。とにかくファイルを作成し、/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

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要求をネットワーク通信に変換し、ユーザーが希望するタスクを実行するようにサーバーに要求/指示します。

サーバーが要求に従うという保証はありません。たとえば、Unix スタイル権限と Windows スタイル権限の両方をサポートするように NetApp サーバーを構成できます。 Unix / Linuxクライアントには、Unixスタイルの権限（ユーザー、グループ、モード、およびACL）が表示されます。 Windowsクライアントは、Windowsスタイルの権限（グループ、属性、ACL、および拡張属性を除くユーザー）を表示できます。 NetAppはファイル属性の組み合わせを内部的に保存し、いくつかのあいまいな独自のアルゴリズムに基づいてアクセスを適用するため、Unixクライアントに表示されないWindowsスタイルの権限の制限によりUnix操作が拒否される可能性があります。

長い話を短く
NetApp サーバーは権限を適用します。したがって、NetApp の NFS ドライバは権限確認を実行するようには作成されません。みんなユーザーがサーバーに要求します。したがって、実行を許可するかどうかは、chownNetAppが100％決定できます。

なぜこれが起こるのかわかりません。これはバグかもしれません。 NetAppがリリースされて25年になったので、今のところ、このような大きなバグが報告され修正されると予想していたので、これはやや驚くべきことです。 NetAppの構成設定かもしれません。これは実際には意味がありませんが、サーバー管理者は自分が何をしているのかをよく理解していない可能性があります（またはこのように構成されたあいまいなポリシーの理由があるかもしれません）。

おすすめ記事