Newsgroup: it.comp.www.php
Titolo: ACL, Regole ed Eventi

Stò costruendo un'applicazione dove i permessi utenti sono basati su Acl (quindi ruoli, ogni ruoli ha dei permessi, ogni utente ha più ruoli).
 
Quest'applicazione fa però largo uso di regole (condizione + azione) ed eventi (creazione contenuto, modifica, etc..)
 
 
Il problema sorge nel momento in cui una determinata regola deve compiere azioni con "permessi di root", nel senso:
 
Utente Amministratore: può fare tutto
Utente Foo: può creare articoli a listino
 
L'utente Foo non può ne creare ne visualizzare, ad esempio, i report, ma l'amministratore ha creato una regola che se viene creato un articolo a listino con categoria 'bar' deve essere creato un report con determinati dati.
 
Quindi fondamentalmente, la regola non deve essere eseguita con i permessi di Foo ma con quelli di amministratore.. la prima idea che mi è venuta in mente è di salvare i permessi dell'utente che crea la regola nella regola stessa, e nella sua esecuzione esegue uno switchRoles() sul controller user.
 
Inutile dire che avere un metodo simile apre problemi di sicurezza non indifferenti...
 
 
 
Vi vengono in mente altre soluzioni?

 Vi vengono in mente altre soluzioni?
 
Cosï¿œ di getto direi che potresti considerare il concetto di "owner".
Mi spiego meglio:
se un utente ï¿œ il proprietario di un qualcosa, allora avrï¿œ dei permessi 
particolari.
Bisognerebbe studiare un po come hai creato l'architettura ma da come 
l'hai descritta direi che potresti specificare delle regole per il role 
"owner". tale ruolo sarï¿œ associato all'utente se e solo se, quella 
risorsa ï¿œ "sua".
un saluto
 
-- 
Emanuele Desideri
 
 

 risorsa ï¿œ "sua".
 
Eh magari fosse così semplice!
 
Esempio: l'utente A è owner di un tipo di contenuto (report, post, chiccessia) mentre l'utente B no;
Il behavior che si deve creare è che l'utente B non può creare direttamente report, ma se l'utente A ha creato una regola che, per dire, ogni volta che l'utente B esegue il login viene creato automaticamente un report, questo deve avvenire, senza che l'utente B ne sappia niente...
 
Ovviamente una regola del genere la può creare solo l'utente A, pertanto potrei isolare le azioni fatte dalle regole eseguendole come "root" e affidando la sicurezza a chi ha il permesso di creare le regole, ma non mi piace, avrei comunque in giro un pezzo di codice che assume per i cavoli suoi i permessi massimi (o meglio, aggira l'acl)

 Vi vengono in mente altre soluzioni?
 
 
Probabilmente la soluzione di Emanuele si avvicina a quello che ti sto 
per dire
 
Su linux quando si vuole fare quello che chiedi si usa il suid bit sui 
permessi dell'eseguibile, ti è possibile un approccio del genere?
 
http://en.wikipedia.org/wiki/Setuid
 
 

 i permessi massimi (o meglio, aggira l'acl)
 
ok, si complica un po ma si puï¿œ fare, credo.
facciamo un esempio pratico.
A crea una risorsa. Possiamo quindi assumere che A ï¿œ owner di quella 
risorsa. Essere owner consente ad A una serie di operazioni su quella 
risorsa, tra cui "abilitare" un qualsiasi utente, diciamo B, ad avere 
permessi speciali per quella risorsa. Fin qui ï¿œ giusto il ragionamento?
se ci siamo allora A non deve creare una regola per B, bensï¿œ assegnare 
a B il role "permessiSpeciali" per quella risorsa.
B farï¿œ il login e ogni qual volta tenterï¿œ di accedere ad una risorsa 
ACL sarï¿œ in grado di stabilire se i permessi di B sono validi.
Assumiamo che B non abbia i permessi per vedere i report, ma quando 
vorrï¿œ vedere il report per la risorsa creata da A, il fatto di avere 
tra i roles il ruolo "permessiSpeciali", gli consentirï¿œ di accedere, 
senza scavalcare ACL.
Spero di essermi spiegato decentemente...
 
-- 
Emanuele Desideri
 
 

Grazie per le risposte, ma forse ho dato troppo pochi dettagli..
 
@RedWiz: fondamentalmente il setuid è quello che volevo fare io, solo mi preoccupa il fatto che allo scatenarsi della regola devo _sovvrascrivere_ i permessi dell'utente loggato per poi ripristinarli dopo l'esecuzione.. conta che queste regole sarano usate (a loro insaputa) anche da utenti anonimi.. la cosa mi spaventa un pò, se devo essere sincero
 
@Emanuele: credo di aver capito ma la cosa è un pò più complessa nel mio caso; Le regole che possono essere create (e le azioni associate) sono, nel mio caso, veramente molto flessibili (leggi: dispersive), e non posso far si che quando l'utente crea una regola deve crearne anche dei permessi.. Conta che anche i permessi sono gestiti dinamicamente, cioè ad esempio per un articolo del blog avrò i permessi _base_:
 
crea_articolo
modifica_articolo
elimina_articolo
 
In più però viene utilizzato il paradigma per le condizioni per creare al volo altri permessi, ad esempio
 
modifica_articolo_con_categoria_X
modifica_articolo_con_lunghezza_titolo_minore_di_5 (esempio un pò estremo)
 
E i permessi non coprono solo il contenuto, ma anche i suoi campi, ad esempio gli utenti anonimi non possono creare o eliminare articoli del blog, ma possono modificare il campo Commenti (aggiungendone degli altri)
 
 
 
La cosa è mooooooolto articolata e complessa

 La cosa è mooooooolto articolata e complessa
 
eh più le cose sono complesse e più bisogna semplificarle!
 
secondo me ti stai preoccupando di troppo cose tutte insieme.
Il problema sono le regole, occupati delle gestione delle stesse.
Il CHI e COME creerà queste regole è in questo momento secondario.
Oltretutto non vedo la difficoltà di creare regole flessibili con la 
logica esposta prima.
 
Scendendo in particolare, immagino che le regole, seppur create 
dinamicamente, avranno un loro insieme di esistenza.
Comincia col definire questo insieme, poi associare un utente ad una 
regola dell'insieme non sarà difficile, nè tantomeno sarà troppo 
complicato verificare se quell'utente, nel suo profilo, ha i permessi 
per fare una certa cosa!
 
Se poi ci dici cosa esattamente stai facendo, vedrai che qualche 
soluzione uscirà fuori, anche perchè più ne parli e più mi sembra che 
tu stia reinventando la ruota!
ti sei chiesto se una tale architettura esiste già? magari in qualche 
CMS? magari open? e magari darci un'occhiata dentro? :oÞ
 
-- 
Emanuele Desideri