[Fedora-directory-devel] Please review: [Bug 204566] Adjustment for new LDAP C SDK
by Noriko Hosoi
Summary: Adjustment for new LDAP C SDK
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204566
Summary: Adjustment for new LDAP C SDK
Product: Fedora Directory Server
Version: 1.0.2
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: Directory Server
AssignedTo: nhosoi(a)redhat.com
ReportedBy: nhosoi(a)redhat.com
QAContact: ohegarty(a)redhat.com
CC: ohegarty(a)redhat.com
Estimated Hours: 0.0
Description of problem:
LDAP C SDK function -- ber_get_next_buffer_ext's API has been changed since the
Sun code merge. (See also https://bugzilla.mozilla.org/show_bug.cgi?id=347933)
We need to update the connection code to adjust.
ber_get_next_buffer_ext in mozilla/directory/c-sdk/ldap/libraries/liblber/io.c
Original:
/*
* Returns the tag of the message or LBER_DEFAULT if an error occurs. There
* are two cases where LBER_DEFAULT is returned:
*
* 1) There was not enough data in the buffer to complete the message; this
* is a "soft" error. In this case, *Bytes_Scanned is set to a positive
* number.
*
* 2) A "fatal" error occurs. In this case, *Bytes_Scanned is set to zero.
* To check for specific errors, the system error number (errno) must
* be consulted. These errno values are explicitly set by this
* function; other errno values may be set by underlying OS functions:
*
* EINVAL - LBER_SOCKBUF_OPT_VALID_TAG option set but tag does not match.
* EMSGSIZE - length was not represented as <= sizeof(long) bytes or the
* LBER_SOCKBUF_OPT_MAX_INCOMING_SIZE option was set and the
* message is longer than the maximum. *len will be set in
* the latter situation.
*/
New:
/*
* Returns the tag of the message or LBER_ return code if an error occurs.
*
* If there was not enough data in the buffer to complete the message this
* is a "soft" error. In this case, *Bytes_Scanned is set to a positive
* number and return code is set to LBER_DEFAULT.
*
* On overflow condition when the length is either bigger than ber_uint_t
* type or the value preset via LBER_SOCKBUF_OPT_MAX_INCOMING_SIZE option,
* *Bytes_Scanned is set to zero and return code is set to LBER_OVERFLOW.
*
* For backward compatibility errno is also set on these error conditions:
*
* EINVAL - LBER_SOCKBUF_OPT_VALID_TAG option set but tag doesnt match.
* EMSGSIZE - an overflow condition as described above for LBER_OVERFLOW.
*/
------- Additional Comments From nhosoi(a)redhat.com 2006-08-29 21:26 EST -------
Created an attachment (id=135178)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=135178&action=view)
cvs diff ldapserver/ldap/servers/slapd/connection.c
File:
ldapserver/ldap/servers/slapd/connection.c
Changes:
1) When ber_get_next_buffer_ext fails, not just LBER_DEFAULT but
LBER_OVERFLOW can be set to the ber tag. Thus, LBER_OVERFLOW is also
checked in the error check now.
2) The too large length error used be checked as "errno == EMSGSIZE",
which is replaced with "tag == LBER_OVERFLOW"
3) When the too large length error occurs, the following error was logged
in the errors log, which was not appropriate since increasing
nsslapd-maxbersize did not solve the problem.
connection - conn=7 fd=65 Incoming BER Element was too long, max
allowable is 2097152 bytes. Change the nsslapd-maxbersize attribute
in cn=config to increase.
Removed the error logging.
4) When the error occurs, B2 (== SLAPD_DISCONNECT_BER_TOO_BIG) is added
at the end of the closed error in the access log. Error code EMSGSIZE
and its description has been added:
conn=7 op=-1 fd=65 closed error 90 (Message too long) - B2
17 years, 1 month
Re: [Fedora-directory-devel] Samba4 onto Fedora DS
by Howard Chu
> Date: Wed, 23 Aug 2006 11:11:17 +1000
> From: Andrew Bartlett <abartlet(a)samba.org>
>
> Yeah, at the moment I'm looking at DS as a replicating (transactional?)
> LDAP-speaking backend, which clients will never talk to. All clients
> will use the Samba lens (as you so very well put it).
>
> Currently, the lens (written for OpenLDAP) maps entryUUID <->
> objectClass, canoncalises objectSid and objectCategory and maps some
> timestamps.
>
I think you meant entryUUID <-> objectGUID. We've done some mapping to
allow OpenLDAP to replicate to AD; it's quite convoluted. There are a
variety of attributes that AD doesn't allow us to write (like
objectGUID) so we retrieve them instead, and stuff them into the
OpenLDAP side.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
17 years, 1 month
[Fedora-directory-devel] Samba4 onto Fedora DS
by Andrew Bartlett
Many moons ago (November last year), I raised the idea that Samba4 might
some day back onto Fedora DS. In the past few months, things have moved
on, and I've done some work to back Samba4 onto OpenLDAP (which now
works for a simple demo). Now I'm trying the same trick with Fedora DS.
Now, I've managed to start the Fedora Directory server, and use the web
(but not Java, for the J word is evil) interface. I'm happy with (and
in fact prefer) command line management at this point.
However, I'm now trying to load a schema into Fedora DS. I'm using the
same schema that I've used with OpenLDAP, run though the
od-schema-migrate.pl script. (Actually, I can also create the file
directly, but they are the same, except for the dividing lines).
Anyway, this is the error I get with the attached schema:
[abartlet@piglett source]$ sudo /opt/fedora-ds/slapd-piglett/start-slapd
Password:
[22/Aug/2006:21:03:47 +1000] dse - The entry cn=schema in
file /opt/fedora-ds/slapd-piglett/config/schema/01samba4.ldif is
invalid, error code 20 (Type or value exists) - attribute type
streetAddress: Does not match the OID "1.2.840.113556.1.2.256". Another
attribute type is already using the name or OID.
[22/Aug/2006:21:03:47 +1000] dse - Please edit the file to correct the
reported problems and then restart the server.
I can find no other reference (in the schema ldif files) to
streetAddress, or that OID.
Is there a list of builtin OIDs that I need to avoid conflicts with? (I
had this trouble with OpenLDAP).
Currently I'm adding the schema to the directory, but I expect I'll need
to remove much of the Fedora DS schema. What is safe/unsafe to remove?
Aside from things like the org chart not working, what else is likely to
break?
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc. http://redhat.com
17 years, 1 month
[Fedora-directory-devel] Re: Samba4 onto Fedora DS
by Howard Chu
> Date: Tue, 22 Aug 2006 17:54:05 -0700 From: Pete Rowley
> <prowley(a)redhat.com> Andrew Bartlett wrote: On Tue, 2006-08-22 at
> 15:35 -0700, Pete Rowley wrote:
>>> >>Why not deal with the specific problems that arise when /adding/ the AD
>>> >>schema? I'm guessing that would be a shorter list?
>> >
>> >Because the AD schema is a whole schema, not just some extra
>> >attributes/objectClasses, I need to be able to replace 'person', and
>> >many other classes that Microsoft has modified.
>> >
>> >Once I start replacing classes, I need to know the list of 'if I replace
>> >this, bad things happen'.
> The problem is the list of broken things is open ended. Perhaps we
> should drill down on a specific example (like the "person" objectclass
> and associated attributes) and look at what is different. At least that
> will make sure we are all talking about the same thing and the folks on
> the list might have more targetted suggestions.
>
> Though, I thought the plan was to make the DS look like AD through
> Sambas lens? Are we just talking about an interim development situation
> until you add the "lens"? If so, I say break what you like. Otherwise I
> would have big concerns about integration with existing DS deployments.
Ultimately, if you need to make a clone of AD in order to satisfy
Windows clients, you are going to have to break the existing LDAP
standards the same way Microsoft did. You pretty much need bug-for-bug
compatibility, otherwise some random MS app will come along later and
break. This means doing such ugly things as requiring "cn" to be single-
valued, etc. etc. Consider that Microsoft redefines the "top"
objectclass to contain a plethora of attributes; it all goes downhill
from there. Andrew, I certainly don't envy you the job ahead of you.
Eventually, when you finish your work, you'll have another server that
is just as broken and non-compliant as Microsoft's. I don't see you
having a lot of choice in the matter, you just have to do what you have
to do. The MS schema just doesn't coexist with real LDAP...
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
17 years, 1 month
[Fedora-directory-devel] Please Review: (202872) Allow the password modify extended op when using SASL privacy layer
by Nathan Kinder
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202872
Bug(s) fixed: 202872
Bug Description: The current behavior of the Directory Server is to only
allow the password
modify extended operation when the connection is using SSL or TLS.
If you
attempt to use a connection that is not using SSL or TLS, the server
returns
LDAP_CONFIDENTIALITY_REQUIRED.
We should allow the password modify extended operation if the
connection is
using a SASL security layer that has privacy.
Reviewed by: ???
Files: See diffs
Branch: HEAD
Fix Description: I added a new internal function "int
ids_sasl_privacy_enabled(Connection
*conn)" that will check if a SASL security layer supporting privacy
has been
negotiated for a particular connection. This function uses the
sasl_getprop()
function to check the SSF (security strength factor) to see if
privacy has been
negotiated.
This function allows us to have the password modify extop code check
if privacy
is enabled so it can allow the operation to be processed. The new
server
behavior is to allow the password modify extended operation if using
SSL, TLS,
or a SASL privacy layer. All other attempts will return
LDAP_CONFIDENTIALITY_REQUIRED.
Platforms tested: RHEL4
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=134347
17 years, 1 month
