Login | Register
My pages Projects Community openCollabNet

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Catacomb] Fwd: catacomb acl



FYI,


---------- Forwarded message ----------
From: Artem Lantsev <art@itm.nkz.ru>
Date: Thu, 24 Jun 2004 01:22:18 +0800 (KRAST)
Subject: catacomb acl
To: art@itm.nkz.ru, hunkim@cs.ucsc.edu


hello Sung

I have several thoughts - and will be very appreciated if you read it

1. It's obvious that the principal is just another type of the
resource - and I wonder why it is not specified in RFC

I mean that the repository will be like directory service -

Root
 Users
   User1
   User2
   ...
   UserN
   Group1
   Group2
   ...
   GroupN

 Repository
   Resource1
     Resource11
     ...
     Resource1N
   Resource2
     Resource21
     ...
     Resource2N

Then I propose introduce several allknown principals - like
Administrators, Guests, Nobody
And some way to identify some users with these allknown principals

2. There are some unclear places in the RFC - as far as I understand,
properties can be live, dead, protected and in addition it is possible
to control the access to a certain property.
I propose do not introduce additional entity like protected property -
instead I propose to implement the protection of the properties by
ACL.

Then I propose add new privileges -
DAV:read-all-properties
DAV:write-all-properties

and

DAV:read-property
DAV:write-property

so ACL request will be like this -

 <?xml version="1.0" encoding="utf-8" ?>
 <D:acl xmlns:D="DAV:">
   <D:ace>
     <D:principal>
       <D:href>http://www.example.com/users/esedlar</D:href>
     </D:principal>
     <D:grant>
       <D:privilege>
         <D:read-property>
           <D:namespace>property_namespace</D:namespace>
           <D:name>property_name</D:name>
         </D:read-property>
       </D:privilege>
     </D:grant>
   </D:ace>
 </D:acl>

Actually, the methods to manipulate ACL concerning with certanin
properties can be changed later to be correspondance with future
releases of the RFC
But now this implementation will allow to make unify way to process
common properties and properties like "owner" or "group"

The owner of the resource can always change the ACL connected with the resource.
A principal which is the member of the allknown group
"Admininistrators" has ability to become the owner of any resource.

3. Then, it needs to rewrite the way of processing the live properties
- as far as I understand it must be implemented as hook - so anyone
will be able to add new live property and the way how to process it
without recompiling the mod_dav and mod_catacomb - only add new module
to apache

I'll try to explain it in details - actually acl, owner, group and so
on is just a special property of the resource - I mean that it is very
similar to plain live prperty - but it can not be processing like
plain live property - it is very similar to lockdiscovery or
supportedloks properties -
of course it is possible to add the swich-case like code ( based on
nesded if-else statements ) into catacomb module - but I think that
this is not right way - I mean that such solution will not be scalable
and it is too difficult to support such desicion
I think it must be introduced hook based way to add different live
properties with functions to fill/get it.

4. I've made several changes in the mod_dav - how to I can integrate
these changes into apache repository?

5. I would like to make several changes in the general catacomb database design

6. Each collection MUST has one ACL to assign it with new created
non-collection child resources, and another ACL to assign with new
created child colllection resources.

I guess that it must be implemented the same way as in the NT - each
ACE in ACL must has special flags which indicate does this ACE
propogate into new created child collection and non-collection
resources.

7. Another point which is not clear to me is the way to communication
between dav module (catacomba) and some authentication module.
As far as I understand, in ideal case the authentcation must be tear
off into separate module - like mod_ldap or something else - this
module will process all authentiation logic

but the problem is that in the same repository collection can be
contained several resoures and one resource can be accessed by anyone,
when another can has access rights only for certain users

I have no idea how to use standard authentication apache modules to allow this.

So I guess that whole repository directory will be mandatory served by
some authentication module.
Another open question is how to map logged user into ACL principal - I
have some ideas how to map logged user into ACL user principal, but it
is not clear what I have to do with groups.

In ideal case will be perfect to use some standart way to manage user
groups - like ldap - but it is not quite clear for me now.

Another thought - as I mentioned above - principal is just another
resource - so in general it is possible to use PROPFIND/PROPPATCH
WebDAV requests to manage groups.

And may be it will be the most easiest way to make initially the
authentiaction implementation completely based on catacomb module.

Your thoughts and advices will be very much appreciated.

I intend to complete the sample working version in the next 1,2 weeks
- it will be almost strightforward implementation of the ACL support -
but I think that the many thing which was mentioned above have to be
implemented in the near future

kind regards
Artem Lantsev

PS: I tried to get catacomba code from CVS something about one week
ago - but I did not get it. I'm using in current work the version 0.9
from source tgz archive.

mailto:art@itm.nkz.ru