Issue 2495 - Access with filters fails to honor some valid filters
Summary: Access with filters fails to honor some valid filters
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: 2003-05-07 17:06 UTC by Quanah Gibson-Mount
Modified: 2014-08-01 21:05 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 Howard Chu 2003-05-07 15:29:49 UTC
changed notes
changed state Open to Closed
Comment 1 Quanah Gibson-Mount 2003-05-07 17:06:26 UTC
Full_Name: Quanah Gibson-Mount
Version: 2.1.18
OS: Solaris 8
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (171.64.19.82)


I have added the following ACL to my slapd.acl file:

access to dn.children="cn=people,dc=stanford,dc=edu"
filter=("suprivilegegroup=stanford:*") attr=uid,suprivilegegroup
by dn.base="uid=cadabra,cn=accounts,dc=stanford,dc=edu"
by * break

I know that the filter "suprivilegegroup=stanford:*" is a valid filter since I
can execute this from the command line without problem (note I've tried this
both with and without the ""'s).

However, when I access the server as cadabra:

BIND dn="uid=cadabra,cn=accounts,dc=stanford,dc=edu" mech=GSSAPI (etc)

I see this from debug 5 in slapd:

bdb_cache_find_entry_id ( 182342 ) "SuRegID=8696e59cf61311d2a<etc>,
cn=People,dc=stanford,dc=edu" (found) (1 tries)
bdb_search: 182342 does not match filter
bdb_cache_return_entry_r ( 182342 ): returned 0

This is obviously incorrect... That entry does indeed match my filter:

ldapsearch uid=cadabra suprivilegegroup
returns
suPrivilegeGroup: stanford:administrative

--Quanah

Comment 2 Quanah Gibson-Mount 2003-05-07 18:42:39 UTC
My fault on this one, didn't put in read access.  It works just fine. 
Please close.


--Quanah

--On Wednesday, May 07, 2003 5:06 PM +0000 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#2495.
>
> 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#2495)
> in the subject will automatically be attached to the issue report.
>
> 	mailto:openldap-its@openldap.org?subject=(ITS#2495)
>
> 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=2495
>
> Please remember to retain your issue tracking number (ITS#2495)
> 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 1999-2003 The OpenLDAP Foundation, All Rights Reserved.
>



--
Quanah Gibson-Mount
Senior Systems Administrator
ITSS/TSS/Computing Systems
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Comment 3 Howard Chu 2007-10-18 11:24:01 UTC
moved from Incoming to Archive.Incoming
Comment 4 OpenLDAP project 2014-08-01 21:05:44 UTC
user error, no bug