Re: uso di GID molto alti
On 21/12/19 19:25, Leonardo Boselli wrote: il numero degli utenti del sistema è oltre i 18 con poche eccezioni di utenti che sono membri di migliaia di gruppi, gli altri sono normalmente membri di qualche decina di gruppi. secondo me per risolvere semplicemente e avere una soluzione efficiente, dal punto di vista della velocità, dovresti poter associare ai file più GID, in modo che poi ogni utente possa agire su tutti i file a cui è associato il suo GID. Da quello che dici sarebbero pochi i file che avrebbero un numero elevato di GID associati Però non so come potresti fare qualcosa del genere :-( Fare l'inverso: associare ad ogni utente un elenco di gruppi, secondo me, potrebbe rendere lenta l'esecuzione, oltre a dover creare un gran numero di gruppi ulteriori. Probabilmente puoi usare i namespaces: ogni namepaces è un gruppo e in quel gruppo ci butti dentro soltanto i processi degli utenti di quel gruppo... il problema è che se un utente appartiene a più gruppi può vedere un gruppo alla volta. Ma anche qui dovendone creare così tati non so se avresti problemi prestazionali. Un'altra soluzione potrebbe essere che ogni gruppo corrisponde ad una directory. Ad ogni utente monti (link simbolico) l'elenco delle directory a cui appartiene. Il problema è che ogni utente, in teoria, potrebbe leggere/scrivere ogni file di ogni gruppo... se accedesse direttamente alla directory reale, ache se non montata per lui. Magari puoi fare un mix tra le ultime due soluzioni: 1) un utente entra 2) crei un namespace con le directory (gruppi) che l'utente può vedere 3) sposti l'utente (il pid del processo usato per visionare i file) in quel namespace Naturalmente i file e le directory all'esterno del namespace non devono essere visibili agli utenti. In questo modo, se il numero di utenti contemporanei è contenuto, dovresti avere buone prestazioni. Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Fate una prova di guida ... e tenetevi la macchina!: http://linguistico.sf.net/wiki/doku.php?id=usaooo2 Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: uso di GID molto alti
il numero degli utenti del sistema è oltre i 18 (Ma per motivi storici con UID fino a 4000), e non ci sono stati problemi a crere utenti con numeri alti , basta forzarli con --uid, e comunque gli utenti regolarmente attivi sono poche centinaia. con poche eccezioni di utenti che sono membri di migliaia di gruppi (ma questi, meno di 15, sono "fidatissimi" e possono utilizzare comandi speciali), gli altri sono normalmente membri di qualche decina di gruppi. Stavo pensando che tutte le possibili combinazioni sarebbero gli utenti presi a n a n, decisamente troppe per 32 bit però ... però la quasi totalità di gruppi è formata da 2 utenti che condividono un certo numero di file, e questi file hanno la caratteristica che hanno permessi 640 , per cui se l'owner è UIDautore:GIDlettore possiamo usare la convenzione normale senza fare troppe ricerche , e solo per quei pochi che hanno due o più "lettori" (in teoria qualche decina di migliaia) usare i gruppi "normali" ( con gid da 1 in su ). Eventualmente mettere questi gruppi all'inizio della lista aiuterebbe ? (faccio presente che tutti gli accessi vengono fatti da una applicazione web che si interfaccia con un sottosttema che gira con permessi elevati e fornisce le informazione in maniera "sicura" ; gli owner e i gruppi sui file sarvono solo per potere usare delle utility di backup che salvino solo i file a cui un determinato utente ha accesso, e questo viene fatto abbastanza di rado (massimo una volta la settimana, e solo per gli utenti attivi [ossia se l'utente nella ultima settimana non ha fatto accessi, non serve fare il backup dei suoi dati]) -- Leonardo Boselli
Re: uso di GID molto alti
On 20/12/19 09:49, Federico Di Gregorio wrote: # adduser --uid 19711019 test Adding user `test' ... Adding new group `test' (19711019) ... Adding new user `test' (19711019) with group `test' ... Creating home directory `/home/test' ... Copying files from `/etc/skel' ... New password: Retype new password: passwd: password updated successfully (Tutto funziona) non ho provato, leggendo il man pensavo non funzionasse senza modificare MAX_UID... che però se inserisci un valore superiore al range di SUBUID potresti aver problemi... L'importante è verificare che nessun'altra parte del sistema (tipo volumi di rete o sistemi di virtualizzazione) utilizzino gli uid alti. sì, ma come puio prevedere il futuro? Se dall'aggiornamento di domani ti arriva un qualcosa che usa un uid alto che tu hai già usato... In ogni caso se dovessi mettere su un sistema con tutta questa granularità utilizzerei gli attributi estesi del file system bisogna anche capire bene cosa vuole fare e per quale scopo. Il problema, se non ho capito male, è avere un numero di utenti e/o gruppi molto elevato. Se è superiore ai 90.000 secondo me rischi di aver problemi futuri. Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Browser: http://www.mozilla.org/products/firefox GNU/Linux User: 302090: http://counter.li.org Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: uso di GID molto alti
On 12/19/19 9:12 PM, Davide Prina wrote: On 19/12/19 10:11, Federico Di Gregorio wrote: Linux usa uid di 32 bit. Non c'è alcuna differenza nello scegliere come id 5 oppure 19711019. (Ovviamente non puoi andare oltre 2^31-1) $ grep UID_T /usr/include/bits/typesizes.h #define __UID_T_TYPE __U32_TYPE $ davide:~# grep '#define __U32_TYPE' /usr/include/bits/types.h #define __U32_TYPE unsigned int ---8<8<8<8<- a.c ---8<8<8<8<8<- #include #include int main( void ) { printf("uid_t: %d bytes (%d bits)\n", sizeof(uid_t), sizeof(uid_t) * 8); } ---8<8<8<8<8<8<8<8<8<8<- $ gcc a.c $ ./a.out uid_t: 4 bytes (32 bits) quindi non dovrebbe essere 2^³²-1? Si, ma _mi sembra_ di ricordare che in alcuni punti venga usato un signed int. Non trovo i riferimenti, roba vecchia di anni. Però andando a leggere in giro ho trovato che: $ cat /etc/login.defs | grep UID UID_MIN 1000 UID_MAX 6 Quindi il massimo UID per l'utente è impostato a 60.000 di default. $ man 5 login.defs In ogni caso puoi cambiare i valori in login.defs oppure utilizzare direttamente i parametri --uid e --gid: # grep UID_MAX /etc/login.defs UID_MAX 6 # adduser --uid 19711019 test Adding user `test' ... Adding new group `test' (19711019) ... Adding new user `test' (19711019) with group `test' ... Creating home directory `/home/test' ... Copying files from `/etc/skel' ... New password: Retype new password: passwd: password updated successfully (Tutto funziona) # deluser --remove-home test Looking for files to backup/remove ... Removing files ... Removing user `test' ... Warning: group `test' has no more members. Done. L'importante è verificare che nessun'altra parte del sistema (tipo volumi di rete o sistemi di virtualizzazione) utilizzino gli uid alti. In ogni caso se dovessi mettere su un sistema con tutta questa granularità utilizzerei gli attributi estesi del file system: imposti i permessi su di una directory e fai in modo che tutti i file le sotto-directory li dentro li ereditino, così non hai bisogno di un numero assurdamente alto di gruppi. [snip] federico -- Federico Di Gregorio federico.digrego...@dndg.it DNDG srl http://dndg.it Ma nostro di chi? Cosa abbiamo in comune io e te? -- Md
Re: uso di GID molto alti
Il 19 dicembre 2019 21:12:09 CET, Davide Prina ha scritto: >On 19/12/19 10:11, Federico Di Gregorio wrote: >> Linux usa uid di 32 bit. Non c'è alcuna differenza nello scegliere >come >> id 5 oppure 19711019. (Ovviamente non puoi andare oltre 2^31-1) > >$ grep UID_T /usr/include/bits/typesizes.h >#define __UID_T_TYPE __U32_TYPE > >$ davide:~# grep '#define __U32_TYPE' /usr/include/bits/types.h >#define __U32_TYPE unsigned int > >---8<8<8<8<- a.c ---8<8<8<8<8<- >#include >#include > >int main( void ) > { >printf("uid_t: %d bytes (%d bits)\n", sizeof(uid_t), sizeof(uid_t) * >8); > } >---8<8<8<8<8<8<8<8<8<8<- > >$ gcc a.c >$ ./a.out >uid_t: 4 bytes (32 bits) > >quindi non dovrebbe essere 2^³²-1? > >Però andando a leggere in giro ho trovato che: > >$ cat /etc/login.defs | grep UID >UID_MIN 1000 >UID_MAX6 > >Quindi il massimo UID per l'utente è impostato a 60.000 di default. > >$ man 5 login.defs >[...] >UID_MAX (numerico), UID_MIN (numerico) >Intervallo di ID utente da utilizzare nella creazione degli utenti >normali tramite useradd o newusers. >Il valore predefinito per UID_MIN (rispettivamente UID_MAX) è 1000 >(rispettivamente 6). >[...] > >valori maggiori sono usati da SUB_UID (tra 100.000, 600.100.000) > >$ man 5 subuid >... > >Poi non so... > > > >> Il 19/12/19 08:38, Leonardo Boselli ha scritto: > A chi ha provato: ci sono problemi a usare dei GID molto, molto >alti > >>> (diciamo sopra il miliardo), soprattutto in temini di prestazioni? > >>> (igruppi sarebbero diverse centinaia di migliaia, in genere con 2 membri, e potrebbero anche essercene alcuni (qualche centinaio) con centinaia di membri. ) (servono per dare accesso a singoli gruppui > >>> di file) > >I subuid sono usati in Debian: > >$ cat /etc/subuid > >L'uid max usabile in teoria è 6, se usi i comandi per la creazione >di utenti. > >Se gestisci tu numeri più alti di 600.100.000, non so se puoi avere >problemi... e non so come puoi fare a creare tanti utenti, scavalcando >il limite sopra indicato. > >Se invece hai utenti limitati, ma sono le combinazioni elevate, allora >penso che per i GID penso valga lo stesso discorso > >$ cat /etc/login.defs | grep GID > >$ cat /etc/subgid > >$ man subgid > >Inoltre dovresti avere che ogni utente appartiene probabilmente a >migliaia di gruppi... e questo penso che possa rallentare parecchio >solo >per il parsing del file. > >Forse puio fare qualcosa con namespace e cgroups > >Ciao >Davide secondo me, per una gestione così capillare di tanti utenti, ti converrebbe avere la gestione su dominio, con autenticazione da dominio. AD è Microsoft, credo che smb simuli qualcosa, forse kerberos può gestire la cosa, ma non ho esperienza, noi abbiamo tantissimi utenti, ma siamo su AD Microsoft, e la maggior parte delle macchine sono winzoz (purtroppo). byez -- gollum1 Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e gli errori, maledetto correttore automatico.
Re: uso di GID molto alti
On 19/12/19 10:11, Federico Di Gregorio wrote: Linux usa uid di 32 bit. Non c'è alcuna differenza nello scegliere come id 5 oppure 19711019. (Ovviamente non puoi andare oltre 2^31-1) $ grep UID_T /usr/include/bits/typesizes.h #define __UID_T_TYPE__U32_TYPE $ davide:~# grep '#define __U32_TYPE' /usr/include/bits/types.h #define __U32_TYPE unsigned int ---8<8<8<8<- a.c ---8<8<8<8<8<- #include #include int main( void ) { printf("uid_t: %d bytes (%d bits)\n", sizeof(uid_t), sizeof(uid_t) * 8); } ---8<8<8<8<8<8<8<8<8<8<- $ gcc a.c $ ./a.out uid_t: 4 bytes (32 bits) quindi non dovrebbe essere 2^³²-1? Però andando a leggere in giro ho trovato che: $ cat /etc/login.defs | grep UID UID_MIN 1000 UID_MAX 6 Quindi il massimo UID per l'utente è impostato a 60.000 di default. $ man 5 login.defs [...] UID_MAX (numerico), UID_MIN (numerico) Intervallo di ID utente da utilizzare nella creazione degli utenti normali tramite useradd o newusers. Il valore predefinito per UID_MIN (rispettivamente UID_MAX) è 1000 (rispettivamente 6). [...] valori maggiori sono usati da SUB_UID (tra 100.000, 600.100.000) $ man 5 subuid ... Poi non so... >> Il 19/12/19 08:38, Leonardo Boselli ha scritto: >>> A chi ha provato: ci sono problemi a usare dei GID molto, molto alti >>> (diciamo sopra il miliardo), soprattutto in temini di prestazioni? >>> (igruppi sarebbero diverse centinaia di migliaia, in genere con 2 >>> membri, e potrebbero anche essercene alcuni (qualche centinaio) con >>> centinaia di membri. ) (servono per dare accesso a singoli gruppui >>> di file) I subuid sono usati in Debian: $ cat /etc/subuid L'uid max usabile in teoria è 6, se usi i comandi per la creazione di utenti. Se gestisci tu numeri più alti di 600.100.000, non so se puoi avere problemi... e non so come puoi fare a creare tanti utenti, scavalcando il limite sopra indicato. Se invece hai utenti limitati, ma sono le combinazioni elevate, allora penso che per i GID penso valga lo stesso discorso $ cat /etc/login.defs | grep GID $ cat /etc/subgid $ man subgid Inoltre dovresti avere che ogni utente appartiene probabilmente a migliaia di gruppi... e questo penso che possa rallentare parecchio solo per il parsing del file. Forse puio fare qualcosa con namespace e cgroups Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Client di posta: https://www.thunderbird.net GNU/Linux User: 302090: http://counter.li.org Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: uso di GID molto alti
On 12/19/19 9:21 AM, Paolo Redælli wrote: Il 19/12/19 08:38, Leonardo Boselli ha scritto: A chi ha provato: ci sono problemi a usare dei GID molto, molto alti (diciamo sopra il miliardo), soprattutto in temini di prestazioni? (i gruppi sarebbero diverse centinaia di migliaia, in genere con 2 membri, e potrebbero anche essercene alcuni (qualche centinaio) con centinaia di membri. ) (servono per dare accesso a singoli gruppui di file) Beh, credo che GID e UID siano sempre "maneggiati" come un int che sulle macchine attuali è "comunque veloce". Non mi sorprenderi di scoprire che ora nel nucleo e nelle utility connesse si usi un int64. Ad ogni modo no, non dovrebbero esserci problemi e non dovrebbero in particolare essercene di prestazioni Linux usa uid di 32 bit. Non c'è alcuna differenza nello scegliere come id 5 oppure 19711019. (Ovviamente non puoi andare oltre 2^31-1). federico -- Federico Di Gregorio federico.digrego...@dndg.it DNDG srl http://dndg.it I did appreciate the irony that I was whining about encoding issues on a mailing list that was unable to show those chars, too. -- Antti S. Lankila to mono-devel-list@
Re: uso di GID molto alti
Il 19/12/19 08:38, Leonardo Boselli ha scritto: A chi ha provato: ci sono problemi a usare dei GID molto, molto alti (diciamo sopra il miliardo), soprattutto in temini di prestazioni? (i gruppi sarebbero diverse centinaia di migliaia, in genere con 2 membri, e potrebbero anche essercene alcuni (qualche centinaio) con centinaia di membri. ) (servono per dare accesso a singoli gruppui di file) Beh, credo che GID e UID siano sempre "maneggiati" come un int che sulle macchine attuali è "comunque veloce". Non mi sorprenderi di scoprire che ora nel nucleo e nelle utility connesse si usi un int64. Ad ogni modo no, non dovrebbero esserci problemi e non dovrebbero in particolare essercene di prestazioni
uso di GID molto alti
A chi ha provato: ci sono problemi a usare dei GID molto, molto alti (diciamo sopra il miliardo), soprattutto in temini di prestazioni? (i gruppi sarebbero diverse centinaia di migliaia, in genere con 2 membri, e potrebbero anche essercene alcuni (qualche centinaio) con centinaia di membri. ) (servono per dare accesso a singoli gruppui di file) -- Leonardo Boselli