openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

(ITS#5096) [enhancement] back-sql should provide a means to reload schema mapping runtime
by ando＠sys-net.it 19 Aug '07

19 Aug '07

Full_Name: Pierangelo Masarati Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando This is a request enhancement for a means to reload schema mapping run-time, without the need to stop slapd. The ideal candidate for this feature seems to be back-monitor.

1 0

(ITS#5095) back-sql concurrency issues
by ando＠sys-net.it 19 Aug '07

19 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I believe there are (at least) two issues with back-sql: 1) cached db handle AVL access in backsql_get_db_conn() is not protected by mutex, as insertion/deletion. 2) cached db handles are shared by operations performed by the same client connection, so concurrent operations use the same db handle. I believe each write operation should use a separate handle in order to be atomic. Issue (1) will be fixed shortly; issue (2) will be fixed as soon as I finish rewriting db handle code. In this sense I think it's meaningless to share handles for write operations based on the client connection. All in all, the same user is always used to access the DB, and access control is done by the backend, while there's no guarantee the client will serialize requests. So a separate pool of handles could be maintained and used for write operations only; handles wouldn't need to be created all times, they can be reused. Only, they need to be used exclusively by one operation, so that SQLTransact() is only called for the specified sequence of operations. The pool could be fixed size, deferring operations when busy, or grow on request. p.

1 0

Re: (ITS#5089) test043-delta-syncrepl: test failed - producer and consumer databases differ
by michael＠stroeder.com 18 Aug '07

18 Aug '07

It seems this has been fixed in the meantime by one of the many changes during the last time. Ciao, Michael.

1 0

(ITS#5094) shutting down multiple ppolicy instances yields double-free
by mbackes＠symas.com 16 Aug '07

16 Aug '07

Full_Name: Matthew Backes Version: 2.3.x, head OS: all URL: Submission from: (NULL) (132.241.73.19) slapo-ppolicy's close method frees the static pwcons without checking to see if someone else is using or has freed it already. This issue appears at shutdown when trying to use slapo-ppolicy on multiple backends. Revisions 1.105 and 1.106 to ppolicy.c (in HEAD) fix this problem.

1 0

Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by h.b.furuseth＠usit.uio.no 16 Aug '07

16 Aug '07

ando(a)sys-net.it writes: > The "right" solution would be to protect the identity of the rootdn > with ACLs, so that regular users cannot add/modify it. Good idea, but that too depends on your policy. If you you have a cron job or whatever which updates entries, including that of the rootdn, you may not want it to have full rootdn access. If nothing else, it's a bit like logging in as root instead of as a regular user - if you screw up you have the opportunity to create much more havoc. I wonder if we need a rootpolicy config parameter to tune the details of all this. Then we can set a fairly paranoid default, and people who need it to work differently can override. (Another thing I remember someone asked about was to only accept rootdn login from some specific IP address. But now that I think of it, normal ACLs could ensure that if he had the password in an entry instead of in rootpw.) -- Hallvard

1 0

Re: (ITS#5092) page size value of 1.2.840.113556.1.4.319 control
by hyc＠symas.com 16 Aug '07

16 Aug '07

randolf.werner(a)sap.com wrote: > Over the years i have > seen quite some Active Directories customers and many of them are very > afraid when you ask them you change some configuration or extending the > schema. Doesn't it seem odd to you that people would voluntarily use software that they are afraid of? Never mind, this discussion has gone far enough off-topic. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5092) page size value of 1.2.840.113556.1.4.319 control
by randolf.werner＠sap.com 16 Aug '07

16 Aug '07

Hi, oh my god what have i started here. Please don't try to convince me that standards are important and slapd pricecly implents RFC 2696, i was already convinced of that before i started the discussion. Anyway i like to resond to Howard Chu because he mentioned something dangerous and wrong regarding Active Directory (somewhat of topic here) but i like to avaoid people following his suggestion: Howard Chu <hyc(a)symas.com> wrote: >> Here is why i believe others might run into the same issue. If you need >> to create a ldap client dealing with big search results for various LDAP >> directories you had to use 1.2.840.113556.1.4.319 even if you are only >> interested in collecting the entire result otherwise you would fail with >> Active Directory. > >Nonsense. You simply ask your AD administrator to raise the default sizelimit, >the same way you would ask an OpenLDAP administrator to do the same thing. Well about 6 years ago when i first noticed this problem, i asked Microsoft about that limit and yes you can use ntdsutil.exe to set MaxPageSize to a higher limit: http://support.microsoft.com/kb/315071/en-us But it is strongly recommend to not change it!!!! Over the years i have seen quite some Active Directories customers and many of them are very afraid when you ask them you change some configuration or extending the schema. In 2001 SAP's IT set MaxPageSize=10000 for a few weeks as a temporary workaround until i was able to provide a real solution. That was a long time ago and today SAP's and probably most other companies Active Directories are running with default values. 1.2.840.113556.1.4.319 and MaxPageSize had not been invented to make our life more difficult. A good article about it is e.g. http://searchwinit.techtarget.com/tip/0,289483,sid1_gci1265206,00.html. I like to close with Gary Olsen's conclusion "The best practice for setting MaxPageSize is to leave it alone." Best regards Randolf

1 0

Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by h.b.furuseth＠usit.uio.no 16 Aug '07

16 Aug '07

hyc(a)symas.com writes: >> The back-bdb behavior sounds right: It should remain possible to have >> the rootdn's password in an entry instead of in slapd.conf. Among other >> things, if the site has routines for regular password changes and "your >> password is getting old" warnings, those will then cover rootdn as well. > > (But aging out the administrator's password is a good way to lock > yourself out of your system. Sure, so it depends on just how central that password is. But if I've ignored a "your password is getting too old" warning for an admin user and it gets disabled I've screwed up anyway, I prefer to set things up to err on the side of caution. Though if it's even hard to log in to the server machine and fix things there, I'd be in trouble. > Note that ppolicy always lets the rootdn > past all policy checks for this reason.) Actually I've never used ppolicy, so I was thinking of our site's automatic emails when we need to change our passwords. >> OTOH if such an entry and rootpw both exist, I think it's a bug to >> accept both passwords. I think an existing rootpw should override the >> entry's password, that's safest and least surprising (if the admin sets >> rootpw and someone else manages to create an entry with dn: <rootdn>). > > I disagree; this behavior has existed for a long time and there are probably > people out there relying on it. Good point. I would still like to get rid of it though. Even if it takes an extra slapd.conf keyword. > This isn't much different from the fact that > userPassword itself is multivalued. I seem to recall this behavior being > documented somewhere, can't find the reference at the moment. I disagree - the difference is that rootpw vs. userPassword are stored in different places and different people can modify or create them. The rootpw doc in slapd.conf(5) looks misleading to me - at least it's easy to read it differently from how it works. I'm getting a deja vu feeling here, but I'm not sure from which discussion... >> A few icky issues: >> >> - if you've got rootdn from a SASL/EXTERNAL DN and rewrite it to inside >> the database's DIT, it would be possible to create such an entry with >> a password. We could advise people to use a DN outside the database >> suffix in this case, and/or accept 'rootpw' with no parameter as >> explicitly refusing Simple Bind with the rootdn. > > I don't think these cases merit any special consideration. OK. Well, I might do something more general to the doc which touches on it anyway if I think of a better way to write it. >> - back-null's "bind on" (accept Simple Bind with any password). >> Maybe in this case it's best to treat rootdn without rootpw as >> "reject simple bind as rootdn", like your patch does. > > If "bind on" means "accept Simple Bind with any password" then rootpw > should be irrelevant here. Of course, for back-null the rootdn itself is > pretty meaningless. I looked cross-eyed at that code. I meant bind off. Nevermind. -- Hallvard

1 0

Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by ando＠sys-net.it 16 Aug '07

16 Aug '07

>> The back-bdb behavior sounds right: It should remain possible to have >> the rootdn's password in an entry instead of in slapd.conf. Among other >> things, if the site has routines for regular password changes and "your >> password is getting old" warnings, those will then cover rootdn as well. > > (But aging out the administrator's password is a good way to lock yourself > out > of your system. Note that ppolicy always lets the rootdn past all policy > checks > for this reason.) > >> OTOH if such an entry and rootpw both exist, I think it's a bug to >> accept both passwords. I think an existing rootpw should override the >> entry's password, that's safest and least surprising (if the admin sets >> rootpw and someone else manages to create an entry with dn: <rootdn>). > > I disagree; this behavior has existed for a long time and there are > probably > people out there relying on it. This isn't much different from the fact > that > userPassword itself is multivalued. I seem to recall this behavior being > documented somewhere, can't find the reference at the moment. In any case, I see this as a bug rather than a feature. The rootdn should be a special identity, which in many cases is only used for internal purposes. If the rootdn is outside the scope of the database, then it's not going to impact that database's be_bind(); if it's inside and it doesn't have a rootpw, then it might make sense that an entry with that DN exists, so that setting the rootpw could represent a means to workaround forgetting the entry's password or database corruptions. But checking both really sounds a bit too cumbersome. The we should allow multiple rootpw values... It's another question whether we should preserve or not this behavior for backward compatibility; in that case, all we need to do is handle the non-success, non-continue case in the switch and let it pass thru. But I'd require this at least to be explicitly enabled. >> A few icky issues: >> >> - if you've got rootdn from a SASL/EXTERNAL DN and rewrite it to inside >> the database's DIT, it would be possible to create such an entry with >> a password. We could advise people to use a DN outside the database >> suffix in this case, and/or accept 'rootpw' with no parameter as >> explicitly refusing Simple Bind with the rootdn. > > I don't think these cases merit any special consideration. I disagree. They sound academic, but they could pose a threat. I don't mean the code should obnoxiously check for this, but the possibility should be documented. The "right" solution would be to protect the identity of the rootdn with ACLs, so that regular users cannot add/modify it. >> - back-null's "bind on" (accept Simple Bind with any password). >> Maybe in this case it's best to treat rootdn without rootpw as >> "reject simple bind as rootdn", like your patch does. > > If "bind on" means "accept Simple Bind with any password" then rootpw > should be > irrelevant here. Of course, for back-null the rootdn itself is pretty > meaningless. Yes. The idea is to provide a simple means to allow binding with some identity without the need to configure anything special - that's the role of back-null, basically. What I essentially did was to take all backends that implement BI_op_bind and add the possibility to exploit the rootdn, which is allowed by the configuration anyway. I think this is better than letting people define rootdn/rootpw in the configuration and not using it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#4962) inconsistent Bind(rootdn) behavior
by quanah＠zimbra.com 16 Aug '07

16 Aug '07

--On Thursday, August 16, 2007 12:37 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > A few icky issues: > > - if you've got rootdn from a SASL/EXTERNAL DN and rewrite it to inside > the database's DIT, it would be possible to create such an entry with > a password. We could advise people to use a DN outside the database > suffix in this case, and/or accept 'rootpw' with no parameter as > explicitly refusing Simple Bind with the rootdn. Or in the case of SASL/GSSAPI, there can be a straight SASL rewrite to an internal DN for the rootdn as well. There is no requirement for the rootdn to have to have a rootpw associated with it, and there needn't be. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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