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
期待どおりの動作が得られます。
LinuxのACLとマスク というタイトルのこの例を見つけました。この記事では、ACLとumask
が相互にどのように相互作用するかを理解するのに役立つ次の例を示します。
Linuxシステムでファイルが作成されると、デフォルトのパーミッション_0666
_が適用されますが、ディレクトリが作成されると、デフォルトのパーミッション_0777
_が適用されます。
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です。
ディレクトリに同じ概念を適用できますが、デフォルトのアクセス許可が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
_)が残っています。
次に、ディレクトリを作成して、デフォルトの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()
関数を呼び出しているためです。
chmod
を使用して手動で設定することです。セキュリティ上の理由から、Linuxオペレーティングシステムでは、実行ビットを含むファイルの自動作成は許可されていません。これは、サイバー攻撃者がサーバーにアクセスした場合に、そのようなファイルにプログラムを書き込んで実行するのを防ぐためです。これは単なる安全対策です。 chmodユーティリティを使用してファイルを作成した後、ファイルに実行ビットを手動で設定する必要があります。