
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 ドライバは権限確認を実行するようには作成されません。みんなユーザーがサーバーに要求します。したがって、実行を許可するかどうかは、chown
NetAppが100%決定できます。
なぜこれが起こるのかわかりません。これはバグかもしれません。 NetAppがリリースされて25年になったので、今のところ、このような大きなバグが報告され修正されると予想していたので、これはやや驚くべきことです。 NetAppの構成設定かもしれません。これは実際には意味がありませんが、サーバー管理者は自分が何をしているのかをよく理解していない可能性があります(またはこのように構成されたあいまいなポリシーの理由があるかもしれません)。
答え2
別の推測は、NFS匿名アクセスがuid 0(つまりルート)に直接マッピングされるため、必要に応じてそれをブロックできることです。これは、anonuid nfsサーバー設定パラメータとnetappのエクスポートポリシー設定を使用して実行できます。
また、注:貼り付けたシェル出力は所有者が変更されたことを証明しません。 「chown」を実行する前に「ls -l」を実行しなかったため、別の可能性は匿名でNFSエクスポートにアクセスし、サーバーが次のように構成されている可能性があります。匿名アクセス ユーザー名 "john" がマップされているため、chown コマンドに対して何も変更する必要はありません。
参考資料:
https://serverfault.com/questions/539267/nfs-share-with-root-for-anonuid-anongid
答え3
これは少し光を照らすことができます。私は使用しますsshfs
。 ssh
.
私がこれをするたびに。すべてのファイル操作は、ファイルシステムのマウントに使用するリモートシステムのユーザーによって制御されます。その場合は、次のようにしてください。
sshsf «remote-user-name»@«remote-machine-name»:~ «local-mount-point»
これにより、すべてがリモートユーザーとして実行されます。他に何もないsudo
。
リモートユーザーに昇格された権限がある場合、マウントアクセス権を取得したすべてのローカルユーザーは昇格された権限を持ちます。