Le Mardi 28 Juin 2005 09:44, delbd a écrit : > Ok, example, as it seems as thread goes on things get confusing: > > let's take the node /a/b/c > > The ACL on /a/b/c is build as follow: > > ACEs on c > ACEs inheritable from b > ACEs inheritable from a > ACEs inheritable from / > > > Then to check security, slide takes the requested permission (eg > /actions/read) > and the requested user (eg unauthenticated). Slide then follow the ACL build > previously > and read it from top to bottom. The *first* ACE found which match the user > and the > requested permission applies (this could be, for example, /actions/read on > user all). > If the matching ACE is a grant, then permission is granted. If the matching > ACE is a > deny, then permission is denied. > > > bonus. :-) > > How can we know exactly what ACEs to put to grant or deny a permission > > (how Slide processes permissions exactly ?) > Just put them in order on /a/b/c, the first to match is applied. > Don't forget when you add permissions to a node already having permissions, > the new permissions you add are put at the top of the list. >
Sorry, i mean, they are added at the *bottom* of the list :D > Le Lundi 27 Juin 2005 18:17, Thomas Bellembois a écrit : > > Hello Miguel, > > > > I don't understand two thinks : > > 1. > > When you say that "the first inherited is always the last processed", do > > you mean that Slide processes inheritable ACE on /b, then inheritable > > ACE on /a ... ? > > 2. > > Why ACEs on a resource are not enougth to grant or deny a permission > > (cf. my problem on /files/partage/demoEsup) ? > > > > bonus. :-) > > How can we know exactly what ACEs to put to grant or deny a permission > > (how Slide processes permissions exactly ?) > > > > Thank you. > > > > Thomas > > > > Miguel Figueiredo wrote: > > > > >Hello Thomas, > > > > > > Inherited ACEs are always resolved last. For example, take the following > > >path: > > > > > >/slide/file/a/b/c.txt > > > > > >Slide first checks for c.txt ACEs, then b/ ACEs, then a/ until slide/ > > >collection's ACEs. Means that inherited ACEs are always processed last, and > > >the first inherited is always the last processed. > > > > > >Hope this helps, > > >Miguel Figueiredo > > > > > >-----Original Message----- > > >From: Thomas Bellembois [mailto:[EMAIL PROTECTED] > > >Sent: segunda-feira, 27 de Junho de 2005 15:35 > > >To: Slide Developers Mailing List > > >Subject: ACL evaluation > > > > > >Hello, > > > > > >I have a problem trying to put permission on one resource. > > >I have understood that ACL's are evaluated from the top to the bottom. > > >But what about inherited ACL's ? Are they evaluated first ? > > >I could not find this information neither in the RFC or in the mailing > > >list. :-( > > > > > >My problem is that I have the following permissions : > > >/files/partage : deny all all inheritable > > >/files/partage/demoEsup : grant read /users/demoEsup inheritable, grant > > >write /users/demoEsup inheritable > > > > > >And the user demoEsup can not read or write in the folder > > >/files/partage/demoEsup. > > >But if I change the permission on /files/partage into : > > >/files/partage : deny write all inheritable > > >it works... > > > > > >Any idea ? > > > > > >Thank you very much > > > > > >Thomas > > > > > > > > > > > > > > -- David Delbecq Royal Meteorological Institute of Belgium - Is there life after /sbin/halt -p? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
