Newsgroup: it.comp.os.linux.iniziare
Titolo: Permessi di un file diversi per + utenti.

Un mio amico che lavora su NT mi ha posto un quesito:
 Avendo 2 o piu' utenti che devono accedere allo stesso file (diciamo:
PIPPO.TXT), come posso fare affinche' i Permessi (RW principalmente, ma
anche X, volendo) siano diversi a seconda dell'Utente che tenta di
accedere al file stesso ?
***
Ad esempio voglio che Andrea e Federico possano accedere su PIPPO.TXT in
Sola Lettura mentre Luca e Francesco in Sola Scrittura.
Lui mi ha detto che con NT si riesce a fare ma con Linux non sono
riuscito a trovare una soluzione; si puo' fare ?
Saluti, U D A.
-- 
**********************************************************************
UDA'Software
mailto:
Andrea....@uda.itgo.com
http://uda.itgo.com


NT e Unix gestiscono le permission in maniera piuttosto diversa; in NT
posso dare permessi specifici su un oggetto per ogni utente diverso; in
Unix io ho:
- chi crea il file (owner);
- il gruppo di appartenenza del file (group)
- il resto del mondo (other);
Ad ognuno di questi posso dare i permessi di read, write, execute. Nel
tuo caso non puoi dare permessi a "andrea" e "federico", ma li dai
all'owner e a group/other (solo l'owner e' un utente, group e other
no).
Nel tuo caso devi gestire dei gruppi, non puoi pensare di dare singoli
permessi ad ogni utente.
Ciao.

 Sola Lettura mentre Luca e Francesco in Sola Scrittura.
Non capisco come Andrea e Federico possano accedere in sola scrittura se
il file e' di proprieta' di uno solo dei due. La stessa cosa credo
avvenga con Linux: se io facessi
# chown Andrea PIPPO.TXT
# chmod 624 PIPPO.TXT
# chgrp gruppoAF PIPPO.TXT
comuqnue Federico si becca un 'permission denied' ed e' giusto che sia
cosi'. Le ACL si NT non sono certamente tutto quello splendore che il
tuo amico vuol far credere, per esempio quando se Administrator deve
cambiare i permessi ad una directory e deve fare "Take ownership" per
poterlo fare, il che mi pare una mega cagata...
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 Sola Lettura mentre Luca e Francesco in Sola Scrittura.
Prendi una patch del kernel che implementi i trustees stile Novell,
con permessi diversi a seconda dell'utente e del gruppo. 
http://www.braysystems.com/linux/trustees.html
Sei avvisato che ti stai cacciando in un bosco di rovi (non tanto per
la patch, quanto per il sistema di gestione dei permessi stile Novell
che e` un bel casino da gestire.
-- 
Matteo Ianeselli  
matteoianeselli AT 
poboxes.com

 * Sostenete la Lega per la Soppressione dei Troll *
Ringrazio tutti per le risposte !
Vedro' di fargliele avere (anche lui e' interessato a Linux, anzi, lo
usa).
***
Devo pero' chiedere una mia curiosita' personale: per quale motivo non
hanno dato la possibilita' ai Links di assumere i Permessi come i files
normali ?
A mio modo di vedere sarebbe piu' che sufficiente per risolvere il
problema citato; ovviamente, il sistema dovrebbe essere fatto in modo
tale che solo l'utente Root possa scavalcare i Permessi del file
originario e non gli Utenti normali.
Ad esempio:
-rw-------   1 uda      gruppo         10 May  9 21:25 pippo.txt
ldddr--ddd   1 root     gruppo          9 May  9 21:26 pippo_Andrea.txt
-> pippo.txt
lddd-w-ddd   1 root     gruppo          9 May  9 21:26
pippo_Federico.txt -> pippo.txt
dove:
 l -> Indica che e' un Link
 d -> Indica che assume il permesso di default (ho buttato li' una
lettera)
In questo modo Andrea potrebbe solo leggere e Federico solo scrivere,
anche se i permessi del file non lo permetterebbero (ma e', ad esempio,
il fatto che il link appartenga a root a scavalcare il sistema).
Ciao, U D A.


 normali ?
Perche` chiunque potrebbe crearsi un link in /tmp e fare quello che
vuole di qualunque file (gia` e` un problema adesso se un'applicazione
suid root sovrascrive un file in /tmp senza prima verificare che
esista).
Se anche ci fosse un meccanismo per cui solo il proprietario di un
file puo` creare dei link simbolici ad esso, cio` sconvolgerebbe tutte
le applicazioni (veramente tante) che utilizzano i link simbolici per
implementare dei meccanismi di lock. 
Oltretutto, visto il modo in cui funzionano, rintracciare tutti i link
simbolici a un determinato file significa effettuare una ricerca per
tutto il filesystem, che non e` ne` veloce, ne` sicuro.
Oltretutto, come ci si dovrebbe comportare nel caso di una catena di
link simbolici? 
Insomma, come vedi, non e` una cosa che si liquida in due minuti e
stop.


 originario e non gli Utenti normali.
Credo sia perche' in realta' il symlink non e' un vero e proprio file
nella accezione in cui e' inteso ma e' un file speciale, come le named
pipes, per esempio. Oltretutto ci deve pur essere una qualche
implementazione delle ACL su Linux ma a me personalmente non interessano
piu' di tanto.


 matteoianeselli AT 
poboxes.com
Ciao, U D A.


 sfuggono, pero' penso che ci si possa lavorare sopra.
Sorry, m'era sfuggita la faccenda di "solo root". L'avevo intesa come
"solo root puo` infischiarsene dei permessi associati sia al file che
al link", come del resto avviene adesso. Questo cambia radicalmente la
cosa.
Sul momento non mi vengono in mente problemi particolari. Se me ne
venissero in mente, ti faccio sapere.
