Ancora su utenti, gruppi, permessi.

[pedrus]

Ciao a tutti. Avrei una ennesima richiesta di chiarimenti.
Ho assegnato ad aclune directory dei proprietari e dei gruppi di appartenenza e ho stabilito i vari permessi per utenti e gruppi. Ora avrei la necessità di fare in modo che i file e le directory creati all'interno di queste directory abbiano gli stessi permessi delle directory stesse. Avrei visto che ci sarebbe il comando umask, ma da quello che ho capito si applica globalmente ad ogni utente, invece nella pratica le directory avrebbero delle impostazioni differenti fra di loro. E' possibile impostare dei permessi specifici per ogni directory? Un po' come avviene con samba con la direttiva create mask.

[414N]

Ora avrei la necessità di fare in modo che i file e le directory creati all'interno di queste directory abbiano gli stessi permessi delle directory stesse.

Ti basta usare l'opzione -R di chmod su di una directory per applicare le stesse impostazione a tutti i file e le sottocartelle contenute. Se poi vuoi particolareggiare alcune sottocartelle con altri permessi, stesso giochino ma applicato alla sottocartella di interesse.

[pedrus]

L'opzione -R va a influire sui file e sottodirectory contenuti. Però sui file che vengono creati dopo no.
Mi spiego, la directory DIR1 è impostata come proprietario:gruppo così come il suo contenuto e con i permessi del tipo
rwx rwx --- , ovvero il proprietario e tutti gli utenti appartenenti al gruppo proprietario della directory leggono e scrivono, gli altri non fanno nulla. Mettiamo che un utente appartenente al gruppo crei un file all'interno della dir in questione, i file creati assumono permessi rwx r-- r--, ovvero solo chi ha creato il file può modificarlo mentre gli altri no, e comunque, il file creato finisce per appartenere al gruppo predefinito dell'utente e non al gruppo proprietario della directory. Di conseguenza sui nuovi file creati non vanno ad applicarsi i permessi precedentemente stabiliti per la directory. Io vorrei che i file che vengono creati all'interno delle varie directory ereditino i permessi della directory stessa.

[Mario Vanoni]

L'opzione -R va a influire sui file e sottodirectory contenuti. Però sui file che vengono creati dopo no.
Mi spiego, la directory DIR1 è impostata come proprietario:gruppo così come il suo contenuto e con i permessi del tipo
rwx rwx --- , ovvero il proprietario e tutti gli utenti appartenenti al gruppo proprietario della directory leggono e scrivono, gli altri non fanno nulla. Mettiamo che un utente appartenente al gruppo crei un file all'interno della dir in questione, i file creati assumono permessi rwx r-- r--, ovvero solo chi ha creato il file può modificarlo mentre gli altri no, e comunque, il file creato finisce per appartenere al gruppo predefinito dell'utente e non al gruppo proprietario della directory. Di conseguenza sui nuovi file creati non vanno ad applicarsi i permessi precedentemente stabiliti per la directory. Io vorrei che i file che vengono creati all'interno delle varie directory ereditino i permessi della directory stessa.

- chmod -R DIR1 e` rischioso, i files diventano eseguibili, sempre meglio solo read e write

- da vent'anni, tua situazione, i files degli utenti vengono creati solo via programma:
-- in C mettendoci un umask(0007);
-- nella shell umask 0660
-- le directories vengono create dal sistema, nel mio caso mensilmente, pregio:
> gli utenti non possono creare in una directory non esistente e non prevista

[pedrus]

E' chiaro, ma fino a un certo punto. Mi spiego con un esempio pratico

directory "gestione" proprietario utente1:gruppo1
il gruppo1 non è il gruppo principale di utente1. La directory ha permessi rwx per utente1 e rwx per gruppo1
Se utente1 scrive un file dentro gestione il file questo avrà come proprietario utente1 e come gruppo di appartenenza il gruppo principale di utente1 e i permessi sono rwx per utente1, r-- per il gruppo e r-- per gli altri. Ora, avrei capito come fare in modo di "forzare" un gruppo diverso da quello principale con chmod g+s gestione , ma resta il problema che il file per il gruppo1 continua ad avere permessi r-- , mentre, per la dir in questione a priori avevo stabilito rwx (o eventualmente rw-)
Settare un umak lo potrei anche fare, ma da quello che ho capito si applica a tutto il file system, mentre io avrei più directory da settare in modo differente fra di loro.
Diciamo che avrei risolto, forse in modo poco elegate, scrivendo uno script da avviare periodicamente e che riscrive i permessi delle varie directory così da aggiornare i permessi anche ai nuovi file creati.
Non ho capito un passaggio:

-- le directories vengono create dal sistema, nel mio caso mensilmente, pregio:
> gli utenti non possono creare in una directory non esistente e non prevista

In particolare non mi è chiaro cosa viene creato mensilmente.

[Mario Vanoni]

E' chiaro, ma fino a un certo punto. Mi spiego con un esempio pratico

directory "gestione" proprietario utente1:gruppo1
il gruppo1 non è il gruppo principale di utente1. La directory ha permessi rwx per utente1 e rwx per gruppo1
Se utente1 scrive un file dentro gestione il file questo avrà come proprietario utente1 e come gruppo di appartenenza il gruppo principale di utente1 e i permessi sono rwx per utente1, r-- per il gruppo e r-- per gli altri. Ora, avrei capito come fare in modo di "forzare" un gruppo diverso da quello principale con chmod g+s gestione , ma resta il problema che il file per il gruppo1 continua ad avere permessi r-- , mentre, per la dir in questione a priori avevo stabilito rwx (o eventualmente rw-)
Settare un umak lo potrei anche fare, ma da quello che ho capito si applica a tutto il file system, mentre io avrei più directory da settare in modo differente fra di loro.
Diciamo che avrei risolto, forse in modo poco elegate, scrivendo uno script da avviare periodicamente e che riscrive i permessi delle varie directory così da aggiornare i permessi anche ai nuovi file creati.
Non ho capito un passaggio:

-- le directories vengono create dal sistema, nel mio caso mensilmente, pregio:
> gli utenti non possono creare in una directory non esistente e non prevista

In particolare non mi è chiaro cosa viene creato mensilmente.

- la directory _deve_ essere chmod 0770 (drwxrwx---, altrimenti niente ricerca possibile!

- viene creata una directory /usr2/2008/2008M03 il 20 febbraio, il 20 marzo /usr2/2008/2008M04 ecc.
> per permettere di anticipare informazioni, ma maggio 2008 non esiste ancora, ne maggio 2009!
> Impedire agli utenti errore inutili, che nel dopo sono difficili da rimediare/trovare.

- per piu` directories, differenti tra di loro, shell script via crontab? Mancano infos per giudicare.

[pedrus]

Io ti sono debitore, il tuo aiuto è sempre prezioso.
Comunque:

per piu` directories, differenti tra di loro, shell script via crontab? Mancano infos per giudicare.

E' quello che sto facendo. Mi spiego.
dir1 -------> utente1:gruppo1 drwxrwx---
dir2--------> utente2:gruppo1 drwxr-----
dir3--------> utente3:gruppo2 dr--rwxrwx
dir4--------> utente4:gruppo3 drwxrwxrwx
ecc. ecc.

Fino ad arrivare ad un certo numero di directory. La situazione è molto eterogenea. C'è anche il caso in cui (vedi dir3) in cui il proprietario deve solo poter leggere ma non scrivere, mentre il gruppo può scrivere. Lo so, sembra una barzelletta, il proprietario che non può scrivere e altri si, ma la storia è lunga e non sto qui ad annoiarvi. Comunque, come detto, la situazione è eterogenea, directory con utenti e gruppi diversi, permessi diversi per le varie directory, allora sto scrivendo uno script da avviare a intervalli regolari (magari 3 minuti o anche meno) che contiene in sequenza comandi chown e chmod per riportare i file di volta in volta creati alla situazione voluta secondo lo schema che ho riportato (dir1, dir2, dir3).

Come detto stavo pensando a questo script da lanciare in crontab ogi 3 minuti. Pensate possa essere troppo gravoso sul sistema o sul disco farlo fare ogni tre minuti? Si tratterebbe si allineare proprietari e permessi di una 30ina di directory e relativo contenuto.
Grazie per la pazienza.

[Mario Vanoni]

Io ti sono debitore, il tuo aiuto è sempre prezioso.
Comunque:

per piu` directories, differenti tra di loro, shell script via crontab? Mancano infos per giudicare.

E' quello che sto facendo. Mi spiego.
dir1 -------> utente1:gruppo1 drwxrwx---
dir2--------> utente2:gruppo1 drwxr-----
dir3--------> utente3:gruppo2 dr--rwxrwx
dir4--------> utente4:gruppo3 drwxrwxrwx
ecc. ecc.

Fino ad arrivare ad un certo numero di directory. La situazione è molto eterogenea. C'è anche il caso in cui (vedi dir3) in cui il proprietario deve solo poter leggere ma non scrivere, mentre il gruppo può scrivere. Lo so, sembra una barzelletta, il proprietario che non può scrivere e altri si, ma la storia è lunga e non sto qui ad annoiarvi. Comunque, come detto, la situazione è eterogenea, directory con utenti e gruppi diversi, permessi diversi per le varie directory, allora sto scrivendo uno script da avviare a intervalli regolari (magari 3 minuti o anche meno) che contiene in sequenza comandi chown e chmod per riportare i file di volta in volta creati alla situazione voluta secondo lo schema che ho riportato (dir1, dir2, dir3).

Come detto stavo pensando a questo script da lanciare in crontab ogi 3 minuti. Pensate possa essere troppo gravoso sul sistema o sul disco farlo fare ogni tre minuti? Si tratterebbe si allineare proprietari e permessi di una 30ina di directory e relativo contenuto.
Grazie per la pazienza.

- dr--rwxrwx, l'utente in questione non puo` neanche ricercare (ls e co.)

- 3 minuti, il tempo dipende dalla HW, ma nel frattempo potrebbe cambiare i permessi, e` lui l'utente!
> con gli HD di oggi, con 32MB di memoria/cache, logica ottimizzata per fare poche mosse di testina, dimenticalo.

- IMVHO la tua sfida e` solvibile unicamente via software, al momento _zero_ idee altrimenti.

- In ditta ho una directory /usr/ditta/account, permessi d---------
> i files contenuti con permessi ----------
> li` registro, un file per utente, di tutti gli accessi dello stesso ai nostri programmi,
> lo fa nei programmi C un system modificato (vecchio trucco AT&T SVR2),
> che chiama un programma C con permesso chmod 4755
> e funziona perfettamente da >20 anni

[pedrus]

- IMVHO la tua sfida e` solvibile unicamente via software, al momento _zero_ idee altrimenti.

- In ditta ho una directory /usr/ditta/account, permessi d---------
> i files contenuti con permessi ----------
> li` registro, un file per utente, di tutti gli accessi dello stesso ai nostri programmi,
> lo fa nei programmi C un system modificato (vecchio trucco AT&T SVR2),
> che chiama un programma C con permesso chmod 4755
> e funziona perfettamente da >20 anni

Troppo incasinato, almeno per me, non ne ho le capacità giuste per farlo.

- 3 minuti, il tempo dipende dalla HW, ma nel frattempo potrebbe cambiare i permessi, e` lui l'utente!

I permessi non li cambiano, e comunque un ritardo di qualche minuto fino al successivo lancio dello script che rimette i permessi in ordine è accettabile. Si tratta di directory che saranno accessiabili via rete con Samba e gli utenti le vedranno nelle rispettive risorse di rete. Solo che Samba per ogni condivisione che si definisce la mostra affianco alle altre e tende, quindi, ad alterare la reale struttura ad albero del file system in questione.

> con gli HD di oggi, con 32MB di memoria/cache, logica ottimizzata per fare poche mosse di testina, dimenticalo.

Nel senso che il disco tende ad una usura troppo elevata? Porterò l'intervallo a 10 minuti. Un sistema per misurare il tempo impiegato dallo script per sistemare i permessi?

[Mario Vanoni]

> con gli HD di oggi, con 32MB di memoria/cache, logica ottimizzata per fare poche mosse di testina, dimenticalo.

Nel senso che il disco tende ad una usura troppo elevata? Porterò l'intervallo a 10 minuti. Un sistema per misurare il tempo impiegato dallo script per sistemare i permessi?

No, il contrario, non scrivono subito sul disco, aspettano di ottimizzare il movimento della testina,
con tanta memoria, manca la corrente, magari non ha ancora scritto niente sul disco.
Per questo ai tempi vecchi si faceva "sync ; sync ; sync" per forzare la scrittura.