web-dev-qa-db-ja.com

umaskはACLにどのように影響しますか？

ACLがアクティブ化されている場合、umaskが新しく作成されたファイルのデフォルトマスクにどのように影響するかを誰かに説明できますか？これに関するドキュメントはありますか？

例：

$ 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期待どおりの動作が得られます。

linuxpermissionsposixacl
12
jofel

LinuxのACLとマスク というタイトルのこの例を見つけました。この記事では、ACLとumaskが相互にどのように相互作用するかを理解するのに役立つ次の例を示します。

バックグラウンド

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_がカーネルによって適用されると、次のアクセス許可が削除されます（_---rwxrwx_）そして、残りは_rw-------_別名0600です。

例-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コマンドがデフォルトの権限_0777_（rwxrwxrwx）でmkdir()システムコールを呼び出していることがわかります。今回は_022_のumaskを使用して、次の権限が削除されているため（_----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に設定されていると、ファイルの作成に対して同じ動作が予想されますが、そのようには機能しません。これは、カーネルが_0666_のデフォルトの権限でopen()関数を呼び出しているためです。

要約する

  • ファイルは実行権限（マスキングまたは有効）を取得しません。どの方法を使用するかは関係ありません：ACL、umask、またはマスクとACL。
  • ディレクトリは実行権限を取得できますが、マスキングフィールドの設定方法によって異なります。
  • ACL権限の下にあるファイルの実行権限を設定する唯一の方法は、chmodを使用して手動で設定することです。

参考文献

10
slm

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

2
Arni