Re: (ITS#8158) cldap broken for aix and solaris
by goran.hammarback＠foxt.com
On tor, 2015-06-04 at 23:06 +0200, Hallvard Breien Furuseth wrote:
> On 03/06/15 08:47, goran.hammarback(a)foxt.com wrote:
> > Hmm, my fingers thought it was still february. Now I have uploaded a
> > file with the correct name, goran-hammarback-150603.ext.
>
> The date is probably just for disambiguation anyway.
>
> Tweaked it a bit, I expect it should look like this:
> ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-150604.diff
>
> Is there a reason you switched to sizeof(struct sockaddr) from
> sockaddr_storage as the fallback? Otherwise sockaddr_storage
> seems better, since that has presumably worked on most hosts.
> Should only matter if people play tricks like using ldap_init_fd()
> to create an unsupported connection type, e.g. "UDP ldapi://".
Yeah, the fallback... I really did not know what to use there. I knew
sizeof(struct sockaddr_storage) would work on Linux but most likely not
on Solaris and AIX, so I used sizeof(struct sockaddr). Unfortunately I
have no way of testing if that really works at all for any platform so I
guess your way is probably better...
>
> Anyway, please test (or protest if it should be sockaddr).
> The change from your patch may be trivial, but that doesn't
> mean I couldn't have managed to break it:-)
>
> Note that OpenLDAP should be edited with editor tab width =
> indentation = 4. Though some code has been written with
> tab width = 8, so it looks messy either way.
>
Your patch looks fine. I will not have time to test it until next week
earliest. My patch was meant only as an example, so I did not really
think about indentation.
Regards,
/Göran
8 years, 5 months
Re: (ITS#8158) cldap broken for aix and solaris
by h.b.furuseth＠usit.uio.no
On 03/06/15 08:47, goran.hammarback(a)foxt.com wrote:
> Hmm, my fingers thought it was still february. Now I have uploaded a
> file with the correct name, goran-hammarback-150603.ext.
The date is probably just for disambiguation anyway.
Tweaked it a bit, I expect it should look like this:
ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-150604.diff
Is there a reason you switched to sizeof(struct sockaddr) from
sockaddr_storage as the fallback? Otherwise sockaddr_storage
seems better, since that has presumably worked on most hosts.
Should only matter if people play tricks like using ldap_init_fd()
to create an unsupported connection type, e.g. "UDP ldapi://".
Anyway, please test (or protest if it should be sockaddr).
The change from your patch may be trivial, but that doesn't
mean I couldn't have managed to break it:-)
Note that OpenLDAP should be edited with editor tab width =
indentation = 4. Though some code has been written with
tab width = 8, so it looks messy either way.
--
Hallvard
8 years, 5 months
Re: (ITS#8163) Broken handling of deprecated attributes
by michael＠stroeder.com
pierre(a)reactos.org wrote:
> It seems that the SQL backend is indeed responsible for this and
> apparently makes OpenLDAP no longer RFC-compliant.
Simply don't use back-sql.
And next time please provide exact config information.
Ciao, Michael.
8 years, 6 months
Re: (ITS#8163) Broken handling of deprecated attributes
by pierre＠reactos.org
This is a cryptographically signed message in MIME format.
--------------ms010206060101070502000609
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 06/03/2015 03:52 PM, Howard Chu wrote:
> pierre(a)reactos.org wrote:
>> This is a cryptographically signed message in MIME format.
>>
>> --------------ms070202050304000100090907
>> Content-Type: text/plain; charset=3Dwindows-1252
>> Content-Transfer-Encoding: quoted-printable
>>
>> Finally, some more information thanks to the testing env.
>>
>> It seems that the SQL backend is indeed responsible for this and
>> apparently makes OpenLDAP no longer RFC-compliant.
>=20
> back-sql currently has no maintainer and is not recommended for use.
> The primary database backends are back-bdb,hdb, and mdb. All of these
> are RFC-compliant.
Unfortunately, these backends are not matching our use-case...
I'll try to see whether I can (hack)fix it, even though, I'm not used to
LDAP nor to OpenLDAP.
And regarding my previous mail, the failing call is actually the call to
structural_class() at line 1057 of entry-id.
--=20
Pierre Schweitzer <pierre(a)reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
--------------ms010206060101070502000609
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGYTCCBUmgAwIBAgICWQwwDQYJKoZIhvcNAQEL
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xNDExMjQxNjI3Mjda
Fw0xNjExMjQyMDIyMjZaMH4xCzAJBgNVBAYTAkZSMRgwFgYDVQQIEw9IYXV0ZS1Ob3JtYW5k
aWUxFjAUBgNVBAcTDU1vbnRpdmlsbGllcnMxGjAYBgNVBAMTEVBpZXJyZSBTY2h3ZWl0emVy
MSEwHwYJKoZIhvcNAQkBFhJwaWVycmVAcmVhY3Rvcy5vcmcwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQC8SYZrOQ1QDv1kIOpgVq/b7szSPKslgvoWds2XORWlmr1sunnT6rh/
dS49XLFIfvqBtjZJfszA5ISFiI0jvp1kWqM+/DRvTZ+IRVyMtPaRjeAnvuXcjn/ARLzgX41l
Ud1Nvhr3xVUaBczz+PBrYpSiL33q8PWBlmPUB/aFCfiOshZUncf6Oyp6htM/wGYLBYPeYe/N
f/H22oA47gecS5Wklywa7mBdsLzDOkWM+4vtxPUSNcup1wsR/uQiYOLEC6NgjoUH+Io9p5oR
RrTYDjd3sLT+bhLAzBpwkMBa0MlIufzyxMSB2pJO0wj1itVbKORU0ms4lMBiOvpJNxMrS93J
AgMBAAGjggLYMIIC1DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF
BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFBhmqkwsm1WisdrKJVqDH/Xhvm32MB8GA1UdIwQY
MBaAFK5Vg2/sMcq59x36r2sx88gd46y7MB0GA1UdEQQWMBSBEnBpZXJyZUByZWFjdG9zLm9y
ZzCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJo
dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0
ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0aW9uIHJlcXVp
cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0
aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5
IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNv
bS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0
dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAj
BgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEB
ACbcmhzJrkldFMDb4Qb1WXVnDtVJBNJjR/AzTZxc+8r/9UAdxfI4SlYbEXU9cZ/r2JaRXPeh
5A3FEaUOBafRkSwKYfw8XXIIe0q0S8tDJ+uigHChf9HR4YqhqhC+1pfO15YnlyEcRXe5xmHt
lNUyKrVqPEzPus/58i2dprOk2TJpoy3jPkg9Z/S31F9+ipojV7aOkOaEUn+GxAPVRhmbEWqr
c0Vnu45vvgVgXI4TwDCVp7lS9Rl/X/ytEunbC/AXAO4eEDLkkYxMTe8xkbLt39da5nqc0ta+
fsAecskmU8Jg38Xh2Kj5K+3MeKhZFyiLNdr4YKYJuVDFoZ8SWwIROBIxggPaMIID1gIBATCB
kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl
Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJZDDAJBgUrDgMCGgUAoIIC
GzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA2MDMxNDUw
MzZaMCMGCSqGSIb3DQEJBDEWBBSRFGOtquxUAEeY2pce3+qkyzZ+mTBsBgkqhkiG9w0BCQ8x
XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD
VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICWQwwgaYGCyqG
SIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE
AxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAlkM
MA0GCSqGSIb3DQEBAQUABIIBAAQyivx/2JJNvDy+ZH7mOs64BaztLIKVASx0NfEKCSI9oYgC
JAhUTCnNAH++THUb8XcF7G9IG7jdqBLXjajuNtbpoCx/sryAGK+Mtjy+IH4hrhICS/U/rSFt
mClSvauMWjCQIRSUjBH43Otasl2nYoMKznYHd9geeFfZI2QYN3hNf0q60GEHoYbG/YMDj3Fy
iJ9SLbCjCcfYdwdBR+JvJWneuv5fYdViE9bUPbyBLy/6EO/hmN7dvXNyn5DnffiSsIuANyYH
4sScAoXLpfBqVjnWVmb2PjaOJ8l/SxBC1jECdgWZe63oNJN/2eYEdOLFRpEuOIf2/LKDofEQ
Mrj/LLsAAAAAAAA=
--------------ms010206060101070502000609--
8 years, 6 months
Re: (ITS#8163) Broken handling of deprecated attributes
by hyc＠symas.com
pierre(a)reactos.org wrote:
> This is a cryptographically signed message in MIME format.
>
> --------------ms070202050304000100090907
> Content-Type: text/plain; charset=windows-1252
> Content-Transfer-Encoding: quoted-printable
>
> Finally, some more information thanks to the testing env.
>
> It seems that the SQL backend is indeed responsible for this and
> apparently makes OpenLDAP no longer RFC-compliant.
back-sql currently has no maintainer and is not recommended for use.
The primary database backends are back-bdb,hdb, and mdb. All of these are
RFC-compliant.
> You'll find the log extract from the server here:
> https://www3.heisspiter.net/query_uid
> https://www3.heisspiter.net/query_javaRemoteLocation
> https://www3.heisspiter.net/query_javaCodeBase
>
> The first one is the query of the uid attribute which exists and returns
> fine.
> The second one is the query of the javaRemoteLocation attribute which
> doesn't exist and thus, doesn't return fine.
> The third one is the query of the javaCodeBase attribute which exists in
> schema but that we don't use at all but returns fine.
>
> The guilty function *might* be backsql_get_attr_vals() which is the last
> one called, raising the error.
>
> On 06/03/2015 01:47 PM, Pierre Schweitzer wrote:
>> On 06/03/2015 11:47 AM, Michael Str=F6der wrote:
>>> On 2015-06-03 11:20, Pierre Schweitzer wrote:
>>>> This is not a question, but really a bug report about a broken behavi=
> or.
>>>
>>> Again:
>>> I can confirm that requesting an attribute which does not exist in the=
>
>>> subschema does not affect whether an entry is returned.
>>>
>>>> I quote them again: "Potentially, OpenLDAP should have a bug raised t=
> o
>>>> make it impossible to get into a situation where error 65 is returned=
> on
>>>> a query, as it likely does not conform to the RFC."
>>>
>>> Again: This statement is right and AFACIS OpenLDAP always worked corre=
> ctly.
>> =20
>> OK, so you confirm that what we see here is an incorrect behavior.
>> =20
>>>> Here is the log extract you're asking for (I just filtered out the
>>>> base DN):
>>>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH base=3D=
> "XXXX"
>>>> scope=3D2 deref=3D0 filter=3D"(&(objectClass=3DinetOrgPerson)(uid=3Dh=
> eis spiter))"
>>>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH
>>>> attr=3DjavaRemoteLocation
>>>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SEARCH RESU=
> LT
>>>> tag=3D101 err=3D65 nentries=3D0 text=3D
>>>
>>> Up to now there's absolutely no evidence in the information you provid=
> ed
>>> that this is a bug.
>>>
>>> How did you make sure that an entry should be returned for exactly thi=
> s
>>> search with the bound identity and your configuration?
>>>
>>> I suspect a configuration or data error on your side. Many things can =
> be
>>> wrong.
>>> Without seeing your config, data and the bound identity nobody can
>>> track this down for you.
>> =20
>> One technical information that would make sense: we are using the SQL
>> backend. I've just checked, there's some attributes management in
>> backend code, and the issue *may* come from this.
>> The Atlassian support cannot reproduce the error with "out-of-the-box"
>> OpenLDAP server not using SQL backend.
>> =20
>> I will setup a dedicated test env for this issue so that I can more
>> easily track & debug the issue. I'll come back at you when I've more
>> information (or even a patch).
>> =20
>
>
> --=20
> Pierre Schweitzer <pierre(a)reactos.org>
> System & Network Administrator
> Senior Kernel Developer
> ReactOS Deutschland e.V.
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years, 6 months
Re: (ITS#8163) Broken handling of deprecated attributes
by pierre＠reactos.org
This is a cryptographically signed message in MIME format.
--------------ms070202050304000100090907
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Finally, some more information thanks to the testing env.
It seems that the SQL backend is indeed responsible for this and
apparently makes OpenLDAP no longer RFC-compliant.
You'll find the log extract from the server here:
https://www3.heisspiter.net/query_uid
https://www3.heisspiter.net/query_javaRemoteLocation
https://www3.heisspiter.net/query_javaCodeBase
The first one is the query of the uid attribute which exists and returns
fine.
The second one is the query of the javaRemoteLocation attribute which
doesn't exist and thus, doesn't return fine.
The third one is the query of the javaCodeBase attribute which exists in
schema but that we don't use at all but returns fine.
The guilty function *might* be backsql_get_attr_vals() which is the last
one called, raising the error.
On 06/03/2015 01:47 PM, Pierre Schweitzer wrote:
> On 06/03/2015 11:47 AM, Michael Str=F6der wrote:
>> On 2015-06-03 11:20, Pierre Schweitzer wrote:
>>> This is not a question, but really a bug report about a broken behavi=
or.
>>
>> Again:
>> I can confirm that requesting an attribute which does not exist in the=
>> subschema does not affect whether an entry is returned.
>>
>>> I quote them again: "Potentially, OpenLDAP should have a bug raised t=
o
>>> make it impossible to get into a situation where error 65 is returned=
on
>>> a query, as it likely does not conform to the RFC."
>>
>> Again: This statement is right and AFACIS OpenLDAP always worked corre=
ctly.
>=20
> OK, so you confirm that what we see here is an incorrect behavior.
>=20
>>> Here is the log extract you're asking for (I just filtered out the
>>> base DN):
>>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH base=3D=
"XXXX"
>>> scope=3D2 deref=3D0 filter=3D"(&(objectClass=3DinetOrgPerson)(uid=3Dh=
eis spiter))"
>>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH
>>> attr=3DjavaRemoteLocation
>>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SEARCH RESU=
LT
>>> tag=3D101 err=3D65 nentries=3D0 text=3D
>>
>> Up to now there's absolutely no evidence in the information you provid=
ed
>> that this is a bug.
>>
>> How did you make sure that an entry should be returned for exactly thi=
s
>> search with the bound identity and your configuration?
>>
>> I suspect a configuration or data error on your side. Many things can =
be
>> wrong.
>> Without seeing your config, data and the bound identity nobody can
>> track this down for you.
>=20
> One technical information that would make sense: we are using the SQL
> backend. I've just checked, there's some attributes management in
> backend code, and the issue *may* come from this.
> The Atlassian support cannot reproduce the error with "out-of-the-box"
> OpenLDAP server not using SQL backend.
>=20
> I will setup a dedicated test env for this issue so that I can more
> easily track & debug the issue. I'll come back at you when I've more
> information (or even a patch).
>=20
--=20
Pierre Schweitzer <pierre(a)reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
--------------ms070202050304000100090907
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGYTCCBUmgAwIBAgICWQwwDQYJKoZIhvcNAQEL
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xNDExMjQxNjI3Mjda
Fw0xNjExMjQyMDIyMjZaMH4xCzAJBgNVBAYTAkZSMRgwFgYDVQQIEw9IYXV0ZS1Ob3JtYW5k
aWUxFjAUBgNVBAcTDU1vbnRpdmlsbGllcnMxGjAYBgNVBAMTEVBpZXJyZSBTY2h3ZWl0emVy
MSEwHwYJKoZIhvcNAQkBFhJwaWVycmVAcmVhY3Rvcy5vcmcwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQC8SYZrOQ1QDv1kIOpgVq/b7szSPKslgvoWds2XORWlmr1sunnT6rh/
dS49XLFIfvqBtjZJfszA5ISFiI0jvp1kWqM+/DRvTZ+IRVyMtPaRjeAnvuXcjn/ARLzgX41l
Ud1Nvhr3xVUaBczz+PBrYpSiL33q8PWBlmPUB/aFCfiOshZUncf6Oyp6htM/wGYLBYPeYe/N
f/H22oA47gecS5Wklywa7mBdsLzDOkWM+4vtxPUSNcup1wsR/uQiYOLEC6NgjoUH+Io9p5oR
RrTYDjd3sLT+bhLAzBpwkMBa0MlIufzyxMSB2pJO0wj1itVbKORU0ms4lMBiOvpJNxMrS93J
AgMBAAGjggLYMIIC1DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF
BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFBhmqkwsm1WisdrKJVqDH/Xhvm32MB8GA1UdIwQY
MBaAFK5Vg2/sMcq59x36r2sx88gd46y7MB0GA1UdEQQWMBSBEnBpZXJyZUByZWFjdG9zLm9y
ZzCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJo
dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0
ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0aW9uIHJlcXVp
cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0
aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5
IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNv
bS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0
dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAj
BgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEB
ACbcmhzJrkldFMDb4Qb1WXVnDtVJBNJjR/AzTZxc+8r/9UAdxfI4SlYbEXU9cZ/r2JaRXPeh
5A3FEaUOBafRkSwKYfw8XXIIe0q0S8tDJ+uigHChf9HR4YqhqhC+1pfO15YnlyEcRXe5xmHt
lNUyKrVqPEzPus/58i2dprOk2TJpoy3jPkg9Z/S31F9+ipojV7aOkOaEUn+GxAPVRhmbEWqr
c0Vnu45vvgVgXI4TwDCVp7lS9Rl/X/ytEunbC/AXAO4eEDLkkYxMTe8xkbLt39da5nqc0ta+
fsAecskmU8Jg38Xh2Kj5K+3MeKhZFyiLNdr4YKYJuVDFoZ8SWwIROBIxggPaMIID1gIBATCB
kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl
Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJZDDAJBgUrDgMCGgUAoIIC
GzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA2MDMxMzQ2
MDJaMCMGCSqGSIb3DQEJBDEWBBSHoP2De9oU79PXJaHQD9IpiZL8qzBsBgkqhkiG9w0BCQ8x
XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD
VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICWQwwgaYGCyqG
SIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE
AxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAlkM
MA0GCSqGSIb3DQEBAQUABIIBAFgpMpCiNM/4e08hDdW/oRsHrkANq/2HsHBEuy4TwFiM908q
S+MejeopEgKkZwqvRw5nR849PQzw15CFjm3/vwzbFc963Vz76SZlkpvAPsRas+34qH2Xs2r3
IiHs4BWSFxJj/IphDoQpaPcCaKCC8BzI4a1rvSO7g6G8n5WdtgZK/acsj3+ai71iuPE6N3js
+ErRqHwvlReJhWED8a0ZrSrJ9ZMf+ULr+D8Jv0WWt1mDnPfUXm8jVATfM82f3q8RHfCsEXfm
jjn1laAUkdY+FR0A14PfV9rFjgWOsNS4vhT3smqCELXAcIoqF6h6TIoZi1qgr2kHl/rmsJIz
tP/VPb4AAAAAAAA=
--------------ms070202050304000100090907--
8 years, 6 months
Re: (ITS#8163) Broken handling of deprecated attributes
by pierre＠reactos.org
This is a cryptographically signed message in MIME format.
--------------ms020405000401010508050306
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 06/03/2015 11:47 AM, Michael Str=F6der wrote:
> On 2015-06-03 11:20, Pierre Schweitzer wrote:
>> This is not a question, but really a bug report about a broken behavio=
r.
>=20
> Again:
> I can confirm that requesting an attribute which does not exist in the
> subschema does not affect whether an entry is returned.
>=20
>> I quote them again: "Potentially, OpenLDAP should have a bug raised to=
>> make it impossible to get into a situation where error 65 is returned =
on
>> a query, as it likely does not conform to the RFC."
>=20
> Again: This statement is right and AFACIS OpenLDAP always worked correc=
tly.
OK, so you confirm that what we see here is an incorrect behavior.
>> Here is the log extract you're asking for (I just filtered out the
>> base DN):
>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH base=3D=
"XXXX"
>> scope=3D2 deref=3D0 filter=3D"(&(objectClass=3DinetOrgPerson)(uid=3Dhe=
is spiter))"
>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH
>> attr=3DjavaRemoteLocation
>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SEARCH RESUL=
T
>> tag=3D101 err=3D65 nentries=3D0 text=3D
>=20
> Up to now there's absolutely no evidence in the information you provide=
d
> that this is a bug.
>=20
> How did you make sure that an entry should be returned for exactly this=
> search with the bound identity and your configuration?
>=20
> I suspect a configuration or data error on your side. Many things can b=
e
> wrong.
> Without seeing your config, data and the bound identity nobody can
> track this down for you.
One technical information that would make sense: we are using the SQL
backend. I've just checked, there's some attributes management in
backend code, and the issue *may* come from this.
The Atlassian support cannot reproduce the error with "out-of-the-box"
OpenLDAP server not using SQL backend.
I will setup a dedicated test env for this issue so that I can more
easily track & debug the issue. I'll come back at you when I've more
information (or even a patch).
--=20
Pierre Schweitzer <pierre(a)reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
--------------ms020405000401010508050306
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGYTCCBUmgAwIBAgICWQwwDQYJKoZIhvcNAQEL
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xNDExMjQxNjI3Mjda
Fw0xNjExMjQyMDIyMjZaMH4xCzAJBgNVBAYTAkZSMRgwFgYDVQQIEw9IYXV0ZS1Ob3JtYW5k
aWUxFjAUBgNVBAcTDU1vbnRpdmlsbGllcnMxGjAYBgNVBAMTEVBpZXJyZSBTY2h3ZWl0emVy
MSEwHwYJKoZIhvcNAQkBFhJwaWVycmVAcmVhY3Rvcy5vcmcwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQC8SYZrOQ1QDv1kIOpgVq/b7szSPKslgvoWds2XORWlmr1sunnT6rh/
dS49XLFIfvqBtjZJfszA5ISFiI0jvp1kWqM+/DRvTZ+IRVyMtPaRjeAnvuXcjn/ARLzgX41l
Ud1Nvhr3xVUaBczz+PBrYpSiL33q8PWBlmPUB/aFCfiOshZUncf6Oyp6htM/wGYLBYPeYe/N
f/H22oA47gecS5Wklywa7mBdsLzDOkWM+4vtxPUSNcup1wsR/uQiYOLEC6NgjoUH+Io9p5oR
RrTYDjd3sLT+bhLAzBpwkMBa0MlIufzyxMSB2pJO0wj1itVbKORU0ms4lMBiOvpJNxMrS93J
AgMBAAGjggLYMIIC1DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF
BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFBhmqkwsm1WisdrKJVqDH/Xhvm32MB8GA1UdIwQY
MBaAFK5Vg2/sMcq59x36r2sx88gd46y7MB0GA1UdEQQWMBSBEnBpZXJyZUByZWFjdG9zLm9y
ZzCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJo
dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0
ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0aW9uIHJlcXVp
cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0
aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5
IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNv
bS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0
dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAj
BgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEB
ACbcmhzJrkldFMDb4Qb1WXVnDtVJBNJjR/AzTZxc+8r/9UAdxfI4SlYbEXU9cZ/r2JaRXPeh
5A3FEaUOBafRkSwKYfw8XXIIe0q0S8tDJ+uigHChf9HR4YqhqhC+1pfO15YnlyEcRXe5xmHt
lNUyKrVqPEzPus/58i2dprOk2TJpoy3jPkg9Z/S31F9+ipojV7aOkOaEUn+GxAPVRhmbEWqr
c0Vnu45vvgVgXI4TwDCVp7lS9Rl/X/ytEunbC/AXAO4eEDLkkYxMTe8xkbLt39da5nqc0ta+
fsAecskmU8Jg38Xh2Kj5K+3MeKhZFyiLNdr4YKYJuVDFoZ8SWwIROBIxggPaMIID1gIBATCB
kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl
Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJZDDAJBgUrDgMCGgUAoIIC
GzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA2MDMxMTQ3
MzhaMCMGCSqGSIb3DQEJBDEWBBQzjI2ph1YSdmtimunu50JmlPABvTBsBgkqhkiG9w0BCQ8x
XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD
VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICWQwwgaYGCyqG
SIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE
AxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAlkM
MA0GCSqGSIb3DQEBAQUABIIBABjJHLdvcE2ADkK1Fkr1+UA431l3bLVA7qOJyXcfuBIk5wRd
nRwlEeA39IRJc4m8lDO2OV7sZt99aTp5z4LC1Z5mfN0s3I9VBZRDvjFgx+oYAqnuoq19eoM0
Tc9VHtDL8hG1mrohtDtPLe6n5yJrTBugBQN7BHPHJL2c3S8/7CJdfWlJOZRwvnxh73Q8KVUD
3rEGfFa0K4JVBhaolSAXcGX1QSKvbb7utDuw7JbnOjNocFv4zIunJO4z23VJbyQ59Tjb1pbl
qEf7b4GFweA6Xkey1TCs6BcscxJEYSvyT0uv9zt/m6fJLkRED88Jxs0wVfyIHDNOhI4HI54/
LPIXytYAAAAAAAA=
--------------ms020405000401010508050306--
8 years, 6 months
Re: (ITS#8163) Broken handling of deprecated attributes
by michael＠stroeder.com
On 2015-06-03 11:20, Pierre Schweitzer wrote:
> This is not a question, but really a bug report about a broken
> behavior.
Again:
I can confirm that requesting an attribute which does not exist in the
subschema does not affect whether an entry is returned.
> I quote them again: "Potentially, OpenLDAP should have a bug raised to
> make it impossible to get into a situation where error 65 is returned
> on
> a query, as it likely does not conform to the RFC."
Again: This statement is right and AFACIS OpenLDAP always worked
correctly.
> Here is the log extract you're asking for (I just filtered out the base
> DN):
> Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SRCH base="XXXX"
> scope=2 deref=0 filter="(&(objectClass=inetOrgPerson)(uid=heis
> spiter))"
> Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SRCH
> attr=javaRemoteLocation
> Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SEARCH RESULT
> tag=101 err=65 nentries=0 text=
Up to now there's absolutely no evidence in the information you provided
that this is a bug.
How did you make sure that an entry should be returned for exactly this
search with the bound identity and your configuration?
I suspect a configuration or data error on your side. Many things can be
wrong.
Without seeing your config, data and the bound identity nobody can
track this down for you.
Ciao, Michael.
8 years, 6 months
Re: (ITS#8163) Broken handling of deprecated attributes
by pierre＠reactos.org
This is a cryptographically signed message in MIME format.
--------------ms070206080505050308030000
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
This is not a question, but really a bug report about a broken behavior.
I quote them again: "Potentially, OpenLDAP should have a bug raised to
make it impossible to get into a situation where error 65 is returned on
a query, as it likely does not conform to the RFC."
Here is the log extract you're asking for (I just filtered out the base D=
N):
Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH base=3D"XX=
XX"
scope=3D2 deref=3D0 filter=3D"(&(objectClass=3DinetOrgPerson)(uid=3Dheis =
spiter))"
Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH
attr=3DjavaRemoteLocation
Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SEARCH RESULT
tag=3D101 err=3D65 nentries=3D0 text=3D
On 06/03/2015 11:10 AM, Michael Str=F6der wrote:
> First, the issue tracker is not for usage questions. Please redirect
> your question to openldap-technical mailing list.
>=20
> On 2015-06-03 10:47, pierre(a)reactos.org wrote:
>> Unfortunately, javaRemoteLocation isn't in java.schema and appears to =
be
>> deprecated.
>>
>> OpenLDAP replies with (ldapsearch result):
>> # search result
>> search: 2
>> result: 65 Object class viatation
>> Seen from OpenLDAP logs:
>> Apr 22 13:09:27 rose-java slapd[25272]: conn=3D1177 op=3D2 SEARCH RESU=
LT
>> tag=3D101
>> err=3D65 nentries=3D0 text=3D
>>
>> According to Jira support, this is an incorrect behavior from
>> OpenLDAP, not
>> matching the LDAP RFCs. Quoting them: "OpenLDAP should not be
>> returning an error
>> when querying for javaRemoteLocation, even if it is deprecated."
>=20
> I can confirm that OpenLDAP works correctly in this regard.
> You did not post the accompanying SEARCH log line with filter and scope=
=2E
> You should check that.
>=20
> Ciao, Michael.
>=20
--=20
Pierre Schweitzer <pierre(a)reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
--------------ms070206080505050308030000
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGYTCCBUmgAwIBAgICWQwwDQYJKoZIhvcNAQEL
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xNDExMjQxNjI3Mjda
Fw0xNjExMjQyMDIyMjZaMH4xCzAJBgNVBAYTAkZSMRgwFgYDVQQIEw9IYXV0ZS1Ob3JtYW5k
aWUxFjAUBgNVBAcTDU1vbnRpdmlsbGllcnMxGjAYBgNVBAMTEVBpZXJyZSBTY2h3ZWl0emVy
MSEwHwYJKoZIhvcNAQkBFhJwaWVycmVAcmVhY3Rvcy5vcmcwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQC8SYZrOQ1QDv1kIOpgVq/b7szSPKslgvoWds2XORWlmr1sunnT6rh/
dS49XLFIfvqBtjZJfszA5ISFiI0jvp1kWqM+/DRvTZ+IRVyMtPaRjeAnvuXcjn/ARLzgX41l
Ud1Nvhr3xVUaBczz+PBrYpSiL33q8PWBlmPUB/aFCfiOshZUncf6Oyp6htM/wGYLBYPeYe/N
f/H22oA47gecS5Wklywa7mBdsLzDOkWM+4vtxPUSNcup1wsR/uQiYOLEC6NgjoUH+Io9p5oR
RrTYDjd3sLT+bhLAzBpwkMBa0MlIufzyxMSB2pJO0wj1itVbKORU0ms4lMBiOvpJNxMrS93J
AgMBAAGjggLYMIIC1DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF
BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFBhmqkwsm1WisdrKJVqDH/Xhvm32MB8GA1UdIwQY
MBaAFK5Vg2/sMcq59x36r2sx88gd46y7MB0GA1UdEQQWMBSBEnBpZXJyZUByZWFjdG9zLm9y
ZzCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJo
dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0
ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0aW9uIHJlcXVp
cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0
aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5
IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNv
bS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0
dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAj
BgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEB
ACbcmhzJrkldFMDb4Qb1WXVnDtVJBNJjR/AzTZxc+8r/9UAdxfI4SlYbEXU9cZ/r2JaRXPeh
5A3FEaUOBafRkSwKYfw8XXIIe0q0S8tDJ+uigHChf9HR4YqhqhC+1pfO15YnlyEcRXe5xmHt
lNUyKrVqPEzPus/58i2dprOk2TJpoy3jPkg9Z/S31F9+ipojV7aOkOaEUn+GxAPVRhmbEWqr
c0Vnu45vvgVgXI4TwDCVp7lS9Rl/X/ytEunbC/AXAO4eEDLkkYxMTe8xkbLt39da5nqc0ta+
fsAecskmU8Jg38Xh2Kj5K+3MeKhZFyiLNdr4YKYJuVDFoZ8SWwIROBIxggPaMIID1gIBATCB
kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl
Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJZDDAJBgUrDgMCGgUAoIIC
GzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA2MDMwOTIw
MjhaMCMGCSqGSIb3DQEJBDEWBBTFhaO7mcYjpu+GXnROB2MNF4mLfzBsBgkqhkiG9w0BCQ8x
XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD
VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICWQwwgaYGCyqG
SIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE
AxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAlkM
MA0GCSqGSIb3DQEBAQUABIIBAGI6hgTKBlf8Gwp6s8GlntzWbcLsnW4MJIkZL78xFxsxhH1V
epkKWwaHp++rHI56hSFa8M7ZM9+vJyGotoLB4gNBrUIEfb8ZzelD8JxqkAvJvfCALVyJ9DVP
hQWaW6i2HU4zjt6Ol4zadY+6GyCjkndjOC9tbnRGNaNIxcaGXjeVPOcZDC+ZMN0OpEVw0AoT
JoUZO8imWacPWtx7nH4MbtmhDBDH/4eHplROBHvP+ABvwYoqpGuc+O11hiabvN+hsOSsGdmX
BSuCev4YSSCTrBER6gWEaeZlTqN9XfHjmdf7B9onPo5XkclqvTDfNV/ZZSTU4Buj2LmJ4bGe
9gFqkIIAAAAAAAA=
--------------ms070206080505050308030000--
8 years, 6 months
Re: (ITS#8163) Broken handling of deprecated attributes
by michael＠stroeder.com
First, the issue tracker is not for usage questions. Please redirect
your question to openldap-technical mailing list.
On 2015-06-03 10:47, pierre(a)reactos.org wrote:
> Unfortunately, javaRemoteLocation isn't in java.schema and appears to
> be
> deprecated.
>
> OpenLDAP replies with (ldapsearch result):
> # search result
> search: 2
> result: 65 Object class viatation
> Seen from OpenLDAP logs:
> Apr 22 13:09:27 rose-java slapd[25272]: conn=1177 op=2 SEARCH RESULT
> tag=101
> err=65 nentries=0 text=
>
> According to Jira support, this is an incorrect behavior from OpenLDAP,
> not
> matching the LDAP RFCs. Quoting them: "OpenLDAP should not be returning
> an error
> when querying for javaRemoteLocation, even if it is deprecated."
I can confirm that OpenLDAP works correctly in this regard.
You did not post the accompanying SEARCH log line with filter and scope.
You should check that.
Ciao, Michael.
8 years, 6 months