Re: New ACL model and test operations

[Pierangelo Masarati <ando@sys-net.it>]

Sébastien Bahloul wrote:

> Hello,
>
> First point : I am looking to integrate a new ACL model in OpenLDAP.
>
> The main idea of this model is that relationship between entries is 
> the main key of authorizing to search or modify entries. So i thought 
> of a relation oriented ACL model. It has not be concepted to replace 
> ACL or ACI, but to fill the gap between ACL and ACI !
>
> The choice to use entries to store these new ACL may also be reused : 
> by using LDAP entries, ACL are synchronized between master and slaves.
>
> I give a first try (which is located at Sourceforge - 
> aacls.sourceforge.net) which is now in beta stage. It has been 
> designed as a backend but i don't think now that this was the good 
> choice.
>
> So i want to know if it could be interesting to rewrite and integrate 
> it in OpenLDAP.
>
> The second point is about test operations :  the main idea is, if the 
> directory is able to know when authenticated users are authorized to 
> write on a attribute, to create or to delete an entry, administration 
> interfaces could use these information to generate pages. So what do 
> you think about implementing a LDAP extended operation which can test 
> a particular right (i.e. right to modify the attribute of a special 
> entry, depending of the authenticated user) ?
>
> (the test write operation is also part of the first try publicated on 
> SourceForge)

I haven't read your document carefully enough, yet, to comment on the 
contents, but your idea sounds interesting.  Let me anticipate that 
attepts to write new ACL models are currently underway, you may want to 
compare with them; check for instance this thread: 
http://www.openldap.org/lists/openldap-devel/200407/msg00000.html
First of all, I suggest you work with CVS HEAD code rather than with 
some (very outdated) release. If you work with CVS code it should be 
much easier t keep your implementation up to date.
Another suggestion is that you try to develop your implementation as an 
overlay rather than as a patch; the straightforward approach would be to 
use a directive "access to * by * write", then control the actuall 
access rights by trapping each operation and applying your own controls, 
reducing the ampunt of information accessed accordingly. However, as a 
possible develoment, it might be worth extending the overlay mechanism 
by adding some ACL handling capabilities, e.g. something similar to ACIs 
syntax.  I'm thinking for instance of adding an "overlay" <by> clause, 
such that

access to *
 by overlay write

passes the overlay mechanism arbitrary access control to an entry (or 
portions of it, as dictated by the attrs[.val]  specification); then 
overlays could be allowed an access_allowed_mask() function that returns 
the mask associated to the combination of (sub)target and user.

Finally, to implement the access testing feature, you might be 
interested in looking at the slapacl(8) tool that is currently available 
in HEAD code; you could design an extended operation based on that 
principle.  Frankly, I don't see a general way to assess the permissions 
on data; the mechanism used in slapacl(8) is the only complete way to 
assess the access to a specific piece of data, but to me it looks rather 
impractical.  However, if the purpose is to let a well-designed client 
to assess in advance, on a limited set of attributes and for a limited 
set of entries what access te current user has, I can see room for 
perfoming a limited number of extended operations.

p.






   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497