Hi Phil, if you mean that removing ACL from Domain.xml should remove them from slide, i do not agree with you. Domain.xml contains data that must be put in slide, however, that does not mean existing datas has to be discarded. If i put a permission on a Collection using DAVExplorer, i don't want to see this permission removed each time i restart the application just because it's not in my Domain.xml, so on this point i'll consider the fact old ACL are not removed as an excpected behaviour, same goes for node metadatas and everything else in Domain.xml.
Now if you mean new ACLs do not get read from Domain.xml when Domain.xml changes, i can tell the problem does not arise with slide 2.1 and the oracle jdbc store. I also have to mention a strange behaviour of ACL, they are not implemented as Access Control List, but as Access control Set (aka duplicates entries are not allowed), and this lead to some management problems, especially when you want to add a temporary rule on top of the acl and the pair principal+action already exist for the node. This for example is impossible to do on a node: /roles/manager all allow all /actions/read deny /roles/manager all allow all /action/read allow However there are cases when the app may want to put a specific set of ACLs on top of an existing one for a specific period of time. Regards -- David Delbecq Royal Meteorological Institute of Belgium - Is there life after /sbin/halt -p? Le Mardi 14 Juin 2005 09:49, Burnside, Phillip (UK - Glasgow) a écrit : > Carlos, > > On investigation I found an issue with the permissions. They don't get > flushed from any existing .def.xml files. So if you change the permission > in the Domain.xml and re-start you are not necessarily going to get what > you think you have set. The only way I found to sort this out was to > comment out the permission block in the .def.xml and then re-start. The new > permissions go in place nicely. I haven't looked at whether the same > problem exists in a relational store. > > If you get the metrics, I would be very interested in them also. > > Thanks in advance > Phil > > -----Original Message----- > From: Carlos Proal [mailto:[EMAIL PROTECTED] > Sent: Mon 13/06/2005 22:52 > To: Slide Users Mailing List > Cc: > Subject: RE: ACL problem > > > > > Great, im understanding more about how it works; digging in the archive > i also find important information about the relevant order the > permissions must have. > Its a little weird the way DavExplorer and command line handle this > order, anyone understand the logic ?? theorically each "add" must be on > top of the current permissions (at least in my mind) but it seems that > doesnt work that way. I'll play a little with the clients (even the > source code) to learn more about it. > > btw, im plannig to deploy the software on production with about 8,000 > users and more than 100,000 files, anyone has any usage benchmark ?? > > thanx again > Carlos > > > On Mon, 2005-06-13 at 22:17 +0100, Burnside, Phillip (UK - Glasgow) > > wrote: > > Carlos, > > > > If you revoke the access by using the negative="true" parameter for > the > > permission which gives all students access to the folder, then specify > > role or user to have access then this should sort you out. > > > > Hth > > Phil > > > > Phillip Burnside > > Deloitte MCS Ltd > > > > Direct: +44 (0)14 1304 5271 > > Main: +44 (0)14 1204 2800 > > Mobile: +44 (0)79 7969 2695 > > > > [EMAIL PROTECTED] > > www.deloitte.co.uk > > > > > > -----Original Message----- > > From: Carlos Proal [mailto:[EMAIL PROTECTED] > > Sent: 13 June 2005 18:24 > > To: slide-user@jakarta.apache.org > > Subject: ACL problem > > > > > > > > hi all. > > > > Im developing my first webdav application so im totally newbie on > this. > > Basically is an scholar module where i want to create folders for each > > subject, the teacher must have full access (read & write) and the > > students read only, but important: restricted to his/her courses. > > > > Let me review what i have done: > > > > For instance the default configuration allow everybody to write inside > > the "files" directory, so i have removed this. > > > > The root user is part of the users role, and i think is not desired in > > my case because root must have full access to everything and if i use > > some deny involving the users role, root will be affected too; so i > > removed root from users role. > > > > I have created a folder for MA123 (Math) as root and gave full access > > to john, now john can read and write on his folder perfectly but still > > remains a problem, everybody has read access* to MA123 (yeah i have a > > copyright issue) so, how can i deny read access to everybody else > except > > john and his students?, i suppose there must be a way to do a deny all > > and then grant the students (individually or by group). > > > > *By default everybody has read access from "/", apparently because a > > user needs to read roles/actions, but its inherited to "files" and i > > cant get rid of it, because appears several errors if i do it. > > > > ACL for /slide/files/MA123: > > ------------------------------------------------------------ > > granted to /slide/users/john (not protected) (not inherited) > > DAV:all > > granted to unauthenticated (not protected) (inherited from > > '/slide/files') > > DAV:all > > granted to property (not protected) (inherited from > '/slide/files') > > DAV:read-acl > > granted to /slide/roles/root (not protected) (inherited from > > '/slide/') > > DAV:all > > denied to all (not protected) (inherited from '/slide/') > > DAV:read-acl > > DAV:write-acl > > DAV:unlock > > granted to /slide/roles/user (not protected) (inherited from > > '/slide/') > > DAV:read > > ------------------------------------------------------------ > > > > Any ideas of how can i configure the right acls ? > > > > thanx in advance > > Carlos > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > IMPORTANT NOTICE > > If you have received this e-mail in error or wish to read our e-mail > > disclaimer statement and monitoring policy, please refer to the > > statement below or contact the sender. This communication is from > > Deloitte & Touche LLP. Deloitte & Touche LLP is a limited liability > > partnership registered in England and Wales with registered number > > OC303675. A list of members' names is available for inspection at > > Stonecutter Court, 1 Stonecutter Street, London EC4A 4TR, United > > Kingdom, the firm's principal place of business and registered > office. > > Deloitte & Touche LLP is authorised and regulated by the Financial > > Services Authority. This communication and any attachments contain > > information which is confidential and may also be privileged. It is > > for the exclusive use of the intended recipient(s). If you are not > the > > intended recipient(s) please note that any form of disclosure, > > distribution, copying or use of this communication or the information > in > > it or in any attachments is strictly prohibited and may be unlawful. > If > > you have received this communication in error, please return it with > the > > title "received in error" to [EMAIL PROTECTED] then delete > > the email and destroy any copies of it. E-mail communications cannot > be > > guaranteed to be secure or error free, as information could be > > intercepted, corrupted, amended, lost, destroyed, arrive late or > > incomplete, or contain viruses. We do not accept liability for any > such > > matters or their consequences. Anyone who communicates with us by > > e-mail is taken to accept the risks in doing so. When addressed to our > > clients, any opinions or advice contained in this e-mail and any > > attachments are subject to the terms and conditions expressed in the > > governing Deloitte & Touche LLP client engagement letter. Opinions, > > conclusions and other information in this e-mail and any attachments > > which do not relate to the official business of the firm are neither > > given nor endorsed by it. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
