Ragioni alla base dei gruppi e degli utenti predefiniti su Linux


14

Dando un'occhiata alla gestione predefinita di utenti e gruppi su alcune consuete distribuzioni Linux (rispettivamente ArchLinux e Debian), mi chiedo due cose a riguardo e sulle conseguenze della modifica dell'installazione e della configurazione predefinite.

Il valore predefinito per USERGROUPS_ENABin /etc/login.defssembra essere "yes", che si riflette nel "Per impostazione predefinita, verrà creato anche un gruppo per il nuovo utente" che può essere trovato useraddnell'uomo, quindi ogni volta che viene creato un nuovo utente, un Il gruppo viene creato con lo stesso nome e solo questo nuovo utente è presente. È utile o è solo un segnaposto?

Mi sento come se stessimo perdendo una parte della gestione dei diritti come utente / gruppo / altri . Sarebbe male avere un gruppo "utenti" o "clienti abituali" o qualunque cosa tu voglia chiamarlo che è il gruppo predefinito per ogni utente invece di avere il proprio?

Seconda parte della mia domanda, che si basa ancora su ciò che ho visto su Arch e Debian: ci sono molti utenti creati di default (FTP, HTTP, ecc.). C'è qualche utilità per loro o esistono solo per ragioni storiche?

Sto pensando di rimuoverli ma non voglio rompere nulla che possa usarlo, ma non ho mai visto nulla farlo e non ho idea di cosa potrebbe farlo. Lo stesso vale per i gruppi predefiniti (tty, mem, ecc.) A cui non ho mai visto alcun utente appartenere.


Se mi dai un po 'di tempo, ti darò una bella risposta. Sono solo un typer lento. Potrebbero essere necessari almeno 30 minuti.
eyoung100,

Il punto principale di tutti questi gruppi è per i programmi set-group-id.
Barmar,

2
La prima domanda è molto vicina a questa .
Leiaz,

@ECarterYoung: certo che puoi prenderti il ​​tuo tempo, grazie per questo!
Horgix,

@Leiaz: Mi sono reso conto che, ma volevo ancora chiedere "Sarebbe male avere un gruppo" utenti "o" clienti abituali "o qualunque cosa tu voglia chiamarlo, che è il gruppo predefinito per ogni utente invece di avere il proprio?" parte, e ha mantenuto ciò che prima era un'introduzione. Ho pubblicato principalmente su StackOverflow ma è stato diretto qui.
Horgix,

Risposte:


13

Gruppi per utente

Anch'io non vedo molta utilità nei gruppi per utente. Il caso d'uso principale è che se un utente volesse consentire agli "amici" l'accesso ai propri file, può avere l'utente amico aggiunto al proprio gruppo. Pochi sistemi che ho incontrato effettivamente lo usano in questo modo.

Quando USERGROUPS_ENABin /etc/login.defsè impostato su "no", useraddaggiunge tutti gli utenti creati al gruppo definito /etc/default/useradddal GROUPcampo. Sulla maggior parte delle distribuzioni, questo è impostato sul GID 100che di solito corrisponde al usersgruppo. Ciò ti consente di avere una gestione più generica degli utenti. Quindi, se hai bisogno di un controllo più preciso, puoi aggiungere manualmente questi gruppi e aggiungere utenti a loro che abbiano senso.

Gruppi creati di default

La maggior parte di essi è nata da ragioni storiche, ma molti hanno ancora usi validi oggi:

  • disk è il gruppo che possiede la maggior parte dei dispositivi di unità disco
  • lp possiede una porta parallela (e talvolta è configurata per i diritti di amministratore sulle tazze)
  • uucp possiede spesso porte seriali (comprese le porte seriali USB)
  • cdrom è necessario per montare i privilegi su un lettore cd
  • Alcuni sistemi usano la ruota per i diritti sudo; alcuni no
  • eccetera.

Altri gruppi vengono utilizzati dagli script in background. Ad esempio, mangenera file temporanei e simili quando viene eseguito; il suo processo usa il gruppo man per alcuni di quei file e generalmente ripulisce da solo.


Secondo la specifica base standard Linux standard , solo 3 utenti root, bin e daemon sono assolutamente obbligatori . La logica alla base degli altri gruppi è:

Lo scopo di specificare utenti e gruppi opzionali è ridurre il potenziale di conflitti di nomi tra applicazioni e distribuzioni.

Quindi sembra che sia meglio mantenere questi gruppi sul posto. È teoricamente possibile rimuoverli senza rotture, anche se per alcune cose "misteriose" potrebbero iniziare a non funzionare correttamente (ad esempio, alcune pagine man non vengono visualizzate se si uccide quel gruppo, ecc.). Non fa nulla per lasciarli lì, e si presume generalmente che tutti i sistemi Linux li avranno.


Dove posso trovare ulteriori informazioni su man che genera file temporanei? Con una pagina man aperta, ps aux | grep mannon mi mostra alcun processo in esecuzione sotto il gruppo man e a find -group man /non mi mostra nulla. Ho provato con man 2.6.7.1 su un'installazione standard di Archlinux.
Horgix,

4

Domanda 1: Ragionamento per lo stesso utente e gruppo

Ciao, sono ecyoung e tu sei horgix. Andiamo al lavoro tutti i giorni e accediamo allo stesso server Linux dei programmatori. Un giorno, non molto tempo fa, il nostro amministratore di sistema ha deciso di semplificare la creazione e la manutenzione degli utenti, quindi ha disattivato l' USERGROUPS_ENABopzione e inserito tutti gli utenti esistenti nel nuovo usersgruppo.


Ciò ha reso più semplice la creazione dell'utente ma non la manutenzione, poiché tutti gli utenti possono accedere a tutti i file degli altri utenti. In un contesto aziendale questo è un grande no a causa di cose come Sarbanes Oxley e Segregation of Duties . Se creo il file A, il bit di gruppo viene impostato sul gruppo di utenti, il che significa che tutti gli utenti possono almeno leggere il file A. Se l'amministratore di sistema è pigro, in alcuni casi tutti gli utenti possono eseguire il file RW A. Ciò sconfigge Sarbanes Oxley e SoD perché dipartimenti separati non dovrebbero essere in grado di leggere molto meno di scrivere documenti di altre persone.


Con Utente / Gruppo abilitato se creo un documento come ecyoung, solo io ho i diritti rwx su di esso. Poiché nessun altro è nel mio gruppo, quando aprono il mio documento vedono una pagina vuota con un avviso. Ciò impone Sarbanes-Oxley e SoD. Se invito altri utenti, a quegli utenti viene concesso l'accesso rw, e così facendo so che ciò che vedono non tornerà a mordere me o loro. Come altri hanno già detto, se a casa, quella separazione potrebbe non essere importante per te. Se lo determini, puoi disattivare l'opzione in modo sicuro e tutti gli utenti verranno aggiunti a un usersgruppo con un GID di 100. Vedi la domanda 2 di seguito.

Ipotetico :
lavori in IT e Louis lavora in Payroll. Louis mantiene il foglio Fiscale e paghe nella sua directory home, ma entrambi siete nel gruppo utenti, quindi aprite la sua directory home perché è contrassegnata con + r per gli utenti e trovate il suo foglio di calcolo. Trovi il tuo stipendio elencato, insieme a Joe e Fred. Pensi che Joe e Fred vorrebbero che tu conoscessi il loro stipendio ??


Domanda 2: ID gruppo da 0 a 500

Gli ID gruppo e viceversa gli ID utente 0 - 500 sono riservati per gli account di sistema e l'accesso al dispositivo. Vedere la tabella dei gruppi di sistemi preconfigurati per l'elenco degli account standard. Non rimuovere questi account manualmente. Ad esempio, se si desidera rimuovere l'utente ftp, rimuovere il demone ftp con il proprio sistema di gestione dei pacchetti. In questo modo verrà rimosso anche l'account di sistema. I servizi di sistema includono ma non sono limitati a:

  • Il servizio di stampa CUPS
  • Il demone di MySQL Server
  • Il demone del server FTP
  • Apace Web Server
  • X Server Socket per connessioni remote
  • Il demone del sistema audio ALSA
  • Il servizio DBUS

Ce ne sono altri, quindi se altri lettori vogliono aggiungere o rimuovere dall'elenco dei servizi sopra, si prega di farlo.


5
Bello ipotetico, ma un fallimento. 1. Le autorizzazioni predefinite sono generalmente mascherate 022, il che significa che altri hanno comunque accesso in lettura. 2. Il sysad non è solo pigro, ma incompetente, dal momento che avrebbe dovuto creare gruppi in base al dipartimento e assegnato il gruppo corretto durante la creazione dell'account, invece di assegnare tutto a un gruppo. L' USERGROUPS_ENABdovrebbe rimanere spento poi. Disabilitazione USERGROUPS_ENAB! = Mettendo tutti gli utenti nello stesso gruppo.
Muru,

@ECarterYound per la prima parte: vedo cosa intendi per protezione dell'accesso e correggimi se sbaglio ma avere tutti gli utenti in un usersgruppo non dovrebbe essere un problema con la corretta gestione dei diritti sui gruppi, che non sta dando esattamente lo stesso diritti sul gruppo rispetto al proprietario. Quindi l'unico punto positivo di aver USERGROUPS_ENABattivato è avere una manutenzione più semplice poiché ti consente di mantenere i diritti predefiniti durante la creazione di file e directory pur avendo accesso limitato per altri utenti?
Horgix,

Sarebbe corretto, ma molte persone non gestiscono correttamente i Gruppi se sono utenti domestici. Non posso verificarlo con certezza, ma credo che i manutentori abbiano creato l'opzione per sostenere la gestione delle autorizzazioni.
eyoung100,

3

Se condividiamo tutti un gruppo predefinito, come ai vecchi tempi, allora dobbiamo impostare umask su 077 per bloccare il gruppo. Se il default sono io, allora posso impostare umask su 027, ora se imposto una directory di file su un gruppo condiviso, questo gruppo può leggere. Non devo fare confusione anche con le modalità.

Questo è solo un esempio, ma in generale è un modo per disabilitare i gruppi, fino a quando non ne hai bisogno, in modo da renderli più facili da accendere e gestire.


1

I gruppi per utente ti consentono sia di "privacy nella tua home directory" sia di "facile collaborazione in cartelle condivise". Senza gruppi per utente, puoi avere uno ma non entrambi. I dettagli seguono:

Unix è un sistema multiutente, che si tratti di un file server aziendale o di un PC con 2 utenti. La "Privacy nella tua home directory" può essere realizzata in diversi modi:

Imposta "umask 077" in modo che i file vengano creati con rw per te e senza permessi per gli altri. In alternativa, 027 o 022 in modo che alcuni o tutti possano leggere ma non scrivere i tuoi file. L'ovvio svantaggio è che non puoi collaborare in una cartella condivisa perché gli altri non possono lavorare sui file che crei lì a causa di rigide autorizzazioni. È possibile modificare le autorizzazioni per tali file, ma questo è "troppo lavoro" e spesso dimenticato.

Per collaborare, vuoi qualcosa come "umask 7" in modo che sia tu che il gruppo proprietario sia possibile leggere e scrivere i file creati. Questo è ottimo per cartelle e gruppi condivisi costituiti da tutte le persone che necessitano di un accesso condiviso. Ma perdi la privacy nella tua cartella home!

Il gruppo per utente è la soluzione! Usi umask 7, quindi tutti i file che crei ottengono "rw per te e rw per il gruppo". I file nella tua home directory vengono creati con il tuo gruppo personale come "gruppo proprietario", quindi nessun altro può accedere a tali file nonostante l'autorizzazione "group rw". Perché nessuno tranne te è in quel particolare gruppo.

Puoi comunque collaborare in cartelle condivise. I file nella cartella condivisa ottengono "rw" per il gruppo proprietario e l'amministratore di sistema ha impostato la cartella condivisa in modo che un gruppo condiviso (chiamato collaboratori) diventi il ​​proprietario del gruppo per i file presenti. Questo viene fatto creando questo gruppo di collaboratori, con tutti gli utenti che collaborano come membri. Quindi, l'amministratore imposta la proprietà del gruppo della cartella condivisa su "collaboratori" e imposta l'autorizzazione SETGID per la cartella condivisa. Con SETGID attivo, tutto ciò che viene creato nella cartella condivisa otterrà lo stesso proprietario del gruppo della cartella condivisa, ovvero il gruppo "collaboratori". E con umask 7 (o in alternativa 2), le persone di questo gruppo avranno tutti accesso in lettura + scrittura e quindi saranno in grado di collaborare.


0

Inizialmente, i processi Unix potevano appartenere a un gruppo alla volta (c'era un chgrp(1)comando che chiedeva la password del gruppo memorizzata nel campo della password vestigiale in /etc/groups). I sistemi Plus sono stati utilizzati da un gruppo affiatato di utenti. Aveva senso avere tutti nel usersgruppo e condividere cose a livello di sistema con le autorizzazioni di gruppo. Nessuna vera coscienza di sicurezza, poca sospettosità della dozzina di altri utenti. Tutto era locale, sulla stessa macchina. Nessuna rete per condividere cose, ad esempio tramite un blog o giù di lì.

I sistemi Unix di oggi hanno centinaia di utenti, i requisiti di sicurezza sono più severi e gli utenti (e i processi) possono appartenere a diversi gruppi. Dai a ciascuno degli utenti (più ignari) un gruppo di casa e consenti di allontanarti da esso per la condivisione. Oppure usa gli ACL.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.