Re: (ITS#4253) val.regex broken

[quanah@stanford.edu]

--On Friday, December 09, 2005 9:28 AM +0000 ando@sys-net.it wrote:

> I'm not yet sure I understand your issue; the tests I'm running (HEAD,
> re23) don't show any issue.  Let me first state that I spotted a "bug"
> in the "val" clause (the value had to be manually normalized for exact
> match; now fixed in HEAD), which however doesn't affect the "regex"
> style, so this is not the issue.
>
> I've set up a simple test, starting from test003 data, which shows that
> access to any of the two values of a multivalued attribute works
> correctly, but I'm not sure I clearly understand your case.  I suggest
> you setup a similar test case, possibly starting from the same data I'm
> posting below, and clearly describe the operations you perform, the
> behavior you obtain and the behavior you expect.

Okay, I'll be a bit more specific.

val.regex in 2.3.13 is not working for the first defined ACL using 
val.regex.  I modified my ACLs so that only a single val.regex ACL is 
defined:

access to dn.children="cn=people,dc=stanford,dc=edu" attrs=suPrivilegeGroup 
val.regex="^securemail:.+"
        by 
dn.base="cn=voltage,cn=service,cn=applications,dc=stanford,dc=edu" 
sasl_ssf=56 read
        by * break


when I search, no values of suPrivilegeGroup for a user that has them 
matching the regex are returned.  For example, here's my data:

tribes:~> ldapsearch -LLL -Q -h ldap-test1 uid=quanah suprivilegegroup
dn: suRegID=85e49978f61311d2ae662436000baa77,cn=people,dc=stanford,dc=edu
suPrivilegeGroup: securemail:testers
suPrivilegeGroup: securemail:main

Yet, when I search as the voltage service, I do not see any of the 
suprivilegegroup values returned:

tribes:/tmp# ldapsearch -LLL -Q -h ldap-test1 uid=quanah
dn: suRegID=85e49978f61311d2ae662436000baa77,cn=people,dc=stanford,dc=edu
suSearchID: qgibsonmount
suSearchID: quanah
suSearchID: quanahgibsonmount
uid: quanah


But, if I change my ACL's so that there are TWO val.regex statements, and 
the voltage one is SECOND, it works, but the first one doesn't:

access to dn.children="cn=people,dc=stanford,dc=edu" attrs=suPrivilegeGroup 
val.regex="^itss-smarts:.+"
        by 
dn.base="cn=smarts,cn=service,cn=applications,dc=stanford,dc=edu" 
sasl_ssf=56 read
        by group.base="cn=smarts,cn=applications,dc=stanford,dc=edu" 
sasl_ssf=56 read
        by * break

access to dn.children="cn=people,dc=stanford,dc=edu" attrs=suPrivilegeGroup 
val.regex="^securemail:.+"
        by 
dn.base="cn=voltage,cn=service,cn=applications,dc=stanford,dc=edu" 
sasl_ssf=56 read
        by * break



ldapsearch -LLL -Q -h ldap-test1 uid=quanah
dn: suRegID=85e49978f61311d2ae662436000baa77,cn=people,dc=stanford,dc=edu
suSearchID: qgibsonmount
suSearchID: quanah
suSearchID: quanahgibsonmount
uid: quanah
suPrivilegeGroup: securemail:testers
suPrivilegeGroup: securemail:main



Your examples you've sent aren't even regex's so I'm not sure that you are 
really testing the behavior here (or it works correctly in HEAD, but 
remains broken in RE_23.  I will build HEAD and see if I can reproduce it 
there as well).

access to attrs=cn val.regex="Mark Elliot"
access to attrs=cn val.regex="Mark A Elliot"

look like to val.exact statements where "regex" was simply put in place 
instead.  So I'm really not clear that the tests are that valid.

--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html