From rmeggins at redhat.com Wed Oct 1 14:54:24 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 01 Oct 2008 08:54:24 -0600 Subject: [Fedora-directory-devel] Please review: Bug 454030 - Need to address 64-bit compiler warnings - part 1 Message-ID: <48E38F20.2020404@redhat.com> 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 From rmeggins at redhat.com Fri Oct 10 01:31:43 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 09 Oct 2008 19:31:43 -0600 Subject: [Fedora-directory-devel] Please review: Bugs 455026, 441026 - RFE: include RFC4876 schema - Autofs does not include LDAP schema for Fedora Directory Server Message-ID: <48EEB07F.3080007@redhat.com> 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 From rmeggins at redhat.com Thu Oct 16 14:16:50 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 16 Oct 2008 08:16:50 -0600 Subject: [Fedora-directory-devel] Redux: Please review: Bugs 455026, 441026 - RFE: include RFC4876 schema - Autofs does not include LDAP schema for Fedora Directory Server Message-ID: <48F74CD2.6040002@redhat.com> 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 at redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Tue Oct 21 06:58:36 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 21 Oct 2008 17:58:36 +1100 Subject: [Fedora-directory-devel] How to implement Extended DNs for Samba4? Message-ID: <1224572316.3494.82.camel@ruth> 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: ;;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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From hyc at symas.com Tue Oct 21 07:21:35 2008 From: hyc at symas.com (Howard Chu) Date: Tue, 21 Oct 2008 00:21:35 -0700 Subject: [Fedora-directory-devel] Re: How to implement Extended DNs for Samba4? In-Reply-To: <1224572316.3494.82.camel@ruth> References: <1224572316.3494.82.camel@ruth> Message-ID: <48FD82FF.3040409@symas.com> Andrew Bartlett wrote: > 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: > > ;;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. In the past I've proposed a UUIDAndName syntax for references, instead of just DN-based references. (But SID is still a bit too specific...) > 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? We already carry a bunch of Samba-related modules in our contrib branch. I don't see any problem with adding this one. In this case all you need is a module to implement parsing and processing of your magic Extended DN control. Frankly, I can see this being generally useful, if you define the semantics broadly enough. For example, the request control could take a data argument providing: MagicData ::= SEQUENCE of DerefSpec DerefSpec ::= SEQUENCE { DerefAttr attributedescription, attributes attrlist } attrlist ::= SEQUENCE of attr attributedescription So for each DerefAttr, dereference the name and extract the attributes from the target entry, and return them all in the response control. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From abartlet at samba.org Tue Oct 21 09:02:43 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 21 Oct 2008 20:02:43 +1100 Subject: [Fedora-directory-devel] Re: How to implement Extended DNs for Samba4? In-Reply-To: <48FD82FF.3040409@symas.com> References: <1224572316.3494.82.camel@ruth> <48FD82FF.3040409@symas.com> Message-ID: <1224579763.3811.35.camel@naomi.s4.naomi.abartlet.net> On Tue, 2008-10-21 at 00:21 -0700, Howard Chu wrote: > Andrew Bartlett wrote: > > At the CIFS plugfest it became clear that Samba3 requires that we > > complete the implementation of 'extended DN' replies in the Samba4 LDAP > > server. > We already carry a bunch of Samba-related modules in our contrib branch. I > don't see any problem with adding this one. In this case all you need is a > module to implement parsing and processing of your magic Extended DN control. OK. > Frankly, I can see this being generally useful, if you define the semantics > broadly enough. For example, the request control could take a data argument > providing: > MagicData ::= SEQUENCE of DerefSpec > > DerefSpec ::= SEQUENCE { > DerefAttr attributedescription, > attributes attrlist } > > attrlist ::= SEQUENCE of attr attributedescription > > So for each DerefAttr, dereference the name and extract the attributes from > the target entry, and return them all in the response control. I would really, really love to have someone knock up a module like this for me. (I'm unlikely to do so successfully). The only comment I have is that these links would need to cross database boundaries (like the refint and memberof modules now do). We should also possibly have some way to work when pointing at targets outside the current directory (which we don't support at the moment, but I'm told we will need to support). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ando at sys-net.it Tue Oct 21 09:25:39 2008 From: ando at sys-net.it (Pierangelo Masarati) Date: Tue, 21 Oct 2008 11:25:39 +0200 Subject: [Fedora-directory-devel] Re: How to implement Extended DNs for Samba4? In-Reply-To: <48FD82FF.3040409@symas.com> References: <1224572316.3494.82.camel@ruth> <48FD82FF.3040409@symas.com> Message-ID: <48FDA013.6040008@sys-net.it> Howard Chu wrote: >> 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? > > We already carry a bunch of Samba-related modules in our contrib branch. > I don't see any problem with adding this one. In this case all you need > is a module to implement parsing and processing of your magic Extended > DN control. > > Frankly, I can see this being generally useful, if you define the > semantics broadly enough. For example, the request control could take a > data argument providing: > MagicData ::= SEQUENCE of DerefSpec > > DerefSpec ::= SEQUENCE { > DerefAttr attributedescription, > attributes attrlist } > > attrlist ::= SEQUENCE of attr attributedescription > > So for each DerefAttr, dereference the name and extract the attributes > from the target entry, and return them all in the response control. I see a few issues: - the resulting values do not conform to RFC4514; this could create interoperability issues with other modules plugged in that receive mucked DN-valued attrs, including the entry's name itself - according to the definition of 1.2.840.113556.1.4.529, the GUID and the DN parts must always be present; we do not have any GUID (unless we think of casting entryUUID to GUID or something the like) In any case, the module would need to perform a subsearch anyway for each DN-valued attr that is being returned, in order to gather the required information, possibly with the exception of the entry's DN (in this case, it would suffice to add the attributes needed by the extended DN to the requested attrs). We should also implement a call that parses a mucked DN value to support the extraction of the additional AVAs; something like ldap_str2extdn() (and possibly ldap_extdn2str()?). I probably can prototype this in the week-end, with the above caveats. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando at sys-net.it ----------------------------------- From abartlet at samba.org Tue Oct 21 09:39:58 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 21 Oct 2008 20:39:58 +1100 Subject: [Fedora-directory-devel] Re: How to implement Extended DNs for Samba4? In-Reply-To: <48FDA013.6040008@sys-net.it> References: <1224572316.3494.82.camel@ruth> <48FD82FF.3040409@symas.com> <48FDA013.6040008@sys-net.it> Message-ID: <1224581998.26316.2.camel@naomi.s4.naomi.abartlet.net> On Tue, 2008-10-21 at 11:25 +0200, Pierangelo Masarati wrote: > Howard Chu wrote: > >> 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? > > > > We already carry a bunch of Samba-related modules in our contrib branch. > > I don't see any problem with adding this one. In this case all you need > > is a module to implement parsing and processing of your magic Extended > > DN control. > > > > Frankly, I can see this being generally useful, if you define the > > semantics broadly enough. For example, the request control could take a > > data argument providing: > > MagicData ::= SEQUENCE of DerefSpec > > > > DerefSpec ::= SEQUENCE { > > DerefAttr attributedescription, > > attributes attrlist } > > > > attrlist ::= SEQUENCE of attr attributedescription > > > > So for each DerefAttr, dereference the name and extract the attributes > > from the target entry, and return them all in the response control. > > I see a few issues: > > - the resulting values do not conform to RFC4514; this could create > interoperability issues with other modules plugged in that receive > mucked DN-valued attrs, including the entry's name itself > > - according to the definition of 1.2.840.113556.1.4.529, the GUID and > the DN parts must always be present; we do not have any GUID (unless we > think of casting entryUUID to GUID or something the like) I always take entryUUID as the GUID. > In any case, the module would need to perform a subsearch anyway for > each DN-valued attr that is being returned, in order to gather the > required information, possibly with the exception of the entry's DN (in > this case, it would suffice to add the attributes needed by the extended > DN to the requested attrs). > > We should also implement a call that parses a mucked DN value to support > the extraction of the additional AVAs; something like ldap_str2extdn() > (and possibly ldap_extdn2str()?). > > I probably can prototype this in the week-end, with the above caveats. I look forward to seeing what we can make work. Thanks! Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From hyc at symas.com Tue Oct 21 10:35:54 2008 From: hyc at symas.com (Howard Chu) Date: Tue, 21 Oct 2008 03:35:54 -0700 Subject: [Fedora-directory-devel] Re: How to implement Extended DNs for Samba4? In-Reply-To: <48FDA013.6040008@sys-net.it> References: <1224572316.3494.82.camel@ruth> <48FD82FF.3040409@symas.com> <48FDA013.6040008@sys-net.it> Message-ID: <48FDB08A.6050702@symas.com> Pierangelo Masarati wrote: > Howard Chu wrote: >>> 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? >> We already carry a bunch of Samba-related modules in our contrib branch. >> I don't see any problem with adding this one. In this case all you need >> is a module to implement parsing and processing of your magic Extended >> DN control. >> >> Frankly, I can see this being generally useful, if you define the >> semantics broadly enough. For example, the request control could take a >> data argument providing: >> MagicData ::= SEQUENCE of DerefSpec >> >> DerefSpec ::= SEQUENCE { >> DerefAttr attributedescription, >> attributes attrlist } >> >> attrlist ::= SEQUENCE of attr attributedescription >> >> So for each DerefAttr, dereference the name and extract the attributes >> from the target entry, and return them all in the response control. > > I see a few issues: > > - the resulting values do not conform to RFC4514; this could create > interoperability issues with other modules plugged in that receive > mucked DN-valued attrs, including the entry's name itself I think you misunderstood my proposal. I'm not suggesting we muck with the returned DNs at all; the extra information will only appear in the response control. > - according to the definition of 1.2.840.113556.1.4.529, the GUID and > the DN parts must always be present; we do not have any GUID (unless we > think of casting entryUUID to GUID or something the like) entryUUID == GUID. > In any case, the module would need to perform a subsearch anyway for > each DN-valued attr that is being returned, in order to gather the > required information, possibly with the exception of the entry's DN (in > this case, it would suffice to add the attributes needed by the extended > DN to the requested attrs). Right. But perhaps we should stop referring to it as an "extended DN," since we're not altering the DN at all. Call it something like Subsearch or Dereference control (or something...). We just need to provide ldap_create_subsearch_control() and ldap_parse_subsearchresponse_control(). -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From abartlet at samba.org Tue Oct 21 10:41:13 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 21 Oct 2008 21:41:13 +1100 Subject: [Fedora-directory-devel] Re: How to implement Extended DNs for Samba4? In-Reply-To: <48FDB08A.6050702@symas.com> References: <1224572316.3494.82.camel@ruth> <48FD82FF.3040409@symas.com> <48FDA013.6040008@sys-net.it> <48FDB08A.6050702@symas.com> Message-ID: <1224585673.26316.33.camel@naomi.s4.naomi.abartlet.net> On Tue, 2008-10-21 at 03:35 -0700, Howard Chu wrote: > Pierangelo Masarati wrote: > > Howard Chu wrote: > >>> 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? > >> We already carry a bunch of Samba-related modules in our contrib branch. > >> I don't see any problem with adding this one. In this case all you need > >> is a module to implement parsing and processing of your magic Extended > >> DN control. > >> > >> Frankly, I can see this being generally useful, if you define the > >> semantics broadly enough. For example, the request control could take a > >> data argument providing: > >> MagicData ::= SEQUENCE of DerefSpec > >> > >> DerefSpec ::= SEQUENCE { > >> DerefAttr attributedescription, > >> attributes attrlist } > >> > >> attrlist ::= SEQUENCE of attr attributedescription > >> > >> So for each DerefAttr, dereference the name and extract the attributes > >> from the target entry, and return them all in the response control. > > > > I see a few issues: > > > > - the resulting values do not conform to RFC4514; this could create > > interoperability issues with other modules plugged in that receive > > mucked DN-valued attrs, including the entry's name itself > > I think you misunderstood my proposal. I'm not suggesting we muck with the > returned DNs at all; the extra information will only appear in the response > control. So the response control would contain lists of attribute/value pairs along with their associated data? (So I can then fit them back into the right place for the AD reply) > > - according to the definition of 1.2.840.113556.1.4.529, the GUID and > > the DN parts must always be present; we do not have any GUID (unless we > > think of casting entryUUID to GUID or something the like) > > entryUUID == GUID. > > > In any case, the module would need to perform a subsearch anyway for > > each DN-valued attr that is being returned, in order to gather the > > required information, possibly with the exception of the entry's DN (in > > this case, it would suffice to add the attributes needed by the extended > > DN to the requested attrs). > > Right. But perhaps we should stop referring to it as an "extended DN," since > we're not altering the DN at all. Call it something like Subsearch or > Dereference control (or something...). We just need to provide > ldap_create_subsearch_control() and ldap_parse_subsearchresponse_control(). Well, that's just the Microsoft name for it, that's all. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ando at sys-net.it Tue Oct 21 10:44:34 2008 From: ando at sys-net.it (Pierangelo Masarati) Date: Tue, 21 Oct 2008 12:44:34 +0200 Subject: [Fedora-directory-devel] Re: How to implement Extended DNs for Samba4? In-Reply-To: <48FDB08A.6050702@symas.com> References: <1224572316.3494.82.camel@ruth> <48FD82FF.3040409@symas.com> <48FDA013.6040008@sys-net.it> <48FDB08A.6050702@symas.com> Message-ID: <48FDB292.5060509@sys-net.it> Howard Chu wrote: > I think you misunderstood my proposal. I'm not suggesting we muck with > the returned DNs at all; the extra information will only appear in the > response control. So you mean adding a response control value made of something like controlValue ::= SEQUENCE { extended extendedDN } extendedDN ::= SEQUENCE { attrval attrVal } attrVal ::= { attrspec attrSpec, value octetString } where the sequence of attrSpec was specified in the control request. In the case at hand, the control request would contain GUID, SID and entryDN. Is this what you mean? Then, it would be the client's task to use the response to build a string in the format specified by 1.2.840.113556.1.4.529. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando at sys-net.it ----------------------------------- From hyc at symas.com Tue Oct 21 10:49:52 2008 From: hyc at symas.com (Howard Chu) Date: Tue, 21 Oct 2008 03:49:52 -0700 Subject: [Fedora-directory-devel] Re: How to implement Extended DNs for Samba4? In-Reply-To: <48FDB292.5060509@sys-net.it> References: <1224572316.3494.82.camel@ruth> <48FD82FF.3040409@symas.com> <48FDA013.6040008@sys-net.it> <48FDB08A.6050702@symas.com> <48FDB292.5060509@sys-net.it> Message-ID: <48FDB3D0.7030600@symas.com> Pierangelo Masarati wrote: > Howard Chu wrote: > >> I think you misunderstood my proposal. I'm not suggesting we muck with >> the returned DNs at all; the extra information will only appear in the >> response control. > > So you mean adding a response control value made of something like > > controlValue ::= SEQUENCE { > extended extendedDN > } > > extendedDN ::= SEQUENCE { > attrval attrVal > } > > attrVal ::= { > attrspec attrSpec, > value octetString > } > > where the sequence of attrSpec was specified in the control request. In > the case at hand, the control request would contain GUID, SID and > entryDN. Is this what you mean? Then, it would be the client's task to > use the response to build a string in the format specified by > 1.2.840.113556.1.4.529. Yes, that's what I had in mind. The question is whether that's sufficient for Samba's purposes; the control that I've described is sufficiently general that it would be useful for a lot of other cases. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From rmeggins at redhat.com Fri Oct 31 02:16:23 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 30 Oct 2008 20:16:23 -0600 Subject: [Fedora-directory-devel] Please review: Bug 469261 - Support server-to-server SASL Message-ID: <490A6A77.3050608@redhat.com> 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