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

Re: Ang. RE: Bdb defaults - WAS: problem importing entries.

Hash: SHA1

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
|>regex (the
|>~       default)"
| 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[16375]: => access_allowed: read access to
|>"uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com" "userPassword"
|>Jun 15 20:44:32 comanche slapd[16375]: => dnpat: [1]
|>(.+,)?,ou=.+,(dc=.+,?)+$$ n
|>sub: 2
|>Jun 15 20:44:32 comanche slapd[16375]: => acl_get: [1] matched
|>Jun 15 20:44:32 comanche slapd[16375]: => acl_get: [1] check attr
|>Jun 15 20:44:32 comanche slapd[16375]: <= acl_get: [1] 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
|>some improvement).
| 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
by default.

|>| 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)
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org