[Date Prev][Date Next]
Re: Ang. RE: Bdb defaults - WAS: problem importing entries.
-----BEGIN PGP SIGNED MESSAGE-----
Pierangelo Masarati wrote:
|>|>>access to dn="(.+,)?,ou=.+,(dc=.+,?)+$$"
|>| The above doesn't work,
|>It does. I tested it quite extensively. Did you try it (remember I am
|>running 2.1 still in most places and haven't tested these with 2.2).
| I mean: doesn't work as intended. I suggest you try the excpetions I
| proposed earlier
Sure, the limited ones are an issue that I will address shortly.
|>| since the default for "dn" in ACL is "exact" (the
|>| pros and cons of relying on defaults...);
|>Either the documentation is wrong,or regex is the default on 2.1, at
|>least according to slapd.access(5):
|>"The statement dn=<pattern> selects the entries based on their naming
|>~ context. The optional style qualifier <dnstyle> can be
| This is another business. I strongly recommend (and the recommendation
| should be even stronger for packagers) the explicit use of ".regex" since
| it is now more than one year that 2.2 (correctly) defaults to exact,
| otherwise an incredibly large number of sistema will cease to work as soon
| as 2.1 moves to historic, which is not too far from now.
Sure. That was also one motivation to be able to use global ACLs in an
included file (so that a user who doesn't make changes will be assisted
when upgrading the package).
|>| you had too many commas in your
|>| first part of the ACL, and there's an extra '$' at the end;
|>Well, it matches:
|>Jun 15 20:44:32 comanche slapd: => access_allowed: read access to
|>Jun 15 20:44:32 comanche slapd: => dnpat: 
|>Jun 15 20:44:32 comanche slapd: => acl_get:  matched
|>Jun 15 20:44:32 comanche slapd: => acl_get:  check attr
|>Jun 15 20:44:32 comanche slapd: <= acl_get:  acl
|>,dc=ranger,dc=dnsalias,dc=com attr: userPassword
| because most of these mistakes are harmless (especially the double '$$' at
| the end); however, the "(.+,)?,ou=" is not, in that it allows ANYTHING
| preceding "ou=" to match, not just a comma preceded by one or more RDNs.
| This is a big security hole.
Only to the point where a user must be able to create such a DN.
|>After reading some incorrect entries in Openldap docs, I trust tested
|>configs over theoreitical examples (even if the tested configs could use
| I tested my example with slapacl, which comes with 2.2 and is exactly
| intended for this. Usually, I don't trust wrong configs even if they pass
| malformed tests.
|>Yes, I know this still needs a bit of work ... but it works for most
|>configurations for now.
| A bit of work? this means anybody who defines an attributeType ending in
| "ou" can defeat your ACL!
Well, either the documentation is totally inadequate, or the user would
have to be able to create an entry with a dn using a naming attribute
ending in ou (and the only attribute in the provide schemas ending in ou
is "^ou$"), which the ACLs prevent except by certain DNs (which we
assume are safe otherwise we might as well set a null root password and
enable a telnet server).
Still better than exposing all passwords to all unauthenticated clients
|>| access to dn.regex="^(.+,)?ou=.+,(dc=.+,?)+$"
|>| But google will index your message, and at some point someone will mail
|>| this list asking for help because the advice [s]he googled out of the
|>| internet doesn't work [any more] so an error must have slipped into the
|>| code (as stuff googled out of the internet cannot be wrong, only code
|>| be); am I too pessimistic? It already happened.
|>Well, they can clearly see that this is not a suggestion. I will add
|>comments to read the relevant docs here too, and there is already a
|>notice saying that the user *must* test them.
|>But, you haven't answered the issue of the global ACLs being useless on
|>a replica (which basically removes any motivation to use regex-based
|>ACLs and any motivation to improve the correctness of these "examples").
| I must have missed that, but I recall recently answering someone that
| global ACL didn't change over time, and if they did it was a mistake;
| please be more precise (i.e. provide a working example, possibly against
| 2.2.latest, and, of course, 2.1.latest, as it is still maintained), and
| file an ITS, if you really think it's something worth getting fixed. A
| comment at the end of a long mail in an even longer thread is really
| likely to go unnoticed.
So, you read a whole mail who's only topic was the effect of global
ACLs, with the given ACLs as an example that is impossible to use on a
slave, yet you can criticise the ACLs?
Please, go back and read my mail again.
This was on 2.1.30. IIRC (I haven't had a chance to test) the behaviour
was different on earlier 2.1.x releases (2.1.22 or 2.1.25).
I will file an ITS later (it's already way too late here and too many
other things to finish up before the long drive home).
Buchan Milne Senior Support Technician
Obsidian Systems http://www.obsidian.co.za
B.Eng RHCE (803004789010797)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----