[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Test operations
- To: Sébastien Bahloul <bahloul@linagora.com>
- Subject: Re: Test operations
- From: Pierangelo Masarati <ando@sys-net.it>
- Date: Sat, 20 Nov 2004 01:41:34 +0100
- Cc: OpenLDAP Devel <openldap-devel@OpenLDAP.org>
- Domainkey-signature: a=rsa-sha1; s=mail; d=sys-net.it; c=simple; q=dns; b=FHMqZyPRSdUhL/CCyUbSYl6pgOYn+LIN8EKP4IlwgYI7iDJVbKfpFjDfR/qPc1Afe PcJNgDYGpDKRLsCW2E8sw==
- References: <419DD514.9020809@linagora.com>
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Sébastien Bahloul wrote:
Hello,
One month ago, I asked the list about integrating a new ACL model
(AACLs), which is currently in test phase, as an overlay.
Sebastien,
on a related note, I just committed a patch that allows to stack custom
access control models much like the original (and experimental) ACI. As
a rough example, the current ACI implementation has been moved to that
infrastructure. It needs some cleanup (at least), and may change
raplidly in the short future, but I expect it to be of limited
criticality. Essentially, you need to design a handler for masking the
access privileges to a value of an attribute of an entry by some
identity. The configuration is essentially that of the ACIs, i.e.
access to <what>
by dynacl/<name>[.<style>][=<pattern>] <access>
where "dynacl/" indicates that the dynamic ACLs are used; <name> is what
is used to locate the appropriate code, and the optional <style> and
<pattern> are intended to provide essential submatch expansion and data
specific to the module. The <access> is intended as a mask of the
privileges the module can give; more than one module can be specified in
the same <by> clause, and the privileges they build up are additive.
For backwards compatibility, the syntax for ACIs is unchanged, i.e. no
"dynacl/" prefix is required. The new code is enabled by default; to
revert to the original one, #undef SLAP_DYNACL in slap.h.
Module registration occurs vis the slap_dynacl_register() function,
which adds a newly registered set of handlers tot he infrastructure, so
that it can be configured thru the syntx described above. The
registration may occur at run-time by using the moduleload command, and
putting the call to slap_dynacl_register() in a function called
module_init(); see any of the overlays, or of the modularized backends
as examples.
Please let me know if you think this may be of any help for your AACLs;
in that case I can provide more details on the implementation. I know
you're now working at an overlay version, which should give you a more
complete view of each operation; this new approach should allow more
granularity and better harmonization with other, more conventional
access control techinques.
p.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497