effective i permessi sono formati mettendo in AND i permessi effettivi (reali?) con mask . Dal mask del tuo file è rw- , tutti i effective i permessi hanno x un po' spento.
Risposta breve:se vuoi mascherare con il bit di esecuzione attivo, devi impostarlo esplicitamente usando setfacl dopo touch . La sicurezza vieta la sua impostazione implicita.
setfacl -n -m m::rwx foo
"-n" per sopprimere il ricalcolo della maschera (potrebbe non essere necessario).
"m::rwx" imposta il valore della maschera su 'rwx'. Si noti che "m::x" disabiliterebbe tutte le letture e le scritture.
Non sono in grado di mostrare perché la maschera è "rw-". Presumo che la directory predefinita fosse touch crea il file rimane invariato per l'intero esempio OP.
-
La voce della directory per 'foo' dovrebbe mostrare il proprietario 'root' (a causa del comando sudo e il gruppo 'guardie' perché la directory ha il bit SUID impostato. Le autorizzazioni saranno predefinite '-rw-...r--' con i permessi di gruppo della directory '-...r-x...' (a causa del bit SUID visualizzato come una piccola s).
-
Poi viene l'ACLes, che dovrebbe essere la directory predefinita. Dato che gli ACL ereditano, non mi aspetto che venga creato alcun ACLe e che la maschera ACLE sia la directory predefinita, "rwx".
Ma se vengono creati, mi aspetterei che i nuovi ACLe vengano innescati dall'impostazione predefinita, lasciando di nuovo la maschera su "rwx". Se non sono innescati dai valori predefiniti, ciò sembrerebbe vanificare l'idea di un ACL predefinito:l'ACL "predefinito" fornirebbe solo ACL utente e gruppo denominato.
Questo ora solleva la questione di quale dovrebbe essere la maschera ACLe. Mi aspetto che sia "rwx" dalla voce maschera predefinita. Ma potrebbe essere creato con una maschera vuota, e quindi si applicano tutti i tipi di legalese.
- Con un ACL provvisorio di user::rw-, group::r-x, other::r--, group:wheel:rwx, group:guards:rwx e mask:::(unset), consultiamo il documentazione per
setfacl, supponendo che le stesse regole si applichino alla creazione dei file.
C'è una clausola:
Se un ACL contiene voci utente o gruppo denominato e non esiste alcuna voce maschera, viene creata una voce maschera contenente le stesse autorizzazioni della voce gruppo.
Ciò imposterebbe la maschera ACL su "r-x", se la voce del gruppo ACL è stata creata dalla voce della directory del file, o "r-x" se la voce del gruppo ACL proveniva dall'ACL predefinito. (In ogni caso, in questo caso, il risultato è lo stesso.)
C'è anche una clausola:
Se un ACL predefinito contiene voci utente o gruppo denominato e non esiste alcuna voce maschera, viene aggiunta una voce maschera contenente le stesse autorizzazioni della voce gruppo dell'ACL predefinito predefinito. ... i permessi della voce maschera vengono ulteriormente adattati per includere l'unione di tutti i permessi interessati dalla voce maschera.
Se questa regola si applica, la maschera inizierà come "r-x" (stessa logica) della clausola precedente), quindi verrà adattata per essere "l'unione di tutte le autorizzazioni interessate dalla voce della maschera".
"autorizzazioni influenzate dalla voce maschera" non è definito nel setfacl documentazione del comando. La documentazione POSIX ACL dice:
La maschera è la combinazione di tutti i permessi di accesso del gruppo proprietario e di tutte le voci di utenti e gruppi.
Dando la parola "unione", che è additiva, leggerei "combinazione" come un logico o-ing. In altre parole, se un ACLe di gruppo o utente ha il permesso "x", la maschera conterrà "x".
- Secondo tutta questa logica, il valore della maschera nell'esempio dell'OP dovrebbe essere 'rwx', indipendentemente dal percorso logico seguito.
Il ragionamento di cui sopra deve essere errato, poiché la x per execute non appare nella maschera.
Pertanto, ci deve essere qualche regola su come viene calcolata la maschera che è stata "nascosta" da fonti di documentazione comuni (o abbiamo trovato un bug).
La mia conclusione è che la "x" viene sempre rimossa incondizionatamente e la documentazione è lassista.
Questa modifica è stata probabilmente apportata sulla giustificazione della "sicurezza" -- nessun file deve essere eseguibile implicitamente, ma deve avere il bit eseguibile attivato dopo che è stato creato.