Full_Name: M Butcher Version: 2.3.27 OS: Linux (Ubuntu 6.06) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.34.42.242) Problem: Running slapacl, attributes marked as 'auth' and '=x' are shown to be readible. I first noticed this on 2.3.25 and posted the message to the list. In the meantime, 2.3.27 was released. At Pierangelo's request, I tested against 2.3.27. Step-by-step account of what I did to test: 1. Built from 2.3.27 and installed 2. Deleted old database files (from 2.3.25) 4. Manually checked version on slapd, symlink on slapacl. Also checked to make sure backend directory was empty. 5. Created minimal slapd and minimal testing ldif (see below) 6. Used 'slapadd -l testing.ldif' to add the LDIF 7. Ran test against cn -- read authorized on =x (full output posted below) 8. Ran test against userPassword -- read authorized on auth (full output pasted below) 7 and 8 seem to indicate incorrect behavior (or is there a reason slapacl would give read access to auth/=x?) Let me know if you need configure/make info, or if more logging would be helpful. It seems quite easy for me to reproduce the bug consistently. The LDIF (comments removed in original): ######## # BEGIN dn: dc=example,dc=com description: Example.Com, your trusted non-existent corporation. dc: example o: Example.Com objectClass: top objectClass: dcObject objectClass: organization dn: ou=Users,dc=example,dc=com ou: Users description: Example.Com Users objectClass: organizationalUnit dn: uid=matt,ou=Users,dc=example,dc=com ou: Users uid: matt cn: Matt Butcher sn: Butcher objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson userPassword: secret dn: uid=barbara,ou=Users,dc=example,dc=com ou: Users uid: barbara sn: Jensen cn: Barbara Jensen userPassword: secret objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson # END ######## SLAPD.CONF ######## # BEGIN include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args loglevel none modulepath /usr/local/libexec/openldap moduleload back_hdb access to attrs=userPassword by anonymous auth by self write by * none access to attrs=cn by users =x by self write by * none access to * by self write by users read by * none database hdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret directory /usr/local/var/openldap-data index objectClass eq index cn eq,sub,pres,approx # END ######## RUNNING SLAPACL # slapacl -D 'uid=matt,ou=Users,dc=example,dc=com' -b 'uid=barbara,ou=Users,dc=example,dc=com' -d acl 'cn/read' Backend ACL: access to attrs=userPassword by anonymous auth by self write by * none Backend ACL: access to attrs=cn by users =x by self write by * none Backend ACL: access to * by self write by users read by * none authcDN: "uid=matt,ou=users,dc=example,dc=com" => access_allowed: read access to "" "cn" requested => access_allowed: backend default read access granted to "uid=matt,ou=users,dc=example,dc=com" read access to cn: ALLOWED # slapacl -D 'uid=matt,ou=Users,dc=example,dc=com' -b 'uid=barbara,ou=Users,dc=example,dc=com' -d acl 'userPassword/read' Backend ACL: access to attrs=userPassword by anonymous auth by self write by * none Backend ACL: access to attrs=cn by users =x by self write by * none Backend ACL: access to * by self write by users read by * none authcDN: "uid=matt,ou=users,dc=example,dc=com" => access_allowed: read access to "" "userPassword" requested => access_allowed: backend default read access granted to "uid=matt,ou=users,dc=example,dc=com" read access to userPassword: ALLOWED Same thing woutout debugging (if this is what Pierangelo wants...): # slapacl -D 'uid=matt,ou=Users,dc=example,dc=com' -b 'uid=barbara,ou=Users,dc=example,dc=com' 'cn/read' authcDN: "uid=matt,ou=users,dc=example,dc=com" read access to cn: ALLOWED # slapacl -D 'uid=matt,ou=Users,dc=example,dc=com' -b 'uid=barbara,ou=Users,dc=example,dc=com' 'userPassword/read' authcDN: "uid=matt,ou=users,dc=example,dc=com" read access to userPassword: ALLOWED
I should note that when using a client app (namely, ldapsearch), it is the case that read access is not granted to cn and userPassword, so the problem does not seem to be a security issue. On 8/26/06, openldap-its@openldap.org <openldap-its@openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#4654. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its@openldap.org with (ITS#4654) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#4654) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=4654 > > Please remember to retain your issue tracking number (ITS#4654) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2006 The OpenLDAP Foundation, All Rights Reserved. > >
After closely looking at the code, when running slapacl global access rules do not get appended to each database specific rules. In fact, this only happens when backend_startup() is called with NULL argument, while slapacl calls it for each database passing the database's pointer as argument. As far as I can recall, this occurred because one of the backends, namely the one resulting from selecting for the DN passed with the "-b" switch, is already started up when control is passed to slapacl. I've fixed this by appending global access rules also when backend_startup() is called with a non-null argument; maybe a better fix would be to move this inside backend_startup_one(), unless I'm overlooking anything. The fix can be extracted from the CVS by running cvs diff -u servers/slapd/backend.c -r 1.366 -r 1.367 p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
changed notes changed state Open to Test moved from Incoming to Software Bugs
changed notes changed state Test to Release
changed state Release to Closed
moved from Software Bugs to Archive.Software Bugs
fixed in HEAD/re23