openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#4675) slapd bus error when searching in a subtree
by ghen＠telenet.be 27 Nov '06

27 Nov '06

On Fri, Nov 17, 2006 at 12:19:58PM -0800, Quanah Gibson-Mount wrote: > --On Wednesday, November 15, 2006 3:53 PM +0000 ghen(a)telenet.be wrote: > >Why was tick ticket closed? The problem still exists. > > Did you read the notes in the ITS system? I did. It says "NetBSD-specific, raise stacksize ulimit". I hope you don't count such a work-around as a fix... Geert

1 0

(ITS#4763) slapd crashed with ldapsearch command without arguments
by saint.cn＠gmail.com 27 Nov '06

27 Nov '06

Full_Name: Jack Chen Version: 2.3.27 OS: Redhat AS 3.0 2.4.21-40.ELsmp URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (60.12.9.18) I found when I run ldap commands without arguments always get password imput requirement before result. But the command always told me "ldap_sasl_interactive_bind_s: Can't contact LDAP server". Then I found the slapd crashed. Then I start slpad with command like "slpad -d 256" with root account and want to get debug information before slpad crash. Then following is the startup information: ===================================================================== @(#) $OpenLDAP: slapd 2.3.27 (Sep 30 2006 16:10:17) $ root@caivs:/home/jack/tools/openldap-2.3.27/servers/slapd daemon: IPv6 socket() failed errno=97 (Address family not supported by protocol) bdb_db_open: unclean shutdown detected; attempting recovery. bdb_db_open: Warning - No DB_CONFIG file found in directory /usr/local/openldap/var/openldap-data: (2) Expect poor performance for suffix dc=test,dc=com. slapd starting ===================================================================== And when I input command "ldapsearch" in shell with root account, and input password with any words and return. The command tell me like following: ===================================================================== /usr/local/BerkeleyDB.4.5/bin:$ldapsearch SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Can't contact LDAP server ===================================================================== And I check the console which is running slapd, and get following information: ===================================================================== conn=0 fd=10 ACCEPT from IP=127.0.0.1:33518 (IP=0.0.0.0:389) conn=0 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" conn=0 op=0 SRCH attr=supportedSASLMechanisms conn=0 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=0 op=1 BIND dn="" method=163 conn=0 op=1 RESULT tag=97 err=14 text= conn=0 op=2 BIND dn="" method=163 /etc/sasldb2: Successful return: 0 segment fault (core dumped) ===================================================================== Because I'v set "ulimit -c 10000000", so get a coredump file additionally with no debug info inside.

1 0

Re: (ITS#4756) IPv6 Addresses are not supported in ACL peername
by hyc＠symas.com 25 Nov '06

25 Nov '06

ando(a)sys-net.it wrote: > Damon.Groenveld(a)ca.com wrote: >> Given that the code (in aclparse.c) calls inet_addr() with the >> peername.ip parameter, I can't see how it could will work with IPv6. >> >> The only possible workaround is using a regex instead of ip type which >> by passes the inet_addr() call. >> >> I raised it as a bug since the latest version (as far as I can tell) is >> meant to support IPv6 and there is no way that peername.ip does and >> there isn't an alternative. >> > The peername.ip was designed with IPv4 in mind. A patch to support IPv6 > in ACLs would be welcome, though. In the meanwhile, I believe a regex > style would be the solution, but note that I have no idea of how IPv6 > would be stringified in the peername. Note that the whole issue is of > questionable relevance, since IP-based access checking is not considered > trustable. Yes, peername.regex works fine. Currently IPv6 peernames are reported as colon-separated hex octets followed by a space, then the port number: "xxxx:....:zzzz ppppp". It strikes me that we should be using URL format instead, which uses square brackets: "[xxxx:....:zzzz]:ppppp". -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4756) IPv6 Addresses are not supported in ACL peername
by ando＠sys-net.it 25 Nov '06

25 Nov '06

Damon.Groenveld(a)ca.com wrote: > Given that the code (in aclparse.c) calls inet_addr() with the > peername.ip parameter, I can't see how it could will work with IPv6. > > The only possible workaround is using a regex instead of ip type which > by passes the inet_addr() call. > > I raised it as a bug since the latest version (as far as I can tell) is > meant to support IPv6 and there is no way that peername.ip does and > there isn't an alternative. > The peername.ip was designed with IPv4 in mind. A patch to support IPv6 in ACLs would be welcome, though. In the meanwhile, I believe a regex style would be the solution, but note that I have no idea of how IPv6 would be stringified in the peername. Note that the whole issue is of questionable relevance, since IP-based access checking is not considered trustable. > I asked the question regarding other ways to restrict access since I > noted that the documentation mentions TCP Wrappers and has a see also of > host_options(5) -- which does not exist, Apparently that should be hosts_options(5): $ apropos hosts_options hosts_options (5) - host access control language extensions Can you point me to the incorrect documentation? > so I was hoping that some > advice might come while someone looked at the problem (if or when it was > deemed important enough). > p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4758) valsort + dynlist can cause 100% cpu utilization causing slapd to become unresponsive
by ando＠sys-net.it 25 Nov '06

25 Nov '06

michael.heep(a)o2.com wrote: > the following valsort + dynlist combination causes slapd to utilize 100% cpu > time when issueing searches against parts of the DIT containing attribute-value > pairs "created" by dynlist: > > overlay dynlist > dynlist-attrset extensibleObject memberURL uniqueMember > > overlay valsort > valsort-attr uniqueMember dc=o2online,dc=de alpha-ascend > > When run independent both overlays work flawlessly. > To be honest, I don't quite see the point in keeping sorted a set of values that by definition is dynamically built. There seems to be contradiction between the two overlays that prevents them from being used together anyway. If your intention is to partition a tree so that the intersection of data subjected to valsort and data subjected to dynlist is empty, then I guess the solution is to use the <attri> and <baseDN> parameters of valsort to exclude those entries that are subjected to dynlist. If this is not enough, you could ask for an enhancement that turns the <attr> <baseDN> into a more general specification that allows increased granularity; for example, an attr and a filter, which incidentally could be specified by means of an URL so that base, attribute list, scope and filter can be present. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4762) Bugs in meta backend
by Kurt＠OpenLDAP.org 24 Nov '06

24 Nov '06

As there is no major security issue here, this report is now public. At 03:01 AM 11/24/2006, jerome.thevenet(a)aviation-civile.gouv.fr wrote: >Full_Name: >Version: 2.3.27 >OS: ubuntu >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (213.41.243.192) > > >In Database meta: >When we define several servers (uri: ldap//....), >onerr CONTINUE > >If all servers are ok, the research is ok. >But if one of them is off, the result of a research is error 52 even if the >others send good result. > >Thanks

1 0

RE: (ITS#4760) problem with group caching and proxyAuth control
by richter＠ecos.de 24 Nov '06

24 Nov '06

> > Fixed (differently) in HEAD/re23; please test. Thanks for > reporting. p. > Just looked at your changes, of course it makes sense to put this in a common function. I will test over the weekend Gerald > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.n.c. > Via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ------------------------------------------ > Office: +39.02.23998309 > Mobile: +39.333.4963172 > Email: pierangelo.masarati(a)sys-net.it > ------------------------------------------ > > > > ** Virus checked by BB-5000 Mailfilter ** > !DSPAM:4566ce0e132554386119908! > ** Virus checked by BB-5000 Mailfilter **

1 0

Re: (ITS#4760) problem with group caching and proxyAuth control
by ando＠sys-net.it 24 Nov '06

24 Nov '06

richter(a)ecos.de wrote: Fixed (differently) in HEAD/re23; please test. Thanks for reporting. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4761) error in "group" authorization parsing
by ando＠sys-net.it 24 Nov '06

24 Nov '06

Full_Name: Pierangelo Masarati Version: HEAD,re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Submitted by: ando When an authorization rule using groups, like "group:<dn>" is used, the default member attribute "member" is erroneously set to an empy berval, resulting in an invalid filter being used for the internal lookup to check for membership. A workaround consists in avoiding defaults: "group/<oc>/<at>:<dn>". "group/<oc>:<dn>" appears to work as intended, i.e. in this case the default attribute is correctly used. A fix is coming. p.

1 0

Re: (ITS#4760) problem with group caching and proxyAuth control
by ando＠sys-net.it 24 Nov '06

24 Nov '06

Gerald Richter wrote: >> I'm not sure I understand the issue you describe. In fact, >> groups appear to be cached on a per-operation basis, and user >> membership is evaluated using the authorized identity (B in >> your case), so the behavior should be correct. I've made a >> simple check using re23 and things appear to work as >> expected: I log in as a user (A) that is not in a group and >> authorize as a user (B) that is in that group. I previously >> configured slapd so that only members of that group are >> allowed to read an attribute in the whole db (say "cn"). >> Things work as expected: if I login as user A I can't see >> "cn", but if I either log in as user B, or login as user A >> and proxyAuthz as B I can read the "cn". Can you provide a >> simple example (slapd.conf, db.ldif and sequence of >> operations, e.g. in a shell script) that causes the issue you see? >> >> > > I think the point is that the group must be evaluated already in the search > for the AuthzTo attribute. > > So my User A has the AuthzTo attribute set to User B and I have the > following access control: > > > access to * > by group/accessCTRL/uniqueMember="cn=Admins,dc=testuml,dc=test" > write > by * break > > ... > > > access to * attrs=authzTo > by self read > by * break > > ... > > User A is not member of cn=Admins,dc=testuml,dc=test, but user B is. So when > I log in as user A and proxyAuth to Openldap will evaluate the group > membership for A and cache it, during the search for the ACL to authzTo. A > is not member. > > Now when the actual search operation takes places, openldap will used the > cached result (which was "is not member"), which is wrong because the user > has changed since the group membership was cached. > > I hope this makes the problem more clear (I have a test environment here, > but it is very complex and easy transferable) > OK, I see. In my test ACLs for authzTo didn't make use of groups. It makes sense to clear out identity related cached stuff when the identity changes. What I'm looking for is a __simple__ test that exploits the feature. This would allow to clearly spot the issue in the first place, and prepare a regression test. I'll do some more testing. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

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