openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#7934) wrong search behavior in accesslog entries
by hyc＠symas.com 08 Sep '14

08 Sep '14

alexoz66(a)gmail.com wrote: > Full_Name: John Alex. > Version: 2.4.39 > OS: FreeBSD 9.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (37.6.134.63) > > > Values of reqAttr in accesslog entries are not searchable the normal way if they > contain at least an uppercase character. Thanks for the report, fixed in git master > > Even though the reqAttr attribute has a caseIgnoreMatch search rule, the only > way to search for values containing uppercase characters is to explicitly use a > caseExactMatch rule. > > Consider this accesslog entry for example: > > dn: reqStart=20140905054555.000001Z,cn=accesslog > objectClass: auditSearch > reqAttr: givenName > reqAttrsOnly: FALSE > reqAuthzID: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > reqDerefAliases: never > reqDN: dc=example,dc=com > reqEnd: 20140905054555.000002Z > reqEntries: 9 > reqFilter: (objectClass=*) > reqResult: 0 > reqScope: sub > reqSession: 1268 > reqSizeLimit: 500 > reqStart: 20140905054555.000001Z > reqTimeLimit: 3600 > reqType: search > > > Searching with "(reqAttr=givenName)" will not return results, while using > "(reqAttr:caseExactMatch:=givenName)" will return the above entry. Accesslog > entries where values of reqAttr contain only lowercase characters are returned > correctly with the "(reqAttr=givenName)" filter. > > The same behavior can be observed with reqFilter (and probably other attributes > as well but I didn't test). > > This applies to entries added to the db by the accesslog overlay and not to > entries otherwise inserted. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7934) wrong search behavior in accesslog entries
by alexoz66＠gmail.com 08 Sep '14

08 Sep '14

Full_Name: John Alex. Version: 2.4.39 OS: FreeBSD 9.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.6.134.63) Values of reqAttr in accesslog entries are not searchable the normal way if they contain at least an uppercase character. Even though the reqAttr attribute has a caseIgnoreMatch search rule, the only way to search for values containing uppercase characters is to explicitly use a caseExactMatch rule. Consider this accesslog entry for example: dn: reqStart=20140905054555.000001Z,cn=accesslog objectClass: auditSearch reqAttr: givenName reqAttrsOnly: FALSE reqAuthzID: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth reqDerefAliases: never reqDN: dc=example,dc=com reqEnd: 20140905054555.000002Z reqEntries: 9 reqFilter: (objectClass=*) reqResult: 0 reqScope: sub reqSession: 1268 reqSizeLimit: 500 reqStart: 20140905054555.000001Z reqTimeLimit: 3600 reqType: search Searching with "(reqAttr=givenName)" will not return results, while using "(reqAttr:caseExactMatch:=givenName)" will return the above entry. Accesslog entries where values of reqAttr contain only lowercase characters are returned correctly with the "(reqAttr=givenName)" filter. The same behavior can be observed with reqFilter (and probably other attributes as well but I didn't test). This applies to entries added to the db by the accesslog overlay and not to entries otherwise inserted.

1 0

Re: (ITS#7933) [PATCH] fix frontend config
by hyc＠symas.com 08 Sep '14

08 Sep '14

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: 2.4.39 > OS: > URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20140908-fix-frontend-c… > Submission from: (NULL) (209.132.186.34) > > > The frontend database in slapd.ldif misses the olcFrontendConfig object class. Thanks, fixed in master. > The slapd-config reads: > > GLOBAL DATABASE OPTIONS > Options in this section may be set in the special "frontend" database and > inherited in all the other databases. These options may be altered by further > settings in each specific database. The frontend entry must be named > olcDatabase=frontend,cn=config and must have the olcFrontendConfig > objectClass. > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7933) [PATCH] fix frontend config
by jsynacek＠redhat.com 08 Sep '14

08 Sep '14

Full_Name: Jan Synacek Version: 2.4.39 OS: URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20140908-fix-frontend-c… Submission from: (NULL) (209.132.186.34) The frontend database in slapd.ldif misses the olcFrontendConfig object class. The slapd-config reads: GLOBAL DATABASE OPTIONS Options in this section may be set in the special "frontend" database and inherited in all the other databases. These options may be altered by further settings in each specific database. The frontend entry must be named olcDatabase=frontend,cn=config and must have the olcFrontendConfig objectClass.

1 0

Re: (ITS#7931) Add sudoers schema to OpenLDAP?
by michael＠stroeder.com 08 Sep '14

08 Sep '14

mike(a)flyn.org wrote: > I would like to see the sudoers schema shipped with OpenLDAP: Hmm, I have no clear opinion on this. But adding an app-specific schema files means that it has to be updated each time the app developers changes the schema. Personally I prefer grabbing schema files from the source distribution file of the application. Ciao, Michael.

1 0

Re: (ITS#7932) ldap sign up php web app
by michael＠stroeder.com 08 Sep '14

08 Sep '14

666threesixes666(a)gmail.com wrote: > Full_Name: three sixes > Version: > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.129.13.155) > > > most web applications have the option to use ldap but do not have a clear way of > signing up. > > i suggest a web application that users could drop into registration.domain.com > or auth.domain.com that gives people a way to sign up, request forgotten > passwords, delete accounts, and captcha. Not feasible in a really general way. Ciao, Michael.

1 0

(ITS#7932) ldap sign up php web app
by 666threesixes666＠gmail.com 07 Sep '14

07 Sep '14

Full_Name: three sixes Version: OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.129.13.155) most web applications have the option to use ldap but do not have a clear way of signing up. i suggest a web application that users could drop into registration.domain.com or auth.domain.com that gives people a way to sign up, request forgotten passwords, delete accounts, and captcha. funtoo has part of this.... http://auth.funtoo.org:9093/new such an application would make adoption of ldap much more feasible for me.

1 0

(ITS#7931) Add sudoers schema to OpenLDAP?
by mike＠flyn.org 07 Sep '14

07 Sep '14

Full_Name: W. Michael Petullo Version: 2.4.39 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.161.95.149) I would like to see the sudoers schema shipped with OpenLDAP: attributetype ( 1.3.6.1.4.1.15953.9.1.1 NAME 'sudoUser' DESC 'User(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.2 NAME 'sudoHost' DESC 'Host(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.3 NAME 'sudoCommand' DESC 'Command(s) to be executed by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.4 NAME 'sudoRunAs' DESC 'User(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.5 NAME 'sudoOption' DESC 'Options(s) followed by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.6 NAME 'sudoRunAsUser' DESC 'User(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.7 NAME 'sudoRunAsGroup' DESC 'Group(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.8 NAME 'sudoNotBefore' DESC 'Start of time interval for which the entry is valid' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) attributetype ( 1.3.6.1.4.1.15953.9.1.9 NAME 'sudoNotAfter' DESC 'End of time interval for which the entry is valid' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) attributeTypes ( 1.3.6.1.4.1.15953.9.1.10 NAME 'sudoOrder' DESC 'an integer to order the sudoRole entries' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL DESC 'Sudoer Entries' MUST ( cn ) MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAfter $ sudoOrder $ description ) )

1 0

Re: (ITS#7929) memberof overlay supresses accesslog olcAccessLogOps = all
by varkoly＠suse.com 06 Sep '14

06 Sep '14

Hello, I've tested it from git://git.openldap.org/openldap.git/OPENLDAP_REL_ENG_2_4 with same result. http://www.openldap.org/its/index.cgi/Incoming?id=7239 looks vaguely similar, although with a different overlay. Am Donnerstag, den 04.09.2014, 15:55 +0000 schrieb quanah(a)zimbra.com: > --On Thursday, September 04, 2014 10:11 AM +0000 varkoly(a)suse.com wrote: > > > Full_Name: Peter Varkoly > > Version: 2.4.26, 2.4.39 > > Hello, > > Can you please test using the current RE24 code? There have been > significant updates made to the overlay interactions since 2.4.39. > > Thanks! > > --Quanah > > > -- > > Quanah Gibson-Mount > Server Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > > -- Peter Varkoly Sr. Developer SUSE Linux Enterprise Applications SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany

1 0

(ITS#7930) slapo-chain causes double-free with rwm
by hyc＠openldap.org 06 Sep '14

06 Sep '14

Full_Name: Howard Chu Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc chaining substitutes op->o_req_dn and then restores its original value after performing the chained op. But rwm tries to cleanup op->o_req_dn when the chained op finishes, and so the original DN will be invalid after that. Partial fix: chain should only resto t the original value if the current value matches the last value that chain used. Additional fix: rwm should not cleanup at this time, because the send_ldap_result() of the chained op is not necessarily the final result of the original op. (E.g., in a search that processes multiple search refs, send_ldap_result will occur for each ref that is chained.)

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs