You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-user@jakarta.apache.org by Brian Moseley <bc...@osafoundation.org> on 2005/03/02 21:13:53 UTC
permissions problem
i'm having a problem setting up permissions correctly.
here's what i want to achieve:
* users in the root role have all permissions throughout /; all others
have no permissions
* within /files, the owner of a resource has all permissions on that
resource; users in the root role continue to have all permissions on all
resources; all others have no permissions
i've attached my Domain.xml which describes the permissions i've
defined. briefly, tho:
<objectnode
classname="org.apache.slide.structure.SubjectNode" uri="/">
<permission action="all" subject="/roles/root"
inheritable="true"/>
<permission action="all" subject="all"
inheritable="true" negative="true"/>
...
<objectnode
classname="org.apache.slide.structure.SubjectNode" uri="/files">
<permission action="all" subject="owner"
inheritable="true"/>
</objectnode>
as a root user, i can log in to / with cadaver (which does a PROPFIND)
as expected, but i can't PUT a file (i get "403 Forbidden: Destination
URI /Domain.xml is restricted"). i would expect that assigning the "all"
permission and making it inheritable would allow me to PUT the file
here. however, i can PUT the file in /files/ (which returns
<unauthenticated>/<unauthenticated> for the owner property... can i set
the owner for an objectnode in Domain.xml?).
as a non-root user named bcm, i cannot log into either / or /files/, but
i can log into /files/bcm/, which is owned by bcm - all as expected.
again, however, i cannot PUT a file, even though i have assigned the
"all" permission to the owner of /files/bcm/ and made it inheritable.
instead i get the response "403 Forbidden: Access denied on / by user
/users/bcm for action /actions/read". as i'm trying to PUT
/files/bcm/Domain.xml, it's somewhat confusing that i'm being denied
access for reading /.
it seems like something's wonky specifically wrt write permissions
and/or inheritable. am i missing something obvious? how can i go about
tracking this down?
thanks!
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
Re: permissions problem
Posted by Brian Moseley <bc...@osafoundation.org>.
[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>.
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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org