Gruppi privati degli utenti - Condivisione del contenuto di directory con un gruppo

I gruppi privati degli utenti sono un idioma di configurazione del sistema che permette agli utenti di collaborare garantendo l'accesso condiviso ad una directory e al suo contenuto. L'accesso è controllato associando a ciascun progetto collaborativo un gruppo Un*x e poi facendo appartenere al gruppo Un*x tutti gli userid dei membri designati per il progetto. Una volta che ciò sia stato abilitato a livello di sistema ed impostato per ciascun progetto, non richiede per funzionare come atteso azioni da parte dell'utente finale. I file e le directory possono essere creati, modificati e cancellati e (per la maggior parte) i loro permessi possono essere modificati come al solito, pur essendo al contempo condivisi con gli altri membri del gruppo e protetti da chi non è membro.

A differenza dei sistemi RedHat, i sistemi Debian non sono preconfigurati per supportare i gruppi privati degli utenti; in questo Debian segue la pratica storicamente usata da Unix. Tuttavia basta una singola modifica a livello di sistema per abilitare il supporto per i gruppi privati degli utenti.

ATTENZIONE

Benché la configurazione dell'idioma per gruppi privati degli utenti qui descritta sia sicura su un sistema Debian "normale", ammesso che esista una cosa simile, fare i cambiamenti qui descritti potrebbe compromettere fortemente la sicurezza del proprio sistema. Tutto dipende dalla configurazione del proprio sistema e da come siano già impostati i permessi e la proprietà dei gruppi sui file e directory esistenti. La scelta del file system può avere un effetto sul comportamento del bit setgid applicato alle directory. I pacchetti installati possono alterare la configurazione del sistema, così come possono farlo altri amministratori del sistema. Gli utenti possono modificare la propria umask predefinita e cambiare i permessi e i gruppi proprietari dei file o directory esistenti. Tutti questi fattori hanno un effetto sulla disponibilità dell'idioma per i gruppi privati degli utenti e, cosa più importante, sulla sicurezza del sistema dopo che i gruppi privati degli utenti sono stati abilitati.

Si può essere fiduciosi del fatto che il sistema di gruppi privati degli utenti funzioni su un sistema Debian con la scelta predefinita per il tipo di file system, con solo i pacchetti base installati e senza personalizzazioni a livello utente o di sistema; più di questo non può essere garantito. Detto tutto ciò, l'idioma per gruppi privati degli utenti può essere una buona scelta (in confronto a ACL) perché usa il sistema base e familiare dei permessi Un*x, per fornire un modo sicuro di condividere file che è facile da abilitare e amministrare ed è trasparente quando si tratta di usare lo spazio condiviso.

Abilitare i gruppi privati degli utenti

L'idioma per gruppi privati degli utenti richiede che i permessi predefiniti per il gruppo siano di scrittura/lettura e con esecuzione permessa. L'impostazione predefinita in Debian garantisce ai gruppi l'accesso in sola lettura con l'esecuzione permessa.

I permessi predefiniti, che vengono attivati al momento della creazione di un file o directory, sono controllati attraverso l'umask. Ci sono vari modi di cambiare l'umask predefinita; il più elegante è probabilmente l'uso di libpam-umask. Aggiungere le righe seguenti alla fine del file /etc/pam.d/common-session:

# Abilitare l'idioma per gruppi privati degli utenti
# per permettere la collaborazione basata sull'appartenenza a gruppi
pam_umask.so silent usergroups

Considerazioni relative alla sicurezza

Concedere i permessi di lettura/scrittura a gruppi potrebbe avere come risultato directory home non sicure. Se due utenti hanno entrambi lo stesso gruppo primario, allora ciascuno potrebbe leggere e scrivere i file privati dell'altro. (Ricordare che il gruppo primario è il gruppo assegnato in modo predefinito ai file e alle directory quando vengono create. L'idioma per gruppi privati degli utenti prende il nome dal fatto che a ciascun utente viene assegnato un gruppo primario univoco, un gruppo a cui appartiene solo l'utente. Perciò in modo predefinito, i file creati da ciascun utente sono associati ad un gruppo a cui appartiene solo l'utente e quindi non importa se i permessi predefiniti per il gruppo sono laschi.

Notare che il comportamento "predefinito" di Debian è di creare un nuovo gruppo ogni volta che viene creato un nuovo userid, e di far sì che questo nuovo gruppo sia quello primario per l'userid. Perciò ci sono le basi per abilitare l'idioma di gruppi privati degli utenti cambiando l'umask predefinita a livello di sistema.

Uso di gruppi privati dell'utente

• Scegliere un nome di gruppo per il proprio progetto. Usare addgroup (con la sintassi "addgroup gruppo") o vigr per creare il gruppo.

• Decidere chi deve collaborare e usare adduser (con la sintassi "adduser utente gruppo") o vigr per concedere ai nomi utente dei collaboratori l'appartenenza al gruppo del progetto. Notare che l'appartenenza ai gruppi è valutata al momento del login, perciò ogni utente deve rifare il login.

• Creare una directory (o più directory) in cui deve aver luogo il lavoro di collaborazione. La directory di progetto deve essere posizionata in una directory a cui tutti i membri del progetto hanno accesso di transito. (Cioè i membri del progetto devono avere il permesso di esecuzione (x) sulla directory contenente il progetto e su tutte le directory genitrici.) La directory /srv può essere una buona scelta di directory base. Vedere lo standard per la gerarchia del file system.

• Concedere i permessi sulla directory di progetto (ladir) al gruppo di progetto (ilgruppo) con i comandi seguenti:

chgrp ilgruppo ladir
chmod g=rwxs ladir

Come funziona

Impostare il bit setgid (chmod g+s) su una directory cambia il gruppo associato ai file o alle sottodirectory create all'interno di essa. Invece del comportamento usuale che associa il gruppo "reale" dei processi ai nuovi file e sottodirectory, viene usato il gruppo della directory genitrice. Perciò il compartamento predefinito diventa di associare il gruppo del progetto a tutti i nuovi file e directory. Dato che tutti i membri del progetto sono nel gruppo di progetto, hanno accesso in lettura e scrittura a tutti i file e possono attraversare tutte le sottodirectory. Inoltre, dato che l'umask di sistema dà ai gruppi tutti i permessi e dato che i membri del gruppo hanno accesso in lettura e scrittura alla directory del progetto e alle sue sottodirectory, i membri del progetto possono sia creare nuovi file e sottodirectory sia cambiare i permessi dei file, compreso concedere i permessi di esecuzione a file.

Il bit setgid su una directory fa anche sì che tutte le sottodirectory create abbiano il bit setgid impostato, il che estende automaticamente le proprietà spiegate in precedenza verso il basso in tutte le sottodirectory del progetto.

Quando non possono essere usati i gruppi privati degli utenti

I gruppi privati degli utenti non possono essere usati quando l'associazione ad un gruppo è necessaria per un altro scopo; ad esempio, ci si aspetta che i contenuti serviti da un server web siano associati al gruppo www-data. In questi casi per condividere i file e le directory devono essere usate le ACL.

Vedere anche

• Permessi

• man chmod

• info coreutils 'Directory Setuid and Setgid'

• man pam_umask

• man login.defs

• Documentazione di Red Hat sui gruppi privati degli utenti