RE: Access Control development and cn=config

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga

> However, another approach would be move our slapd.conf(5)-based
> access control directives (and everything else) out of a file
> and into the directory.  This seems like a fairly pragmatic
> approach.

Moving into the directory would be sufficient. Moving away from a file isn't
necessary to accomplish that.
>
> Anyways, it would be interesting to pursue a slapd.conf(5)-less
> slapd(8).   Initially the server would start up without no
> configuration, listening only on ldapi:// and running with
> access controls allowing only the owner of slapd(8) process
> to read/write to the directory (use ldapi:// SASL/EXTERNAL for
> authentication).   Then, by a series of LDAP add, modify, and
> extended operations, the owner could configure the directory
> as desired.  In general, changes to configuration items would
> take effect immediately.  So, adding an ACL would change the
> policy being enforced.

Unfortunately, bootstrapping like this is impractical for the platforms that
don't/fully support ldapi.

> And to persist the configuration between slapd(8) instances,
> the configuration would be written to disk (LDIF) or database
> files.  While an admin could, in theory, muck with these
> files, that practice would be undocumented and unsupported.

My original idea was simply to change the slapd.conf syntax to LDIF so that
it could be readily exposed via LDAP. We can certainly put a BDB layer above
it, since BDB supports a flat file backend as well. We could even put a
back-bdb layer above it, using a "config compiler" to import from LDIF into a
binary database format, much like sendmail's "frozen config" files, (but not
actually frozen, of course).

> I'm thinking that LDAP administration would, besides allowing
> for dynamic update of configuration information (including ACLs),
> it would ease development of slicker administrative tools,
> including GUI and/or remote tools.

Yes!

Of course, there's a performance cost hiding in here - we will need to
mutex-protect a lot of tables that currently aren't, because they don't
normally change at runtime. E.g., all the schema tables, the ACLs, etc...

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support