[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:
|>
|>--On Tuesday, June 15, 2004 4:21 PM +0200 Buchan Milne
|><bgmilne@obsidian.co.za> wrote:
|>
|>
|>># 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=.+,?)+$$"
|
|
| 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).
| 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)"
| 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
....
Jun 15 20:44:32 comanche slapd[16375]: access_allowed: no res from state
(userPassword)
Jun 15 20:44:32 comanche slapd[16375]: => acl_mask: access to entry
"uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com", attr userPassword"
requested
Jun 15 20:44:32 comanche slapd[16375]: => acl_mask: to all values by
"uid=bgmilne,ou=people,dc=ranger,dc=dnsalias,dc=com", (=n)
Jun 15 20:44:32 comanche slapd[16375]: <= check a_dn_pat: self
Jun 15 20:44:32 comanche slapd[16375]: <= acl_mask: [1] applying
write(=wrscx) (stop)
Jun 15 20:44:32 comanche slapd[16375]: <= acl_mask: [1] mask: write(=wrscx)
Jun 15 20:44:32 comanche slapd[16375]: => access_allowed: read access
granted by write(=wrscx)
After reading some incorrect entries in Openldap docs, I trust tested
configs over theoreitical examples (even if the tested configs could use
some improvement).
| this,
| moreover, will never match anything, because if $1 matches, there will be
| two consecutive commas in your pattern; if it doesn't, the DN will start
| with a comma, which is illegal. but, since you didn't put any '^' at the
| beginning, anything can appear before "ou=", even
| "landrou=x,dc=example,dc=com" would match, which I guess is not hat you
| meant; you should have done
Yes, I know this still needs a bit of work ... but it works for most
configurations for now.
|
| 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").
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
iD8DBQFAz0V5rJK6UGDSBKcRAqTbAJ95u10zWFsFIfUdTgnabShVIH40jACgsAoP
tRrZJzqlBbjSi4Tudq1GdJ0=
=bvR8
-----END PGP SIGNATURE-----