cpがACLを尊重しないのはなぜですか？

グループ内でファイルを共有するためのディレクトリを設定する一般的な方法は次のとおりです。

$ 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を適用するより良い方法は、次の方法です。

http://www.commandlinefu.com/commands/view/4281/copy-acl-of-one-file-to-another-using-getfacl-and-setfacl

将来リンクが壊れた場合には、ここにコンテンツを貼り付けます：

getfacl <file-with-acl> | setfacl -f - <file-with-no-acl>

getfaclおよびsetfaclを使用して、あるファイルのACLを別のファイルにコピーします

警告：既存のACLは失われます。

ターゲットのサブディレクトリに適切なデフォルトACLがないrsyncedファイルで同様の問題が発生しました。Cpには、ターゲットのアクセス許可を設定する方法がありません。ただし、rsyncは--chmod=ugo=rwxフラグを使用します。ここで私の答えをご覧ください。

あなたは使用する必要があります-pか--preserveとcp。

から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を投稿してください。

「ACL」オプションを有効にしてファイルシステムをマウントしていますか？

/dev/sda4        /wherefolderislocated         ext3        defaults,acl     1   2

そうでない場合は、変更してから再マウントします。

mount -o remount /wherefolderislocated

私が見るところから、あなたはcpの前後のファイル（bhm）の所有者です。ディレクトリのリストが示すように、所有者には読み取りおよび書き込みアクセス権があります！