(ITS#4760) problem with group caching and proxyAuth control
by richter＠ecos.de
Full_Name: Gerald Richter
Version: 2.3.30
OS: Linux
URL: ftp://ftp.openldap.org/incoming/Gerald-Richter-061123.2.patch
Submission from: (NULL) (194.95.226.11)
Hi,
I noticed that when I use the proxyAuth control group members are not correctly
resolved.
What I do is to login as user A and do a search with proxyAuth control with an
authzid of user B.
User B is member of a group, which grants him access to the some items. User A
is not.
When directly logging in as user B, everything is ok. Using proxyAuth user B
doesn't have access to the items that are granted to the group.
The reason is that the group membership is cached, and therefore users A
membership is used for ACL evaluation, instead of users B membership.
The attached patch, simply deletes all cached groups, when inside the proxyAuth
control setup, which resolvs this issue.
Gerald
This patch file is derived from OpenLDAP Software. All of the modifications to
OpenLDAP Software represented in the following patch(es) were developed by
Gerald Richter <richter(a)ecos.de>. These modifications are not subject to any
license of ecos GmbH.
Redistribution and use in source and binary forms, with or without modification,
are permitted only as authorized by the OpenLDAP Public License.
16 years, 6 months
(ITS#4759) aci comptibilty to V2.1; multiple attrs
by richter＠ecos.de
Full_Name: Gerald Richter
Version: 2.3.30
OS: Linux
URL: ftp://ftp.openldap.org/incoming/Gerald-Richter-061123.patch
Submission from: (NULL) (194.95.226.11)
Hi,
I found that due to the rewrite of ACI code, the possiblity to specify more than
one attribute in one ACI entry has gone lost. We discussed this already at the
beginning of the year on the mailing list.
I have made a patch, that is in heavy production use on several systems for some
time now, that again (as in OpenLDAP 2.1) allows to have multiple attributes in
one ACI.
This is not only a compatibility issue, but also improves the performance of ACI
handling, if you need to specifiy a lot of attributes.
The patch also adds some more debugging output, that allows to easyer understand
what's going on, when you have set some ACI and it does not have the desired
result.
Gerald
This patch file is derived from OpenLDAP Software. All of the modifications to
OpenLDAP Software represented in the following patch(es) were developed by
Gerald Richter <richter(a)ecos.de>. These modifications are not subject to any
license of ecos GmbH.
Redistribution and use in source and binary forms, with or without modification,
are permitted only as authorized by the OpenLDAP Public License.
16 years, 6 months
(ITS#4758) valsort + dynlist can cause 100% cpu utilization causing slapd to become unresponsive
by michael.heep＠o2.com
Full_Name: Michael Heep
Version: 2.3.30
OS: Linux (RHES30)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (82.113.101.1)
Hi,
the following valsort + dynlist combination causes slapd to utilize 100% cpu
time when issueing searches against parts of the DIT containing attribute-value
pairs "created" by dynlist:
overlay dynlist
dynlist-attrset extensibleObject memberURL uniqueMember
overlay valsort
valsort-attr uniqueMember dc=o2online,dc=de alpha-ascend
When run independent both overlays work flawlessly.
16 years, 6 months
Re: (ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu
Since test033 didn't replicate, I ran librtc against a full production
config. The SEGV occurred here (note we're not inside malloc due to librtc
redzone features):
<rtc> Write to unallocated (wua) on thread 11:
Attempting to write 1 byte at address 0xc886b0
which is just past heap block of size 128 bytes at 0xc88630
This block was allocated from:
[1] default_malloc_ex() at line 79 in "mem.c"
[2] CRYPTO_malloc() at line 304 in "mem.c"
[3] RSA_eay_private_decrypt() at line 488 in "rsa_eay.c"
[4] RSA_private_decrypt() at line 292 in "rsa_lib.c"
[5] ssl3_get_client_key_exchange() at line 1454 in "s3_srvr.c"
[6] ssl3_accept() at line 448 in "s3_srvr.c"
[7] SSL_accept() at line 816 in "ssl_lib.c"
[8] ldap_pvt_tls_accept() at line 863 in "tls.c"
Location of error:
current thread: t@11
=>[1] BN_bn2bin(a = 0xd93ff3d4, to = 0xc886b0 ""), line 649 in "bn_lib.c"
[2] RSA_eay_private_decrypt(flen = 128, from = 0xc76066 "6^D\xf3\xd8\xfb\xa4\x83^H5\xd8b\xa2\xe2\xd9\xdf_0`(^T:w\xd8\xff^C\xf7W\xe2_\xaar\xec\xc7\xf5~\xf1\xf1E{^NX\xe2.\xf5\xa4B^L\xf6$\xb7=\x8er\xde\xee\xce^R^W\x95^?^?", to = 0xc76066 "6^D\xf3\xd8\xfb\xa4\x83^H5\xd8b\xa2\xe2\xd9\xdf_0`(^T:w\xd8\xff^C\xf7W\xe2_\xaar\xec\xc7\xf5~\xf1\xf1E{^NX\xe2.\xf5\xa4B^L\xf6$\xb7=\x8er\xde\xee\xce^R^W\x95^?^?", rsa = 0xbb5a08, padding = 1), line 576 in "rsa_eay.c"
[3] RSA_private_decrypt(flen = 128, from = 0xc76066 "6^D\xf3\xd8\xfb\xa4\x83^H5\xd8b\xa2\xe2\xd9\xdf_0`(^T:w\xd8\xff^C\xf7W\xe2_\xaar\xec\xc7\xf5~\xf1\xf1E{^NX\xe2.\xf5\xa4B^L\xf6$\xb7=\x8er\xde\xee\xce^R^W\x95^?^?", to = 0xc76066 "6^D\xf3\xd8\xfb\xa4\x83^H5\xd8b\xa2\xe2\xd9\xdf_0`(^T:w\xd8\xff^C\xf7W\xe2_\xaar\xec\xc7\xf5~\xf1\xf1E{^NX\xe2.\xf5\xa4B^L\xf6$\xb7=\x8er\xde\xee\xce^R^W\x95^?^?", rsa = 0xbb5a08, padding = 1), line 292 in "rsa_lib.c"
[4] ssl3_get_client_key_exchange(s = 0xc74500), line 1454 in "s3_srvr.c"
[5] ssl3_accept(s = 0xc74500), line 448 in "s3_srvr.c"
[6] SSL_accept(s = 0xc74500), line 816 in "ssl_lib.c"
[7] ldap_pvt_tls_accept(sb = 0xc74068, ctx_arg = 0xb53bd8), line 863 in "tls.c"
[8] connection_read(s = 46), line 1337 in "connection.c"
[9] slapd_daemon_task(ptr = (nil)), line 2352 in "daemon.c"
This system is running OpenSSL 0.9.7l, although I've seen the #4723
segfault (not under debugger, alas) on 0.9.7d systems as well.
Is there any easy way to turn on traffic encryption in 'make test',
possibly with some on-the-fly self-gen certs?
16 years, 6 months
Re: (ITS#3460) Adding LDAP statistics script to contrib directory
by Frank.Swasey＠uvm.edu
This is a cryptographically signed message in MIME format.
--------------ms020103070007040700000908
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I'm slow reading my email (well 18 days isn't so bad really... ahem...)
On 11/2/06 2:42 PM, quanah(a)stanford.edu wrote:
> As for #2, I grant such a release for the work I've done on the script.
>
> Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a release
> for the work you've done with this script? :)
Yes, I do grant this release.
--
Frank Swasey | http://www.uvm.edu/~fcs
Sr Systems Administrator | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
"I am not young enough to know everything." - Oscar Wilde (1854-1900)
--------------ms020103070007040700000908
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJDzCC
AuIwggJLoAMCAQICEAq9rKiduK3HCbKzsBiBodUwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDcxNzE2NTcyNloX
DTA3MDcxNzE2NTcyNlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEG
CSqGSIb3DQEJARYURnJhbmsuU3dhc2V5QHV2bS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQCzhSmesaR8qf2y5cNt0qa27m42Kq3Bwubs28CzSxR1uRUaRZUfL/C2FEFV
kKSat6da5b19UEWxM1giaWvLeDtQE5Tok8GhN8LNgScTiSEM6gFWnL0o7A9W7oAj42dfFvBV
md7/u7nSJoAP3Wt9cU3TBJBh99U89EzIYLNik8iVhzbwfNmisxmuR5870AHURoR1sN/X4jWx
q5114Rv8r60+bVitlXL7P20Z2S9+va9+a7+C1P/yJLPq1GK8+X9uaoUaGHlapBeBYNu3QWQG
Q+mF+QuidS01jbaburvJxUm7dVO3QRt1PovVhlidv89eqcH8n4h7xSG1IG3teNJkschdAgMB
AAGjMTAvMB8GA1UdEQQYMBaBFEZyYW5rLlN3YXNleUB1dm0uZWR1MAwGA1UdEwEB/wQCMAAw
DQYJKoZIhvcNAQEEBQADgYEAblV8ye5ZLs/y3DX0W3NU67N2T6tOSZ1609L+BRWB/Md7RDFd
Cm8AXFIldDLzkyPFqs9WpgAQLvZ0gRXQ8aqwYEBB3WlZzkpUS+YTuY6X9wjcroMjHCyWNpq0
/joDumCNSEWiZJ6AZMRom9Z/P6foBxXmgCBKVq/O0mGqgArlxdkwggLiMIICS6ADAgECAhAK
vayonbitxwmys7AYgaHVMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK
ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u
YWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjA3MTcxNjU3MjZaFw0wNzA3MTcxNjU3MjZa
MEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFEZy
YW5rLlN3YXNleUB1dm0uZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs4Up
nrGkfKn9suXDbdKmtu5uNiqtwcLm7NvAs0sUdbkVGkWVHy/wthRBVZCkmrenWuW9fVBFsTNY
Imlry3g7UBOU6JPBoTfCzYEnE4khDOoBVpy9KOwPVu6AI+NnXxbwVZne/7u50iaAD91rfXFN
0wSQYffVPPRMyGCzYpPIlYc28HzZorMZrkefO9AB1EaEdbDf1+I1sauddeEb/K+tPm1YrZVy
+z9tGdkvfr2vfmu/gtT/8iSz6tRivPl/bmqFGhh5WqQXgWDbt0FkBkPphfkLonUtNY22m7q7
ycVJu3VTt0EbdT6L1YZYnb/PXqnB/J+Ie8UhtSBt7XjSZLHIXQIDAQABozEwLzAfBgNVHREE
GDAWgRRGcmFuay5Td2FzZXlAdXZtLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA
A4GBAG5VfMnuWS7P8tw19FtzVOuzdk+rTkmdetPS/gUVgfzHe0QxXQpvAFxSJXQy85MjxarP
VqYAEC72dIEV0PGqsGBAQd1pWc5KVEvmE7mOl/cI3K6DIxwsljaatP46A7pgjUhFomSegGTE
aJvWfz+n6AcV5oAgSlavztJhqoAK5cXZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF
ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw
ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh
dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X
DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV
c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J
8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I
BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f
BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h
aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl
TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU
nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d
qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2Qw
ggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB
AhAKvayonbitxwmys7AYgaHVMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MTEyMDE5NTUxN1owIwYJKoZIhvcNAQkEMRYEFEe5
R0tOqDV5mZSEX9tMzc1x2JoeMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr
BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu
ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu
ZyBDQQIQCr2sqJ24rccJsrOwGIGh1TCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQCr2sqJ24rccJsrOwGIGh1TAN
BgkqhkiG9w0BAQEFAASCAQB5jfu/W/bTIPufVHhrEsZS19DtAZXNQisiNsDTRGtdQGyyS9w2
NE0w5B0Lhbhg+dgwBGvd03/OqxwguatStF0fpgW2sFK3pbvClmRA7mXte5d51GNP49COPd4C
R1dLsOtzmhHb2YJ8Cg46vZWE/UdgGYYoV4zStPNJHs3Z07pQ5pCBMhd4l/BZht+BPgNiirLv
UskWVwSwUfGxfgEka9yG4KLCQdhL44oUXRcawWfrOPcmN80jrXHp6FnsNSJ43ifztqK4QKyY
idUeA+NEmv3Ss5AO6PkvC51rsr2qmLkMeczl/ZuvcxGaDDloBibCdWJu5R81pRoTO0UdPfiw
uwbIAAAAAAAA
--------------ms020103070007040700000908--
16 years, 6 months
Re: (ITS#4757) Support for RFC 3045: Storing Vendor Information in the LDAP root DSE
by Kurt＠OpenLDAP.org
At 12:36 AM 11/20/2006, michael(a)stroeder.com wrote:
>Kurt D. Zeilenga wrote:
>> At 01:37 AM 11/19/2006, michael(a)stroeder.com wrote:
>>>
>>>I'd like to see support for RFC 3045 in slapd.
>>
>> The only reasonably decent use of such attributes is for
>> administrators to determine whether they need to upgrade
>> some software or not
>
>Yes, that's what I'm after.
This purpose is, I think, somewhat beyond the intended purpose
of the vendorName/Version attributes. These attributes appear
to be intended to be used by general LDAP clients, not just
administrative clients, for "limited feature discovery".
The vendorName/Version you might want reported for "limited
feature discovery" might be quite different than what you want
reported for "need to upgrade" purposes.
And for "need to upgrade" purposes, one needs to know not only
the version of the protocol engine (slapd(8)), but version of
backend codes, overlay codes, underlying libraries, etc..
>> We provide cn=monitor for this purpose.
>
>This is proprietary. Think of vendor-independent management/monitoring
>software which just gives an terse overview.
Generally speaking, DSA administrative interfaces are not
standardized. (Which is, to some degree, why I think use of
vendorName/Version for administrative purposes is beyond the
intentions of these attributes.)
>> While it certainly is possible for a client to abuse
>> cn=monitor version information, the very fact that the
>> version information is in cn=monitor, which generally
>> requires special authorization to read, instead of
>> the root dse, which generally is readable by most
>> every client, is effective in discouraging this abuse.
>
>The server admin can easily define access control for vendor information
>in root DSE. The sample slapd.conf could endorse this. Or another value
>for configuration directive 'allow'.
Yes, but...
Kurt
16 years, 6 months
Re: (ITS#4757) Support for RFC 3045: Storing Vendor Information in the LDAP root DSE
by michael＠stroeder.com
Kurt D. Zeilenga wrote:
> At 01:37 AM 11/19/2006, michael(a)stroeder.com wrote:
>>
>>I'd like to see support for RFC 3045 in slapd.
>
> The only reasonably decent use of such attributes is for
> administrators to determine whether they need to upgrade
> some software or not
Yes, that's what I'm after.
> We provide cn=monitor for this purpose.
This is proprietary. Think of vendor-independent management/monitoring
software which just gives an terse overview.
> While it certainly is possible for a client to abuse
> cn=monitor version information, the very fact that the
> version information is in cn=monitor, which generally
> requires special authorization to read, instead of
> the root dse, which generally is readable by most
> every client, is effective in discouraging this abuse.
The server admin can easily define access control for vendor information
in root DSE. The sample slapd.conf could endorse this. Or another value
for configuration directive 'allow'.
Ciao, Michael.
16 years, 6 months
Re: (ITS#4757) Support for RFC 3045: Storing Vendor Information in the LDAP root DSE
by Kurt＠OpenLDAP.org
At 01:37 AM 11/19/2006, michael(a)stroeder.com wrote:
>Full_Name: Michael Ströder
>Version: not relevant
>OS: not relevant
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (83.124.27.203)
>
>
>HI!
>
>I'd like to see support for RFC 3045 in slapd.
The only reasonably decent use of such attributes is for
administrators to determine whether they need to upgrade
some software or not (though use of a protocol attribute
for this purpose is somewhat problematic). We provide
cn=monitor for this purpose.
The primary use (or I should say misuse) of such strings
is for server behavior discovery (whether the behavior
is due to a feature or a bug). As this use leads to
interoperability problems (as illustrated by the HTTP
"mozilla" compatibility problems), we must allow
spoofing and should discourage this use. We support
the former via the rootdse configuration option.
We support the latter by not providing any values by
default.
While it certainly is possible for a client to abuse
cn=monitor version information, the very fact that the
version information is in cn=monitor, which generally
requires special authorization to read, instead of
the root dse, which generally is readable by most
every client, is effective in discouraging this abuse.
I think it reasonable to assume any administrative tool
for determining whether an OpenLDAP server is up to date
would have appropriate authorization to read the
cn=monitor values.
I note that such tools should not assume a server
needs not be upgraded simply because the version is high
enough. There easily could be dependent software whose
version is not high enough. It would be good for
cn=monitor to not only expose the OpenLDAP version
information, but to expose version information for
dependent software. Of course, as there is an endless
number of dependent software, this upgrade detection
approach problematic. Seems it would be better to
use tools that ran directly on the box to determine
whether a server's software needed to be upgraded.
But I digresss.
In the past we have rejected submissions to extend
slapd(8) to generate these values, hence I think this
feature request should be closed.
However, such closure certainly doesn't preclude someone
from implementing **additional** vendorName/Version functionality
and submitting it for consideration. There is one aspect of our
current vendorName/Version support that is lacking is in dealing
with multiple broken clients requiring different
vendorName/Version strings. An overlay which spoofed these
strings on a configurable basis, whether by authorization
identity and/or IP address and/or other authorization factor,
would be an interesting functionality addition.
Kurt
16 years, 6 months
