You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Brian Moseley <bc...@osafoundation.org> on 2005/03/11 22:20:04 UTC
Re: permissions problem
[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: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: permissions problem
Posted by Brian Moseley <bc...@osafoundation.org>.
James Mason wrote:
> 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.
i think the problem is one step before that. when ACLSecurityImpl tries
to retrieve the revision descriptor for the resource, which happens
before checking the resource's owner, an exception is thrown since the
resource hasn't yet been created.
perhaps i don't understand the permission inheritance model, but my
expectation was that if the owner has an inherited write permission on
the parent collection, he would automatically have permission to write
any resources within the collection. that doesn't seem to be the wa
things work tho :)
> 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.
yeah, i'm not really sure what to do about it. i don't have enough a
feeling for the design of this component (or for Slide's security
framework in general) to propose a solution without a lot more study.
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: permissions problem
Posted by James Mason <ma...@apache.org>.
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: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org