Issue 4654 - slapacl behavior seems suspect
Summary: slapacl behavior seems suspect
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-27 04:30 UTC by technosophos@gmail.com
Modified: 2014-08-01 21:06 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description technosophos@gmail.com 2006-08-27 04:30:13 UTC
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



Comment 1 technosophos@gmail.com 2006-08-27 05:12:15 UTC
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.
>
>

Comment 2 ando@openldap.org 2006-08-28 11:31:43 UTC
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
------------------------------------------

Comment 3 ando@openldap.org 2006-08-28 11:32:56 UTC
changed notes
changed state Open to Test
moved from Incoming to Software Bugs
Comment 4 Kurt Zeilenga 2006-10-10 11:39:16 UTC
changed notes
changed state Test to Release
Comment 5 Kurt Zeilenga 2006-10-20 19:14:12 UTC
changed state Release to Closed
Comment 6 Howard Chu 2009-02-17 05:18:47 UTC
moved from Software Bugs to Archive.Software Bugs
Comment 7 OpenLDAP project 2014-08-01 21:06:45 UTC
fixed in HEAD/re23