Newsgroup: it.comp.os.linux.iniziare
Titolo: permessi ereditari

è possibile in qualche modo fare in modo che quando un utente crea un
file questo venga creato con gli stessi permessi della directory in
cui si trova?
Matteo

 permessi della directory in cui si trova?
No. Il motivo e` che i permessi per le directory
hanno un significato leggermente diverso rispetto 
ai permessi per le directory.
man umask
PS. Lo so, e` built-in nella bash.

PS. Lo so, e` built-in nella bash.
Vabbe' pero' puo' non sapere di: help umask.
Per i built-in e' piu' comodo di: man bash e poi / per
cecare, ed inoltre per questa voce e' equivalente.
-- 
Saluti, Dalet

> Vabbe' pero' puo' non sapere di: help umask.
Conosco ed uso umask (e prevedevo la risposta), ma questa mi vale per
tutto il sistema, ovunque creo un file questo me lo fa con quei
permessi. Io invece voglio che siano quelli della directory corrente e
se mi sposto su un'altra directory che abbia permessi diversi, voglio
che si propaghino quelli. Che sò, magari esiste un attributo o acl che
si può aggiungere alle directory.
Matteo

 acl che si può aggiungere alle directory.
L'unica cosa che potrebbe esserti utile e` applicare i
permessi SUID e SGID alle directory in oggetto; in questo
modo il proprietario ed il gruppo del file sono quelli 
della directory e non chi crea il file.

 della directory e non chi crea il file.
Il che mi starebbe pure bene, ma l'ultima volta che l'ho fatto non ha
funzionato (è passato molto tempo, quindi non ricordo bene).
Il problema, sempre a memoria e intuito, è che se l'utente crea la
directory, questi saranno del proprietario della dir padre, ma la
directory appena creata non avrà i permessi suid/sgid, il che vanifica
tutto. Ho avuto lo stesso problema quando ho tentato di fare una cosa
analoga con lo sticky bit.
Matteo

Il 09-07-2007, Matteo Rossini dice:


Non ho questa competenza: non ho utenti veri con una rete
aziendale. Di utenti ci sono solo io con diversi nick.
Cmq il max che si puo' avere e' 666, l'eseguibilita' non
credo sia controllatra da umask.
Considera che in qualche modo - ma non so quale! - quando
salvi news o mail vengono impostati a 600 da qualunque
editor, dunque (concludo io) da bash.
Si tratta di scoprire se esiste (penso proprio di si') un
qualche programma che faccia qcs come: get permissions,
e poi farglielo fare sulla directory destinazione.
Con questo get potresti poi ottenere la umask da imporre a
bash... 'na parola, visto che bash puo' essere talvolta di
login, altre non di login (esempio con gli script).
-- 
Saluti, Dalet

 Matteo
Devi usare le ACL e creare una default ACL sulla directory

> Devi usare le ACL e creare una default ACL sulla directory
La default acl si propaga ai nuovi file e directory create?
Fantastico, visto che quello che mi serve propagare sono appunto acl.
Matteo

Matteo Rossini wrote:

esatto. ti consiglio un link per approfondire:
http://www.suse.de/~agruen/acl/linux-acls/online/

Matteo Rossini wrote:

]zac[
mmm ... di solito queste cose servono al mondo win, e tipicamente via samba.
Se fosse quello il caso samba ha delle opzioni per farlo facilmente (da quel
che ricordo).

Matteo Rossini wrote:

]zac[
Se usi le ACL, presta attenzione ai programmi di copia, backup, archivio,
ecc. che potrebbero non mantenere le ACL (una prova è cosa buona e giusta).

 ecc. che potrebbero non mantenere le ACL (una prova è cosa buona e giusta).
acc.. non ci avevo pensato.
devo ancora pensare se è importante o no. Io faccio una copia
periodica di quei dati, e di restore ne ho bisogno solamente per
disaster recover; a quel punto non credo sia un problema ripristinare
a mano i permessi...
Matteo

 che ricordo).
Il caso concreto:
si tratta delle directory htdocs di apache.
Ho fatto tanti virtualhost ed a ognuno ho assegnato una docroot
diversa.
ogni docroot ha un proprietario diverso. nessuna docroot ha come
proprietario l'utente con cui apache è running
tutti questi utenti si trovano nello stesso gruppo (quello dell'utente
apache)
Lo scopo di dividere gli utenti è quello di assegnare un virtual host
ad ogni persona, ed ognuno si può loggare solamente in FTP chrootato
nella propria htdocs.
(Voglio evitare di settare l'umask nel file di configurazione di ftp)
Il problema:
1) c'è un utente (webmaster), in sftp e ssh (no ftp) in modo da poter
controllare in lettura e scrittura tutte le htdocs.
2) in qualche directory l'utente apache deve poter fare upload.
3) in tali directory cmq sia webmaster, sia il proprietario del
virtualhost devono poter continuare a scrivere nuovi file e prelevare/
cancellare/modificare i file uplodati.
Per tutto questo non basta mettere una semplice umask a 002, anche
perchè seppure bastasse per gli utenti ftp, non posso chiedere a
webmaster di settarsi lui una umask a 002 quando si connette in ssh
perchè creerebbe file con tali permessi in giro per tutto il
filesystem. Il webmaster non sono io; dentro le docroot facesse quasi
quello che gli pare, ma non voglio vada a fare casini nel resto del
sistema. Inoltre il demone apache crea file con mask 022.
Probabilmente pure questo si può modificare, ma preferisco agire a
livello di filesystem rispetto a quello di utente.
credo che le acl bastino per questo.
Matteo

Matteo Rossini wrote:

se per il backup usi star invece di tar ti salva anche le ACL


Interessante...
lo terrò in considerazione.

 credo che le acl bastino per questo.
]zac[
Si dovrebbero essere una buona soluzione.
La '''tipica soluzione''' unix è invece di quella di preparare delle zone in
cui gli utenti scaricano i propri dati e poi un comando manuale o attivato
via crontab provvede alla pubblicazione con tutto quello che serve (in
sintesi il punto è evitare che gli utenti abbiano accesso diretto alla zona
su cui si vuole operare).


Una simile l'ho tenuta in considerazione, ma significa che le
modifiche ad una pagina non sono attive istantaneamente.
Allora, semmai, una soluzione più utile sarebbe che un crontab
sistemasse periodicamente tutti i permessi al modo giusto, tipicamente
a 664, così anche se uno crea un file questo può essere modificato da
tutto il gruppo.
Comunque le zone rimangono chrootate. Il problema è solamente l'utente
admin che deve poter far tutto.
Matteo