openldap-bugs March 2023

openldap-bugs@openldap.org

1 participants
160 discussions

[Issue 10017] New: ldap.conf setting "BINDDN" has no associated LDAP_OPT_XXX constant for ldap_get_opt ldap_set_opt
by openldap-its＠openldap.org 14 Mar '23

14 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=10017 Issue ID: 10017 Summary: ldap.conf setting "BINDDN" has no associated LDAP_OPT_XXX constant for ldap_get_opt ldap_set_opt Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: sean(a)teletech.com.au Target Milestone: --- The Configuration file setting "BINDDN" has no associated LDAP_OPT_XXX constant and is not exposed to the ldap_get_opt / ldap_set_opt API. This is the only option that is not so accessible and this seems like an oversight. Option "PORT" is also not exposed but that is deprecated. You could make the case it shouldn't be. This setting could obviously be of interest to the Application and I see no reason for it to be hidden. Simple applications / tools may not have their own configuration files and instead rely solely of the ldap.conf file to configure openldap. Such an application could not easy supply a DN to the "bind" calls but may still wish to know the value specified in the configuration file. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10019] New: dynlist's +memberOf attribute not searchable/fetchable with anonymous binds
by openldap-its＠openldap.org 14 Mar '23

14 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=10019 Issue ID: 10019 Summary: dynlist's +memberOf attribute not searchable/fetchable with anonymous binds Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: msl(a)touk.pl Target Milestone: --- Hi, This is and issue we discovered (as a side effect of testing) after switching from memberof overlay to dynlist with our confluence directory setup - which previously worked fine, but not anymore. Side effect of testing - as judging from the logs it seems that confluence is doing normal binds (which is even stranger as non-anonymous bind ldapsearch from commandline works correctly). Anyway, consider the following setup: groupOfURLs labeledURI uniqueMember+memberOf@groupOfUniqueNames We only use static groups, so the following group with one of members: DN: cn=TouK,ou=TouK,ou=Group,dc=touk,dc=pl objectClass: groupOfUniqueNames ... uniqueMember: cn=Michał Sołtys,ou=Touki,ou=People,dc=touk,dc=pl Correlates to: DN: cn=Michał Sołtys,ou=Touki,ou=People,dc=touk,dc=pl ... memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl The initial ACLs are set as follows: {0}to * by dn=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break {1}to dn.subtree=ou=People,dc=touk,dc=pl attrs=entry,entryUUID,memberOf,@toukAnonAccess by anonymous =scr by * break {2}to dn.subtree=ou=Group,dc=touk,dc=pl attrs=entry,@groupOfUniqueNames,@groupOfNames by anonymous =scr by * break ... later ACLs handling specific accesses and stuff, terminated with: {14}to * by users =scr Now if we do search doing non-anonymous binds, everything works correctly: ldapsearch -x -H ldaps://ldap.touk.pl -D "cn=Michał Sołtys,ou=Touki,ou=People,dc=touk,dc=pl" -s sub -b 'ou=Touki,ou=People,dc=touk,dc=pl' -o ldif-wrap=no -y ./pass -LLL -v '(uid=ast)' memberOf entryUUID ldap_initialize( ldaps://ldap.touk.pl:636/??base ) filter: (uid=ast) requesting: memberOf entryUUID dn: cn=Adam Stus,ou=Touki,ou=People,dc=touk,dc=pl entryUUID: 6c1adf48-a800-103a-8044-3100241d53c2 memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl But if we do an anonymous search - with ACLs as above explicitly allowing access to all relevant parts as in rule {1}, memberOf is not returned (it can't be used in filtering either): ldapsearch -x -H ldaps://ldap.touk.pl -s sub -b 'ou=Touki,ou=People,dc=touk,dc=pl' -o ldif-wrap=no -LLL -v '(uid=ast)' memberOf entryUUID ldap_initialize( ldaps://ldap.touk.pl:636/??base ) filter: (uid=ast) requesting: memberOf entryUUID dn: cn=Adam Stus,ou=Touki,ou=People,dc=touk,dc=pl entryUUID: 6c1adf48-a800-103a-8044-3100241d53c2 This - unless I missed something - looks like a bug. As mentioned above - our local confluence install is using dedicated user, but for some reason it is also unable filter using memberOf (though surprisingly it does work from command line for non-anonymous bind). Relevant parts of the slapd.log of such query: Mar 6 19:21:24 lipa1 slapd[1206591]: conn=1009 op=0 BIND dn="cn=confluence,ou=Apps,dc=touk,dc=pl" method=128 Mar 6 19:21:24 lipa1 slapd[1206591]: conn=1009 op=0 BIND dn="cn=confluence,ou=Apps,dc=touk,dc=pl" mech=SIMPLE bind_ssf=0 ssf=256 Mar 6 19:21:24 lipa1 slapd[1206591]: conn=1009 op=0 RESULT tag=97 err=0 qtime=0.000016 etime=0.000230 text= ... other operations Mar 6 19:26:58 lipa1 slapd[1206591]: conn=1009 op=28 SRCH base="ou=Touki,ou=People,dc=touk,dc=pl" scope=2 deref=3 filter="(&(toukAccountActive=TRUE)(memberOf=cn=finanse,ou=touk,ou=group,dc=touk,dc=pl))" Mar 6 19:26:58 lipa1 slapd[1206591]: conn=1009 op=28 SRCH attr=1.1 Mar 6 19:26:58 lipa1 slapd[1206591]: conn=1009 op=28 SEARCH RESULT tag=101 err=0 qtime=0.000019 etime=0.000541 nentries=0 text= See (nentries=0) above - but identical search performed from command line, e.g.: ldapsearch -x -H ldaps://ldap.touk.pl -D "cn=confluence,ou=Apps,dc=touk,dc=pl" -y ./b -a always -s sub -b 'ou=Touki,ou=People,dc=touk,dc=pl' -o ldif-wrap=no -LLL -v '(&(toukAccountActive=TRUE)(memberOf=cn=finanse,ou=touk,ou=group,dc=touk,dc=pl))' 1.1 correctly returns 6 people: Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=0 BIND dn="cn=confluence,ou=Apps,dc=touk,dc=pl" method=128 Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=0 BIND dn="cn=confluence,ou=Apps,dc=touk,dc=pl" mech=SIMPLE bind_ssf=0 ssf=256 Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=0 RESULT tag=97 err=0 qtime=0.000025 etime=0.000269 text= Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=1 SRCH base="ou=Touki,ou=People,dc=touk,dc=pl" scope=2 deref=3 filter="(&(toukAccountActive=TRUE)(memberOf=cn=finanse,ou=touk,ou=group,dc=touk,dc=pl))" Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=1 SRCH attr=1.1 Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=2 UNBIND Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000019 etime=0.002765 nentries=6 text= -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 4501] jdbcldap: use of enum reserved work (Java 1.5)
by openldap-its＠openldap.org 14 Mar '23

14 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=4501 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 4501] jdbcldap: use of enum reserved work (Java 1.5)
by openldap-its＠openldap.org 14 Mar '23

14 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=4501 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Fredrik Roubert from comment #6) > Does anyone have any opinion about this? We've assigned it for review, ty for the PR! -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 4501] jdbcldap: use of enum reserved work (Java 1.5)
by openldap-its＠openldap.org 13 Mar '23

13 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=4501 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |needs_review -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 4501] jdbcldap: use of enum reserved work (Java 1.5)
by openldap-its＠openldap.org 13 Mar '23

13 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=4501 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |smckinney(a)symas.com -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 4501] jdbcldap: use of enum reserved work (Java 1.5)
by openldap-its＠openldap.org 12 Mar '23

12 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=4501 --- Comment #6 from Fredrik Roubert <fredrik(a)roubert.name> --- Does anyone have any opinion about this? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10018] New: lmdb runs for two years and triggers abort error
by openldap-its＠openldap.org 10 Mar '23

10 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=10018 Issue ID: 10018 Summary: lmdb runs for two years and triggers abort error Product: LMDB Version: 0.9.23 Hardware: Other OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: Zhou.chang(a)h3c.com Target Milestone: --- We found that when the Last transaction ID exceeds the maximum value, the database abort signal will be triggered and two errors will be reported： Assertion 'rc == 0' failed in mdb_page_dirty() Assertion 'mp->mp_pgno != pgno' failed in mdb_page_touch() I would like to ask whether the current lmdb has considered this situation, ./mdb_stat -e /tmp/lmdb Environment Info Map address: (nil) Map size: 10485760 Page size: 4096 Max pages: 2560 Number of pages used: 238 Last transaction ID: 4294967295 Max readers: 126 Number of readers used: 2 -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 8447] LMDB: Overwriting values in MDB_DUPSORT databases broken
by openldap-its＠openldap.org 07 Mar '23

07 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=8447 --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- Created attachment 951 --> https://bugs.openldap.org/attachment.cgi?id=951&action=edit test case Simple reproducer -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8447] LMDB: Overwriting values in MDB_DUPSORT databases broken
by openldap-its＠openldap.org 07 Mar '23

07 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=8447 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |TEST --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- Fixed in mdb.master c7b3cc4df6dfe8f0772fb509bdc74777667caa43 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2023