access control on version storage

[Brian Moseley <bc...@osafoundation.org>]

preface: i've set up a workspace that contains home directories for my 
WebDAV server's users. i've written a custom AccessManager that allows 
root users to access any item in the workspace, but regular users can 
only access items within their home directories.

i've now run into the problem that when a regular user tries to create 
an item underneath his homedir node, a version history is created, but 
my AccessManager doesn't give him write access to 
/jcr:system/jcr:versionStorage.

i'm trying to formulate an access control policy for the version storage 
so that user A can't access user B's version histories. does the below 
make sense?

1) if the item i'm checking permissions for represents a version history 
node, then find the versionable node it represents and check permissions 
for that node instead

2) if the item i'm checking permissions for represents a version node, 
find its parent version history node, then do step 1

assuming that is a good approach, what api can i use to implement it? an 
access manager only has a HierarchyManager and an ItemId to work with, 
so i can't see how to examine node types and so forth.

thanks for any advice!

Re: access control on version storage

[Brian Moseley <bc...@osafoundation.org>]

Tobias Strasser wrote:

> all versioning operations that write to the version storage, do not
> make use of the accessmanager (yet). the 'checkPermission' or
> 'isGranted' calls you see are only read accesses for initializing the
> versionable node.
> 
> but you are right, the default accessmanager setup does not contain an
> ItemStateMgr or a SystemSession that you can use to retrieve more
> information about what is to be granted.
> 
> currently, i would use the hierarchymanager to retrieve the path of
> the item to be checked, and allow read-access for anything below
> /jcr:system/jcr:versionStorage. you cannot lookup the respective
> versionable node from within the accessmanager.
> 
> we should probably pass a system session upon initialization of the
> version manager or add it to the AMContext.

thanks for the explanation. i've taken your advice and allowed read 
access for everything below /jcr:system/jcr:versionStorage. i'll be 
happy to see the change you suggest made, tho :)

Re: access control on version storage

[Tobias Strasser <to...@gmail.com>]

hi brian,
all versioning operations that write to the version storage, do not
make use of the accessmanager (yet). the 'checkPermission' or
'isGranted' calls you see are only read accesses for initializing the
versionable node.

but you are right, the default accessmanager setup does not contain an
ItemStateMgr or a SystemSession that you can use to retrieve more
information about what is to be granted.

currently, i would use the hierarchymanager to retrieve the path of
the item to be checked, and allow read-access for anything below
/jcr:system/jcr:versionStorage. you cannot lookup the respective
versionable node from within the accessmanager.

we should probably pass a system session upon initialization of the
version manager or add it to the AMContext.

cheers, tobi

On Apr 1, 2005 11:08 PM, Brian Moseley <bc...@osafoundation.org> wrote:
> 
> preface: i've set up a workspace that contains home directories for my
> WebDAV server's users. i've written a custom AccessManager that allows
> root users to access any item in the workspace, but regular users can
> only access items within their home directories.
> 
> i've now run into the problem that when a regular user tries to create
> an item underneath his homedir node, a version history is created, but
> my AccessManager doesn't give him write access to
> /jcr:system/jcr:versionStorage.
> 
> i'm trying to formulate an access control policy for the version storage
> so that user A can't access user B's version histories. does the below
> make sense?
> 
> 1) if the item i'm checking permissions for represents a version history
> node, then find the versionable node it represents and check permissions
> for that node instead
> 
> 2) if the item i'm checking permissions for represents a version node,
> find its parent version history node, then do step 1
> 
> assuming that is a good approach, what api can i use to implement it? an
> access manager only has a HierarchyManager and an ItemId to work with,
> so i can't see how to examine node types and so forth.
> 
> thanks for any advice!
> 


-- 
------------------------------------------< tobias.strasser@day.com >---
Tobias Strasser, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97 
-----------------------------------------------< http://www.day.com >---