openldap-devel

openldap-devel@openldap.org

1443 discussions

Re: commit: ldap/libraries/libldap deref.c Makefile.in
by Pierangelo Masarati 10 Nov '08

10 Nov '08

quanah(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap > > Modified Files: > Tag: OPENLDAP_REL_ENG_2_4 > Makefile.in 1.79.2.6 -> 1.79.2.7 > Added Files: > Tag: OPENLDAP_REL_ENG_2_4 > deref.c NONE -> 1.2.2.1 > > Log Message: > ITS#5768 This commit breaks 2.4 because LDAP_CONTROL_X_DEREF is only defined when LDAP_DEVEL is, but it is used in libldap/deref.c without #ifdef. Probably, the macro declaration should be moved outside #ifdef LDAP_DEVEL. I don't want to intervene while you're consolidating 2.4, though. 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 -----------------------------------

2 1

Re: commit: ldap/doc/drafts draft-masarati-ldap-whatfailed-xx.txt draft-masarati-ldap-whatfailed.xml
by Pierangelo Masarati 10 Nov '08

10 Nov '08

quanah(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/doc/drafts > > Added Files: > Tag: OPENLDAP_REL_ENG_2_4 > draft-masarati-ldap-whatfailed-xx.txt NONE -> 1.4.2.1 > draft-masarati-ldap-whatfailed.xml NONE -> 1.4.2.1 > > Log Message: > ITS#5784 Probably, you should not release the .xml code. It's there because it's the source of the textual form. 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 -----------------------------------

2 1

Re: commit: ldap/servers/slapd/schema pmi.schema
by Quanah Gibson-Mount 10 Nov '08

10 Nov '08

Pierangelo, Do you plan on committing a cn=config (LDIF) formatted version of this schema? --Quanah --On Saturday, October 18, 2008 6:33 AM +0000 ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/schema > > Added Files: > pmi.schema NONE -> 1.1 > > Log Message: > apply Luca Tamburo's patch for Attribute Certificate and X.509 PMI > support (with modifications, ITS#5695) > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/schema/ > > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/schema/pmi.schema > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

Fw: [x500standard] Important resolutions out of Montreux
by Gavin Henry 09 Nov '08

09 Nov '08

Would an x500 password policy influence our LDAP one? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. -----Original Message----- From: "Erik Andersen" <era(a)x500.eu> Date: Sun, 9 Nov 2008 10:05:31 To: Directory list<x500standard(a)freelists.org> Subject: [x500standard] Important resolutions out of Montreux Hi Folks, The ISO/IEC JTC1/SC6 meeting in Montreux has ended. It resulted in a new working draft for Password Policy. Among resolutions for the directory works (WG8) the following are quite important Resolution 6.8.4 Advance Authorisation for Project Subdivision SC 6 approves the split of Project 47.05.23, Directory Communication support enhancements under the condition that ITU-T Study Group 17 in its coming meeting approves further work in this area. The work will then continue to allow for further communication enhancements to the new edition. Resolution 6.8.6 Scope of Project 47.06.22 SC 6 recognises that Password Policy is a part of Identity Management and that the Password Policy project may include related Identity Management aspects. The first resolution allows us to continue work on for communication enhancement. This may mean enhancing the X.500 communications support and make communication enhancement supporting for other type of specifications, e.g. tag-based applications. The second resolution allows us the add support for well defined requirement for Identity Management. Regards, Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 email: era(a)x500.eu www.x500.eu www.x500standard.com

1 0

Filtering for entryDN
by Pierangelo Masarati 04 Nov '08

04 Nov '08

There's an application that "bombs" slapd filtering for equality on entryDN. I know it sounds like a nonsense, but that's how it is. Would it make sense to use the dn2id index as the default entryDN key database for equality on entryDN, instead of explicitly configuring (and maintaining) an index on entryDN? 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

Controls and criticality
by Pierangelo Masarati 03 Nov '08

03 Nov '08

I see some inconsistency and possibly some misunderstanding (probably mostly at my side) on controls and criticality. This has been discussed many times, but probably slapd did not converge yet. The specs (RFC4511) say that controls CAN be critical or non-critical. Implementations (DSAs) MAY or MAY NOT recognize controls. I see many cases; some of them are trivial, but other are not. Let's consider a matrix, where columns represent criticality (FALSE, TRUE) and rows represent implementation (FALSE, TRUE). implemented \ criticality | FALSE | TRUE | ----------------------------+--------+--------+ FALSE | F,F | F,T | ----------------------------+--------+--------+ TRUE | T,F | T,T | ----------------------------+--------+--------+ The specs state that if a control is not implemented, criticality determines whether the control is ignored (crit == FALSE) or the operation fails (crit == TRUE). If the control is implemented, then criticality determines whether, in case the control cannot be applied, whether the control is ignored (crit == FALSE) or the operation fails (crit == TRUE). It should be clear that the criticality field is already overloaded: in the first case the implementation does not know the control, while in the second case it knows the control so much that it can determine whether or not it can be applied. Let's now add a third, fuzzy dimension: control semantics. In fact, in many specs, the control semantics tries to bend the meaning of criticality towards common sense. The specs say that all four combinations F,F; F,T; T,F; T,T are perfectly legitimate, and describe how a DSA MUST behave in all cases (or CAN, when an arbitrary behavior is legitimate). Let me start with intuitive considerations: there are cases in which some of the four possible behaviors should (lowercase "should") not be allowed by common sense. However, this seems to violate a strict interpretation of the specs. I'll bring examples shortly. But in any case, I believe slapd should behave: 1) consistently 2) biased towards security Examples: a) RFC4370, proxied authorization control, states that "Clients MUST include the criticality flag and MUST set it to TRUE. Servers MUST reject any request containing a Proxy Authorization Control without a criticality flag or with the flag set to FALSE with a protocolError error." and explains why: "These requirements protect clients from submitting a request that is executed with an unintended authorization identity." This is just common sense, and is part of the control's semantics, but it disagrees with RFC4511, which is normative. Currently, slapd does not follow this common sense advice, and allows non-critical proxied authorization requests. Please note the first "MUST" (for the DUA) and the second "MUST" (for the DSA; this is in violation of RFC4511). b) <draft-zeilenga-ldap-dontusecopy-04> (a work in progress) states that "The criticality MUST be TRUE. There is no corresponding response control." This again is common sense, since if the control is not recognized, the operation's semantics would be totally different, as (out of sync) copies could be used instead of the original data, which is the purpose of the control. Please note the "MUST" (uppercase; for the DUA). Currently, slapd follows the advice of this work in progress, but it'll probably need to be changed in order to be published as an RFC, because as it is now it does not comply with RFC4511 (see ITS#5785). Note that RFC4511 provides a sentence, about what controls specifications are to provide, that sounds a little bit ambiguous: "[...] direction as to what value the sender should provide for the criticality field (note: the semantics of the criticality field are defined above should not be altered by the control's specification)". In the end, the responsibility for getting into trouble is all placed on the DUA; the specs "are to" (lowercase, no "MUST") provide what the sender "should" (lowercase, no "SHOULD") provide for the criticality field. I believe that this is absolutely correct, but as a DSA implementor, and not only a DUA implementor, I also believe that it is the responsibility of the DSA to make sure its integrity and security is not compromised by a poorly behaving DUA. I recommend we take two actions: 1) make sure slapd behaves consistently in all those cases, no matter whether we choose to follow the letter of RFC4511 or to tend towards the security and integrity side 2) act in direction of a modification of RFC4511 that somehow allows the semantics of a control to override those of the criticality field. I believe the criticality field is a mandatory mechanism to promote interoperability when it comes to extensions. However, there are cases where either interoperability exists or doesn't. In those cases, we cannot simply delegate security and integrity to the DUA, as the DSA is responsible of both in the end. I believe the main consequence of allowing the DSA to reject (as something closely related to a protocol violation) a control whose criticality does not conform with that control's specification in terms of semantics would be that in the case of criticality set to FALSE two implementations would behave differently depending on whether that control is implemented or not. But this degree of arbitrarity does not differ much from that implicitly allowed by clients when they set criticality to FALSE. Sending dontUseCopy with FALSE is an error. RFC4511 says we should return possibly outdated data in response. Receiving an error in response to an error, instead of incorrect data because the control was ignored, seems more appropriate. Not per se, but rather because it brings less harm than it could by behaving according to RFC4511. This is my 2c (well, reading back, it looks like more than just 2 :) p.

3 7

Fwd: [x500standard] Password attribute
by Gavin Henry 03 Nov '08

03 Nov '08

----- Forwarded Message ----- From: "David Chadwick" <d.w.chadwick(a)kent.ac.uk> To: x500standard(a)freelists.org Sent: Monday, 3 November, 2008 3:56:46 PM GMT +00:00 GMT Britain, Ireland, Portugal Subject: [x500standard] Password attribute Hi All In the new version of X.500 that we are working on, we are creating password policies, grace periods, password expiration times and the like. Currently the password attribute in X.509 is defined semantically to be SINGLE valued, but syntactically to be multi-valued. We are considering changing the syntax to agree with the semantic definition, since this will significantly simplify the password management text. DOES ANYONE HAVE ANY OBJECTIONS TO THE PASSWORD ATTRIBUTE BECOMING SINGLE VALUED, and if so could they say why thanks David -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick(a)kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** ----- www.x500standard.com: The central source for information on the X.500 Directory Standard. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP.

1 0

Re: commit: ldap/servers/slapd/back-ldif ldif.c
by Hallvard B Furuseth 29 Oct '08

29 Oct '08

hyc(a)OpenLDAP.org writes: > ldif.c 1.86 -> 1.87 > ITS#5774 blind fix for Windows, please test Another question - does strerror(errno) get the right error message after MoveFileEx()? The errno == ENOENT test can go away, we need to pre-check that the directory exists anyway. But the debug message currently printed by the caller should report what is wrong. The Microsoft doc shows a horrible call to FormatMessage() at <http://msdn.microsoft.com/en-us/library/ms679351(VS.85).aspx> except that produces a wide string, not a plain string. -- Hallvard

1 0

Re: commit: ldap/servers/slapd limits.c
by Hallvard B Furuseth 25 Oct '08

25 Oct '08

hallvard(a)OpenLDAP.org writes: > limits.c 1.83 -> 1.84 > More ITS#5734: Handle empty o_req_ndn. (...) This gets somewhat inconsistent: dn.this.<subtree or exact>="" now matches target DN "". However, to preserve backwards compatibility, dn.<subtree or exact>="" does not match anonymous binding. OTOH, limits dn.<anything>=* becomes limits *, again preserving backwards compatibility. However dn.<onelevel or children>=* should not match empty target DN/anonymous connections. Should we leave it as it is? Or change the old behavior? And if so, does an anonymous connection have a DN so it should match "", or not? Or we could make them errors to avoid admins seeing unexpected behavior for a config which slapd accepts. These cases seem fairly useless, but could arise from something like an auto-generated config files when the admin inputs suffix "". -- Hallvard

2 1

Re: commit: ldap/include portable.hin ldap.h
by Howard Chu 22 Oct '08

22 Oct '08

ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/include > > Modified Files: > portable.hin 1.44 -> 1.45 > ldap.h 1.337 -> 1.338 > > Log Message: > add support for (experimental) dereference control (ITS#5768); need to re-run autoconf (and autoheader?) portable.hin is generated by autoheader, so you ordinarily should leave that commit until after autoheader is rerun. No big deal... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

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-devel