web-dev-qa-db-ja.com

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もグループ所有権も考慮されませんが、その理由は理解できます。ファイルの名前を変更しただけで、ファイルのアクセス許可を変更したくない場合があります。)

15
bhm

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は失われます。

3
biocyberman

ターゲットのサブディレクトリに適切なデフォルトACLがないrsyncされたファイルで同様の問題がありました。 Cpには、ターゲットに権限を設定する方法がありません。しかし、rsyncは--chmod=ugo=rwx 国旗。私の答えを見てください ここ

1
Eric.chowanski

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

0
Ryan Bair