I've created a bug entry for this: http://issues.apache.org/bugzilla/show_bug.cgi?id=32352
-James On Sat, 2004-11-20 at 00:13 -0500, Jason McElravy wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
