Dlaczego CP nie szanuje list ACL?

Typowym sposobem konfigurowania katalogu do udostępniania plików w grupie jest:

$ mkdir foo
$ chgrp felles foo
$ chmod g+ws foo
$ setfacl -m group:felles:rwx foo
$ setfacl -dm group:felles:rwx foo

Zapewnia to, że wszystkie utworzone pliki foosą odczytywalne i zapisywane przez grupę 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

Jeśli jednak skopiujesz plik foo, domyślne listy ACL nie zostaną zastosowane:

$ 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--

Dlaczego tak się dzieje i czy można to obejść?

( Przeniesienie pliku do katalogu nie uwzględnia ani list ACL, ani własności grupy, ale rozumiem dlaczego: możesz nie chcieć, aby uprawnienia do pliku były zmieniane tylko dlatego, że zmieniasz jego nazwę).

Jeśli cptworzy plik docelowy, replikuje uprawnienia do pliku źródłowego, z wyjątkiem bitów ustawionych w umask. Jest to standardowe zachowanie (patrz np. Krok 3.b w specyfikacji Single Unix v3 (POSIX 2001)) .

Dlaczego CP zaprojektowano w ten sposób? Ponieważ istnieje wiele przypadków, w których takie zachowanie jest pożądane, na przykład zachowanie prywatności pliku, gdy oryginalne uprawnienia są restrykcyjne, a zachowanie wykonalności jest prawie zawsze właściwe. Szkoda jednak, że nawet GNU cp nie ma możliwości wyłączenia tego zachowania.

Większość narzędzi do kopiowania (np. Pax, rsync) zachowuje się w ten sam sposób. Możesz upewnić się, że plik zostanie utworzony z domyślnym uprawnieniem, oddzielając źródło od miejsca docelowego, na przykład za pomocą cat <baz >foo/baz.

Cóż, trzyletni i więcej pytań, ale wciąż aktualny. Dla przyszłych czytelników chcę dodać, że oczekuje się, że polecenia mv, cp nie będą podążać za listą ACL katalogu docelowego. Odpowiedź Gillesa jest w porządku oprócz ostatniego zdania. Lepszym sposobem zastosowania listy ACL miejsca docelowego do skopiowanego / przeniesionego pliku jest sposób wymieniony tutaj:

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

Jeśli link zostanie zerwany w przyszłości, wklejam tutaj treść:

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

skopiuj ACL jednego pliku do drugiego za pomocą getfacl i setfacl

OSTRZEŻENIE: Istniejące listy ACL zostaną utracone.

Miałem podobny problem z plikami rsynced bez odpowiednich domyślnych list ACL w podkatalogu docelowym. Cp nie ma możliwości ustawienia uprawnień do celu. Ale rsync robi to, używając --chmod=ugo=rwxflagi. Zobacz moją odpowiedź tutaj .

Musisz użyć -plub --preservez cp.

Od man 5 acl:

ZMIANY W UŻYTKOWNIKACH PLIKÓW

 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.

Listy ACL propagują się poprawnie, ale domyślna maska ​​wydaje się nieprawidłowa. Prawdopodobnie chcesz, aby domyślną maską była rwX.

setfacl -dm m::rwX foo

Jeśli to nie zadziała, prześlij ACL do foo.

Czy Twój system plików jest podłączony z włączoną opcją „ACL”?

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

Jeśli nie, dokonaj zmiany, a następnie podłącz ponownie.

mount -o remount /wherefolderislocated

Z tego, co widzę, jesteś właścicielem plików (bhm) przed i po cp. Jak pokazuje katalog, właściciel ma dostęp do odczytu i zapisu!