In AclSecurityImpl.evaluateAcl() when checking to see if /users/john can /actions/write resource /files/john/test.txt, the code finds a permissions match on the following permission (output is from the toString method): permission=[object=/files/john, subject=/roles/user, action=/actions/write, ->GRANT] because john has both /action/write permissions and matches the role of /roles/user but it doesn't find a match when the subject is owner because it only finds a match on the /action/write permission. The match on the subject fails because john is not yet the owner of /files/john/test.txt from what I can see. Since /files/john/test.txt is a new resource, the check should only be on /files/john.
Jason -----Original Message----- From: James Mason [mailto:[EMAIL PROTECTED] Sent: Friday, November 19, 2004 11:14 PM To: Slide Users Mailing List Subject: RE: write privileges for owner This sounds like a bug. You say it works if you grant write /roles/users? How does the logic in SecurityImpl differ in that case? -James On Fri, 2004-11-19 at 16:00 -0500, Jason McElravy wrote: > I tried setting the owner of the collection as you said but using the > webDAV client I got: > > $ propget john owner > Getting properties '/slide/files/john': /slide/users/<D:href > xmlns:D='DAV:'>/users/john</D:href> > > I switched back to the other way and put some debug lines in the > matchOwner method of ACLSecurityImpl and the owner of the resource is > being recognized fine so that's not the issue. > > I added some additional debug lines to gather some more information. > Here is my test scenario: > > /actions/write is granted to "owner" of /files and is inheritable > The /files/john collection has an "owner" set to /users/john > The /files/john collection is empty > I am authenticated as john > I try to PUT test.txt into /files/john > > In this scenario I get a 403. I put in some debug lines and found that > the 403 is being thrown because the security implementation is trying to > enforce /actions/write privileges for /users/john on > /files/john/test.txt which does not exist yet. This behavior doesn't > jive with the method privilege table in the webDAV access control > extension > (http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.html#rfc. > section.B) > Which says that when doing a PUT and the target resource does not > exist, you need <D:bind> privileges on the parent collection of the > target. Using these guidelines, in my scenario the PUT should succeed > by virtue of john having /actions/write privileges on the parent > directory /files/john. > > Is this a bug in the implementation? Would an alternative be to set the > owner on the new resource prior to the security checks? Any other > thoughts? Thanks in advance. > > Jason > > -----Original Message----- > From: James Mason [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 17, 2004 11:37 PM > To: Slide Users Mailing List > Subject: RE: write privileges for owner > > The "owner" property should be an href referencing the URI of a > principal in the system, eg: <D:href>/users/john</D:href>. Check out the > group-member-set properties of the various roles for examples. > > -James > > On Wed, 2004-11-17 at 21:18 -0500, Jason McElravy wrote: > > Oliver, > > > > Thanks for the tip on the users collection. As an alternative, > > I created a "john" collection under /files using the following > > configuration: > > > > <objectnode classname="org.apache.slide.structure.SubjectNode" > > uri="/files"> > > <permission action="all" subject="unauthenticated" > > inheritable="true" negative="true"/> > > <permission action="/actions/write" subject="owner" > > inheritable="true"/> > > <permission action="/actions/read-acl" subject="owner" > > inheritable="true"/> > > <permission action="/actions/write-acl" subject="owner" > > inheritable="true"/> > > > > <objectnode classname="org.apache.slide.structure.SubjectNode" > > uri="/files/john"> > > <revision> > > <property namespace="DAV:" > > name="owner">john</property> > > </revision> > > </objectnode> > > </objectnode> > > > > Unfortunately, I still get a 403 when I try to PUT a file into the > john > > collection even though I'm authenticated as john and john is the owner > > of the collection. Can anyone offer any clarification as to why this > is > > the behavior? I would also welcome alternative suggestions for an > > easily maintainable solution to setting up "home" directories for > users. > > Thanks in advance. > > > > -Jason > > > > > > -----Original Message----- > > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 17, 2004 6:06 PM > > To: Slide Users Mailing List > > Subject: Re: write privileges for owner > > > > Jason, the collections in users should not be used to store data. > > These are not supposed to be the home directory of the specific user, > > but are the representation of the user itself. > > > > Oliver > > > > > > On Wed, 17 Nov 2004 13:54:59 -0500, Jason McElravy > > <[EMAIL PROTECTED]> wrote: > > > I am hoping to get some clarification on a security configuration > for > > > slide. I want each user on my server to have write privileges in > his > > > "home" directory. To test this I tried to alter the default > > domain.xml > > > configuration so john could write to /slide/users/john. I tried > > > granting /actions/write to subject owner on /users and set > > > inheritable="true". Here is the snippet: > > > > > > <objectnode classname="org.apache.slide.structure.SubjectNode" > > > uri="/users"> > > > <permission action="/actions/write" subject="owner" > > > inheritable="true"/> > > > <permission action="/actions/write-acl" subject="owner" > > > inheritable="true"/> > > > <permission action="/actions/read-acl" subject="owner" > > > inheritable="true"/> > > > <permission action="all" subject="unauthenticated" > > > inheritable="true" negative="true"/> > > > > > > I set john as the owner of the john directory like this: > > > > > > <objectnode classname="org.apache.slide.structure.SubjectNode" > > > uri="/users/john"> > > > > > > <revision> > > > <property > namespace="http://jakarta.apache.org/slide/"; > > > name="password">john</property> > > > <property namespace="DAV:" > > name="owner">john</property> > > > </revision> > > > </objectnode> > > > > > > I am able to modify the properties of /users/john under this when > > > authenticated as john using this configuration but I get a 403 when > I > > > try to PUT a file in that directory. It works if /actions/write is > > > granted to /roles/user instead of owner for the /users uri but that > > > doesn't meet my requirements. I want to avoid having to maintain > > write > > > permissions for each user to their home directory like this: > > > > > > <objectnode classname="org.apache.slide.structure.SubjectNode" > > > uri="/users/john"> > > > <permission action="/actions/write" subject="/users/john" > > > inheritable="true"/> > > > > > > What am I missing in regard to granting write permissions to the > > owner > > > of a resource? Thanks in advance for your help. I am using > > > slide-server 2.1b2 and webdavclient 2.1b1. > > > > > > -Jason > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
