Perché cp non rispetta gli ACL?

Un modo comune per impostare una directory per la condivisione di file all'interno di un gruppo è:

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

Ciò garantisce che tutti i file creati foosiano leggibili e scrivibili dal gruppo 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

Tuttavia, se si copia un file in foo, gli ACL predefiniti non vengono applicati:

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

Perché questo accade e c'è un modo per aggirarlo?

(Lo spostamento di un file nella directory non rispetta né gli ACL né la proprietà del gruppo, ma posso capire perché: potresti non voler cambiare le autorizzazioni di un file semplicemente perché ne cambi il nome.)

Se cpcrea il file di destinazione, replica le autorizzazioni del file di origine, ad eccezione dei bit impostati in umask. Questo è un comportamento standard (vedere ad esempio il passaggio 3.b della specifica Single Unix v3 (POSIX 2001) .

Perché cp è stato progettato in questo modo? Perché ci sono molti casi in cui questo comportamento è desiderabile, ad esempio preservare la privacy di un file quando le autorizzazioni originali sono restrittive e preservare l'eseguibilità è quasi sempre la cosa giusta da fare. È tuttavia un peccato che nemmeno GNU cp abbia un'opzione per disattivare questo comportamento.

La maggior parte degli strumenti di copia (ad es. Pax, rsync) si comporta allo stesso modo. Puoi assicurarti che il file verrà creato con l'autorizzazione predefinita disaccoppiando l'origine dalla destinazione, ad esempio con cat <baz >foo/baz.

Bene, un bambino di tre anni e più domande ma ancora rilevante. Per i lettori futuri, voglio aggiungere che ci si aspetta che i comandi mv, cp non seguano l'ACL della directory di destinazione. La risposta di Gilles va bene, tranne l'ultima frase. Il modo migliore per applicare l'ACL di destinazione al file copiato / spostato è il modo menzionato qui:

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

Nel caso in cui il collegamento venga interrotto in futuro, incollo il contenuto qui:

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

copia ACL di un file su un altro usando getfacl e setfacl

ATTENZIONE: l'ACL esistente andrà perso.

Ho avuto un problema simile con i file rsynced privi degli ACL predefiniti appropriati nella sottodirectory di destinazione. Cp non ha un modo di impostare le autorizzazioni sulla destinazione. Ma rsync lo fa, usando la --chmod=ugo=rwxbandiera. Vedi la mia risposta qui .

Devi usare -po --preservecon cp.

Da man 5 acl:

MODIFICHE ALLE UTILITÀ DEL FILE

 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.

Gli ACL si stanno propagando correttamente, ma la maschera predefinita non sembra essere corretta. Probabilmente vuoi che la tua maschera predefinita sia rwX.

setfacl -dm m::rwX foo

Se ciò non funziona, si prega di pubblicare l'ACL per foo.

Il tuo filesystem è montato con l'opzione "ACL" abilitata?

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

In caso contrario, apportare la modifica, quindi rimontare.

mount -o remount /wherefolderislocated

Da quello che vedo tu sei il proprietario dei file (bhm) prima e dopo il cp. Come mostra l'elenco delle directory, il proprietario ha accesso in lettura e scrittura!