グループ内のファイル共有用のディレクトリを設定する一般的な方法は、次のとおりです。
$ mkdir foo
$ chgrp felles foo
$ chmod g+ws foo
$ setfacl -m group:felles:rwx foo
$ setfacl -dm group:felles:rwx foo
これにより、foo
で作成されたファイルはすべて、グループfelles
による読み取りと書き込みが可能になります。
$ umask
0022
$ echo hi > foo/bar
$ ls -l foo
total 4
-rw-rw-r--+ 1 bhm felles 3 2010-09-23 00:18 bar
ただし、ファイルをfoo
にコピーした場合、デフォルトのACLは適用されません。
$ echo you > baz
$ cp baz foo/
$ ls -l foo
total 8
-rw-rw-r--+ 1 bhm felles 3 2010-09-23 00:18 bar
-rw-r--r--+ 1 bhm felles 4 2010-09-23 00:19 baz
$ getfacl foo/baz
# file: foo/baz
# owner: bhm
# group: felles
user::rw-
group::rwx #effective:r--
group:felles:rwx #effective:r--
mask::r--
other::r--
なぜこれが起こるのですか?それを回避する方法はありますか?
(移動ファイルをディレクトリに移動しても、ACLもグループ所有権も考慮されませんが、その理由は理解できます。ファイルの名前を変更しただけで、ファイルのアクセス許可を変更したくない場合があります。)
cp
が宛先ファイルを作成する場合、umaskで設定されているビットを除いて、ソースファイルの権限を複製します。これは標準の動作です(たとえば、 Single Unix v3(POSIX 2001)仕様のステップ3.bを参照 。
なぜcpはこのように設計されたのですか?たとえば、元のアクセス許可が制限されている場合にファイルのプライバシーを保持し、実行可能性を保持することはほとんど常に正しいことです。ただし、GNU cpにもこの動作をオフにするオプションがないことは残念です。
ほとんどのコピーツール(pax、rsyncなど)は同じように動作します。たとえばcat <baz >foo/baz
を使用して、ソースを宛先から分離することにより、ファイルがデフォルトの権限で作成されるようにすることができます。
さて、3歳以上の質問ですが、まだ関連性があります。将来の読者のために、mv、cpコマンドが宛先ディレクトリのACLに従っていないことが予想されることを付け加えておきます。 Gillesの答えはすべて最後の文を除いて結構です。宛先のACLをコピー/移動したファイルに適用するためのより良い方法は、次の方法です。
リンクが壊れた場合に備えて、ここにコンテンツを貼り付けます。
getfacl <file-with-acl> | setfacl -f - <file-with-no-acl>
getfaclおよびsetfaclを使用して、あるファイルのACLを別のファイルにコピーします
警告:既存のACLは失われます。
ターゲットのサブディレクトリに適切なデフォルトACLがないrsyncされたファイルで同様の問題がありました。 Cpには、ターゲットに権限を設定する方法がありません。しかし、rsyncは--chmod=ugo=rwx
国旗。私の答えを見てください ここ 。
cp
とともに-p
または--preserve
を使用する必要があります。
man 5 acl
から:
ファイルユーティリティの変更
On a system that supports ACLs, the file utilities ls(1), cp(1), and mv(1) change their behavior in the following way: · For files that have a default ACL or an access ACL that contains more than the three required ACL entries, the ls(1) utility in the long form produced by ls -l displays a plus sign (+) after the permission string. · If the -p flag is specified, the cp(1) utility also preserves ACLs. If this is not possible, a warning is produced. · The mv(1) utility always preserves ACLs. If this is not possible, a warning is produced. The effect of the chmod(1) utility, and of the chmod(2) system call, on the access ACL is described in CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS.
ACLは正しく伝達されていますが、デフォルトのマスクが正しくないようです。デフォルトのマスクをrwXにしたいと思うでしょう。
setfacl -dm m::rwX foo
それが機能しない場合は、fooのACLを投稿してください。