Perché chmod (1) sul gruppo influenza la maschera ACL?

Sto cercando di capire questo comportamento Unix (che mi capita di provare su Ubuntu 11.10):

$ touch foo
$ setfacl -m u:nobody:rwx foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx
group::rw-
mask::rwx
other::r--

$ chmod g-rw foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx         #effective:--x
group::rw-          #effective:---
mask::--x
other::r--

Si noti che il comando chmod (1) ha aggiornato la maschera ACL. Perché succede?

La manpage di SunOS ha il seguente da dire:

Se si utilizza il comando chmod (1) per modificare le autorizzazioni del proprietario del gruppo di file su un file con voci ACL, sia le autorizzazioni del proprietario del gruppo di file sia la maschera ACL vengono cambiate con le nuove autorizzazioni. Tenere presente che le nuove autorizzazioni maschera ACL possono modificare le autorizzazioni effettive per utenti e gruppi aggiuntivi che dispongono di voci ACL nel file.

Chiedo perché sarebbe conveniente per me se chmod (1) non avesse questo comportamento. Spero che capendo perché fa quello che fa, posso progettare meglio come impostare i permessi del filesystem.

Sarebbe non essere conveniente per voi se chmod()non ha avuto questo comportamento.

Sarebbe estremamente scomodo, perché le cose che le persone si aspettano tradizionalmente di lavorare su Unix si rompono. Questo comportamento ti serve bene, lo sapevi ma lo sapevi.

È un peccato che IEEE 1003.1e non sia mai diventato uno standard e sia stato ritirato nel 1998. In pratica, a quattordici anni, è uno standard che implementano una vasta gamma di sistemi operativi - da Linux a FreeBSD a Solaris .

La bozza di lavoro n. 17 di IEEE 1003.1e rende interessante la lettura e lo consiglio. Nell'appendice B § 23.3 il gruppo di lavoro fornisce una spiegazione dettagliata, di otto pagine, per il modo in qualche modo complesso in cui gli ACL POSIX funzionano rispetto ai vecchi S_IRWXGflag di autorizzazione del gruppo. (Vale la pena notare che le persone di TRUSIX hanno fornito la stessa analisi dieci anni prima.) Non copierò tutto qui. Leggi la logica nella bozza dello standard per i dettagli. Ecco una sintesi molto breve :

• Il manuale di SunOS è sbagliato. Si dovrebbe leggere

  Se si utilizza il chmod(1)comando per modificare le autorizzazioni di proprietario del gruppo di file su un file con voci ACL, sia le autorizzazioni di proprietario del gruppo di file o la maschera ACL sono cambiati per le nuove autorizzazioni.

  Questo è il comportamento che puoi vedere accadere , nonostante ciò che dice l'attuale pagina di manuale, nella tua domanda. È anche il comportamento specificato dalla bozza dello standard POSIX. Se esiste una voce CLASS_OBJ(Sun's e la terminologia di TRUSIX per ACL_MASK) controllo accessi, i bit di gruppo di una chmod()impostazione, altrimenti impostano la GROUP_OBJvoce controllo accessi.

• Se così non fosse, le applicazioni che facevano varie cose standard con `chmod ()`, aspettandosi che funzionasse come `chmod ()` ha tradizionalmente lavorato su vecchi Unix non ACL, lascerebbero vuoti buchi di sicurezza o vedrebbero cosa pensano di essere buchi di sicurezza spalancati:

  • Le applicazioni Unix tradizionali prevedono di poter negare qualsiasi accesso a un file, denominato pipe, dispositivo o directory con chmod(…,000). In presenza di ACL, questo disattiva tutte le autorizzazioni utente e di gruppo solo se le vecchie S_IRWXGmappe lo fanno CLASS_OBJ. Senza questo, l'impostazione delle vecchie autorizzazioni sui file 000non influirebbe su nessuna USERo le GROUPvoci e gli altri utenti, sorprendentemente, avrebbero comunque accesso all'oggetto.

    Cambiare temporaneamente i bit di autorizzazione di un file per non accedervi chmod 000e poi cambiarli di nuovo era un vecchio meccanismo di blocco dei file, usato prima che Unixes acquisisse meccanismi di blocco consultivo, che - come puoi vedere - le persone usano ancora oggi .

  • Gli script Unix tradizionali prevedono di essere in grado di funzionare chmod go-rwxe finire con l'accesso al solo proprietario dell'oggetto. Ancora una volta - come puoi vedere - questa è ancora la saggezza ricevuta dodici anni dopo. E ancora, questo non funziona a meno che le vecchie S_IRWXGmappe CLASS_OBJnon esistano, perché altrimenti quel chmodcomando non disattiverebbe nessuna USERo GROUPle voci di controllo dell'accesso, portando gli utenti diversi dal proprietario e i gruppi non proprietari che mantengono l'accesso a qualcosa che è dovrebbe essere accessibile solo al proprietario.

  • Un sistema in cui i bit di autorizzazione sarebbero stati altrimenti separati e modificati andcon gli ACL richiederebbe rwxrwxrwxnella maggior parte dei casi i flag di autorizzazione dei file , il che confonderebbe il diavolo delle molte applicazioni Unix che si lamentano quando vedono ciò che pensano siano scrivibili dal mondo cose.

    Un sistema in cui i bit di autorizzazione sarebbero stati separati e modificati orcon gli ACL avrebbe il chmod(…,000)problema menzionato in precedenza.

Ulteriori letture

• Winfried Trümper (28-02-2005). Riepilogo su Posix.1e
• Comitato degli standard di applicazioni portatili della IEEE Computer Society (ottobre 1997). Progetto di standard per l'Information Technology — POSIX (Portable Operating System Interface) —Parte 1: Interfaccia del programma applicativo di sistema (API) - Emendamento n.: Interfacce di protezione, audit e controllo [linguaggio C] IEEE 1003.1e. Bozza 17.
• Craig Rubin (1989-08-18). Razionale per la selezione delle funzioni dell'elenco di controllo di accesso per il sistema Unix . NCSC-TG-020-A. Pubblicazione DIANE. ISBN 9780788105548.

Questo comportamento si applica solo alle voci ACL POSIX. Il motivo è che se hai una cartella e all'interno di quella cartella esiste un file, puoi acl come rwx (ad esempio) la cartella e il file. Se le autorizzazioni di gruppo del file sono rw- (che potrebbero essere come uno scenario tipico), la maschera fornisce quindi all'acl le autorizzazioni effettive di rw- anche se l'ACL indica esplicitamente rwx.

D'altra parte, la directory che è quasi sempre + x ha permessi maschera ACL efficaci che consentono anche + x.

In breve, questa maschera viene sostanzialmente utilizzata per differenziare le autorizzazioni tra file e cartelle per il set ACL POSIX in modo che un file non diventi eseguibile quando normalmente non dovrebbe esserlo.