Re: [Fwd: Re: Ang. RE: Bdb defaults - WAS: problem importing

["Pierangelo Masarati" <ando@sys-net.it>]

> Pierangelo Masarati wrote:
>
> | This is another issue.  please use the ITS if you think there's a bug.
> | Note that this part of ACLs has been the subject of a debate recently;
> | global scope ACLs are supposed to behave as they used to be from all
> | times; only, they are evaluated AFTER those database specific; so if you
> | have something like
> |
> | <slapd.conf>
> | # ...
> | access to attrs=userpassword
> |     by * =x
> |
> | database xxx
> | # ...
> | access to *
> |     by * read
> | </slapd.conf>
> |
> | then of course the global rule will never be used.  I'm positive
> | the behavior didn't change; if it did, then it's an error and deserves
> | an ITS.
>
> Hmm, how about a configuration with a global ACL like:
>
> # Protect passwords, using a regex so we can have generic accounts with
> # write access
> # Openldap will not authenticate against non-userPassword attributes
> # but we would have to duplicate most rules ...
> access to dn="(.+,)?,ou=.+,(dc=.+,?)+$$"
> 	attrs=lmPassword,ntPassword,sambaLMPassword,sambaNTPassword,userPassword
> ~        by self write
> ~        by dn="uid=root,ou=People,$2" write
> ~        by group="cn=Domain Controllers,ou=Group,$2" write
> ~        by anonymous auth
> ~        by * none

what if one doesn't load samba.schema?  Moot point: your package will
distribute samba.schema as well; but since it's not standard track
(no RFC making it commonly accepted by ietf) openldap is not likely
to distribute it.  This is why your package is more user-friendly than
openldap, no doubt.

A more sophisticated solution would be:

access to dn.regex="^(.+,)?ou=[^,]+,(dc=[^,]+)+$"
        attrs=userPassword@@SEP@@@@SAMBAPWD@@
    by self =xw
    by group.expand="cn=Domain Controllers,ou=Groups,$2" write
    by anonymous auth
    @@BYREPLICATOR@@

and have it processed by a m4 (or even a sed) to expand @@SAMBAPWD@@ and
@@REPLICATOR@@ respectively if samba has been selected and the file is
destined to a replica...  we did something like this for a customer who
wanted to be able to reconfigure the system at a glance by simply
answering a few questions; then the site administrators started makeing
changes manually instead of changing the template and running the macro
processor, but that's a completely different story...

note that by * none is implied (stupid defaults!) and the rootdn by
definition doesn't even run thru ACL evaluation... answered tons of times,
please test if you don't trust me!

>
> Then, a database definition like:
> directory       /var/lib/ldap
>
> ...
>
> access to *
> ~        by dn.exact="uid=root,ou=People,dc=example,dc=com" write
> ~        by group="cn=Replicator,ou=Group,dc=example,dc=com" write
> ~        by * read
>
> Now, if we have the final rule "by * read", then we aren't protecting
> the password, and if we have "by * none", then we can't do anonymous
> auth or let users change their passwords. Catch 22.
>
> Global ACLs should (IMHO) be global ... otherwise they are useless (at
> least if you have a replica).

seriously, I really don't understand this replica issue;
what's the difference between a master and a replica?
I haven't ever seen such a different behavior in terms
of ACL evaluation...

>
> If global ACLs are processed first, then they can be generic enough for
> most purposes, and database-specific ACLs can tighten up the last bits.
> But, if they are processed last, they are either used (with no
> customisation available), or they aren't.
>
> Maybe there are counter-arguments?

let's reverse your sentence: if global acls are processed first, either
they're too global, and then they catch all, so database specific rules
never get processed, or they are too specific, so they should really stay
with the database.  If you have just one database, it really does not make
any difference (well, except for rootDSE), and I guess you don't have more
than one, otherwise all this talking about defaults is really pointless,
because 99% of the installations need just one.

If you look at HEAD code, there's something that will make you happy: ACLs
are tested for scope, and those that are out of scope (e.g. "access to *"
in a database) issue a warning, to inform admins that their ACL is likely
to be inappropriate or to hide a more specific one (e.g. a global rule). 
This is simply a warning, because many times we want rules to be a bit
broader, and because this would break the usual "access to *" final rule
and the like in most of the installations (at least that minority that
make use of ACLs, according to your experience).  This is a completely
different point, and I don't know if this test will ever make into
release, because it really tricks people; I just added this note to show
you that ACL issues and in general user friendliness is something we do
consider and care about, we're not just "sitting arrogantly on our
positions" ;)  From our perspective (I guess the most of us) flexibility
is the key issue, because openldap must be able to adapt to a wide variety
of cases, and let me tell that in my limited experience as a consultant I
really had to face a lot of unusual situations.  The drawback is that the
software doesn't appear to have safe defaults; I'm really sorry about
that, and I hope that at some point ends will meet.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


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