[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: New ACL model and test operations

Sébastien Bahloul wrote:


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.


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