openldap-bugs April 2012

openldap-bugs@openldap.org

36 participants
172 discussions

Re: ITS#7239: testbed
by masarati＠aero.polimi.it 18 Apr '12

18 Apr '12

>> Thanks. The explanation is always simple, after one finds it. The DN >> of >> accesslog entries is generated using the reqStart AVA. When logops all >> and internal operations take place, multiple entries are generated with >> the same reqStart AVA. So an internal search which is logged because of >> some overlay eats up the DN of the modrdn, and be_add() called by >> slapo-accesslog(5) fails because the entry already exists. >> >> Although logging internal entries could be of some use, I see two >> solutions: >> >> - modify the value of reqStart (e.g. instead of using o_tincr for the >> fractional part of the timestamp, we could use an incremental counter >> initialized with o_tincr and incremented at each logging within the same >> operation. The counter could be stored somewhere in the operation >> structure (e.g. in o_extra) >> >> - prevent logging of internal ops; again, this could be achieved by >> setting a dedicated o_internal_op field in the Operation structure. >> >> Since this modification could be intrusive, I'd like to gather some >> comments before proceeding with a fix. > > Hm, we've run into this similar problem before with syncprov and > introduced > op->o_dont_replicate. As a general rule, accesslog is meant to log user > operations, not internal operations. Currently accesslog checks > (op->o_dont_replicate && op->orm_no_opattrs) to skip logging of write ops. > I > guess we need a more general flag instead. A definitive and simple solution, although invasive, would be to: - add a o_internal flag to the Operation structure - add a macro BE_INTERNAL(op, rs, op_type) like #define BE_INTERNAL(op, rs, op_type, rcp) \ { int save_o_internal = op->o_internal; op->o_internal = 1; *rcp = (&op->o_bd->bi_info->bi_op_bind)[op_type]( op, rs ); op->o_internal = save_o_internal; } fix all calls to internal operations (brrr....) p.

1 0

(ITS#7251) MDB shared mutexes ambiguous on Apple/Windows
by hyc＠OpenLDAP.org 18 Apr '12

18 Apr '12

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.151.244.127) Submitted by: hyc Currently since MacOSX and Windows don't support process-shared mutexes residing in shared memory, MDB uses global named semaphores instead on these platforms. The semaphore name is derived from a hash of the pathname of the lock file. This approach was quick and dirty and is prone to failure if relative paths and absolute paths are mixed, or if a file can be accessed thru multiple paths (e.g. symlinks, loopback mounts, whatever). Instead of the pathname, a unique file identifier of the lock file should be used. For MacOSX we can obtain (device,inode) using fstat(). For Windows we can obtain (dwVolumeSerialNumber,nFileIndexLow,nFileIndexHigh) using GetFileInformationByHandle().

1 0

Re: ITS#7239: testbed
by hyc＠symas.com 18 Apr '12

18 Apr '12

masarati(a)aero.polimi.it wrote: >> This is a cryptographically signed message in MIME format. >> >> --------------ms020801020604080509050502 >> Content-Type: text/plain; charset=ISO-8859-15 >> Content-Transfer-Encoding: quoted-printable >> >> masarati(a)aero.polimi.it wrote: >>> =20 >>> The attachment is unreadable; can you ftp it somewhere? Thanks, p. >> >> http://www.stroeder.com/temp/openldap-testbed-its7239.tar.bz2 > > Thanks. The explanation is always simple, after one finds it. The DN of > accesslog entries is generated using the reqStart AVA. When logops all > and internal operations take place, multiple entries are generated with > the same reqStart AVA. So an internal search which is logged because of > some overlay eats up the DN of the modrdn, and be_add() called by > slapo-accesslog(5) fails because the entry already exists. > > Although logging internal entries could be of some use, I see two solutions: > > - modify the value of reqStart (e.g. instead of using o_tincr for the > fractional part of the timestamp, we could use an incremental counter > initialized with o_tincr and incremented at each logging within the same > operation. The counter could be stored somewhere in the operation > structure (e.g. in o_extra) > > - prevent logging of internal ops; again, this could be achieved by > setting a dedicated o_internal_op field in the Operation structure. > > Since this modification could be intrusive, I'd like to gather some > comments before proceeding with a fix. Hm, we've run into this similar problem before with syncprov and introduced op->o_dont_replicate. As a general rule, accesslog is meant to log user operations, not internal operations. Currently accesslog checks (op->o_dont_replicate && op->orm_no_opattrs) to skip logging of write ops. I guess we need a more general flag instead. -- -- 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#7239: testbed
by masarati＠aero.polimi.it 18 Apr '12

18 Apr '12

> This is a cryptographically signed message in MIME format. > > --------------ms020801020604080509050502 > Content-Type: text/plain; charset=ISO-8859-15 > Content-Transfer-Encoding: quoted-printable > > masarati(a)aero.polimi.it wrote: >>=20 >> The attachment is unreadable; can you ftp it somewhere? Thanks, p. > > http://www.stroeder.com/temp/openldap-testbed-its7239.tar.bz2 Thanks. The explanation is always simple, after one finds it. The DN of accesslog entries is generated using the reqStart AVA. When logops all and internal operations take place, multiple entries are generated with the same reqStart AVA. So an internal search which is logged because of some overlay eats up the DN of the modrdn, and be_add() called by slapo-accesslog(5) fails because the entry already exists. Although logging internal entries could be of some use, I see two solutions: - modify the value of reqStart (e.g. instead of using o_tincr for the fractional part of the timestamp, we could use an incremental counter initialized with o_tincr and incremented at each logging within the same operation. The counter could be stored somewhere in the operation structure (e.g. in o_extra) - prevent logging of internal ops; again, this could be achieved by setting a dedicated o_internal_op field in the Operation structure. Since this modification could be intrusive, I'd like to gather some comments before proceeding with a fix. p.

1 0

Re: ITS#7239: testbed
by michael＠stroeder.com 18 Apr '12

18 Apr '12

This is a cryptographically signed message in MIME format. --------------ms020801020604080509050502 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable masarati(a)aero.polimi.it wrote: >=20 > The attachment is unreadable; can you ftp it somewhere? Thanks, p. http://www.stroeder.com/temp/openldap-testbed-its7239.tar.bz2 --------------ms020801020604080509050502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxODIwNTAyOFowIwYJKoZIhvcNAQkEMRYE FO5TfD14PMXVNCzh4rtO6MQEgfVNMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAWC2ZU3Z19tk5FafFmH93ox5VIq85YoZoKvQEjiZC/aWis578hUnfkJXS/Dh+Ltt+dyj/ t3DzDSlJHBbvjyAoReVO54SwPKpJZE8SadEXNLK31Cs6J0QJFHt3gW9nW2wr/sXcNnLHqxxm fq8Ofn3ztGC5bxBa2BYTKGq/23Oa6zDK/5GfG7BTw4KZ4JlpGat0/12z9oqDgNkYCEEHFmVa bXNGpFnV5e0+ngjIqBvdRt80iuV9et3vXRBWrJWJMC0uA5NfKWldOh3Ov4WL/GKl2PtCWRo0 Q3twLoa88WPMWDdZzKeKRLvxQxMtYCh2ZIk74aNAATNXPznIDyMnlWPqOAAAAAAAAA== --------------ms020801020604080509050502--

1 0

Re: ITS#7239: testbed
by masarati＠aero.polimi.it 18 Apr '12

18 Apr '12

The attachment is unreadable; can you ftp it somewhere? Thanks, p.

1 0

ITS#7239: testbed
by michael＠stroeder.com 18 Apr '12

18 Apr '12

This is a multi-part message in MIME format. --------------000704030300080804030201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit See openldap-testbed-its7239.tar.bz2 attached. You have to adjust paths in the config of course. ldapadd -H ldap://localhost:2071 \ -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret \ -f initial.ldif ldapadd -H ldap://localhost:2071 \ -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret \ -f modrdn.ldif Now look at the accesslog DB: ldapsearch -x -H ldap://localhost:2071 -b cn=accesslog -s one "(objectClass=auditModRDN)" => no results. Now repeat that with "logops writes" instead of "logops all": rm db/*/* ldapadd... ldapmodify... $ ldapsearch -x -H ldap://localhost:2071 -b cn=accesslog -s one "(objectClass=auditModRDN)" # extended LDIF # # LDAPv3 # base <cn=accesslog> with scope oneLevel # filter: (objectClass=auditModRDN) # requesting: ALL # # 20120418194545.000001Z, accesslog dn: reqStart=20120418194545.000001Z,cn=accesslog objectClass: auditModRDN reqStart: 20120418194545.000001Z reqEnd: 20120418194545.000002Z reqType: modrdn reqSession: 1001 reqAuthzID: uid=diradm,ou=schulung,dc=stroeder,dc=local reqDN: uid=test1,ou=schulung,dc=stroeder,dc=local reqResult: 0 reqMod: entryCSN:= 20120418194545.412289Z#000000#000#000000 reqMod: modifiersName:= uid=diradm,ou=schulung,dc=stroeder,dc=local reqMod: modifyTimestamp:= 20120418194545Z reqNewRDN: uid=test2 reqDeleteOldRDN: TRUE reqEntryUUID: 86014e61-7c47-4062-931f-39526f738016 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 --------------000704030300080804030201 Content-Type: application/x-bzip2; name="openldap-testbed-its7239.tar.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="openldap-testbed-its7239.tar.bz2" QlpoOTFBWSZTWUmYCwUAHGV/pf7wIiB//////+///v////4AQEABQAAACGAYTc+5LsPvZ6D5 S0u9988PvuzvWcErt3vmfHtqpub6fXnZrqotFaNWzWqBSlaalKe2+3rXQclH00F7PXeEkhBG mIU9pMnpMTRT8ieptUep6ZTyjaTNQep6mnqPUwmmgeobU0yHqCSITEAJpKeanqbSpptG0j1G iDaTxTQep6hhAMaNAgMQBiJqZBU2p6g9qjRo9QGmajQBoaABoAAZAaAaaDCTUiECRmk9KP0R ogyNNDIekMmgGjQAA0AGmgAEVET1CmnjU0mhiab1TENMmTJkMgyDaIPU0NGIeoMQGjAkSCAE ARkI0yaT0A0KnkhsoaHqaBoNNGQaGgAPShWelmPPk8yZHbmS0CkHt1gnOGQDrIJCM+7nzfOc Z72Sqn4gqiDACCJRBhlQZGTF3hTvhTvZsGMJikIgTnLCIQGUJJIZUVEREUIJEJ3/vXuwnL7p h3znhR3iv2MqIbboLeIBa0NpJjEKAunYNEppc/8z2oXvOhXcOtedrYOHXT4cOK+BIpwcvGhh 3rpNlphr7KbU4qZBqPd5JTP4b5kzQsRFrYeTYoyPyO2pMXZeuz3bMfqwXrYiphmDAdn3jf+O qu/IsCyfb+1mfpLOPWlcNDaA2J95Jrz8+3sfZOWNO7R9/fXyupdZdO27I5jOHhB4NNpNtMsj 3eQM98bZDYslevmFrskMW6HaOzD3qoqlC/zVcT/aUU2KORwxAnm50pFOzZbZqCFbDKcVOyWC lHkKw+R2kr0ZbuEjc2mVeLq69FdhfdFiC08bNU1Azp2+uPze6MAxeP5Ll2vd7SO4JxeO6fCQ jeAwGqU3mugGJ6g6TI82RW0Z0ehKN+Dm9RmdFORarbZkLW0xmfbq9mHPbZl/xsI8ZhSzlsPo JMSEH0ZqDugLWjzoTQghG4wFUhiGcVicNgXpyDAhYPoSZgqkT4zA5QWBQ1EtyVOi79Orq4m8 26fG2+bvViPZTLw+GqXWeFK98VtI8mG38E38EC/H9aYxChiGNTQtqf64f2g11kkgmJ7zbgT4 ++vXWu17abfMoXxNUh4Q2gQhTxw0aURDyMaKROl4U4w4bT072Vhso7qWsOMXF7+pIMPsHQE2 r8TqlkfLIXuKn5zSCDE+nX4eesv9xhEz3Skw458ZIfd3Ekc4IwHyKBcEl+nvrv+dFLkcsydz DGkDrBP1WcfzmZSofJoL77NROzH25fZH13e8Wt/I0I45rlhL09SsK2TIL+cHvlx+JMxYYhjx lLHixxdze1zRXjdw0Ia5T2DYfWcTI9JYHxRXXrxE69qnPFsYWUNFZE02shprwKa1+bGyBtJ4 MWWubpGPnILszMj24321nWdN/a2zO5np27zmuibmxyTkOKuic8s7eC8SoHOb3wYZOHJb4OfL DGYWxt037dQqLa7hql0EBcZ4E/5zLurQ1Y4u9HdoZG6K7lePA8dbMe2BbrsG12cdoX2rYa9s 7zu6i2K2naGeGebxh5i7LRdunRDgrkRYUto+yeJSgykk3ulSGTy4XGXCPMo6+6tnnOOWGSwZ jGnfWRkdlxFweYw5C9LXKtvHbJeRsGfBnJbFtp3iJIEGbd3opT0RGKq2HBIGxRyl+zFLXtvV Z/5bdCW/ZIz5bB1dxotZoXnZ3XSMEwLdakUtJULO7NTVWcsSTnuZMmplpyYJI4iQJccNiiP0 nDuSST7zyjAX/EzxqK8tmedVfcEKqn1pD/UgsCLAgLAUIcsFfDFWIrACoCkmBG7Wybdrq42H Iptw6k2jiRJFemKBLGK5iy/fhg8M1zhMFoTG9HLFofMpI0ENdP6Wz6PBUt6BAB822kqtrN9W NzLrhTdRp8164pkzLVvMwsoOALx/JdV8cNs/gqIbufg8vXf1rv79IHwys9CJulGHpPhhzyT0 er2NM3iursXVdQtfwmC4VEVTnX2wpGFIzS0QrYZs7rVnvS4jTLppJX2pzSWj2uLm5yoS0pL0 efh4DzfjBeWMj6WJi1oVv0FVvwdx/iJjn2BFrygHR9EARWCDdLmkcT2EI3jOJJ9OaOylyRQQ A2zn9xO6xnsIRSWtBglmZyjbfsxz5i9ekNi+SQQoYJsfkAiIckIgKuEKovIDwSAkheN6Z5zy XhL2qQIMxNkkSAQxNo/G9Tw70sFmRyhGO/m3a05XdH67x++8Oh21wKRnoqZdP5Zauj8X4wYw fT00Pws13lqHUB+P3tEKb1qn9W5KdGbeAjelKQF96DQnYFUNNDWXXJWITNGsKU16eYNtLHjB ZGEhYoGV8ULrfPA5oEw4gd3s/oPdWwSSN6IE06OY9dgHaJTgkGFRSSQgJCbbQqeSSHX1YeX9 9/P1dU6StjJDFxVPETsTfDZObiu6RfrIKnC+CRa5j6+O8lhfZzt/vJx+LOOtf0Wu+WR7656J BACIAQ0kBoPHXaSBFG9s2PzmL+YeytHBHz2CHjF0gspGOe2fVKFUKYbQuuSCsFOFUggc8lEw Z6tNlNIaGTEscMyBOjvdCHNtUg2+evYSkCMOeCygfmOT5RxbQvSB8xNI/Jx3IRIxGwhshDrw pGfPMljZE/QOUm4sfrRi7Eb7nLCErW3kUCM8GYqhEmhWq21iQSjQmWwQiMEKiSvrRUpWoOeB VAi2QjZnN3ZUMEjAmILW6qAQ2oI2isrY7IsxusKY0mO/E+ZJIJnF1he0S+hSoIm2FIONiTuE eimQiJ1E5y0u0h5X4lAEUSCtsM0DUZjnqRvZFl4UCcqEFUFTGCQLgWQiU5pRhe2JuDdYTUIp XjywERi117pFg7vmqoVd9hYX44wxbQ6ZTIGNOaVTp2jU0ThBRa7i5+rovnwtjNfU+HRBy6eJ Kevi49xJmx5HQaRmiiKjzThO1oPlvc3vL+yje9UHX29FQLO5IOx2RJlJ26CV9LLPAe0vr+3s TXme5p5pjq/MAmETgGyFYT9V5OiZz3xnvKnsWN/tHqJiN0Y9GL0CZ+1oTu/cN95lQmMwxPjF UCUlfrOseHL8X9nWb0eWfUi+UhWVJE4xS0wSn9IqOL3lkQZRkJmXVJPicOdrTZ2SlLYkdohD RkAYJHI3wbfzGmgMBvy3hRgk8Qyz+w9wTPXtjaPM9YcDP9rquUGLKhyObtkAUvU9RcYMx4iN CxNnDoZ8pBL3b+4PmIvDiAeSgcC8+wxSVTQ9Zv2aoqbjsOwgcgYZmV07txlDerMwBWIiSXR8 zgDgMncLJtZdw0GdmYuEI1kSDgtvcH86biJQ2H5Mc/IMEce2HHd9MwTUJJyFcDWBG4WvwSQ/ m37zZdB4+DbaD4oSOi2o5k6ksic5ScXHSzaH1Hr31XmR3d2S9OhoWLGOuXboRMhajlhqSWQx HCONorkG5bNdmh1MqWRATzq2kd8sEN6MGaCNlza8VrWf0vNw7wS8DoR6QGsep94agtVajEMg hQDGhpkH2sOI+Blslm/HUa7ZncGvPmdKSGG9raBspqEEl3Ly0ZMjQXVpluYM6FB/FcnrAGEU K4tjNCyYANqgpAMdpCROyL4giYMRKI5ZQBUWFlWFpUnCsUFjuaDOl65tPzPqOXrO8+AxQQzs JGKF8Uc22ga+cZ0hQEMugQ7I+lEASBgAdfHpysThPJ+JZzSsi8zHQZwKYBmfeesR++uL/UbD 6H6EdKYwxLVdf9ZRoRB8Mgd4uA3Ky0WVRx7icSnClxkUiYpqIIJr33ej9B3A3CbpNO7JWBfk DQiKCCQVgiKDhM1UvQ84Y20ldJaay1PTzi4FAGhW2UCHOIkg2EdL4IVIzDQ6SiXl4HKyoSe7 OCWvqPYYBmwcENChkJFlp6RDusbrrDodIIbAcRB7gi9SOHbYYtmGOV2xUMIVzreFg8mRGDSW Ikl206i3N8/AcrDALQPjvCNcxMbbDcu486AIFkgCD1LOiYbG31bf7BdpO8QxGSETAjJIMTkT u7sCxL3et28QWMhgQytBaLUY4DUpSqEFpI9rDaTMWte19G0B0o0TSRFgZGfQ39DXaKwYJMoN iS5EGSqJZOhDQgaSBsMSQr+3fnO4MZkwR9G2gHMVqtngMFaGUtQDkKZQuUWLGqBlJqyIUdN7 ilSkqiz0iAckmRwaJJ9viIg8zPeMKnAQf16v+9+UlvNpIlJKGBsElkmwsVeFkvRje3YW9obX x8qhiicwwuN8GxhQMG+aiwwRzDnzlOYpQhhUsniGNpMlcZxCUD41FSX0rpkkDXkKPmPt+B63 wRUR9DsEh3ngI3Gj7Gd5wWaOLWjvtVd4wGFNWU3iQfYSFsGEbEwFj2DEeOBHlkVWDWsvzwHw Mqjb/UXRUmqmZjGlJgUN+2xoGuZi1C7Hp4hq6+ulYJe2JqQJtIL5KQ0oYWB1GjNQTylYYmyh 6Cmlca0kMpZpF8WyBsvcMtRlFnHZN00sa1rna57rqQlAg6yvearR6FyzxcM74LajeDTJLGpT CTzsrPZpWU0r8LjOTnIq7GrSxlqLBoHLLEDsrDpFHXM+VtTrmoP7JJaOY3Z000Ik0WxFrJDo juKFN6EWKwnwFLoEhbr0Y3Efdpl5DbTncjAVhJp3Go5oWnyiGlw2bZiyRgzYZI2gI/he8kjk qqQWAaM1cYrXdrmeoakBw1N5tRAjBbmFEekE7JzBY4CGXhZGO1la6y/JMbtT9kd0gL7L3kQQ tQ9KbaZZxVkWitmRZmlOEEhg1pAEEhkog8RRFX4DlzeDD0SpdNUHT7rAExDcjjCM9I7JygFV ejrxmPi1XRxlj1WKpEFpbPmNVXFbRV4JgxoNdQvaEUTOdi7GSi1sjIRf4AYl6rVJLCfUe70y lVGV+DS5ip3rjtoy2LTb1WEk/G/2zlMiYOdQ2jAUEGdZloFpQke5i6IkS+bQSunkocEPwgRC knYwlh61zRaGB4BEloXuTPtSZ8CVCyqvFVLL60Xpx+d81UpWdp5KDGbxTHZHymEg2cu1ChkB tSpmoqMJcoCdM6/YMLlFUCNTt0YwYCP42g8nUKtphr+PQluPZ68K2FzZ1KQQCa1zVT2EHCod bZCSD1kMbvAj3+2aESmHSGz7ZnpeURfHsaUhwODhz0FsMS76y27V6vUY2OANWYOh9ozdmBFR Jpw1otrN2c147aS22m8Te7UeMGAVtYN+BhsA4CLPYQKv4s8W63MKezzwcdmORshtG+6QY6rz Y5I6Dhl9QxD2RZzuvSMBoJDA7XDA1w5fDE8zf5GLJuHEIIKpljvbNugMsIhks8Zp6XFS+KQX qb4pSJtHUXpMgLztQiasCVegrgmJgZiZqQBiTA2DfGEKBtYl6gzUVSba5vEU+9VLZpVVtVKq rpz86RcqbzKQdeqD2DCwlCbbFDNtkS0IrgQTSYi1NLvRgZNN+kPUFbRF3jgkNjXcQfDcZ8wu jmN4vz219m1IMhGEOohtRY9WXN/bOAz08R9QdR2aEBJjJkSZJGs1JE0Qhwxl9mgq4lCmd5IW xaZaUkll43RQYDOiMfxt+FI4LVkcfLtI7UbsdNOJSUG4RQgFPaD2ViHNQQcqyEIkbAEaI+D7 aT6EXDEqtSZgci0CqFRg7TSQM7JuDKQiBRGsdDCplkRV8G2QokvFC7epKlsQRYrwlfIc6bxQ su4MAk8WlejQUUO9gosVVc9GWvfOlmOFmdil+CjSF3UsLQslgq1oJzLlrKhRlje+RTTzMUqF EKiFaVUMYw4NZJB6GfsEz7bCRgIPdDNVqKvoblpYuNwtFuTkGGkEdDW7jJQaWUHBhCGRczID IJM8Ka0oaJsq7hDZ27QLgiiEsBCJAehXa7phadcJWKWQ4o2EDKFgsUVRgqXZuQvAtMCrwFnh VWscHJLMXQbCsTcgJ1DqcZINbTjuc2HWO0VOfYJYZmQVpWSnMZFUop7JBmUxhRnIVBWqK8F5 T/28nx+NeGeVqYhHlK4RpNjQ39hPpNEyCHKRiVRUUYC9Ayu2xIHYHf9ddlBgXQGRMNvfJSLY N1C1dv6P5mbQ3+PHcbndtPbBBf+ChniH5nUQDFpLrn8wpu+KmKpSiIOIPALbWps2XfcOLr7t 6cbxD5HKuKvSDCKpX3HfrO8Msr/EVI5Hf91PaNIS+bhJiW8GfUZ8wKIhe3NwOojxBBJ4PHOg RIzIMbRyymaqeYiDicqCtEHcZNB44pb5S2o7J+25R0Sjsdu5C2joAE+KiLQT1ohUHuRGSUio KrGFUQWEApkMYX46sS+qwVkZKmxbEAQTONXKAkSUda9GVFVhBQM0aPSN5ZOqjTUVPwlTbUrJ U8wfGVS9QVX4MtYxsNAwoZIQQw+dzFBWaiesN5BNFGJDTCgkJvvXPrRW8qeaRH2pgGTEDBnB CiQ9eC61VZASKMIiFedSF1V7cmWydInBFmudiCxcfv1uWeY/Vyrgjk5g07xzqrERbkO0rHwt ng05jESw8EVAla9ubomONIsulV5CRAishTcgpk4HhxpO3vDixHhBEPoQEjkkWGBuxghjV8Ih ruzxJ9LRvZX7DEffMlhiokhsSfc5jSHhq1TMkNMFvLoLCIPiSitTAW4zV1GGYbXvZgQ1y4Tn XVGgA14Fi1LFIzYNJpm1wEoAiYMT17CbYSHCFqu0CaEVKosJKKcEhggsT3K9UqZ0PyldYbiq opBkQWk7oITjX54bBjMCGBnDhBaWObgxaWxIbcStsNRh7WtSToVSpXSk6kzrETRRILkXVIGT GpDGkTQZYSupUS+9PiWTUkTkvumiaEWAXCC9BIzMjOhDyZE2RQWnD0EsKZzJip5bsOyQSVMA oreC4oR6xqVSSoVzkmrYIGNKYSBoZ0zUFRYAemqieYXFjA6Bq1lAbcnerUrV0lUiJ3q8qJGQ yq0eC7Q4qxcTC7z1BBSYcobEhQ00Gl5K/gTJsYI2UNA9VG0AcS6LEakktbd0a0L1QtCH/Nkc BJNNayNQjTKsiYQHioMl0d3wJLnh/rnqvTDd4DjsBniuAJ0x7SOAwDFgtahmvJeBTvy9F95I CMBSpFkK7kiJGA2zZHaWP+QtSD7mbDmQW//IV5KYIMEHbHd0x2uD2ZngVb6sGw/WifgqUHH0 CRIodpSZaDaTOQRVtlgbAuL7oNVJSmSFpaWTzy5ViizNJyuhw2Diw1yyXSZKxkJVGWBMKUUO xlFU7ZFS/uNSfmIZaeQqADMULa7HJtBWMANsf+PrPP53/oN8o+Q3V0xPWVg+TayXv9HhJAGy LuSKcKEgkzAWCg== --------------000704030300080804030201--

1 0

Re: (ITS#7250) Issue with search filter escape sequanced
by masarati＠aero.polimi.it 18 Apr '12

18 Apr '12

On 04/18/2012 02:47 PM, malleswari.nandi(a)gmail.com wrote: > Full_Name: Malleswari Nandireddy > Version: 2.4.23 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (206.126.170.20) > > > In our code we are using ldap_add_ext_s and ldap_search_ext_s , to add an entry > to LDAP and to search and entry in the LDAP. > > If the enter added is "00*#116cr36_1R1T1S1P1Q1" , then we we try to search using > ldap_search_ext_s , it is not returning any records. > > But when I try to search using ldapsearch , after replacing escape charecter "*" > in the string with "\2a" it is returning records. > > ./ldapsearch -h 10.29.6.33:12660 -x -b 'dc=CVGLDAP,dc=com' > 'ets=1:00\2a#116cr36_1R1T1S1P1Q1' > > We have tried passing 'ets=1:00\2a#116cr36_1R1T1S1P1Q1' to ldap_search_ext_s() , > but it is not returning any records. > > Please help me searching records in LDAP using ldap_search_ext_s() if the filter > has escape charecters like "*,(,)....). You're clearly missing the point between escaping in shell and in C code. However this is a user error, not an (Open)LDAP bug, so I suggest you direct your question to openldap-technical(a)openldap.org; this ITS will be closed. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7250) Issue with search filter escape sequanced
by malleswari.nandi＠gmail.com 18 Apr '12

18 Apr '12

Full_Name: Malleswari Nandireddy Version: 2.4.23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.126.170.20) In our code we are using ldap_add_ext_s and ldap_search_ext_s , to add an entry to LDAP and to search and entry in the LDAP. If the enter added is "00*#116cr36_1R1T1S1P1Q1" , then we we try to search using ldap_search_ext_s , it is not returning any records. But when I try to search using ldapsearch , after replacing escape charecter "*" in the string with "\2a" it is returning records. ./ldapsearch -h 10.29.6.33:12660 -x -b 'dc=CVGLDAP,dc=com' 'ets=1:00\2a#116cr36_1R1T1S1P1Q1' We have tried passing 'ets=1:00\2a#116cr36_1R1T1S1P1Q1' to ldap_search_ext_s() , but it is not returning any records. Please help me searching records in LDAP using ldap_search_ext_s() if the filter has escape charecters like "*,(,)....).

1 0

(ITS#7249) slapd segfault with memberof overlay on frontend db
by jvcelak＠redhat.com 18 Apr '12

18 Apr '12

Full_Name: Jan Vcelak Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.132.186.34) Enabling memberof overlay on frontend database causes slapd to SEGFAULT due to stack overflow when renaming an entry. Slapd should not segfault even if the configuration is wrong. Initial server configuration: (slapadd -F /etc/openldap/slapd.d -n 0 -l slapd.ldif) dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd.args olcPidFile: /var/run/slapd.pid dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///etc/openldap/schema/core.ldif dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: frontend dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config olcAccess: to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,c n=auth" manage by * none dn: olcDatabase=bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: bdb olcSuffix: dc=my-domain,dc=com olcRootDN: cn=Manager,dc=my-domain,dc=com olcRootPW: secret olcDbDirectory: /var/lib/ldap olcDbIndex: objectClass eq Initial data: (ldapadd -c -H ldap://localhost -x -D cn=manager,dc=my-domain,dc=com -w secret -f data.ldif) dn: dc=my-domain,dc=com objectclass: dcObject objectclass: organization o: Example Org dc: my-domain dn: cn=Manager,dc=my-domain,dc=com objectclass: organizationalRole cn: Manager dn: ou=users,dc=my-domain,dc=com objectclass: organizationalUnit ou: users dn: cn=foo,ou=users,dc=my-domain,dc=com objectclass: organizationalRole cn: foo Enabling overlay: (ldapadd -c -Y EXTERNAL -H ldapi:/// -f data_overlays.ldif) dn: olcOverlay={0}memberof,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {0}memberof olcMemberOfDangling: error olcMemberOfDanglingError: constraintViolation olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf Renaming the entries, causing segmentation fault: (ldapmodify -c -H ldap://localhost -x -D cn=manager,dc=my-domain,dc=com -w secret -f data_modify.ldif) dn: cn=foo,ou=users,dc=my-domain,dc=com changetype: modrdn newrdn: cn=bar deleteoldrdn: 1 dn: cn=bar,ou=users,dc=my-domain,dc=com changetype: modrdn newrdn: cn=foo deleteoldrdn: 1 Server backtrace: (gdb) bt 6 full #0 0x000000000044f188 in backend_check_restrictions (op=0x0, rs=0x0, opdata=0x0) at ../../../servers/slapd/backend.c:1022 restrictops = 140737153878880 requires = 4515244 opflag = 8413346912 exopflag = 140737311768104 ssfs = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0} ssf = 0xa0bc30 updateop = 0 starttls = 0 session = -184966544 #1 0x000000000043f3cf in fe_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/search.c:370 bd = 0x7ffff4f9a180 #2 0x00000000004d9fd4 in overlay_op_walk (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search, oi=0x7fffec104b60, on=0x0) at ../../../servers/slapd/backover.c:671 func = 0x8dc018 rc = 32768 #3 0x00000000004da225 in over_op_func (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search) at ../../../servers/slapd/backover.c:723 oi = 0x7fffec104b60 on = 0x7fffec104d40 be = 0xa0bc30 db = {bd_info = 0x8dbfc0, bd_self = 0xa0bc30, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001", '\000' <repeats 16 times>, "\001", be_flags = 67848, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0xa16380, be_nsuffix = 0xa163b0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 30, bv_val = 0xa16450 "cn=Manager,dc=my-domain,dc=com"}, be_rootndn = {bv_len = 30, bv_val = 0xa164a0 "cn=manager,dc=my-domain,dc=com"}, be_rootpw = {bv_len = 6, bv_val = 0xa16320 "secret"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xbefb60, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x8d4c60, be_private = 0xa11e80, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff4f9a410, sc_response = 0x4d8d5b <over_back_response>, sc_cleanup = 0, sc_private = 0x7fffec104b60} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #4 0x00000000004da334 in over_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/backover.c:750 No locals. #5 0x000000000043f5bb in fe_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/search.c:402 bd = 0x7ffff4f9a460 (More stack frames follow...) ... #45535 0x00000000004da225 in over_op_func (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search) at ../../../servers/slapd/backover.c:723 #45536 0x00000000004da334 in over_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/backover.c:750 #45537 0x000000000043f5bb in fe_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/search.c:402 #45538 0x00000000004d9fd4 in overlay_op_walk (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search, oi=0x7fffe81050a0, on=0x0) at ../../../servers/slapd/backover.c:671 #45539 0x00000000004da225 in over_op_func (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search) at ../../../servers/slapd/backover.c:723 #45540 0x00000000004da334 in over_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/backover.c:750 #45541 0x00000000005abaeb in memberof_isGroupOrMember (op=0x7fffec000940, mci=0x7fffec001420) at ../../../../servers/slapd/overlays/memberof.c:289 #45542 0x00000000005b00c0 in memberof_res_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../../servers/slapd/overlays/memberof.c:1513 #45543 0x000000000045262c in slap_response_play (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/result.c:507 #45544 0x0000000000452868 in send_ldap_response (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/result.c:582 #45545 0x0000000000453a52 in slap_send_ldap_result (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/result.c:860 #45546 0x000000000050e0a9 in bdb_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../../servers/slapd/back-bdb/modrdn.c:789 #45547 0x00000000004626be in fe_op_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/modrdn.c:314 #45548 0x00000000004d9fd4 in overlay_op_walk (op=0x7fffec000940, rs=0x7ffff57989e0, which=op_modrdn, oi=0x7fffe81050a0, on=0x0) at ../../../servers/slapd/backover.c:671 #45549 0x00000000004da225 in over_op_func (op=0x7fffec000940, rs=0x7ffff57989e0, which=op_modrdn) at ../../../servers/slapd/backover.c:723 #45550 0x00000000004da3b2 in over_op_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/backover.c:768 #45551 0x0000000000461e20 in do_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/modrdn.c:186 #45552 0x000000000043a9df in connection_operation (ctx=0x7ffff5798b20, arg_v=0x7fffec000940) at ../../../servers/slapd/connection.c:1150 #45553 0x000000000043af9c in connection_read_thread (ctx=0x7ffff5798b20, argv=0x13) at ../../../servers/slapd/connection.c:1286 #45554 0x00000000005d0dd2 in ldap_int_thread_pool_wrapper (xpool=0x9b0170) at ../../../libraries/libldap_r/tpool.c:688 #45555 0x00000034ad607b41 in start_thread (arg=0x7ffff5799700) at pthread_create.c:305 #45556 0x00000034acee0e6d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

1 0

← Newer
1
2
3
4
5
6
7
8
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2012