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]
