Hi Ray,

It's been a while since the last followup to this bug, and I suppose by
now you've likely moved on, but if there's anything I can still help
with, or a bug still existing in the current version that I can fix, I'd
like to try.

On 16/06/11 01:24 PM, Ray Klassen wrote:
> I now know where my problem is coming from.
> 
> On upgrade without warning or comment the dpkg script slapd.preinst
> inserts the following access rules into the new cn=config configuration
> database  in the "dn: olcDatabase={-1}frontend,cn=config"
> 
> 
>> olcAccess: {0}to * by
>> dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
>> manage by * break
>> olcAccess: {1}to dn.exact="" by * read
>> olcAccess: {2}to dn.base="cn=Subschema" by * read
> 
> If if it's a live system and you depend on the default openldap access
> rules ( * by * read ) this is a sudden and (imho rude) change. Obviously
> tightening security is admirable, but some warning would be appreciated.
> 
> So the problem is not the conversion to 'cn=config' it's the debian
> package.

I don't think that's right. The first rule only affects the unix root
user, and only when using peer auth (-H ldapi:// -Y EXTERNAL); the
ending "by * break" means that the rule doesn't affect anyone else. Then
the second and third rules are exactly "by * read" rules, to make sure
that those specific entries can be read by the public even if you put
tighter access controls on your own database.

Without more info I can't comment on the result of the upgrade scripts
operating on your particular configuration, but I can say for sure that
the default setup in both squeeze and wheezy does in fact have the "to *
by * read" behaviour that you expected, except for the userPassword and
shadowLastChange attributes.

Debian slapd also did (and still does) have an option in
/etc/default/slapd to keep using slapd.conf instead of the new cn=config
style, and AFAIK that will remain for at least the duration of the 2.4
series.

thanks,
Ryan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to