I think this is related to an issue where the owner property of a file is not set until after the resource is created. So when ACLSecurityImpl checks an inherited "owner has write" permission, no one is the owner yet.
It seems like a simple bug, but I haven't come up with a good way to fix the design, so it would probably have to be a special case in the code (and I think that's just ugly). Also, I think owner-only write permissions aren't very common, so no one's gotten itchy enough yet to scratch at it. -James On Fri, 2005-03-11 at 13:20 -0800, Brian Moseley wrote: > [bringing this over to dev list in hopes somebody will see it] > > have been looking into this further, and it seems like maybe > inheritance is not being followed through with when > ACLSecurityImpl checks my permissions. > > here are the debug log entries corresponding to storing the > parent collection's modification time: > > 2005-03-11 12:47:12,792 DEBUG [ACLSecurityImpl] @@@ check > object=/files/bcm, subject=/users/bcm, action=/actions/write > > 2005-03-11 12:49:53,760 DEBUG [ACLSecurityImpl] > permission=[object=/files, subject=owner, > action=/actions/write, ->GRANT], match=true > > and these are the log entries for storing the resource itself: > > 2005-03-11 12:49:53,775 DEBUG [ACLSecurityImpl] @@@ check > object=/files/bcm/test.txt, subject=/users/bcm, > action=/actions/write > > 2005-03-11 12:53:24,763 DEBUG [ACLSecurityImpl] > permission=[object=/files, subject=owner, > action=/actions/write, ->GRANT], match=false > > ********** here is the key. this one should have matched, > since /files/bcm/test.txt is within /files/bcm, right? or do > i misunderstand inheritance somehow? > > <snip a bunch more debug statements and then the exception > when checkOwner tries to access the revision descriptor for > /files/bcm/test.txt which does not exist> > > for what it's worth, i have acl_inheritance_type set to path. > > Brian Moseley wrote: > > > > finally i've been able to fire up a debugger and figure out what > > specifically is going on with my permissions issue. it seems that an > > "owner" permission cannot successfully be matched when the resource does > > not actually exist. > > > > i've changed my permissions so that "all" can read everything within > > /files. furthermore i have explicitly granted write permission to > > "owner" for /files. > > > > my expectation now is that because /files/bcm is owned by /users/bcm, > > that user should be able to PUT /files/bcm/test.txt with no problems. > > however, that request returns "Access denied on /home/bcm/test.txt by > > user /users/bcm for action /actions/write". > > > > when ACLSecurityImpl.matchOwner() attempts to retrieve the revision > > descriptor for /home/bcm/test.txt, a RevisionDescriptorNotFoundException > > is thrown. this makes sense, because i'm trying to create the resource > > on the server. however, it means that matchOwner() fails - and therefore > > so does the entire PUT request. > > > > can anybody suggest an alternate way for me to structure permissions (or > > extend slide) so that only the owner of the parent collection can create > > a resource within that collection? > > > > > --------------------------------------------------------------------- > 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]
