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

Re: Access control in slapd (was Re: no more direct support ACIs?)

On Fri, 2005-12-09 at 16:54 +0100, RaphaÃl Ouazana-Sustowski wrote:
> On Ven 9 dÃcembre 2005 16:43, Pierangelo Masarati wrote:
> > Let me stress that, as I wrote in the initial message, ACIs will remain
> > part of slapd; only, they have already been factored out of access
> > control code, and they likely will move into a run-time loaded module,
> > but the original functionality will be fully preserved.
> As we are working on an other access control for slapd, I have some
> questions about that:
> - when you say "a run-time loaded module" do you mean a module as in
> contrib/slapd-modules or an overlay?

Let me clarify that the fact of being run-time loadable has little to do
with the functionality of the module; the main difference is that built-
in modules need be distributed (and compiled) with slapd's code, because
they must be statically initialized, while run-time loadable modules can
be compiled separately, they get loaded at startup (or when required),
so they take care of initializing themselves when they're actually
loaded.  I'm stating this because most of the overlays can be run-time
loaded as well, but they are supposed to do different things with
respect to dynacl modules.

> - in the first case do you think it is possible to make an overlay which
> does access control or is there any technical reason that prevent doing
> that ? 

If you read the (skeleton) FAQ <http://www.openldap.org/faq/index.cgi?
file=1284> about this topic, you'll find out yourself that you can use
either, but there is an essential difference between the overlay and the
dynacl approach:

- the overlay provides an infrastructure that allows to intercept
__all__ of the database operations (well, most of them, and some more),
PLUS the access control.  The way they do access control is: first use
the overlay function, which may either return access granted/denied, or
allow control to get to the default access checking.

- the dynacl is integrated within default access control, and allows to
insert custom checking at the <who> clause level; so you would end up
configuring access like

access to <something>
    by dn="cn=someone" read
    by group="cn=group" search
    by dynacl/mymodule="squeez'em" write

You need to weigh pros and cons, and see what approach best fits your
needs.  If you want to use default rules plus a variant, use dynacl; if 
you want to completely bypass default rules, and deal yourself with the
<what>, <who>, <access> and so clauses, use the overlay.


Ing. Pierangelo Masarati
Responsabile Open Solution

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it