April 2011 - openldap-bugs

Re: (ITS#6900) dnattr acl statement: users can produce dangling entries

by daniel＠pluta.biz

Hopefully nobody else than me has wasted his/her time reviewing my previously submitted patches related to this ITS. They are completely wrong! Here you'll find a rewritten version from scratch which should work as expected or at least can be taken as a basis for further reviewing: ftp://ftp.openldap.org/incoming/Daniel-Pluta-110424-2.patch

11 years, 11 months

1
0
0 / 0

Re: (ITS#6912) authz-regexp DN normalization of authcIDs

by daniel＠pluta.biz

this micro-patch "works for me": ftp://ftp.openldap.org/incoming/Daniel-Pluta-110424.patch Disclaimer: I don't know the details regarding the need for normalization but ... ... to my current knowledge and opposed to authDNs, there's no need to normalize authcIDs at all? slapd's behaviour before the patch: do_bind: dn () SASL mech DIGEST-MD5 SASL [conn=1001] Debug: DIGEST-MD5 server step 2 slap_sasl_getdn: u:id converted to uid=userHAHAHA,cn=DIGEST-MD5,cn=auth >>> dnNormalize: <uid=userHAHAHA,cn=DIGEST-MD5,cn=auth> <<< dnNormalize: <uid=userhahaha,cn=digest-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=userhahaha,cn=digest-md5,cn=auth to a DN ==> rewrite_context_apply [depth=1] string='uid=userhahaha,cn=digest-md5,cn=auth' ==> rewrite_rule_apply rule='uid=([^,]+),cn=(PLAIN|LOGIN|OTP|DIGEST-MD5|CRAM-MD5),cn=auth' string='uid=userhahaha,cn=digest-md5,cn=auth' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userhahaha)'} slap_parseURI: parsing ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userhahaha) ldap_url_parse_ext(ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userhahaha)) put_filter: "(userLogin=userhahaha)" slapd's behaviour after the patch has been applied: do_bind: dn () SASL mech DIGEST-MD5 SASL [conn=1000] Debug: DIGEST-MD5 server step 2 slap_sasl_getdn: u:id converted to uid=userHAHAHA,cn=DIGEST-MD5,cn=auth ==>slap_sasl2dn: converting SASL name uid=userHAHAHA,cn=DIGEST-MD5,cn=auth to a DN ==> rewrite_context_apply [depth=1] string='uid=userHAHAHA,cn=DIGEST-MD5,cn=auth' ==> rewrite_rule_apply rule='uid=([^,]+),cn=(PLAIN|LOGIN|OTP|DIGEST-MD5|CRAM-MD5),cn=auth' string='uid=userHAHAHA,cn=DIGEST-MD5,cn=auth' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userHAHAHA)'} slap_parseURI: parsing ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userHAHAHA) ldap_url_parse_ext(ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userHAHAHA)) put_filter: "(userLogin=userHAHAHA)" put_filter: simple put_simple_filter: "userLogin=userHAHAHA" note, the userLogin attribute is defined using octetString-Syntax and thus is compared case sensitive

11 years, 11 months

1
0
0 / 0

Re: (ITS#6915) memberof+accesslog duplicate reqStart

by michael＠stroeder.com

ebackes(a)symas.com wrote: > Full_Name: Emily Backes > Version: 2.4.25 > OS: any > URL: > Submission from: (NULL) (76.88.107.46) > > In recent OpenLDAPs (2.4.25 at least, but I haven't found exactly where > it started), memberof interacts badly with accesslog. See also: http://www.openldap.org/lists/openldap-technical/201104/msg00242.html > In a simple test case with a groupOfNames and two people, if you add a > person to the group, memberOf should set their memberOf opeational > attribute to point to the group. That works! But currently the > accesslog db will only show the change for the memberof update and not > the original group change. I can confirm that. > Digging deeper, I found: > [..] > The changes are reaching accesslog, but don't make it into the logdb > because their generated DNs based on reqStart match. Ah, that explains it. > reqStart is generated with a generalizedTime stamp where the > microseconds are an incrementing count based on o_tincr, but this does > not seem to be incremented, or incremented enough. > > It's not entirely clear why this is a problem now and not earlier. Maybe it was always a problem. Because I've started the thread above before installing 2.4.25: http://www.openldap.org/lists/openldap-technical/201103/msg00032.html I had 2.4.24 or 2.4.23 installed back then. > This may be related to ITS#6766. Seems similar and the group modification is the same like in cases where I observed the behaviour described in my postings. Ciao, Michael.

11 years, 11 months

1
0
0 / 0

Re: (ITS#6914) Feature Request: slapd.conf "include" extension

by marco.pizzoli＠gmail.com

--0015175746fc400b2404a1a5d46f Content-Type: text/plain; charset=ISO-8859-1 On 23 Apr 2011 21:08, "Quanah Gibson-Mount" <quanah(a)zimbra.com> wrote: > > > > --On April 23, 2011 1:17:44 PM +0000 marco.pizzoli(a)gmail.com wrote: > >> Full_Name: Marco Pizzoli >> Version: 2.4.x >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (217.133.1.151) >> >> >> Hi, >> this is a feature request. >> > > slapd.conf is being phased out. I cannot imagine why anyone would work on extending what it does. > > --Quanah > > I know that. Btw I'm still hoping that slapd.conf will not be dismissed... --0015175746fc400b2404a1a5d46f Content-Type: text/html; charset=ISO-8859-1 On 23 Apr 2011 21:08, "Quanah Gibson-Mount" <<a href="mailto:quanah@zimbra.com">quanah(a)zimbra.com</a>> wrote: > > > > --On April 23, 2011 1:17:44 PM +0000 <a href="mailto:marco.pizzoli@gmail.com">marco.pizzoli(a)gmail.com</a> wrote: > >> Full_Name: Marco Pizzoli >> Version: 2.4.x >> OS: Linux >> URL: <a href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> >> Submission from: (NULL) (217.133.1.151) >> >> >> Hi, >> this is a feature request. >> > > slapd.conf is being phased out. I cannot imagine why anyone would work on extending what it does. > > --Quanah > > I know that. Btw I'm still hoping that slapd.conf will not be dismissed... --0015175746fc400b2404a1a5d46f--

11 years, 11 months

1
0
0 / 0

Re: (ITS#6909)

by hyc＠symas.com

diego.jesus.granados.lopez(a)ericsson.com wrote: > --_000_7A5601613D0AF042A5EDA8C8A7AA805D0E3E82C53DESESSCMS0356e_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > It was difficult to achieve, but I was able to include several errors (rega= > rding line numbers) in my two-line patch XD Thanks for the report and patch. I've committed a different solution in HEAD, please test. > > The correct one: > > --- ../../origtmp/openldap-2.4.21/servers/slapd/back-meta/search.c 200= > 9-08-14 22:54:14.000000000 +0200 > +++ ./servers/slapd/back-meta/search.c 2011-04-15 13:11:51.395261000 +0200 > @@ -309,6 +309,8 @@ > > if ( rc =3D=3D LDAP_SUCCESS ) { > candidates[ candidate ].sr_msgid =3D META_M= > SGID_IGNORE; > + binddn =3D msc->msc_bound_ndn; > + cred =3D msc->msc_cred; > goto retry; > } > } > > > Regards, > Diego -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

11 years, 11 months

1
0
0 / 0

(ITS#6915) memberof+accesslog duplicate reqStart

by ebackes＠symas.com

Full_Name: Emily Backes Version: 2.4.25 OS: any URL: Submission from: (NULL) (76.88.107.46) In recent OpenLDAPs (2.4.25 at least, but I haven't found exactly where it started), memberof interacts badly with accesslog. In a simple test case with a groupOfNames and two people, if you add a person to the group, memberOf should set their memberOf opeational attribute to point to the group. That works! But currently the accesslog db will only show the change for the memberof update and not the original group change. Digging deeper, I found: ==> hdb_add: reqStart=20110422103943.000001Z,cn=log oc_check_required entry (reqStart=20110422103943.000001Z,cn=log), objectClass "auditModify" oc_check_allowed type "objectClass" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "reqStart" oc_check_allowed type "reqEnd" oc_check_allowed type "reqType" oc_check_allowed type "reqSession" oc_check_allowed type "reqAuthzID" oc_check_allowed type "reqDN" oc_check_allowed type "reqResult" oc_check_allowed type "reqMod" bdb_dn2entry("reqStart=20110422103943.000001Z,cn=log") send_ldap_result: conn=1000 op=1 p=3 send_ldap_result: err=68 matched="" text="" The changes are reaching accesslog, but don't make it into the logdb because their generated DNs based on reqStart match. reqStart is generated with a generalizedTime stamp where the microseconds are an incrementing count based on o_tincr, but this does not seem to be incremented, or incremented enough. It's not entirely clear why this is a problem now and not earlier. This may be related to ITS#6766.

11 years, 11 months

1
0
0 / 0

Re: (ITS#6914) Feature Request: slapd.conf "include" extension

by quanah＠zimbra.com

--On April 23, 2011 1:17:44 PM +0000 marco.pizzoli(a)gmail.com wrote: > Full_Name: Marco Pizzoli > Version: 2.4.x > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.133.1.151) > > > Hi, > this is a feature request. > slapd.conf is being phased out. I cannot imagine why anyone would work on extending what it does. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

11 years, 11 months

1
0
0 / 0

(ITS#6914) Feature Request: slapd.conf "include" extension

by marco.pizzoli＠gmail.com

Full_Name: Marco Pizzoli Version: 2.4.x OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.133.1.151) Hi, this is a feature request. I would like to extend "include" directive of slapd.conf by having defined a default path in witch beginning to search for the filename specified by "include" directive(s). In short I would like to mimic the behaviour of "modulepath" and "moduleload" directives. "includepath" could be a suggestion of the name of this new directive. Thanks Marco

11 years, 11 months

1
0
0 / 0

Re: (ITS#6900) dnattr acl statement: users can produce dangling entries

by daniel＠pluta.biz

Once again an update of this patch: One more step further dnattr's documented behaviour: Now the DN in dnattr is additionally allowed to remove the whole entry. The update can be found here: ftp://ftp.openldap.org/incoming/Daniel-Pluta-110422.patch I'm not quite satisfied with my code and its internal processing. It's more some kind of a prototype. Probably you guys do have the knowlege to "convert" it into a better and slapd-like design... Thanks a lot!

11 years, 11 months

1
0
0 / 0

Re: (ITS#6873) Feature request slapo-lastbind: authTimestamp and relax rules control

by michael＠stroeder.com

I tried to find the magic flag where to put SLAP_AT_MANAGEABLE but failed. It must be something emotional with C code on my side... ;-) Ciao, Michael.

11 years, 11 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2011