[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Ang. RE: Bdb defaults - WAS: problem importing entries.
-----BEGIN PGP SIGNED MESSAGE-----
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"
|>requested
|>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
|>userPassword
|>Jun 15 20:44:32 comanche slapd[16375]: <= acl_get: [1] acl
|>uid=bgmilne,ou=People
|>,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
|>can
|>| 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).
Regards,
Buchan
- --
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
iD8DBQFAz1AsrJK6UGDSBKcRAgROAJ4xUjF94W+iNzLF54apSFt4KU8uigCePJtb
OW4Dn4+lQBb2ty9SRmrvgJs=
=nXOW
-----END PGP SIGNATURE-----