umaskはACLにどのような影響を与えますか?

umaskはACLにどのような影響を与えますか?

umaskACLの有効化が新しく作成されたファイルのデフォルトマスクにどのような影響を与えるかを誰かが説明できますか?これに関する文書はありますか?

例:

$ mkdir test_dir && cd test_dir
$ setfacl -m d:someuser:rwx -m u:someuser:rwx .  # give access to some user
$ getfacl .
# file: .
# owner: myUsername
# group: myGroup
user::rwx
user:someuser:rwx
group::---
mask::rwx
other::---
default:user::rwx
default:user:someuser:rwx
default:group::---
default:mask::rwx
default:other::---
$ umask # show my umask
077
$ echo "main(){}" > x.c # minimal C program
$ make x # build it
cc     x.c   -o x
$ getfacl x
# file: x
# owner: myUsername
# group: myGroup
user::rwx
user:someuser:rwx           #effective:rw-
group::---
mask::rw-
other::---

私は予測するmask:rwx。実際には、たとえばumask設定した後に027予想される動作を取得します。

答え1

次のタイトルの例を見つけました。LinuxのACLとMASK。この記事では、umaskACLとACLがどのようにやり取りするかを理解するのに役立つ次の例について説明します。

背景

Linuxシステムでは、ファイル作成時に0666基本権限が適用され、ディレクトリ作成時には0777基本権限が適用されます。

例1 - ファイル

umaskを077に設定し、ファイルに触れるとしましょう。これにより、strace実際に何が起こっているのかを確認できます。

$ umask 077; strace -eopen touch testfile 2>&1 | tail -1; ls -l testfile
open("testfile", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3
-rw-------. 1 root root 0 Sep 4 15:25 testfile

この例では、システムコールはopen()権限0666で行われていますが、カーネルumask 077がその権限を適用すると、次の権限が削除され(---rwxrwx0600のみ)残ることがわかりますrw-------

例 - 2 目次

デフォルト権限が0666ではなく0777であることを除いて、同じ概念がディレクトリに適用されます。

$ umask 022; strace -emkdir mkdir testdir; ls -ld testdir
mkdir("testdir", 0777)                  = 0
drwxr-xr-x 2 saml saml 4096 Jul  9 10:55 testdir

今回はmkdirコマンドを使用します。その後、コマンドはmkdirシステムコールを呼び出しますmkdir()。上記の例では、mkdirコマンドがmkdir()デフォルト権限0777()でシステムコールを呼び出すことがわかりますrwxrwxrwx。今回は、次の権限に対するumaskが削除されたため、022ディレクトリの作成時に----w--w-0755()が残ります。rwxr-xr-x

例3(基本ACL適用)

次に、ディレクトリを作成し、デフォルトのACLとその中のファイルがディレクトリに適用されたときに何が起こるかを見てみましょう。

$ mkdir acldir
$ sudo strace -s 128 -fvTttto luv setfacl -m d:u:nginx:rwx,u:nginx:rwx acldir

$ getfacl --all-effective acldir
# file: acldir
# owner: saml
# group: saml
user::rwx
user:nginx:rwx          #effective:rwx
group::r-x          #effective:r-x
mask::rwx
other::r-x
default:user::rwx
default:user:nginx:rwx      #effective:rwx
default:group::r-x      #effective:r-x
default:mask::rwx
default:other::r-x

それではファイルを作成しましょうaclfile

$ strace -s 128 -fvTttto luvly touch acldir/aclfile

# view the results of this command in the log file "luvly"
$ less luvly

次に、新しく作成されたファイルに対する権限を取得します。

$ getfacl --all-effective acldir/aclfile 
# file: acldir/aclfile
# owner: saml
# group: saml
user::rw-
user:nginx:rwx          #effective:rw-
group::r-x          #effective:r--
mask::rw-
other::r--

マスクに注意してくださいmask::rw-mask::rwxディレクトリが作成されたときと同じではないのはなぜですか?

luvlyログファイルを確認して、ファイルの作成時に使用されたデフォルト権限を確認してください。

$ less luvly |grep open |tail -1
10006 1373382808.176797 open("acldir/aclfile", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3 <0.000060>

これが少し混乱する場所です。ディレクトリを作成するためにマスクを設定すると、ファイルの作成とrwx同じ動作が予想されますが、そうではありません。これは、カーネルがopen()デフォルト権限で実行されているためです0666

結論として

  • ファイルに実行権限(ブロックまたは有効)は付与されません。 ACL、umask、またはマスクとACLのどちらを使用するかは重要ではありません。
  • ディレクトリは実行権限を取得できますが、これはマスクフィールドの設定方法によって異なります。
  • ACL権限に従ってファイルの実行権限を設定する唯一の方法は、手動で設定することですchmod

引用する

答え2

セキュリティ上の理由から、Linuxオペレーティングシステムは実行ビットを含むファイルの自動生成を許可しません。これは、サイバー攻撃者がサーバーにアクセスしたときにそのファイルにプログラムを作成して実行するのを防ぐためです。これは安全予防措置にすぎません。 chmodユーティリティを使用してファイルを生成したら、常にファイルの実行ビットを手動で設定する必要があります。

関連情報