389-devel October 2008

389-devel@lists.fedoraproject.org

4 participants
5 discussions

[Fedora-directory-devel] Please review: Bug 469261 - Support server-to-server SASL
by Rich Megginson 30 Oct '08

30 Oct '08

https://bugzilla.redhat.com/show_bug.cgi?id=469261 Resolves: bug 469261 Bug Description: Support server-to-server SASL Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: I've created two new functions to handle the client side of LDAP in the server - slapi_ldap_init_ext and slapi_ldap_bind. These two functions are designed to work with any connection type (ldap, ldaps, ldap+starttls, and eventually ldapi) and bind type (plain, sasl, client cert). The secure flag has been extended to use a value of 2 to mean use startTLS. One tricky part is that there is no place to store the startTLS flag in init to pass to bind, so we store that in the clientcontrols field which is currently unused. We do that because the semantics of ldap_init are not to do any network traffic, but defer that until the bind operation (or whatever the first actual operation is e.g. start_tls). I plan to replace all of the places in the code that do ldap init and bind with these functions. I started with replication. I extended the transport to add tls for startTLS and the bind method to add sasl/gssapi and sasl/digest-md5. I removed a lot of code from repl5_connection that is now done with just slapi_ldap_init_ext and slapi_ldap_bind. One tricky part of the replication code is that it polls the connection for write available, using some ldap sdk internals. I had to fix that code to work within the public ldap api since nspr and sasl muck with the internals in different incompatible ways. Finally, there is a lot of new kerberos code in the server. The way the server does sasl/gssapi auth with its keytab is similar to the way it does client cert auth with its ssl server cert. One big difference is that the server cannot pass the kerberos identity and credentials through the ldap/sasl/gssapi layers directly. Instead, we have to create a memory credentials cache and set the environment variable to point to it. This allows the sasl/gssapi layer to grab the credentials for use with kerberos. The way the code is written, it should also allow "external" kerberos auth e.g. if someone really wants to do some script which does a periodic kinit to refresh the file based cache, that should also work. I added some kerberos configure options. configure tries to first use krb5-config to get the compiler and linker information. If that fails, it just looks for some standard system libraries. Note that Solaris does not allow direct use of the kerberos api until Solaris 11, so most likely Solaris builds will have to use --without-kerberos (--with-kerberos is on by default). Platforms tested: Fedora 9, Fedora 8 Flag Day: yes Doc impact: oh yes https://bugzilla.redhat.com/attachment.cgi?id=322014&action=diff https://bugzilla.redhat.com/attachment.cgi?id=322015

1 0

[Fedora-directory-devel] How to implement Extended DNs for Samba4?
by Andrew Bartlett 21 Oct '08

21 Oct '08

At the CIFS plugfest it became clear that Samba3 requires that we complete the implementation of 'extended DN' replies in the Samba4 LDAP server. This means that a DN in things like memberOf are in the form: <GUID=0bc11d00-e431-40a0-8767-344a320142fa>;<SID=S-1-2-3-2345>;cn=abartlet,cn=users,dc=abartlet,dc=net (or so, I've just made this one up) If the magic 'extended DN' control is specificed, then we have to return this form to the client, and it would work really well to store it in that form on the backend, and if they do not specify the control, only then strip it back to the 'normal' DN. The problem is now particularly how to implement these locally - inside Samba4 it should be pretty easy to have the right triggers in the existing memberOf module, but how to implement this in OpenLDAP and (eventually) FedoraDS. Currently OpenLDAP uses the refint and memberOf modules, knowing that this attribute is simply a DN, nothing more. These modules (and probably the input validation) will no doubt be unable to cope with the 'extended' DN form. Is it reasonable to ask that OpenLDAP carry a module so Samba-specific in it's application (reading the objectSid and entryUUID and formatting the link that way)? Should we try to just fill this in with another search as part of the search entry callback? (at great performance cost). Any thoughts? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com

3 8

[Fedora-directory-devel] Redux: Please review: Bugs 455026, 441026 - RFE: include RFC4876 schema - Autofs does not include LDAP schema for Fedora Directory Server
by Rich Megginson 16 Oct '08

16 Oct '08

https://bugzilla.redhat.com/show_bug.cgi?id=455026 https://bugzilla.redhat.com/show_bug.cgi?id=441026 Resolves: bug 455026 bug 441026 Bug Description: RFE: include RFC4876 schema - Autofs does not include LDAP schema for Fedora Directory Server Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Pieter D.J. Krul has contributed many schema files that have been tested in production environments. They are divided into two groups - those that conflict with existing schema in DS, CertSys, and IPA, and those which do not. The latter are installed in the default schema directory to be available for new instances - the former are installed in the data directory just as the rfc2307bis schema. The schema provided cover autofs and rfc4876, as in the bug reports, and more. Here is the full list of new files: 60trust.ldif 60pureftpd.ldif 60sudo.ldif 60nis.ldif 60samba.ldif 60mozilla.ldif 60samba3.ldif 60krb5kdc.ldif 60sabayon.ldif 60kerberos.ldif 60rfc4876.ldif 60inetmail.ldif 60rfc3712.ldif 60eduperson.ldif 60rfc2739.ldif 60changelog.ldif 60radius.ldif 60autofs.ldif 60qmail.ldif Platforms tested: RHEL5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=319966&action=diff -- Fedora-directory-devel mailing list Fedora-directory-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-devel

1 0

[Fedora-directory-devel] Please review: Bugs 455026, 441026 - RFE: include RFC4876 schema - Autofs does not include LDAP schema for Fedora Directory Server
by Rich Megginson 09 Oct '08

09 Oct '08

1 0

[Fedora-directory-devel] Please review: Bug 454030 - Need to address 64-bit compiler warnings - part 1
by Rich Megginson 01 Oct '08

01 Oct '08

https://bugzilla.redhat.com/show_bug.cgi?id=454030 Resolves: bug 454030 Bug Description: Need to address 64-bit compiler warnings - part 1 Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The intptr_t and uintptr_t are types which are defined as integer types that are the same size as the pointer (void *) type. On the platforms we currently support, this is the same as long and unsigned long, respectively (ILP32 and LP64). However, intptr_t and uintptr_t are more portable. These can be used to assign a value passed as a void * to get an integer value, then "cast down" to an int or PRBool, and vice versa. This seems to be a common idiom in other applications where values must be passed as void *. For the printf/scanf formats, there is a standard header called inttypes.h which defines formats to use for various 64 bit quantities, so that you don't need to figure out if you have to use %lld or %ld for a 64-bit value - you just use PRId64 which is set to the correct value. I also assumed that size_t is defined as the same size as a pointer so I used the PRIuPTR format macro for size_t. I removed many unused variables and some unused functions. I put parentheses around assignments in conditional expressions to tell the compiler not to complain about them. I cleaned up some #defines that were defined more than once. I commented out some unused goto labels. Some of our header files shared among several source files define static variables. I made it so that those variables are not defined unless a macro is set in the source file. This avoids a lot of unused variable warnings. I added some return values to functions that were declared as returning a value but did not return a value. In all of these cases no one was checking the return value anyway. I put explicit parentheses around cases like this: expr || expr && expr - the && has greater precedence than the ||. The compiler complains because it wants you to make sure you mean expr || (expr && expr), not (expr || expr) && expr. I cleaned up several places where the compiler was complaining about possible use of uninitialized variables. There are still a lot of these cases remaining. There are a lot of warnings like this: lib/ldaputil/certmap.c:1279: warning: dereferencing type-punned pointer will break strict-aliasing rules These are due to our use of void ** to pass in addresses of addresses of structures. Many of these are calls to slapi_ch_free, but many are not - they are cases where we do not know what the type is going to be and may have to cast and modify the structure or pointer. I started replacing the calls to slapi_ch_free with slapi_ch_free_string, but there are many many more that need to be fixed. The dblayer code also contains a fix for https://bugzilla.redhat.com/show_bug.cgi?id=463991 - instead of checking for dbenv->foo_handle to see if a db "feature" is enabled, instead check the flags passed to open the dbenv. This works for bdb 4.2 through bdb 4.7 and probably other releases as well. Platforms tested: RHEL5 x86_64, Fedora 8 i386 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=318201&action=diff

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel October 2008