Translation(s): English - Italiano

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

I gruppi privati degli utenti (UPG, User Private Groups) 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.

Debian ha usato (creandoli) i gruppi privati degli utenti in modo predefinito quasi da sempre. Tuttavia a partire dal rilascio 2.2, non li aveva abilitati completamente in modo appropriato sulle nuove installazioni. Le impostazioni centrali per l'umask per gli UPG da login.defs sono state tolte con l'inclusione di PAM e questa funzionalità è stata reintrodotta e riabilitata solamente con libpam-umask nel rilascio 6.0 (Squeeze).

Informazioni introduttive per gli utenti (->per l'inclusione come aiuto al momento dell'installazione)

Sui sistemi Debian è facile per diversi utenti collaborare.

Tenere a mente che i permessi di accesso ad un file dipendono sempre dai permessi del file stesso e dai permessi delle directory nel suo percorso. I file appena creati in Debian sono, in modo predefinito, leggibili per chiunque vi abbia accesso, proprio come lo sono i documenti cartacei, ma non scrivibili. Se non si desidera che altri leggano i propri file, tenerli in una sottodirectory private/. Il percorso fino alla propria directory home non è ristretto, proprio come non è ristretto il percorso che chiunque può fare per venire a suonare alla porta di casa. Di fatto si può appendere alla propria porta dei documenti che si desidera gli altri leggano. Come esempio, molti programmi leggono i file di configurazione che l'utente mette nel proprio percorso home; e altri utenti possono lasciare file, destinati personalmente ad un utente, nella sua directory ~/incoming/.

Tutto ciò funziona perché i nuovi utenti creati hanno in modo predefinito un gruppo primario che è privato; è un gruppo che non ha alcun altro membro. ¹ Ciò permette ai permessi predefiniti di garantire al gruppo l'accesso in scrittura ai nuovi file creati perché, in modo predefinito, il gruppo associato ad un file creato da un utente è il gruppo privato dell'utente (UPG) e perciò nessuno tranne l'utente che lo ha creato avrà i permessi di scrittura. I file di ciascun utente rimangono al sicuro da manomissioni. Fanno eccezione, ovviamente, i file creati in una directory impostata per la condivisione del suo contenuto con i membri di gruppo...

Le directory configurate per la condivisione del loro contenuto con un gruppo, directory con impostato il bit setgid, sono spazi di lavoro condivisi (ancora una volta leggibili da tutti). Tutti i membri del gruppo associato ad una tale directory possono creare e scrivere file in essa. Il bit setgid fa sì che tutti i file creati nella directory saranno associati all'utente che li ha creati e al gruppo associato alla directory. Il risultato è che tutti i membri del gruppo possono lavorare sui file in una tale directory. A parte questo le directory setgid funzionano esattamente come le directory home; perciò se un file, per esempio, dovrebbe essere leggibile solo dai membri del gruppo metterlo in una sottodirectory privata!

ATTENZIONE

Coloro che usano un sistema Debian più vecchio del rilascio 6.0 (Squeeze) possono dover considerare questo avvertimento.

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

A partire da Debian 6.0 (Squeeze) i gruppi privati degli utenti sono abilitati in modo predefinito. Coloro che usano un sistema più vecchio dovranno 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. Tuttavia l'impostazione predefinita in Debian ha garantito per un lungo tempo 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 quello di disabilitare tutte le particolari impostazioni umask di shell specifiche, display manager, ecc e di usare libpam-umask per impostarla in modo centralizzato. Per 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
session required     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

Si può applicare una patch ad adduser in modo da creare le directory appropriate automaticamente e creare sottoutenti e sottodirectory manualmente, ad esempio per usarle per testare applicazioni specifiche.

Per ogni <nomegruppo> creare:

/home/group/<nomegruppo> (leggibile da tutti, scrivibile sgid per i membri del gruppo)
/home/group/<nomegruppo>/private (leggibile (e scrivibile) solo per i membri del gruppo)
/home/group/<nomegruppo>/incoming (scrivibile da tutti, file memo, nomi dei file non-pubblici (non sfogliabile))

Per ogni <utente>:

/home/<utente>/private (leggibile (e scrivibile) solo per l'utente)
/home/<utente>/incoming (scrivibile da tutti, sgid, file memo, nomi dei file non-pubblici (non sfogliabile))


Chiunque voglia rendere le directory home (/home/<utente>) non accessibili, deve introdurre un posto separato per le condivisioni:

/home/share/<utente> (in lettura e scrittura per l'utente e la sua XDG_PUBLICSHARE_DIR
(Tuttavia questo significa che le directory home degli utenti si comporterebbero in modo diverso dalle directory di gruppo e dallo schema d'uso degli UPG.)

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

• umask: cronistoria e stato della umask predefinita di Debian

• Documentazione di Red Hat sui gruppi privati degli utenti