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