openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

(ITS#6524) gnutls cipher spec is unclear
by matthijs＠cacholong.nl 16 Apr '10

16 Apr '10

Full_Name: Matthijs Mohlmann Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.163.247.203) Hi, The manpage about the TLS_CIPHER_SUITE is for gnutls a bit unclear, only an example for OpenSSL is provided. Peter Marschall wrote a patch for this documentation issue. See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510346 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563113 Regards, Matthijs Mohlmann Patch: --- openldap-2.1.21/doc/man/man5/ldap.conf.5 +++ openldap-2.1.21/doc/man/man5/ldap.conf.5 2010-04-15 08:26:41.000000000 +0200 @@ -334,19 +334,37 @@ .B TLS_CIPHER_SUITE <cipher-suite-spec> Specifies acceptable cipher suite and preference order. <cipher-suite-spec> should be a cipher specification for OpenSSL, -e.g., HIGH:MEDIUM:+SSLv2. +<cipher-suite-spec> should be a cipher specification for OpenSSL resp. GNUtls. +Example: +.RS +.RS +.TP +.I OpenSSL: +TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv2 +.TP +.I GNUtls: +TLS_CIPHER_SUITE SECURE256:!AES-128-CBC +.RE -To check what ciphers a given spec selects, use: +To check what ciphers a given spec selects in OpenSSL, use: .nf openssl ciphers \-v <cipher-suite-spec> .fi -To obtain the list of ciphers in GNUtls use: +With GNUtls the available specs can be found in the manual page of +.BR gnutls\-cli (1) +(see the description of the +option +.BR \-\-priority ). + +In older versions of GNUtls, where gnutls\-cli does not support the option +\-\-priority, you can obtain the \(em more limited \(em list of ciphers by calling: .nf - gnutls-cli \-l + gnutls\-cli \-l .fi +.RE .TP .B TLS_RANDFILE <filename> Specifies the file to obtain random bits from when /dev/[u]random is

1 0

Re: (ITS#6515) A lot of dead links on main page of OpenLDAP man.
by Kurt＠OpenLDAP.org 15 Apr '10

15 Apr '10

On Apr 15, 2010, at 5:37 PM, hyc(a)symas.com wrote: > Dzmitry Stremkouski wrote: >> http://www.openldap.org/doc/admin24/schema.html - Contains them, as = well >=20 > I guess the web site is just out of date. I note that update to date for doc/admin24 means "as of the last 2.4 = patch release". -- Kurt=

1 0

Re: (ITS#6515) A lot of dead links on main page of OpenLDAP man.
by hyc＠symas.com 15 Apr '10

15 Apr '10

Dzmitry Stremkouski wrote: > http://www.openldap.org/doc/admin24/schema.html - Contains them, as well I guess the web site is just out of date. The last link in question was fixed by ITS#6493 on 2010-03-18. The IANA link was fixed on 2007-07-07. I don't recall when the bsa link was removed, but it's gone in the 2.4 doc. > On Mon, Apr 12, 2010 at 10:10 PM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > mitroko(a)gmail.com <mailto:mitroko@gmail.com> wrote: > > Full_Name: Dmitry Stremkouski > Version: > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.84.189.132) > > > Hello guys. The part of OpenLDAP Manual (wich can be found here - > http://www.openldap.org/doc/admin23/schema.html) contains a lot of broken > links. > Please correct. > > > The 2.3 release is no longer maintained. This doc will not be updated. > > FE: http://www.alvestrand.no/harald/objectid/ - dead > A: http://www.bsa-global.com/ - dead (doesn't look good enough for > global OID > authority) > A: http://www.iana.org/cgi-bin/enterprise.pl - should be (redirect, > but futher, > IMHO, will be dead, try http://pen.iana.org/pen/PenApplication.page) > > Thanks. > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > > -- > <pre> > (o_ - Dzmitry Stremkouski. > //\ - cel: +7 (916) 090-85-68 > V_/_- web: http://mitroko.com > </pre> > -- -- 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#6475
by masarati＠aero.polimi.it 15 Apr '10

15 Apr '10

>> Such a behavior allows replays attacks >> within the modification propagation time frame, but it ensures that bind >> are still possible when then master is down. I think it could be >> interesting to have a configuration setting for that. > > We should bring this to -devel, to see whether it makes sense and whether > it would be acceptable. A fix in this sense is in HEAD. Modifications consist in the original patch (well-known SASL mechs exploit the dontUseCopy control to actually lookup and propagate auxprops to the master ("sasl-auxprops-dontusecopy" directive). Another directive ("sasl-auxprops-dontusecopy-ignore") allows to ignore errors and lookup/store auxprops locally. By default it's FALSE for consistency. If set to TRUE, replicas will be misaligned, but service will be possible. Choose what best fits your needs. Both directives are not documented yet, as I consider the whole code highly experimental. Right now, is only built when #define LDAP_DEVEL. Please note that the relatively minor modifications to slapo-chain(5) are not conditioned on #define SLAP_AUXPROP_DONTUSECOPY, because I think they are generally useful, and I've checked they don't break anything (I could check so far). Please report any inconvenience. p.

1 0

Re: (ITS#6469) push replication entryCSN of database suffix out of sync
by rhafer＠suse.de 15 Apr '10

15 Apr '10

Am Donnerstag 15 April 2010 00:53:04 schrieb hyc(a)symas.com: > rhafer(a)suse.de wrote: > > Am Mittwoch 03 Februar 2010 09:39:19 schrieb hyc(a)symas.com: > >> rhafer(a)suse.de wrote: > >>> Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc(a)symas.com: > >>>> But how did the suffix entry get created without an entryCSN in > >>>> the first place? The MOD that updates the contextCSN doesn't > >>>> happen until after the suffix entry already exists. > >>> > >>> It wasn't created without an entryCSN. It always had one. But the > >>> MOD to update the contextCSN (coming from the provider) doesn't > >>> contain one. So bdb_modify() will call slap_mods_opattrs() to add > >>> entryCSN to the MOD operation. The easiest fix is probably to > >>> never touch the opattrs if "updatedn" is doing MODs, though I am > >>> not yet sure if it might break something. Currently my fix (not > >>> committed yet) only skips the slap_mods_opattrs() step if > >>> "updatedn" it is doing a MOD on contextCSN. > >> > >> Ah, got it. Yes, sounds like your fix is fine. > > > > Do you think it's fine to always skip slap_mods_opattrs() if > > "updatedn" is writing? Or should I check for contextCSN MODs > > specifically? > > > >> Historically the updatedn user (e.g. slurpd) has always provided > >> all of the operational attributes in its updates. > > I guess the question is what have we done in the past for updatedn > writes? If we filled in missing opattrs, then we should continue to > do so. So it should be a special case for contextCSN mods. Ok, that's how the current fix work. So I think we are fine here now. -- Ralf

1 0

Re: (ITS#6513) dynacl/aci fails on searches with attributes
by masarati＠aero.polimi.it 14 Apr '10

14 Apr '10

> If you don't mind playing with HEAD code, you could try this patch > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-14-extra-attrs.…> Never mind, I think I already made it incompatible with HEAD code. I'm going to commit this stuff anyway, please stay tuned. p. > You need to add > > extra_attrs OpenLDAPACI > > within the database that contains the offending slapo-rwm instance. > > Please test and report. Thanks, p. > > > >

1 0

Re: (ITS#6513) dynacl/aci fails on searches with attributes
by masarati＠aero.polimi.it 14 Apr '10

14 Apr '10

If you don't mind playing with HEAD code, you could try this patch <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-14-extra-attrs.…> You need to add extra_attrs OpenLDAPACI within the database that contains the offending slapo-rwm instance. Please test and report. Thanks, p.

1 0

Re: (ITS#6469) push replication entryCSN of database suffix out of sync
by hyc＠symas.com 14 Apr '10

14 Apr '10

rhafer(a)suse.de wrote: > Am Mittwoch 03 Februar 2010 09:39:19 schrieb hyc(a)symas.com: >> rhafer(a)suse.de wrote: >>> Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc(a)symas.com: >>>> But how did the suffix entry get created without an entryCSN in the >>>> first place? The MOD that updates the contextCSN doesn't happen >>>> until after the suffix entry already exists. >>> >>> It wasn't created without an entryCSN. It always had one. But the >>> MOD to update the contextCSN (coming from the provider) doesn't >>> contain one. So bdb_modify() will call slap_mods_opattrs() to add >>> entryCSN to the MOD operation. The easiest fix is probably to never >>> touch the opattrs if "updatedn" is doing MODs, though I am not yet >>> sure if it might break something. Currently my fix (not committed >>> yet) only skips the slap_mods_opattrs() step if "updatedn" it is >>> doing a MOD on contextCSN. >> >> Ah, got it. Yes, sounds like your fix is fine. > Do you think it's fine to always skip slap_mods_opattrs() if "updatedn" > is writing? Or should I check for contextCSN MODs specifically? > >> Historically the updatedn user (e.g. slurpd) has always provided all of >> the operational attributes in its updates. > I guess the question is what have we done in the past for updatedn writes? If we filled in missing opattrs, then we should continue to do so. So it should be a special case for contextCSN mods. -- -- 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#6513) dynacl/aci fails on searches with attributes
by masarati＠aero.polimi.it 14 Apr '10

14 Apr '10

> --Boundary-00=_glFxL04kLcJl7l6 > Content-Type: Text/Plain; > charset="iso-8859-15" > Content-Transfer-Encoding: quoted-printable > > Thanks for your quick answer Pierangelo, > > On Monday, 12. April 2010, masarati(a)aero.polimi.it wrote: >> > [...] >> > My guess is that you're trying to use ACIs with a non-local storage. >> In >> > that case your analysis is correct. Can you provide your (sanitized) >> > configuration? > > I am using a local hdb backend. > > In order to generate a minimal test case I found out, that it seems to > be=20 > related to the rwm overlay. > > Although I have set rwm-rewriteEngine to off, rwm seems to be partially=20 > active. > Commenting out the rwm directives completely makes the searches work as=20 > expected. > > Please find attached a testcase with slapd.conf and ldif data. > To experience the issue simply perform a search with e.g. attribute 1.1 as > = > one=20 > of the users in the data. > Then comment the rwm-... lines in slapd.conf, restart slapd and try again. > Voil=E0 the difference. I see. probably, a relatively "quick" fix would be to allow to define a list of attributes, specific for a database, that is available to all implementations that need to muck with requested attrs (e.g. slapd-ldap, slapd-meta, slapo-rwm). They are supposed to be added to the list of requested attrs whenever appropriate. It's up to the administrato to keep it updated with everything that may be needed by special features like ACI. Something like required_attrs OpenLDAPACI In the future, we might be able to figure out a clever way to self-detect what attributes need to be treated this way. I'll work at that, time permitting. Thanks for reporting. p.

1 0

(ITS#6523) idassert marks proxyAuthz as non-critical
by masarati＠aero.polimi.it 14 Apr '10

14 Apr '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.141.24) Submitted by: ando RFC 4370 requires the criticality flag to be present and set to TRUE. I also note that slapd by default tolerates this behavior, and provides the disallow proxy_authz_non_critical directive to behave in strict accordance with RFC 4370. I've introduced a corresponding proxy-authz-[non-]critical flag in idassert. p.

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