Differences between revisions 10 and 11
Revision 10 as of 2011-02-24 18:04:24
Size: 12895
Comment: sync with English version
Revision 11 as of 2012-09-07 16:05:01
Size: 15905
Comment: sync with English version
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:
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. 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.
Line 13: Line 13:
'''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'[[it/umask|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). 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.
Line 15: Line 15:
== Informazioni introduttive per gli utenti (->per l'inclusione come aiuto al momento dell'installazione) == 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.)
Line 19: Line 23:
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/}}}. 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/}}}.
Line 21: Line 25:
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. <<FootNote(Il gruppo primario di un utente ha lo stesso nome dell'utente e is suo GID e uguale all'ID dell'utente. Dato che il gid è presente nella riga che definisce l'utente in {{{/etc/passwd}}}, l'utente non è elencato esplicitamente come membro del gruppo in {{{/etc/group}}}.)>> 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... 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...
Line 23: Line 27:
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! Le direct 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!
Line 25: Line 29:
== 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.
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.
Line 36: Line 33:
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. '''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'[[it/umask|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).
Line 38: Line 35:
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.
Line 40: Line 36:
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}}}: 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.
Line 42: Line 38:
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 DebianBug:646992 aggiungere una riga al file {{{/etc/pam.d/common-session}}} eseguendo:
Line 43: Line 42:
# 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.
echo "session optional pam_umask.so usergroups" >> /etc/pam.d/common-session
}}}
Line 61: Line 53:
 * Concedere i permessi sulla directory di progetto ({{{ladir}}}) al gruppo di progetto ({{{ilgruppo}}}) con i comandi seguenti:

{{{
 * Concedere i permessi sulla directory di progetto ({{{ladir}}}) al gruppo di progetto ({{{ilgruppo}}}) con i comandi seguenti:{{{
Line 66: Line 56:


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 le directory dei gruppi non verranno create automaticamente 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), [[http://www.stubbornroses.com/setgid|questo script]] può far risparmiare tempo.
Line 89: Line 112:
=== Come funziona === === Considerazioni relative alla sicurezza ===
Line 91: Line 114:
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. 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

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

 1. 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:

   a. 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:

 A. 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).
    
 A. 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.
Line 95: Line 164:
=== Quando non possono essere usati i gruppi privati degli utenti === == Quando non possono essere usati i gruppi privati degli utenti ==
Line 98: Line 167:

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
}}}

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 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 direct 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

  • 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

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 le directory dei gruppi non verranno create automaticamente 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