Azure NetApp Files のモード ビットについて

NFS のファイル アクセス許可では、NAS ボリュームがマウントされた後にユーザーとグループが実行できる操作が制限されます。 モード ビットは、Azure NetApp Files の NFS ファイル アクセス許可の重要な機能です。

NFS モード ビット

NFS のモード ビット アクセス許可は、アクセス制御の標準的な数値表現を使用して、ファイルとフォルダーに対する基本的なアクセス許可を提供します。 モード ビットは NFSv3 または NFSv4.1 で使用できますが、モード ビットは RFC-1813 で定義されている NFSv3 をセキュリティで保護するための標準オプションです。 以下の表は、これらの数値がアクセス制御にどのように対応するかを示しています。

数値は、アクセス制御のさまざまなセグメント (所有者、グループ、他のすべてのユーザー) に適用されます。つまり、基本的な 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 の間のアクセス許可の粒度を比較します。

詳細については、「 NFSv4.x アクセス制御リスト ACL について」を参照してください。

スティッキー ビット、setuid、setgid

NFS マウントでモード ビットを使用する場合、ファイルとフォルダーの所有権は、ファイルとフォルダーを作成したユーザーの uid と gid に基づいています。 さらに、プロセスが実行されると、プロセスは開始したユーザーとして実行されるため、対応するアクセス許可が与えられます。 特別なアクセス許可 ( setuid、 setgid、スティッキー ビットなど) を使用すると、この動作を制御できます。

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" に変更されます。

例えば次が挙げられます。

# 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 ビットを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)

この変更後、user1はmkdirを実行できますが、user2がuser2されていないため、group1できません。

# 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 操作では、アクセス許可は、数値属性を利用してファイルとフォルダーへのアクセスを決定するモード ビットを使用して制御できます。 これらのモード ビットは、読み取り、書き込み、実行、および特殊な属性を決定します。 数値では、アクセス許可は次のように表されます。

• 実行 = 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

次のステップ

• NFS を使用して補助的/補足的なグループを理解する
• NFSv4.x アクセス制御リストについて