Translation(s): English - Italiano


Gruppi privati degli utenti - Condividere il contenuto di directory con un gruppo e lavorare in modo collaborativo

I gruppi privati degli utenti (UPG, User Private Groups) sono un idioma di configurazione del sistema che permette a diversi utenti di un sistema di collaborare su file senza complicazioni coi permessi.

Per funzionare come atteso non richiede azioni da parte dell'utente finale. I file e le directory, all'interno di una directory di gruppo, 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.

L'accesso è controllato da gruppi Un*x a cui possono essere aggiunti o rimossi ID utente.

Informazioni introduttive per gli utenti (->per l'inclusione come testo informativo da mostrare durante la copia di file al momento dell'installazione)

(Dovrebbe essere vero ma necessita ancora degli aggiustamenti più sotto.)

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 in modo predefinito. Se si vuole impedire 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ò può funzionare perché in Debian il gruppo primario dei nuovi utenti creati è in modo predefinito un gruppo privato dell'utente (UPG). [Il gruppo primario di un utente ha il suo stesso nome e ID, senza che l'utente sia esplicitamente elencato come membro in /etc/group (cioè il gid viene elencato nella riga che definisce l'utente in /etc/passwd, ma l'utente non è elencato esplicitamente come membro del gruppo in /etc/group).)] Ciò permette di garantire al gruppo l'accesso in scrittura ai nuovi file creati perché, in modo predefinito, solo l'utente che li crea (e opzionalmente gli utenti supervisori) è membro del gruppo privato primario a cui appartiene il file creato. Fanno eccezione, ovviamente, i file creati in una directory di gruppo...

Le directory di gruppo (directory con impostato il bit set-group-id, sono spazi di lavoro condivisi (ancora una volta leggibili da tutti). Tutti i membri del gruppo proprietario di una tale directory possono creare e scrivere file in essa. Inoltre, in accordo con l'impostazione set-group-id, tutti i file creati nella directory del gruppo saranno di proprietà dell'utente che li ha creati e (e questo è speciale) del gruppo proprietario della directory. Il risultato è che tutti i membri del gruppo possono lavorare sui file nella loro directory di gruppo. A parte questo, le directory di gruppo funzionano esattamente come le directory home; perciò se un file, per esempio, deve essere leggibile solo dai membri del gruppo metterlo in una sottodirectory privata!

Le directory di gruppo possono essere impostate automaticamente (create/eliminate insieme a ciascun gruppo dal comando addgroup) in /home/share, oppure dagli utenti normali stessi all'interno delle proprie directory home.

Abilitare i gruppi privati degli utenti

Debian ha usato (creandoli) i gruppi privati degli utenti in modo predefinito quasi da sempre. Tuttavia gli UPG non erano completamente abilitati sulle nuove intallazioni fino al rilascio 2.2, perché le impostazioni centrali per l'umask per gli UPG, come configurate in /etc/login.defs sono state danneggiate con l'inclusione di PAM. Questa funzionalità è stata reintrodotta solamente con libpam-umask nel rilascio 6.0 (Squeeze).

L'idioma per gruppi privati degli utenti richiede che i permessi umask predefiniti per il gruppo siano di scrittura/lettura e con esecuzione permessa. Tuttavia l'umask predefinita nei sistemi Debian è stata per lungo tempo quella di garantire 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 del processo. 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 configurare libpam-umask fino a che non viene risolto il bug 646992 aggiungere una riga al file /etc/pam.d/common-session eseguendo:

echo "session optional pam_umask.so usergroups" >> /etc/pam.d/common-session

Uso di gruppi privati dell'utente

Ecco un esempio per usare un gruppo "famiglia" a casa: creare il gruppo "famiglia" (sudo addgroup famiglia) e aggiungervi gli utenti appropriati (sudo adduser <user> family).

Fino a che non verrà fatta una patch allo strumento per la creazione dei gruppi del sistema Debian in modo che crei automaticamente la directory appropriata con ciascun gruppo (come le directory home) è necessario impostare le directory manualmente:

sudo mkdir -p /home/share/famiglia #crea la directory pubblica del gruppo
sudo chgrp famiglia /home/share/famiglia #la assegna al gruppo
sudo chmod 2775 /home/share/famiglia #regola i suoi permessi (sgid)

#crea le sottodirectory
sudo mkdir -p /home/share/famiglia/privata
sudo chgrp famiglia /home/share/famiglia/privata
sudo chmod 2770 /home/share/famiglia/privata

sudo mkdir -p /home/share/famiglia/in_entrata
sudo chgrp famiglia /home/share/famiglia/in_entrata
sudo chmod 3773 /home/share/famiglia/in_entrata

# per ciascun utente (facilita il lavoro collaborativo)
sudo mkdir /home/<utente>/in_entrata
sudo chown <utente>:<utente> /home/<utente>/in_entrata
sudo chmod 5773 /home/<utente>/in_entrata

# per completezza, coerenza e come esempio anche
sudo mkdir /home/<utente>/privata
sudo chown <utente>:<utente> /home/<utente>/privata
sudo chmod 770 /home/<utente>/privata

Ora tutti i membri del gruppo famiglia possono lavorare con i file degli altri nella directory del gruppo senza complicazioni coi permessi.

Se si ha già una directory esistente piena di file (fotografia/musica/quant'altro), questo script può far risparmiare tempo.

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.)

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.

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.

Come funziona

UPG

Un UPG può essere identificato dalle seguenti condizioni:

  1. Un gruppo con lo stesso nome dell'utente
  2. Un caso speciale è vero: il gruppo è impostato come gruppo principale dell'utente (in /etc/passwd) mentre l'utente NON viene aggiunto al suo gruppo in /etc/groups.
    • => Permette di rilevare che un gruppo è stato esplicitamente impostato come UPG anche se utenti addizionali vengono aggiunti al gruppo.

  3. UID==GID
    • Questo è stato discusso come requisito, probabilmente perché si è visto che adduser (non saltando gli ID che sono stati presi da gruppi non UPG durante la creazione degli utenti) non rispetta pienamente questo requisito. Tuttavia:
    • UID==GID può essere di grande aiuto se si guarda un file system (dispositivo rimovibile) senza conoscere i relativi file passwd/groups. b) man pam_umask:

      "Se l'utente non è root, e l'ID utente è uguale all'ID del gruppo e il nome utente è lo stesso del nome del gruppo primario, i bit umask del gruppo sono impostati come gli stessi dei bit del proprietario (esempio: 022 -> 002, 077 -> 007)."

Questa definizione permette:

  1. di aggiungere intenzionalmente uno o più utenti (supervisori) ad un UPG di (sotto-)utenti e perciò permettere al supervisore un accesso pieno alle risorse dei sotto-utenti (senza rompere lo schema UPG umask).
  2. di eliminare correttamente il gruppo privato se viene eliminato l'utente corrispondente (anche se utenti supervisori possono ancora essere membri di quel gruppo obsoleto).

setgid per le directory

Impostare il bit setgid (chmod g+s) su una directory fa sì che tutti i file o sottodirectory create all'interno di essa siano di proprietà del gruppo che possiede la directory (superiore). Il comportamento usuale invece è che i file o le directory create sono di proprietà del gruppo principale del processo che li ha creati

Se l'umask di sistema dà ai proprietari dei gruppi i permessi di scrittura i membri del gruppo possono creare nuovi file e sottodirectory, e 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.

Tuttavia in molti casi si possono evitare le ACL usando il percorso per restringere l'accesso a dati altrimenti "scrivibili dal mondo"

/filterdir www-data:web-admin rwxrwx---
/filterdir/datadir web-admin:www-data rwxrwx---
/filterdir/datadir/file-or-dir www-data:www-data rwxrwxrwx

Vedere anche