[Date Prev][Date Next]
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
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
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:
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,
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