Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <428A2E27.3090304@wanadoo.fr>
Date: Tue, 17 May 2005 19:47:19 +0200
From: Tony Blanchard <bltony@wanadoo.fr>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: ACLs questions
References: <20050517125401.93404.qmail@web30714.mail.mud.yahoo.com>
In-Reply-To: <20050517125401.93404.qmail@web30714.mail.mud.yahoo.com>
Content-Type: multipart/alternative;
 boundary="------------010603050801020407060505"

This is a multi-part message in MIME format.
--------------010603050801020407060505
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

I have no idea on  how to do those things now but a thing that I can do 
is to point out the security requirement  that I told about in a mail on 
this thread.
A duplication of the tree should duplicate ACLs.
So subentries look better for this.
Meanwhile, a duplication could also transfer a configuration file 
instead... But how ?

Best regards
Tony Blanchard


Marc Boorshtein a �crit :

>>X.500 subentries are recommended to store various
>>information for an 
>>autonomous administrative area.  The area can be for
>>schema, ACLs, or 
>>collective attributes.  The area of coverage for the
>>contained 
>>information in the subentry is defined by the
>>subtree specification 
>>which includes parameters for chop before, chop
>>after, and subtree 
>>refinements.  This is all X.500 stuff that the LDAP
>>community is 
>>reintroducing today.  One can almost say there is a
>>subtle convergence 
>>going on. 
>>
>>    
>>
>
>Well, there's allways a difference between
>"theoretical" truths and "practical" truths.  While it
>might seem that it makes the most sence to store ACL
>entries in a subtree, the implementation and
>performace is not practical.  
>
>For instance, what if you have an ACL that defines a
>restriction on reads of the "sn" attribute for
>anything subtree of "dc=domain,dc=com".  When
>processing the entry
>"uid=test,ou=Users,dc=test,dc=domain,dc=com".  You
>could allways travers the DN backworkds to get all the
>ACLs and cache those acls so you don't need to find
>them again in the request, but that seems like a lot
>of overhead (on top of the ACL processing overhead).
>
>A second practical issue is managment.  Instead of
>managing all your ACLs in one place, now you have to
>manage it on each node.  Seaches could show you all of
>the acls in a single report, but now it makes
>management a bit harder.
>
>Finally, what about custom partitions and remote
>services? (LDAP Proxy, DB Partition).  Now you need
>each partition to be responsible for it's own ACL
>processing.
>
>So while in a stand alone directory environment with
>simple ACLs using a sub entry may be the easiest way
>to go, but when you have a large envuronment with
>other types of partitions this could become combersome
>quickly.
> 
>  
>
>>If you want to commit to something we can explore
>>implementing 
>>subentries together first.  Next we need to include
>>support for schema 
>>structures for subtree specifications and algorithms
>>for subtree entry 
>>set inclusion evaluation.  Finally we can begin
>>talking about 
>>implementing the actual ACL mechanism - IMO the ACL
>>mechanism can be 
>>developed in parallel and stored somewhere else
>>until we complete these 
>>components in parallel.  This way Tony can begin
>>working with us as well.
>>    
>>
>
>As much as I would like to contribute, I simply don't
>have time to share anything but my experience.
>
>Marc
>
>
>
>
>  
>

--------------010603050801020407060505
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I have no idea on&nbsp; how to do those things now but a thing that I can do
is to point out the security requirement&nbsp; that I told about in a mail
on this thread.<br>
A duplication of the tree should duplicate ACLs. <br>
So subentries look better for this.<br>
Meanwhile, a duplication could also transfer a configuration file
instead... But how ?<br>
<br>
Best regards<br>
Tony Blanchard<br>
<br>
<br>
Marc Boorshtein a &eacute;crit&nbsp;:
<blockquote
 cite="mid20050517125401.93404.qmail@web30714.mail.mud.yahoo.com"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">X.500 subentries are recommended to store various
information for an 
autonomous administrative area.  The area can be for
schema, ACLs, or 
collective attributes.  The area of coverage for the
contained 
information in the subentry is defined by the
subtree specification 
which includes parameters for chop before, chop
after, and subtree 
refinements.  This is all X.500 stuff that the LDAP
community is 
reintroducing today.  One can almost say there is a
subtle convergence 
going on. 

    </pre>
  </blockquote>
  <pre wrap=""><!---->
Well, there's allways a difference between
"theoretical" truths and "practical" truths.  While it
might seem that it makes the most sence to store ACL
entries in a subtree, the implementation and
performace is not practical.  

For instance, what if you have an ACL that defines a
restriction on reads of the "sn" attribute for
anything subtree of "dc=domain,dc=com".  When
processing the entry
"uid=test,ou=Users,dc=test,dc=domain,dc=com".  You
could allways travers the DN backworkds to get all the
ACLs and cache those acls so you don't need to find
them again in the request, but that seems like a lot
of overhead (on top of the ACL processing overhead).

A second practical issue is managment.  Instead of
managing all your ACLs in one place, now you have to
manage it on each node.  Seaches could show you all of
the acls in a single report, but now it makes
management a bit harder.

Finally, what about custom partitions and remote
services? (LDAP Proxy, DB Partition).  Now you need
each partition to be responsible for it's own ACL
processing.

So while in a stand alone directory environment with
simple ACLs using a sub entry may be the easiest way
to go, but when you have a large envuronment with
other types of partitions this could become combersome
quickly.
 
  </pre>
  <blockquote type="cite">
    <pre wrap="">If you want to commit to something we can explore
implementing 
subentries together first.  Next we need to include
support for schema 
structures for subtree specifications and algorithms
for subtree entry 
set inclusion evaluation.  Finally we can begin
talking about 
implementing the actual ACL mechanism - IMO the ACL
mechanism can be 
developed in parallel and stored somewhere else
until we complete these 
components in parallel.  This way Tony can begin
working with us as well.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
As much as I would like to contribute, I simply don't
have time to share anything but my experience.

Marc


  </pre>
</blockquote>
</body>
</html>

--------------010603050801020407060505--