facl, setfacl, directory share, perché cp inserisce i permessi del file originale nella maschera facl? ' non dovrebbe essere un comportamento cp -p?

Gli utenti di questo sistema sono attenti e hanno i loro umask impostati sul molto privato 0077. Tuttavia, gli utenti vorrebbero avere directory specifiche del gruppo, dove i file possono essere copiati in modo da condividerli esplicitamente solo tra gli altri membri del gruppo. Potrebbero essere presenti più directory di condivisione di questo tipo, sebbene ciascuna sia specifica di un gruppo.

Limpostazione del bit sticky di gruppo su una data directory da utilizzare per la condivisione non è sufficiente. Sebbene limpostazione dello sticky bit faccia sì che la proprietà del gruppo sia corretta sui file posizionati nella directory, i permessi su tali file sono spesso impostati in modo tale che i file non possano essere letti o modificati, ovvero non possano essere effettivamente condivisi. Appaiono solo nellelenco delle directory. Questo perché alcuni utenti non pensano o non sanno come fare manualmente la regolazione dei permessi di gruppo richiesta per consentire la lettura e la scrittura. Possiamo dare loro una pausa su questo perché gli utenti non sono amministratori, dopotutto. acls può essere utilizzato per specificare che un particolare gruppo ha accesso ai file nella directory di condivisione, indipendentemente da quali sarebbero stati i permessi del gruppo senza acls. Questa è la soluzione perfetta, ma non funziona del tutto.

Di seguito, il gruppo condiviso è “customer_gateway” e lutente di esempio che cerca di condividere un file è “svw”. Come si può vedere nella trascrizione, lutente svw è un membro del gruppo customer_gateway. La directory in cui deve avvenire la condivisione è anche chiamata “customer_gateway /”

Quanto segue usa acls. Ho impostato i permessi di gruppo, i permessi di gruppo predefiniti, la maschera e la maschera predefinita. Funziona bene per i file creati nella directory o per i file spostati lì tramite cat (o tar), ma stranamente, non per i file che “cp” sono presenti:

# rm -r customer_gateway/ # umask 0077 # cat ~/script1 mkdir customer_gateway chown :customer_gateway customer_gateway/ chmod g+rwx customer_gateway/ setfacl -m group:customer_gateway:rwX customer_gateway/ setfacl -m d:group:customer_gateway:rwX customer_gateway/ setfacl -m m::rwX customer_gateway/ setfacl -m d:m::rwX customer_gateway/ getfacl customer_gateway cd customer_gateway touch cga cat << EOF > cgb c g b EOF ls -l # . ~/script1 # file: customer_gateway # owner: root # group: customer_gateway user::rwx group::rwx group:customer_gateway:rwx mask::rwx other::--- default:user::rwx default:group::rwx default:group:customer_gateway:rwx default:mask::rwx default:other::--- total 4 -rw-rw----+ 1 root root 0 Mar 2 20:43 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb # su - svw /home/svw/bin:/usr/local/bin:/usr/bin:/bin (note umask is 0077) > cd /share/customer_gateway/ > groups svw adm dip video plugdev google-sudoers customer_gateway > cat >> cga e f g > cat > cgc c g c > ls -l total 12 -rw-rw----+ 1 root root 6 Mar 2 20:44 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb -rw-rw----+ 1 svw svw 6 Mar 2 20:44 cgc > ls ~/dat ta tb tc > cat ~/dat/ta > ta > cp ~/dat/tb tb > ls -l total 20 -rw-rw----+ 1 root root 6 Mar 2 20:44 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb -rw-rw----+ 1 svw svw 6 Mar 2 20:44 cgc -rw-rw----+ 1 svw svw 4 Mar 2 20:45 ta -rw-------+ 1 svw svw 4 Mar 2 20:45 tb > getfacl ta # file: ta # owner: svw # group: svw user::rw- group::rwx #effective:rw- group:customer_gateway:rwx #effective:rw- mask::rw- other::--- > getfacl tb # file: tb # owner: svw # group: svw user::rw- group::rwx #effective:--- group:customer_gateway:rwx #effective:--- mask::--- other::--- > 

Ciò che mostra è che quando un file viene creato nella directory, riceve i permessi predefiniti ed è condivisibile. Ma gli utenti non creano sempre i loro file lì, comunemente li copiano lì.

Ma fare una copia è la stessa cosa, perché per fare una copia dobbiamo prima creare un nuovo file. Stiamo parlando di una copia semplice qui, non una copia dei permessi di conservazione. È lo stesso del modulo seguente, che, btw funziona e copia un file che sarà condivisibile nella directory indipendentemente dai suoi permessi di gruppo originali:

cat < data.in > shared/data.out 

funziona bene, funziona anche il piping attraverso tar, ma il modulo

cp data.in shared/data.out 

fallisce. Il cat ed il file ottiene la maschera e i permessi predefiniti. Il file cp ed conserva i suoi permessi nella maschera acl e i permessi del gruppo, come se fosse un cp -p (ma non era “t), e quindi i permessi effettivi si leggono come il file originale, non come sono stati impostati gli ACL.

Come secondo tentativo ho eseguito questo esperimento con il gruppo sticky bit, chmod g + rwxs, insieme al facl ch anges e ha ottenuto gli stessi risultati. Sebbene gli elenchi di directory siano più belli a causa della proprietà del gruppo mostrata per tutti i file condivisi. Lho anche eseguito impostando solo il bit appiccicoso del gruppo, senza setfacl. Ha anche avuto lo stesso risultato per i file copiati (quindi i facl sembrano abbastanza inutili per una directory in cui i file vengono copiati per essere condivisi).

Su quali basi e con quale giustificazione i facl di Linux distinguono tra diverse forme di creazione di dati? Perché forzare cp a preservare i permessi quando non gli è stato detto di farlo? Quale ragione giustificherebbe la confusione causata da questa distinzione tra cat e piping attraverso il funzionamento di tar ma cp non funzionante? Mi manca un incantesimo magico che farebbe questa distinzione evaporare?

Questo riepilogo è corretto: facls ti consentirà di superare la proprietà per condividere file, renderà i permessi più permissivi dellumask durante la “creazione” dei file, a meno che la creazione non sia dovuta al comando cp e per una buona ragione perché … perché perché?

Commenti

• Quale sistema operativo (distribuzione e versione linux) e quale file system stai usando? Sarebbe corretto che le persone usassero cat, magari tramite uno shellscript dedicato per questo scopo?
• Intendi che qualsiasi utente del gruppo possa modificare o eliminare qualsiasi file, o solo il creatore dovrebbe avere tali permessi? In altre parole solo leggere i permessi (e forse eseguire i permessi) per o altri utenti.
• Debian 10. Poiché la creazione di file funziona, ‘ ho inviato le copie tramite tar. Lo ‘ lo impacchetterò come comando proj_cp in / usr / local / bin. Tuttavia, se un utente deve utilizzare un comando di copia speciale, è possibile utilizzare il bit sticky del gruppo senza facl e impostare le autorizzazioni. Voglio sapere come impostare gli ACL in modo che cat tar e cp funzionino.’ penso che ci sia un problema con ACL con cp, poiché stanno eseguendo il comportamento cp -p invece del comportamento cp. ‘ non vedo lora di sentire gli esperti delle autorizzazioni.
• La condivisione di gruppo è un problema ricorrente con variazioni, come hai sottolineato. In questo caso, gli sviluppatori di software hanno accesso alla directory del rilascio di prova. È loro con cui masticare. Possono lavorare in quella directory, eseguire il push, il pull, linstallazione nellambiente virtuale, ecc. Il problema nasce quando copiano cose da unaltra area in cui hanno lavorato, e le loro umask non sono impostate con i permessi di gruppo. È fonte di confusione per loro perché la creazione di file e la copia da tar funziona bene. È anche divertente che devo dare loro una copia dello script che fa proprio quello che fa cp. ‘ acls ‘ sono magici dico LOL
• Non sono esperto di autorizzazioni, ma spero che le mie domande e le tue risposte possono aiutare gli esperti a darti risposte pertinenti.