- openldap-bugs - openldap.org

Re: (ITS#5805) Problem when modifying access control
by ando＠sys-net.it 16 Nov '08

16 Nov '08

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.4.11 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.78.0.137) > > > I have a single BDB database directory with root DN as a physical entry. My > access control is defined as follows in olcDatabase={-1}frontend: > olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * no > ne > olcAccess: {1}to dn=cn=manager,c=fr by self write by * none > olcAccess: {2}to * by self write by users read by anonymous read by * none > > I perform a modify operation as follows: > dn: olcDatabase={-1}frontend,cn=config > changetype: modify > replace: olcAccess > olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * no > ne > olcAccess: {1}to dn=cn=manager,c=fr by self write by * none > olcAccess: {2}to * by self write by users read by anonymous read by * none > > dn: olcDatabase={0}config,cn=config > changetype: modify > replace: olcAccess > olcAccess: {0}to * by * none > - > replace: olcRootDN > olcRootDN: cn=manager,c=fr > > then I can not bind any more to the directory (invalid credentials). > The log says (do notice the line dn: [1]... with non printable characters): > do_bind: version=3 dn="cn=manager,c=fr" method=128 > ==> bdb_bind: dn: cn=manager,c=fr > bdb_dn2entry("cn=manager,c=fr") > => access_allowed: auth access to "cn=manager,c=fr" "userPassword" requested > => dn: [1] <some non printable characters>anager,c=fr > => acl_get: [2] attr userPassword > => slap_access_allowed: result not in cache (userPassword) > => acl_mask: access to entry "cn=manager,c=fr", attr "userPassword" requested > => acl_mask: to value by "", (=0) > <= check a_dn_pat: * > <= acl_mask: [1] applying none(=0) (stop) > <= acl_mask: [1] mask: none(=0) > => slap_access_allowed: auth access denied by none(=0) > => access_allowed: no more rules > > When I stop the directory, the log says (filter_free lines may vary): > bdb_db_close: database "c=fr": alock_close failed > filter_free: unknown filter type=20224 > filter_free: unknown filter type=496 > slapd stopped. > filter_free: unknown filter type=29776 > filter_free: unknown filter type=13944 > filter_free: unknown filter type=29496 > > When I restart slapd, all is fine: the access control is OK and I can bind. I can't confirm your report with HEAD code. I suggest you retry with either 2.4.12 or (better) re24, which is about to be released as 2.4.13. I note that by performing the operations you indicate, the cn=config database (dn: olcDatabase={0}config,cn=config) ends up in an inconsistent state, because the rootdn does not belong to its naming context, but the rootpw is set, which should not be allowed. A check for this does not exist, while it should. In any case, this is harmless. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5814) concurrent access to connections
by ando＠sys-net.it 16 Nov '08

16 Nov '08

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > There is code that accesses c_conn_state and c_struct_state while not adequately > mutex-protected. In most cases, this code basically consists in assertions, so > we risk a core dump because of an assertion on non-mutex protected data. This > is the case (as happened to me) of connection_next(). > > I have a fix for the case I noticed, with two unhandled asserts (marked with a > FIXME) because I'm not sure whether it's worth to add extra mutexes just to be > able to safely assert, or remove assertions. > > Committing the fix; there might be more. Please check. I noticed this while testing concurrency for re24; here is the relevant portion of the core dump: (gdb) bt #0 0x00483402 in __kernel_vsyscall () #1 0x00c9ad20 in raise () from /lib/libc.so.6 #2 0x00c9c631 in abort () from /lib/libc.so.6 #3 0x00c9416b in __assert_fail () from /lib/libc.so.6 #4 0x08084b80 in connection_next (c=0x0, index=0xb62e3d8c) at ../../../ldap-2.4-src/servers/slapd/connection.c:871 #5 0x081a810c in monitor_subsys_conn_update (op=0x8a145f0, rs=0xb62e5128, e=0x896632c) at ../../../../ldap-2.4-src/servers/slapd/back-monitor/conn.c:230 <snip> (gdb) f 4 #4 0x08084b80 in connection_next (c=0x0, index=0xb62e3d8c) at ../../../ldap-2.4-src/servers/slapd/connection.c:871 (gdb) p connections[*index] $1 = {c_struct_state = 2, c_conn_state = 1, c_conn_idx = 19, c_sd = 19, <snip> Cheers, 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5814) concurrent access to connections
by ando＠sys-net.it 16 Nov '08

16 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando There is code that accesses c_conn_state and c_struct_state while not adequately mutex-protected. In most cases, this code basically consists in assertions, so we risk a core dump because of an assertion on non-mutex protected data. This is the case (as happened to me) of connection_next(). I have a fix for the case I noticed, with two unhandled asserts (marked with a FIXME) because I'm not sure whether it's worth to add extra mutexes just to be able to safely assert, or remove assertions. Committing the fix; there might be more. Please check. p.

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by geert＠boskant.nl 16 Nov '08

16 Nov '08

------=_Part_45002_9684276.1226844472048 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sun, Nov 16, 2008 at 2:25 AM, Howard Chu <hyc(a)symas.com> wrote: > That is completely irrelevant. If a given site has a misconfigured DNS, > whether or not it uses integrity or privacy checks on the DNS service, it is > still misconfigured. My point was that even if your reverse DNS mappings are correct, this is not a sufficient base for canonicalization. as it would have to be secure too. Or would you consider a DNS setup without DNSSEC to be broken too? In that case 99% of all setups would be broken. To maximize interoperability and security, applications SHOULD provide > security > mechanisms with names that result from folding the user- entered name to > lowercase without performing any other modifications or canonicalization. > Wishful thinking; that recommendation is at least 15 years too late and the > majority of Kerberized software isn't going to change to accommodate it. Not everybody needs to do this at once. MIT Kerberos already supports multiple ways of canonicalizing, including reverse DNS and the Canonicalize bit. Applications can start supporting this one by one. > In the meantime, the arguments about secure DNS are pure red herrings: > 1. if your DNS has been hijacked, it's most likely that you'll be directed > to a rogue KDC first, so the question of which service you're talking to is > moot. Wrong. Kerberos protects against that. A rogue KDC would not have your secret key and therefore is unable to generate a correct ticket for you. This would get noticed immediately by the library and the handshake would be aborted. > 2. there's nothing to gain from directing you to a rogue service, since > if you managed to contact the legitimate KDC, you're going to have a service > ticket that can only be decoded by the legitimate service principal. > On the other hand, if the rogue service is actually a valid principal in > your trusted KDC's database, then you clearly have an administrative problem > in your KDC. > Ok, so let me show you a real attack scenario as it indeed requires one copromised server. Supose an attacker has compromised one system in a Kerberos realm that was running a Kerberos service. The attacker can now spoof reverse DNS based on any of the available methods, and use it to redirect any internal service to a service on his server. He now puts up a mock up of the original service on the comprimised server, and coaxes users into entering any data that he would only enter in the real service. He can use this data to expand his compromised systems. If you would use secure canonicalization, the above cannot happen. It limits the scope of a compromise to that server. Without security canonicalization this is basically all-or-nothing security which is bad. This patch attempts to provide a band-aid without actually solving the real > problem. It merely masks the problem temporarily, until it gets even worse. No. From a security point it limits the impact of a comprimise of one server in your environment. From other point of views it helps environments that use the current best practise albeit broken method of canonicalizing host name. > This request is akin to asking for "schemachecking off" to be resurrected. > This sort of feature is always requested because of an existing mistake, and > allowing it only compounds the mistake further. We should never make it > easier for admins to make and ignore mistakes. This analogy does not work. The proposed option provides the possibility to implement a recommendation from the Kerberos RFC. Where in the LDAP RFCs does it say that it is recommended to turn schemachecking off? Regards,Geert ------=_Part_45002_9684276.1226844472048 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sun, Nov 16, 2008 at 2:25 AM, Howard Chu <span dir="ltr"><<a href="mailto:hyc@symas.com">hyc(a)symas.com</a>></span> wrote:<br><div class="gmail_quote"> <br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> That is completely irrelevant. If a given site has a misconfigured DNS, whether or not it uses integrity or privacy checks on the DNS service, it is still misconfigured.</blockquote><div class="Ih2E3d"><br>My point was that even if your reverse DNS mappings are correct, this is not a sufficient base for canonicalization. as it would have to be secure too. Or would you consider a DNS setup without DNSSEC to be broken too? In that case 99% of all setups would be broken.<br> <br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">   To maximize interoperability and security, applications SHOULD provide security<br>   mechanisms with names that result from folding the user- entered name to<br>   lowercase without performing any other modifications or canonicalization.<br> </blockquote> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Wishful thinking; that recommendation is at least 15 years too late and the majority of Kerberized software isn't going to change to accommodate it.</blockquote><div><br>Not everybody needs to do this at once. MIT Kerberos already supports multiple ways of canonicalizing, including reverse DNS and the Canonicalize bit. Applications can start supporting this one by one.<br> </div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> In the meantime, the arguments about secure DNS are pure red herrings:<br>  1. if your DNS has been hijacked, it's most likely that you'll be directed to a rogue KDC first, so the question of which service you're talking to is moot.</blockquote><div><br>Wrong. Kerberos protects against that. A rogue KDC would not have your secret key and therefore is unable to generate a correct ticket for you. This would get noticed immediately by the library and the handshake would be aborted.<br>  <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">  2. there's nothing to gain from directing you to a rogue service, since if you managed to contact the legitimate KDC, you're going to have a service ticket that can only be decoded by the legitimate service principal.</blockquote> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>  On the other hand, if the rogue service is actually a valid principal in your trusted KDC's database, then you clearly have an administrative problem in your KDC.<br></blockquote><div><br>Ok, so let me show you a real attack scenario as it indeed requires one copromised server. Supose an attacker has compromised one system in a Kerberos realm that was running a Kerberos service. The attacker can now spoof reverse DNS based on any of the available methods, and use it to redirect any internal service to a service on his server. He now puts up a mock up of the original service on the comprimised server, and coaxes users into entering any data that he would only enter in the real service. He can use this data to expand his compromised systems.<br> <br>If you would use secure canonicalization, the above cannot happen. It limits the scope of a compromise to that server. Without security canonicalization this is basically all-or-nothing security which is bad.<br><br></div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> This patch attempts to provide a band-aid without actually solving the real problem. It merely masks the problem temporarily, until it gets even worse.</blockquote><div><br>No. From a security point it limits the impact of a comprimise of one server in your environment. From other point of views it helps environments that use the current best practise albeit broken method of canonicalizing host name. <br> </div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> This request is akin to asking for "schemachecking off" to be resurrected. This sort of feature is always requested because of an existing mistake, and allowing it only compounds the mistake further. We should never make it easier for admins to make and ignore mistakes.</blockquote> <div><br>This analogy does not work. The proposed option provides the possibility to implement a recommendation from the Kerberos RFC. Where in the LDAP RFCs does it say that it is recommended to turn schemachecking off?<br> <br>Regards,Geert</div></div><br> ------=_Part_45002_9684276.1226844472048--

1 0

(ITS#5813) limits with empty dn mostly do not work
by h.b.furuseth＠usit.uio.no 15 Nov '08

15 Nov '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: http://folk.uio.no/hbf/OpenLDAP/limits-empty.txt Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Limits set as limits dn.<exact/base/onelevel/subtree/children>="" ... are never used: - exact/base: it only matches the empty Bind DN, which in slapd means anonymous, for which limits_get() does not test dn.<exact/base>. - onelevel/subtree/children: limits_get() does not use these for the empty Bind DN, and it expects a non-empty Bind DNs to end with ",". Some cases above work with dn.this.foo instead of dn.foo. limits dn.regex="" works (equivalent to limits users). limits dn.group="" may work if the admin stuffs group members into the root DSE. (I haven't tested.) My preferred fixes: - For dn.this, fix the above since baseDN "" makes sense and dn.this is new anyway, so there is no backwards compatibility to worry about. - For dn.self, fail parsing of the limit cases above that do not work. Otherwise the dn.this change could invoke new functionality in existing configurations. We won't know what the admin meant with DN "" - did he mean to include anonymous? That is not an entry with a DN, but is stored in slapd and the Bind request as the empty DN. Also limits parsing vs. anonymous connections is dubious today anyway: dn.<anything>=* or dn.regex=.* are special-cased to match anonymous, while dn="" does not. Also dn.children=* should not match anonymous but does. So it seems to me that any cleanup should consist of first removing strange cases, and if anyone want them reintroduce them in a later branch with correct semantics. I enclose a suggested fix. Giving Pierangelo at least time to repond since he either agreed or disagreed with this in this message, I'm not sure which:-) http://www.openldap.org/lists/openldap-devel/200810/msg00116.html I knew there was an issue about these limits I had forgotten.

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by hyc＠symas.com 15 Nov '08

15 Nov '08

Geert Jansen wrote: > Well .. I don't think my patch qualifies as breaking software to work > with broken software. The patch allows OpenLDAP applications to use > alternative ways for name canonicalization. At this moment this is not > possible because OpenLDAP is hard coded to canonicalize names with > reverse DNS. This means I cannot use the option that MIT Kerberos > provides me to disable this (rdns = no), as host names have already been > reverse mapped by OpenLDAP before they are passed into Kerberos. > > I agree with you that reverse DNS should be correct. I just mentioned > the fact that many reverse DNS setups are broken as an example of why it > can be problematic. The fact that many environments are misconfigured is not a good reason to change the current behavior. > Another reason why canonicalization based on reverse > DNS is problematic is that it requires secure DNS to be secure. RFC4120 > mentions this: That is completely irrelevant. If a given site has a misconfigured DNS, whether or not it uses integrity or privacy checks on the DNS service, it is still misconfigured. > Implementations of Kerberos and protocols based on Kerberos MUST NOT > use insecure DNS queries to canonicalize the hostname components of > the service principal names (i.e., they MUST NOT use insecure DNS > queries to map one name to another to determine the host part of the > principal name with which one is to communicate). > The same RFC recommends in fact that applications do not canonicalize > host names at all: > > To maximize interoperability and security, applications SHOULD provide security > mechanisms with names that result from folding the user- entered name to > lowercase without performing any other modifications or canonicalization. Wishful thinking; that recommendation is at least 15 years too late and the majority of Kerberized software isn't going to change to accommodate it. In the meantime, the arguments about secure DNS are pure red herrings: 1. if your DNS has been hijacked, it's most likely that you'll be directed to a rogue KDC first, so the question of which service you're talking to is moot. 2. there's nothing to gain from directing you to a rogue service, since if you managed to contact the legitimate KDC, you're going to have a service ticket that can only be decoded by the legitimate service principal. On the other hand, if the rogue service is actually a valid principal in your trusted KDC's database, then you clearly have an administrative problem in your KDC. This patch attempts to provide a band-aid without actually solving the real problem. It merely masks the problem temporarily, until it gets even worse. This request is akin to asking for "schemachecking off" to be resurrected. This sort of feature is always requested because of an existing mistake, and allowing it only compounds the mistake further. We should never make it easier for admins to make and ignore mistakes. -- -- 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

Re: (ITS#5812) New option to disable SASL host canonicalization
by geert＠boskant.nl 15 Nov '08

15 Nov '08

------=_Part_39674_19690948.1226797622518 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, Nov 15, 2008 at 6:20 PM, Howard Chu <hyc(a)symas.com> wrote: > > Breaking more software to use it with already broken software is, in a > word, stupid. The standard practice for Kerberos requires you to have > consistent forward and reverse DNS lookups. Sysadmins who are afraid to > administer their software should either change their software or change > their jobs. Well .. I don't think my patch qualifies as breaking software to work with broken software. The patch allows OpenLDAP applications to use alternative ways for name canonicalization. At this moment this is not possible because OpenLDAP is hard coded to canonicalize names with reverse DNS. This means I cannot use the option that MIT Kerberos provides me to disable this (rdns = no), as host names have already been reverse mapped by OpenLDAP before they are passed into Kerberos. I agree with you that reverse DNS should be correct. I just mentioned the fact that many reverse DNS setups are broken as an example of why it can be problematic. Another reason why canonicalization based on reverse DNS is problematic is that it requires secure DNS to be secure. RFC4120 mentions this: Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names (i.e., they MUST NOT use insecure DNS queries to map one name to another to determine the host part of the principal name with which one is to communicate). The same RFC recommends in fact that applications do not canonicalize host names at all: To maximize interoperability and security, applications SHOULD provide security mechanisms with names that result from folding the user- entered name to lowercase without performing any other modifications or canonicalization. My patch implements this behaviour, as an option. Regards, Geert ------=_Part_39674_19690948.1226797622518 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, Nov 15, 2008 at 6:20 PM, Howard Chu <span dir="ltr"><<a href="mailto:hyc@symas.com" target="_blank">hyc(a)symas.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br> Breaking more software to use it with already broken software is, in a word, stupid. The standard practice for Kerberos requires you to have consistent forward and reverse DNS lookups. Sysadmins who are afraid to administer their software should either change their software or change their jobs.</blockquote> <div><br>Well .. I don't think my patch qualifies as breaking software to work with broken software. The patch allows OpenLDAP applications to use alternative ways for name canonicalization. At this moment this is not possible because OpenLDAP is hard coded to canonicalize names with reverse DNS. This means I cannot use the option that MIT Kerberos provides me to disable this (rdns = no), as host names have already been reverse mapped by OpenLDAP before they are passed into Kerberos.<br> <br>I agree with you that reverse DNS should be correct. I just mentioned the fact that many reverse DNS setups are broken as an example of why it can be problematic. Another reason why canonicalization based on reverse DNS is problematic is that it requires secure DNS to be secure. RFC4120 mentions this:<br> <br><pre> Implementations of Kerberos and protocols based on Kerberos MUST NOT<br> use insecure DNS queries to canonicalize the hostname components of<br> the service principal names (i.e., they MUST NOT use insecure DNS<br> queries to map one name to another to determine the host part of the<br> principal name with which one is to communicate). </pre><br>The same RFC recommends in fact that applications do not canonicalize host names at all:<br> <br><pre> To maximize interoperability and security, applications SHOULD provide security<br> mechanisms with names that result from folding the user- entered name to<br> lowercase without performing any other modifications or canonicalization.<br> </pre><br>My patch implements this behaviour, as an option.<br><br>Regards,<br>Geert</div></div><br> ------=_Part_39674_19690948.1226797622518--

1 0

RE: (ITS#5788) Search does not work with nested naming contexts
by h.b.furuseth＠usit.uio.no 15 Nov '08

15 Nov '08

I wrote: > "LDAP operations normally access only one database. However > databases that provide related naming contexts ("suffixes") may be > glued together with the /subordinate/ keyword. Some other features > such as access controls and the /translucent/ overlay can also > involve multiple databases." I've added similar text to slapd.conf.5, but didn't see a suitable place for it in slapd-config.5. (Except in olcSubordinate description itself, where it is already mentioned). Admin guide fix still needed. -- Hallvard

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by hyc＠symas.com 15 Nov '08

15 Nov '08

geert(a)boskant.nl wrote: > Full_Name: Geert Jansen > Version: 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/geert-jansen-081115.patch > Submission from: (NULL) (12.230.186.195) > > > This is a resubmission of my earlier patch in [1]. I'm asking for this patch to > be included into OpenLDAP. > > The patch adds an LDAP option called LDAP_OPT_X_SASL_NOCANON to disable host > name canonicalization using reverse DNS for the host name that is passed into > SASL. Instead, it passes verbatim the host name part from the LDAP URI and lets > SASL do the canonicalization. The option is disabled by default. > > Kerberos requires a canonical host name to work. Traditionally, host name > canonicalization has been done using reverse DNS. However, this is problematic. > See the comment below from the MIT Kerberos source on this subject: > > /* XXX: This is *so* bogus. There are several cases where > this won't get us the canonical name of the host, but > this is what we've trained people to expect. We'll > probably fix it at some point, but let's try to > preserve the current behavior and only shake things up > once when it comes time to fix this lossage. */ > > Since some time MIT Kerberos has support for server-side canonicalization which > is an alternative for the DNS based scheme. By default it uses both, but with an > option "rdns = no", reverse DNS can be disabled. > > The use case for this is environments that do not have reverse DNS set up > correctly. Especially in Windows Active Directory environments this is very > common. Administrators are afraid to enable scavenging for their zones, and > therefore any server IP change will leave a stale PTR record in place. This > breaks reverse DNS based canonicalization if the IP adress is reassigned. Breaking more software to use it with already broken software is, in a word, stupid. The standard practice for Kerberos requires you to have consistent forward and reverse DNS lookups. Sysadmins who are afraid to administer their software should either change their software or change their jobs. -- -- 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#5812) New option to disable SASL host canonicalization
by geert＠boskant.nl 15 Nov '08

15 Nov '08

Full_Name: Geert Jansen Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/geert-jansen-081115.patch Submission from: (NULL) (12.230.186.195) This is a resubmission of my earlier patch in [1]. I'm asking for this patch to be included into OpenLDAP. The patch adds an LDAP option called LDAP_OPT_X_SASL_NOCANON to disable host name canonicalization using reverse DNS for the host name that is passed into SASL. Instead, it passes verbatim the host name part from the LDAP URI and lets SASL do the canonicalization. The option is disabled by default. Kerberos requires a canonical host name to work. Traditionally, host name canonicalization has been done using reverse DNS. However, this is problematic. See the comment below from the MIT Kerberos source on this subject: /* XXX: This is *so* bogus. There are several cases where this won't get us the canonical name of the host, but this is what we've trained people to expect. We'll probably fix it at some point, but let's try to preserve the current behavior and only shake things up once when it comes time to fix this lossage. */ Since some time MIT Kerberos has support for server-side canonicalization which is an alternative for the DNS based scheme. By default it uses both, but with an option "rdns = no", reverse DNS can be disabled. The use case for this is environments that do not have reverse DNS set up correctly. Especially in Windows Active Directory environments this is very common. Administrators are afraid to enable scavenging for their zones, and therefore any server IP change will leave a stale PTR record in place. This breaks reverse DNS based canonicalization if the IP adress is reassigned. The behaviour enabled by this patch should remain optional and cannot become the default. It breaks the use case when multiple LDAP servers are load balanced using a CNAME record. [1] http://www.openldap.org/lists/openldap-devel/200710/msg00071.html

1 0

Re: (ITS#5807) build broken for solaris 9
by brett.maxfield＠gmail.com 15 Nov '08

15 Nov '08

------=_Part_31358_1557470.1226757706470 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline There's a path worth travelling, not. These are relatively old servers, but even assuming Sun could be made to care, which i doubt, thier solution would probably be to upgrade the server to sol10 / new hardware, and not provide a patch. But i think the solution is probably in autoconf detection somehow, i'll see if i can do something with autoconf/automake stuff. This is sol9 sparc with gcc from sunfreeware, so maybe the autoconf assumes solaris cc in parts, as gcc was not always around. I dont have any sparc gear presently to test on, i'll investigate next week.. On Sat, Nov 15, 2008 at 9:09 AM, Howard Chu <hyc(a)symas.com> wrote: > The Solaris 9 docs say otherwise. > > http://docs.sun.com/app/docs/doc/816-0214/6m6nf1omp?a=view#indexterm-646 > > >>> > If the AI_PASSIVE bit is set in the ai_flags member of the hints structure, > the caller plans to use the returned socket address structure in a call to > bind(3SOCKET). > <<< > > We are using the flag correctly per the documentation, therefore I don't > believe this is an OpenLDAP bug. Take this up with Sun... > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > ------=_Part_31358_1557470.1226757706470 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <br>There's a path worth travelling, not. These are relatively old servers, but even assuming Sun could be made to care, which i doubt, thier solution would probably be to upgrade the server to sol10 / new hardware, and not provide a patch.<br> <br>But i think the solution is probably in autoconf detection somehow, i'll see if i can do something with autoconf/automake stuff. This is sol9 sparc with gcc from sunfreeware, so maybe the autoconf assumes solaris cc in parts, as gcc was not always around. <br> <br>I dont have any sparc gear presently to test on, i'll investigate next week..<br><br><div class="gmail_quote">On Sat, Nov 15, 2008 at 9:09 AM, Howard Chu <span dir="ltr"><<a href="mailto:hyc@symas.com">hyc(a)symas.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> The Solaris 9 docs say otherwise.<br> <br> <a href="http://docs.sun.com/app/docs/doc/816-0214/6m6nf1omp?a=view#indexterm-646" target="_blank">http://docs.sun.com/app/docs/doc/816-0214/6m6nf1omp?a=view#indexterm-646</a><br> <br> >>><br> If the AI_PASSIVE bit is set in the ai_flags member of the hints structure, the caller plans to use the returned socket address structure in a call to bind(3SOCKET).<br> <<<<br> <br> We are using the flag correctly per the documentation, therefore I don't believe this is an OpenLDAP bug. Take this up with Sun...<br><font color="#888888"> -- <br>  -- Howard Chu<br>  CTO, Symas Corp.           <a href="http://www.symas.com" target="_blank">http://www.symas.com</a><br>  Director, Highland Sun     <a href="http://highlandsun.com/hyc/" target="_blank">http://highlandsun.com/hyc/</a><br>  Chief Architect, OpenLDAP  <a href="http://www.openldap.org/project/" target="_blank">http://www.openldap.org/project/</a><br> </font></blockquote></div><br> ------=_Part_31358_1557470.1226757706470--

1 0

Re: (ITS#5811) slapo-dds documentation
by ando＠sys-net.it 15 Nov '08

15 Nov '08

Emmanuel Dreyfus wrote: > Pierangelo Masarati <ando(a)sys-net.it> wrote: > >> So, was that the issue? > > Yes, and I just added it to the man page. Probably, slapo-dds should allow a different means to perform internal operations as a privileged user without requiring rootdn to be defined. This problem is common to many overlays (and features in general) that need to perform internal operations, like syncrepl. Documenting this requirement is fine by now, but the general problem persists. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5811) slapo-dds documentation
by manu＠netbsd.org 15 Nov '08

15 Nov '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > So, was that the issue? Yes, and I just added it to the man page. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5804) attribute value regex expantion
by manu＠netbsd.org 15 Nov '08

15 Nov '08

Emmanuel Dreyfus <manu(a)netbsd.org> wrote: > I committed the modification: > http://www.openldap.org/lists/openldap-commit/200811/msg00303.html And this: http://www.openldap.org/lists/openldap-commit/200811/msg00302.html -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5804) attribute value regex expantion
by manu＠netbsd.org 15 Nov '08

15 Nov '08

I committed the modification: http://www.openldap.org/lists/openldap-commit/200811/msg00303.html -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5811) slapo-dds documentation
by ando＠sys-net.it 15 Nov '08

15 Nov '08

manu(a)netbsd.org wrote: > Full_Name: Emmanuel Dreyfus > Version: HEAD > OS: NetBSD > URL: > Submission from: (NULL) (213.41.141.172) > > > slapo-dds(5) does not document that rootdn definition is mandatory for proper > function So, was that the issue? 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5811) slapo-dds documentation
by manu＠netbsd.org 15 Nov '08

15 Nov '08

Full_Name: Emmanuel Dreyfus Version: HEAD OS: NetBSD URL: Submission from: (NULL) (213.41.141.172) slapo-dds(5) does not document that rootdn definition is mandatory for proper function

1 0

Re: (ITS#5807) build broken for solaris 9
by hyc＠symas.com 14 Nov '08

14 Nov '08

brett.maxfield(a)gmail.com wrote: > Full_Name: Brett Maxfield > Version: 2.4.RELENG > OS: Solaris 9 (SunOS 2.9) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.18.108.167) > > > Hello, > > Trying to make tests for RE24 and 2.4.12 on solaris (SunOS 2.9) and getting a > failure : > > (build options - berkeleyDB previously installed with > --prefix=/usr/local/openldap24) > > export PATH=/usr/local/bin:/usr/ccs/bin:/usr/bin:/bin:/usr/sbin:/sbin > export LD_LIBRARY_PATH=/usr/local/openldap24/lib:/usr/local/ssl/lib:/usr/local/lib > CPPFLAGS="-I/usr/local/openldap24/include -I/usr/local/include" > LDFLAGS="-L/usr/local/openldap24/lib -L/usr/local/lib > -R/usr/local/openldap24/lib -R/usr/local/lib" ./configure --enable-shared > --enable-ssl --disable-ipv6 --with-threads --enable-slapd --enable-backends > --enable-overlays --disable-sql --disable-ndb --disable-slapi > > (result of make test, fails on the first test) > > # cat tests/testrun/slapd.1.log > @(#) $OpenLDAP: slapd 2.4.12 (Nov 13 2008 17:57:10) $ > testuser@myhost:/export/home/testuser/openldap24-build/openldap-2.4.12/servers/slapd > ldap_pvt_gethostbyname_a: host=myhost, r=0 > daemon_init: ldap://localhost:9011/ > daemon_init: listen on ldap://localhost:9011/ > daemon_init: 1 listeners to open... > ldap_url_parse_ext(ldap://localhost:9011/) > daemon: getaddrinfo() failed: invalid ai_flags > slapd stopped. > connections_destroy: nothing to destroy. > > ai_flags has to do with the options to listen/accept, and should be something > like NULL, it seemss sol9 does not like the AI_PASSIVE value. > > I manually changed it to šhints.ai_flags = NULL; // AI_PASSIVE;" > (servers/slapd/daemon.c line 1131) and the code compiles, and make test > succeeds. > > For solaris 9, hints.ai_flags should just use NULL. The Solaris 9 docs say otherwise. http://docs.sun.com/app/docs/doc/816-0214/6m6nf1omp?a=view#indexterm-646 >>> If the AI_PASSIVE bit is set in the ai_flags member of the hints structure, the caller plans to use the returned socket address structure in a call to bind(3SOCKET). <<< We are using the flag correctly per the documentation, therefore I don't believe this is an OpenLDAP bug. Take this up with Sun... -- -- 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

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by hyc＠symas.com 14 Nov '08

14 Nov '08

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> Pierangelo Masarati writes: >>>> I think ITS#5326 is related. Namely, write operations (add, rename) >>>> should always rebuild the (new)DN hierarchically from the tree. >>> I'm not sure what exactly the problem is, if any:-) Syncrepl itself >>> needs to handle databases that are not that nice: We can't require >>> that of back-perl, nor back-ldap which accesses a non-OpenLDAP server >>> (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl >>> is an RFC (4533) so it should handle non-OpenLDAP peers. >> Syncrepl of course *handles* all of those cases. The only issue here is that >> our tests expect the results to be in a specific order, which is obviously an >> invalid requirement in the grand scheme of things. > I'm hitting an issue like this in some of the replication tests I'm > currently performing. For this purpose, I think we could hack > ldapsearch (or add a new prog, or use a script on ldapsearch output) > that sorts entries content attribute-wise and, within each attribute, > value-wise. Something like "sort" applied entry-wise after unwrapping > line folding, optionally case-insensitive would probably suffice. Hm, I already added that, when I was first putting back-ndb thru the test suite. In acfilter.sh, but currently only used for back-ndb too. At any rate, I've tweaked the consumer's rename detection code, so this specific ITS is now fixed. -- -- 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

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by ando＠sys-net.it 14 Nov '08

14 Nov '08

Quanah Gibson-Mount wrote: >> I'm hitting an issue like this in some of the replication tests I'm >> currently performing. For this purpose, I think we could hack >> ldapsearch (or add a new prog, or use a script on ldapsearch output) >> that sorts entries content attribute-wise and, within each attribute, >> value-wise. Something like "sort" applied entry-wise after unwrapping >> line folding, optionally case-insensitive would probably suffice. > > I have a script somewhere from Matt Backes @ Symas that sorts LDIF > files. It was useful for seeing if it made any difference in slapadd (it > didn't). Well, if it were distributable, and written in a widely supported scripting language, it would be quite useful... 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by quanah＠zimbra.com 14 Nov '08

14 Nov '08

--On Friday, November 14, 2008 9:34 PM +0000 ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> Pierangelo Masarati writes: >>>> I think ITS#5326 is related. Namely, write operations (add, rename) >>>> should always rebuild the (new)DN hierarchically from the tree. >>> I'm not sure what exactly the problem is, if any:-) Syncrepl itself >>> needs to handle databases that are not that nice: We can't require >>> that of back-perl, nor back-ldap which accesses a non-OpenLDAP server >>> (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl >>> is an RFC (4533) so it should handle non-OpenLDAP peers. >> >> Syncrepl of course *handles* all of those cases. The only issue here is >> that our tests expect the results to be in a specific order, which is >> obviously an invalid requirement in the grand scheme of things. > > > I'm hitting an issue like this in some of the replication tests I'm > currently performing. For this purpose, I think we could hack > ldapsearch (or add a new prog, or use a script on ldapsearch output) > that sorts entries content attribute-wise and, within each attribute, > value-wise. Something like "sort" applied entry-wise after unwrapping > line folding, optionally case-insensitive would probably suffice. I have a script somewhere from Matt Backes @ Symas that sorts LDIF files. It was useful for seeing if it made any difference in slapadd (it didn't). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by ando＠sys-net.it 14 Nov '08

14 Nov '08

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Pierangelo Masarati writes: >>> I think ITS#5326 is related. Namely, write operations (add, rename) >>> should always rebuild the (new)DN hierarchically from the tree. >> I'm not sure what exactly the problem is, if any:-) Syncrepl itself >> needs to handle databases that are not that nice: We can't require >> that of back-perl, nor back-ldap which accesses a non-OpenLDAP server >> (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl >> is an RFC (4533) so it should handle non-OpenLDAP peers. > > Syncrepl of course *handles* all of those cases. The only issue here is that > our tests expect the results to be in a specific order, which is obviously an > invalid requirement in the grand scheme of things. I'm hitting an issue like this in some of the replication tests I'm currently performing. For this purpose, I think we could hack ldapsearch (or add a new prog, or use a script on ldapsearch output) that sorts entries content attribute-wise and, within each attribute, value-wise. Something like "sort" applied entry-wise after unwrapping line folding, optionally case-insensitive would probably suffice. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by hyc＠symas.com 14 Nov '08

14 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > Pierangelo Masarati writes: >> I think ITS#5326 is related. Namely, write operations (add, rename) >> should always rebuild the (new)DN hierarchically from the tree. > > I'm not sure what exactly the problem is, if any:-) Syncrepl itself > needs to handle databases that are not that nice: We can't require > that of back-perl, nor back-ldap which accesses a non-OpenLDAP server > (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl > is an RFC (4533) so it should handle non-OpenLDAP peers. Syncrepl of course *handles* all of those cases. The only issue here is that our tests expect the results to be in a specific order, which is obviously an invalid requirement in the grand scheme of things. > Still, if it keeps OpenLDAP-on-OpenLDAP clean, that's a plus. > Unless we want back-ldif to be different just to test that syncrepl > handles different backends. Might also make a test which replicates > between different backends - e.g. $BACKEND and back-ldif. The syncrepl rename-detection can be improved - we can compare the normalized parent DN, separately from the un-normalized RDN. This would eliminate a false detection of a move/rename solely due to superior RDNs being mismatched. -- -- 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

Re: (ITS#5810) $BACKEND selections in make test
by h.b.furuseth＠usit.uio.no 14 Nov '08

14 Nov '08

quanah(a)zimbra.com writes: > What about back-sql, back-ndb, etc? The test0* scripts don't seem to be really ported to other backends than bdb, hdb and ldbm, though I'm guessing about ndb. Back-sql has its own test scripts: tests/scripts/sql-*. acfilter.sh and run.in accomodate ndb a bit, but most of the $BACKEND tests are years old so I expect porting tests to ndb is in its infancy. Same with back-ldif and back-null, they will need help from acfilter.sh and some of the tests. Though there are a few tests for $BACKEND = ldif. -- Hallvard

1 0

Re: (ITS#5810) $BACKEND selections in make test
by quanah＠zimbra.com 14 Nov '08

14 Nov '08

--On Friday, November 14, 2008 3:38 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE24 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > A number of tests contain code like > if test "$BACKEND" != "bdb" && test "$BACKEND" != "hdb" ; then > echo "Test does not support $BACKEND" > exit 0 > fi > This looks like a holdover from ldbm, I suggest we remove it. What about back-sql, back-ndb, etc? I'm not sure it's just a holdover of ldbm. There's quite a few backends that may not support a number of things. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs