Azure NetApp Files のモード ビットについて
NFS のファイル アクセス許可では、NAS ボリュームがマウントされた後にユーザーとグループが実行できる操作が制限されます。 モード ビットは、Azure NetApp Files の NFS ファイルアクセス許可の重要な機能です。
NFS モード ビット
NFS のモード ビットのアクセス許可は、アクセス制御の標準的な数値表現を使用して、ファイルとフォルダーに対する基本的なアクセス許可を提供します。 モード ビットは NFSv3 または NFSv4.1 で使用できますが、モード ビットは RFC-1813 で定義されている NFSv3 をセキュリティで保護するための標準オプションです。 次の表は、これらの数値がアクセス制御にどのように対応するかを示しています。
| モード ビット数値 |
|---|
| 1 – 実行 (x) |
| 2 – 書き込み (w) |
| 3 – 書き込み/実行 (wx) |
| 4 – 読み取り (r) |
| 5 – 読み取り/実行 (rx) |
| 6 – 読み取り/書き込み (rw) |
| 7 – 読み取り/書き込み/実行 (rwx) |
数値は、アクセス制御のさまざまなセグメント (所有者、グループ、およびその他のすべてのユーザー) に適用されます。つまり、基本的な NFSv3 には細かいユーザー アクセス制御が適用されません。 次の図は、NFSv3 オブジェクトで使用するためにモード ビット アクセス制御を構築する方法の例を示しています。
Azure NetApp Files では、POSIX ACL はサポートされていません。 したがって、NFSv3 では、Active Directory LDAP などのネーム サービスを介して有効な UNIX と Windows 名のマッピングを持つ NTFS セキュリティ スタイル のボリュームを使用する場合にのみ、詳細な ACL を使用できます。 または、Azure NetApp Files と NFSv4.1 ACL で NFSv4.1 を使用することもできます。
次の表では、NFSv3 モード ビットと NFSv4.x ACL の間のアクセス許可の粒度を比較します。
| NFSv3 モード ビット | NFSv4.x ACL |
|---|---|
|
|
詳細については、「NFSv4.x アクセス制御リスト ACL について」を参照してください。
スティッキー ビット、setuid、setgid
NFS マウントでモード ビットを使用する場合、ファイルとフォルダーの所有権は、ファイルとgidフォルダーをuid作成したユーザーに基づいています。 さらに、プロセスが実行されると、プロセスは開始したユーザーとして実行されるため、対応するアクセス許可が与えられます。 特殊なアクセス許可 (、setgidスティッキー ビットなどsetuid) を使用すると、この動作を制御できます。
Setuid
ビットは setuid 、権限の所有者ビットの実行部分の "s" によって指定されます。 この setuid ビットを使用すると、ユーザーがファイルを実行しようとするのではなく、ファイルの所有者として実行可能ファイルを実行できます。 たとえば、 /bin/passwd アプリケーションでは既定でビットが setuid 有効になっているため、ユーザーがパスワードを変更しようとすると、アプリケーションがルートとして実行されます。
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
ビットが setuid 削除されると、パスワード変更機能が正しく機能しません。
# ls -la /bin/passwd
-rwxr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password:
New password:
Retype new password:
passwd: Authentication token manipulation error
passwd: password unchanged
ビットが setuid 復元されると、passwd アプリケーションは所有者 (ルート) として実行され、正常に動作しますが、passwd コマンドを実行しているユーザーに対してのみ動作します。
# chmod u+s /bin/passwd
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
# su user2
user2@parisi-ubuntu:/mnt$ passwd user1
passwd: You may not view or modify password information for user1.
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password:
New password:
Retype new password:
passwd: password updated successfully
Setuid はディレクトリには影響しません。
Setgid
このビットは setgid 、ファイルとディレクトリの両方で使用できます。
ディレクトリでは、setgid を使用して、ビット セットを持つ親ディレクトリの下に作成されたファイルとフォルダーの所有者グループを継承する方法として使用できます。 同様 setuidに、実行可能ビットは "s" または "S" に変更されます。
Note
大文字 "S" は、ディレクトリのアクセス許可が "6" または "rw" の場合など、実行可能ビットが設定されていないことを意味します。
次に例を示します。
# chmod g+s testdir
# ls -la | grep testdir
drwxrwSrw- 2 user1 group1 4096 Oct 11 16:34 testdir
# who
root ttyS0 2023-10-11 16:28
# touch testdir/file
# ls -la testdir
total 8
drwxrwSrw- 2 user1 group1 4096 Oct 11 17:09 .
drwxrwxrwx 5 root root 4096 Oct 11 16:37 ..
-rw-r--r-- 1 root group1 0 Oct 11 17:09 file
ファイルの場合、setgid は、グループ所有者のグループアクセス許可を使用して実行される実行可能ファイルと同様 setuidに動作します。 ユーザーが所有者グループに含まれている場合、setgid が設定されている場合、そのユーザーは実行可能ファイルを実行するアクセス権を持っています。 グループに含まれていない場合は、アクセスできません。 たとえば、管理者がクライアントでコマンドを実行できるユーザーを mkdir 制限する場合は、setgid を使用できます。
通常、 /bin/mkdir ルート所有権を持つ 755 のアクセス許可があります。 つまり、すべてのユーザーがクライアントで実行 mkdir できます。
# ls -la /bin/mkdir
-rwxr-xr-x 1 root root 88408 Sep 5 2019 /bin/mkdir
コマンドを実行 mkdir できるユーザーを制限するように動作を変更するには、アプリケーションを所有するグループを mkdir 変更し、アクセス許可 /bin/mkdir を 750 に変更してから、setgid ビットを < a0/> に mkdir追加します。
# chgrp group1 /bin/mkdir
# chmod g+s /bin/mkdir
# chmod 750 /bin/mkdir
# ls -la /bin/mkdir
-rwxr-s--- 1 root group1 88408 Sep 5 2019 /bin/mkdir
その結果、アプリケーションは次のアクセス許可 group1で実行されます。 ユーザーがメンバー group1でない場合、ユーザーは実行 mkdirにアクセスできません。
User1 はメンバー group1ですが、 user2 次のメンバーではありません。
# id user1
uid=1001(user1) gid=1001(group1) groups=1001(group1)
# id user2
uid=1002(user2) gid=2002(group2) groups=2002(group2)
この変更後は実行できますが、実行できませんgroup1user2。 user1 user2 mkdir
# su user1
$ mkdir test
$ ls -la | grep test
drwxr-xr-x 2 user1 group1 4096 Oct 11 18:48 test
# su user2
$ mkdir user2-test
bash: /usr/bin/mkdir: Permission denied
スティッキー ビット
スティッキー ビットはディレクトリにのみ使用され、使用すると、モード ビットのアクセス許可に関係なく、そのディレクトリで変更できるファイルを制御します。 スティッキー ビットが設定されている場合、ファイルのアクセス許可が "777" と表示されている場合でも、ファイルの所有者 (およびルート) のみがファイルを変更できます。
次の例では、ディレクトリ "sticky" は Azure NetApp Fils ボリュームに存在し、幅広いオープン アクセス許可を持っていますが、スティッキー ビットが設定されています。
# mkdir sticky
# chmod 777 sticky
# chmod o+t sticky
# ls -la | grep sticky
drwxrwxrwt 2 root root 4096 Oct 11 19:24 sticky
フォルダー内には、異なるユーザーが所有するファイルがあります。 すべてのユーザーには 777 のアクセス許可があります。
# ls -la
total 8
drwxrwxrwt 2 root root 4096 Oct 11 19:29 .
drwxrwxrwx 8 root root 4096 Oct 11 19:24 ..
-rwxr-xr-x 1 user2 group1 0 Oct 11 19:29 4913
-rwxrwxrwx 1 UNIXuser group1 40 Oct 11 19:28 UNIX-file
-rwxrwxrwx 1 user1 group1 33 Oct 11 19:27 user1-file
-rwxrwxrwx 1 user2 group1 34 Oct 11 19:27 user2-file
通常、誰でもこれらのファイルを変更または削除できます。 ただし、親フォルダーには固定ビットが設定されているため、ファイルの所有者のみがファイルを変更できます。
たとえば、user1 は次の変更や削除 user2-fileを行うことはできません。
# su user1
$ vi user2-file
Only user2 can modify this file.
Hi
~
"user2-file"
"user2-file" E212: Can't open file for writing
$ rm user2-file
rm: can't remove 'user2-file': Operation not permitted
逆に、ファイルを所有せず、 user2 固定ビットが親ディレクトリに設定されているため、変更も削除 user1-file もできません。
# su user2
$ vi user1-file
Only user1 can modify this file.
Hi
~
"user1-file"
"user1-file" E212: Can't open file for writing
$ rm user1-file
rm: can't remove 'user1-file': Operation not permitted
ただし、ルートは引き続きファイルを削除できます。
# rm UNIX-file
ファイルを変更する root の機能を変更するには、Azure NetApp Files エクスポート ポリシールールを使用してルートを別のユーザーにスカッシュする必要があります。 詳細については、ルートスカッシュを参照してください。
Umask
NFS 操作では、アクセス許可は、数値属性を利用してファイルとフォルダーへのアクセスを決定するモード ビットを使用して制御できます。 これらのモード ビットは、読み取り、書き込み、実行、および特殊な属性を決定します。 数値では、アクセス許可は次のように表されます。
- Execute = 1
- 読み取り = 2
- 書き込み = 4
アクセス許可の合計は、上記の組み合わせを加算または減算することによって決定されます。 次に例を示します。
- 4 + 2 + 1 = 7 (すべてを実行できます)
- 4 + 2 = 6 (読み取り/書き込み)
詳細については、「UNIX 権限ヘルプ」を参照してください。
Umask は、管理者がクライアントに許可されるアクセス許可のレベルを制限できる機能です。 既定では、ほとんどのクライアントの umask は 0022 に設定されています。 0022 は、そのクライアントから作成されたファイルにその umask が割り当てられていることを意味します。 umask は、オブジェクトの基本権限から減算されます。 ボリュームに 0777 アクセス許可があり、NFS を使用して umask が 0022 のクライアントにマウントされている場合、クライアントからそのボリュームに書き込まれたオブジェクトは 0755 アクセス (0777 - 0022) になります。
# umask
0022
# umask -S
u=rwx,g=rx,o=rx
ただし、多くのオペレーティング システムでは、実行アクセス許可を持つファイルの作成は許可されていませんが、フォルダーには適切なアクセス許可が付与されます。 したがって、umask 0022 で作成されたファイルのアクセス許可は 0644 になる可能性があります。 次の例では、RHEL 6.5 を使用します。
# umask
0022
# cd /cdot
# mkdir umask_dir
# ls -la | grep umask_dir
drwxr-xr-x. 2 root root 4096 Apr 23 14:39 umask_dir
# touch umask_file
# ls -la | grep umask_file
-rw-r--r--. 1 root root 0 Apr 23 14:39 umask_file