openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#7866) [PATCH] Mention default database in tools' man pages
by hyc＠symas.com 30 May '14

30 May '14

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: 2.4.39 > OS: > URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20140530-0001-Mention-de… > Submission from: (NULL) (209.132.186.34) > > > Many of the slaptools use -b to specify a database. However, there is no mention > (apart from section 10.2.1. "The slapadd program" in the admin guide) in the > documentation that if there are multiple databases in the configuration, the > first one is used when no -b is given. The provided patch tries to improve the > situation by providing an explicit mention of the default database. Seriously? In 15 years no one else has ever remarked on this, why is this even worth discussing? At any rate, the added text is incorrect. Technically, "the first database in the configuration that supports the requested operation" is used. E.g., if back-monitor is the first DB in the config, it is skipped. -- -- 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#7866) [PATCH] Mention default database in tools' man pages
by jsynacek＠redhat.com 30 May '14

30 May '14

Full_Name: Jan Synacek Version: 2.4.39 OS: URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20140530-0001-Mention-de… Submission from: (NULL) (209.132.186.34) Many of the slaptools use -b to specify a database. However, there is no mention (apart from section 10.2.1. "The slapadd program" in the admin guide) in the documentation that if there are multiple databases in the configuration, the first one is used when no -b is given. The provided patch tries to improve the situation by providing an explicit mention of the default database.

1 0

Re: (ITS#7863) Invalid DN syntax (34) not written by slapo-accesslog
by pierangelo.masarati＠polimi.it 30 May '14

30 May '14

On 05/30/2014 01:33 AM, hyc(a)symas.com wrote: > pierangelo.masarati(a)polimi.it wrote: >> It now comes to my mind that another perhaps less intrusive chance of >> intervention could be to act at the *response* level. Think of: >> >> - the possibility to stack code in the response chain (not necessarily >> overlays) >> >> - have a way to understand if the response originates *before* the >> frontend was called >> >> In this case, the custom code could re-parse the request to re-detect >> why it failed and handle it (e.g. log custom information on failure >> reason). Not a piece of cake, but probably less intrusive than other >> options. (I'm not sure the raw request buffer is still available at >> this stage, though.) > > Still not something useful for slapo-accesslog - we're storing log info as > LDAP attributes. We can't store reqDN if the DN has invalid syntax. We can't > store reqMod values if the attributetype is unknown or the values are invalid. > When a request fails validation it's literally garbage, and toxic - cannot be > considered safe to preserve in a DB. Sure. Indeed, it could not be associated with accesslog (invalid DN needs to be detected way before a database can be selected). Such a case would belong to some "debugging" layer (e.g. client-server interaction troubleshooting), which BTW I'm convinced the current logging is more than enough for. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

Re: (ITS#7863) Invalid DN syntax (34) not written by slapo-accesslog
by hyc＠symas.com 29 May '14

29 May '14

pierangelo.masarati(a)polimi.it wrote: > It now comes to my mind that another perhaps less intrusive chance of > intervention could be to act at the *response* level. Think of: > > - the possibility to stack code in the response chain (not necessarily > overlays) > > - have a way to understand if the response originates *before* the > frontend was called > > In this case, the custom code could re-parse the request to re-detect > why it failed and handle it (e.g. log custom information on failure > reason). Not a piece of cake, but probably less intrusive than other > options. (I'm not sure the raw request buffer is still available at > this stage, though.) Still not something useful for slapo-accesslog - we're storing log info as LDAP attributes. We can't store reqDN if the DN has invalid syntax. We can't store reqMod values if the attributetype is unknown or the values are invalid. When a request fails validation it's literally garbage, and toxic - cannot be considered safe to preserve in a DB. -- -- 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#7863) Invalid DN syntax (34) not written by slapo-accesslog
by pierangelo.masarati＠polimi.it 29 May '14

29 May '14

On 05/29/2014 09:31 PM, pierangelo.masarati(a)polimi.it wrote: > On 05/29/2014 06:13 PM, michael(a)stroeder.com wrote: >> Howard Chu wrote: >>> michael(a)stroeder.com wrote: >>>> It seems that modify requests which failed due to Invalid DN syntax (34) are >>>> not >>>> written to accesslog-DB. I guess that those requests get abandoned by the >>>> frontend and never reach the backend at all. >>> >>> Correct. >>> >>>> It would be handy to see the invalid modify request in the accesslog-DB though. >>>> >>>> Any chance to achieve this? >>> >>> Not likely. The frontend must call select_backend() based on the incoming DN >>> to determine which backend to invoke, and thus which stack of overlays are >>> involved. If the DN is invalid, no selection can occur. >> >> Hmm, I've done some more tests. Invalid syntax (21) also does not make it >> beyond the frontend into accesslog-DB. >> >> I have no clear opinion on this. Of course the current behaviour is good for >> performance. But sometimes one would like to observe what broken LDAP clients >> sent in a modify request in the past. >> >> Also running with BER loglevel or breaking up the TLS connection with stunnel >> and sniff with Wireshark is not always an option. >> >> Having this configurable would be great. >> >> What's your opinion on this? > > In terms of code architecture, overlays have been designed to work on > validated data (the request must be well formed). To this end, the > notion of "frontend" database was added to make it possible to layer an > overlay *before* backend selection. > > To have a custom piece of code muck with a request before it is > validated (or even before it is parsed) you need to split the code into: > > - parsing, without doing any sanity check > > - allow custom code to step in > > - do validation afterwards > > This does not necessarily imply performance penalty (when no custom code > steps in, the amount of operations would be the same for sane requests; > in case of malformed requests, you would miss the opportunity to bail > out on the first inconsistency). > > However, it would imply significant refactorization of the current code, > without (IMHO) a strong motivation for it: malformed requests are > already handled in terms of response to clients, and somehow logged. > > An (expensive) alternative would be to register a handler at connection > level which duplicates the parsing to anticipate checking for errors > that would be detected before passing control to the frontend. Not the > way I'd go, unless strictly necessary. > > A paranoid but intriguing alternative would be to implement an operation > mode that keeps parsing after the first error is detected, turning the > operation into a no-op. Again, lots of refactorization and error > handling and so on (for example, what if a syntax, an attribute > description or a matching rule is not found? You'd always have to check > that the corresponding pointer is not NULL before using it, whereas > right now we often assume that if execution got there, data must be > consistent. Of course, we could introduce dummy syntaxes > "NonExistingSyntax", ..., but we'd probably need to define their > semantics in such a way that they apply to every case we need to handle > and so). It now comes to my mind that another perhaps less intrusive chance of intervention could be to act at the *response* level. Think of: - the possibility to stack code in the response chain (not necessarily overlays) - have a way to understand if the response originates *before* the frontend was called In this case, the custom code could re-parse the request to re-detect why it failed and handle it (e.g. log custom information on failure reason). Not a piece of cake, but probably less intrusive than other options. (I'm not sure the raw request buffer is still available at this stage, though.) p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

Re: (ITS#7863) Invalid DN syntax (34) not written by slapo-accesslog
by pierangelo.masarati＠polimi.it 29 May '14

29 May '14

On 05/29/2014 06:13 PM, michael(a)stroeder.com wrote: > Howard Chu wrote: >> michael(a)stroeder.com wrote: >>> It seems that modify requests which failed due to Invalid DN syntax (34) are >>> not >>> written to accesslog-DB. I guess that those requests get abandoned by the >>> frontend and never reach the backend at all. >> >> Correct. >> >>> It would be handy to see the invalid modify request in the accesslog-DB though. >>> >>> Any chance to achieve this? >> >> Not likely. The frontend must call select_backend() based on the incoming DN >> to determine which backend to invoke, and thus which stack of overlays are >> involved. If the DN is invalid, no selection can occur. > > Hmm, I've done some more tests. Invalid syntax (21) also does not make it > beyond the frontend into accesslog-DB. > > I have no clear opinion on this. Of course the current behaviour is good for > performance. But sometimes one would like to observe what broken LDAP clients > sent in a modify request in the past. > > Also running with BER loglevel or breaking up the TLS connection with stunnel > and sniff with Wireshark is not always an option. > > Having this configurable would be great. > > What's your opinion on this? In terms of code architecture, overlays have been designed to work on validated data (the request must be well formed). To this end, the notion of "frontend" database was added to make it possible to layer an overlay *before* backend selection. To have a custom piece of code muck with a request before it is validated (or even before it is parsed) you need to split the code into: - parsing, without doing any sanity check - allow custom code to step in - do validation afterwards This does not necessarily imply performance penalty (when no custom code steps in, the amount of operations would be the same for sane requests; in case of malformed requests, you would miss the opportunity to bail out on the first inconsistency). However, it would imply significant refactorization of the current code, without (IMHO) a strong motivation for it: malformed requests are already handled in terms of response to clients, and somehow logged. An (expensive) alternative would be to register a handler at connection level which duplicates the parsing to anticipate checking for errors that would be detected before passing control to the frontend. Not the way I'd go, unless strictly necessary. A paranoid but intriguing alternative would be to implement an operation mode that keeps parsing after the first error is detected, turning the operation into a no-op. Again, lots of refactorization and error handling and so on (for example, what if a syntax, an attribute description or a matching rule is not found? You'd always have to check that the corresponding pointer is not NULL before using it, whereas right now we often assume that if execution got there, data must be consistent. Of course, we could introduce dummy syntaxes "NonExistingSyntax", ..., but we'd probably need to define their semantics in such a way that they apply to every case we need to handle and so). My 2c. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

Re: (ITS#7863) Invalid DN syntax (34) not written by slapo-accesslog
by michael＠stroeder.com 29 May '14

29 May '14

Howard Chu wrote: > michael(a)stroeder.com wrote: >> It seems that modify requests which failed due to Invalid DN syntax (34) are >> not >> written to accesslog-DB. I guess that those requests get abandoned by the >> frontend and never reach the backend at all. > > Correct. > >> It would be handy to see the invalid modify request in the accesslog-DB though. >> >> Any chance to achieve this? > > Not likely. The frontend must call select_backend() based on the incoming DN > to determine which backend to invoke, and thus which stack of overlays are > involved. If the DN is invalid, no selection can occur. Hmm, I've done some more tests. Invalid syntax (21) also does not make it beyond the frontend into accesslog-DB. I have no clear opinion on this. Of course the current behaviour is good for performance. But sometimes one would like to observe what broken LDAP clients sent in a modify request in the past. Also running with BER loglevel or breaking up the TLS connection with stunnel and sniff with Wireshark is not always an option. Having this configurable would be great. What's your opinion on this? Ciao, Michael.

1 0

(ITS#7865) man slapo-refint extended with olc-example
by wandel＠b1-systems.de 29 May '14

29 May '14

Full_Name: Michael Wandel Version: 2.4.39 OS: Linux URL: ftp://ftp.openldap.org/incoming/wandel-140529-0001-Manpage-enhancement-for-… Submission from: (NULL) (217.86.177.164) The man pag of the refint Overlay handle only the slapd.conf variant. I add an example for using the conf Backend.

1 0

Re: (ITS#7864) slapo-translucent should honour the manageDSAit control
by michael＠stroeder.com 29 May '14

29 May '14

This is a cryptographically signed message in MIME format. --------------ms080107050802050209040602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> This is a cryptographically signed message in MIME format. >=20 >> jkozyra(a)gmail.com wrote: >>> ManageDSAit is honoured by other overlays like dynlist, retcode, and = un=3D >> ique. The >>> translucent overlay should add this functionality. >> >> Can your please elaborate on the semantics you want to have when using= >> ManageDSAit control. >> >> Originally ManageDSAit control was only meant to manage referral entri= es.=3D >=20 >> It was (ab)used for some other purposes especially *before* Relax Rule= s >> control was defined/implemented. >=20 > In particular, the control changes search behavior to return the actual= entry=20 > for a referral entry, instead of returning a searchReference. In the ot= her=20 > overlays, e.g. dynlist, the control changes search behavior to return t= he=20 > actual entry, instead of trying to expand the list of dynamic members. >=20 > For translucent, the control should return the actual local entry, inst= ead of=20 > trying to return the result of merging local and remote data. I thought the Proxy cache privateDB control (1.3.6.1.4.1.4203.666.11.9.5.= 1) should be used for that. CIao, Michael. --------------ms080107050802050209040602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNTI5MTM1MzM5WjAj BgkqhkiG9w0BCQQxFgQUHudXKkMwDWUJD1r/NhU+1GGT2vQwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAdkiNkhBAipUQ1XBLmnIEzrcs+AC5V2WE 0MiMn7MmAL2072PBLWnF6Bei2CdM3F9E608yBBM9seU1FQsxXf2fnzUd3PUqVvuQpFvbiJVG sDgggrDV2FZocvkYcBLhgBhEaUJ2zSVHofqWfWScgEz9jwUFbq2n8W9NpkBpbSMG+JdUAq6u stXKZ+oXybqFvwUybP/0qPfjvFOFF/w7wOUdk7heDUNsMXMydil0fptIIOop9r29fLqK3fLo tFHB9QNG7PTy1ZoBh/5WM6891WSWtJm1RWvstb8XIMEvg2MC2a3+au2I0lPX7UwNO3Bglw7F D3cADleduhU/HrUmNItKvQAAAAAAAA== --------------ms080107050802050209040602--

1 0

Re: (ITS#7864) slapo-translucent should honour the manageDSAit control
by hyc＠symas.com 29 May '14

29 May '14

michael(a)stroeder.com wrote: > This is a cryptographically signed message in MIME format. > jkozyra(a)gmail.com wrote: >> ManageDSAit is honoured by other overlays like dynlist, retcode, and un= > ique. The >> translucent overlay should add this functionality. > > Can your please elaborate on the semantics you want to have when using > ManageDSAit control. > > Originally ManageDSAit control was only meant to manage referral entries.= > It was (ab)used for some other purposes especially *before* Relax Rules > control was defined/implemented. In particular, the control changes search behavior to return the actual entry for a referral entry, instead of returning a searchReference. In the other overlays, e.g. dynlist, the control changes search behavior to return the actual entry, instead of trying to expand the list of dynamic members. For translucent, the control should return the actual local entry, instead of trying to return the result of merging local and remote data. The use case is the same as for the other overlays - make sure we get actual entries as they are stored in the server, as opposed to some dynamically transformed version of the entries. -- -- 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

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