From jhrozek at redhat.com Mon Jun 1 08:46:16 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 01 Jun 2009 10:46:16 +0200 Subject: [Freeipa-devel] [PATCH] Add more manpages In-Reply-To: <4A1FEF0A.3030608@redhat.com> References: <1243545718.30689.6.camel@hendrix> <4A1FCF58.9010004@redhat.com> <1243600444.431.27.camel@zeppelin.englab.brq.redhat.com> <4A1FD865.3020003@redhat.com> <1243602901.431.32.camel@zeppelin.englab.brq.redhat.com> <4A1FE02C.7070904@redhat.com> <4A1FEF0A.3030608@redhat.com> Message-ID: <1243845976.27557.33.camel@zeppelin.englab.brq.redhat.com> On Fri, 2009-05-29 at 10:19 -0400, Stephen Gallagher wrote: > > I'm rescinding my ack. I reviewed that the changes had been merged, > but > I just now attempted to apply this patch and git gives the following > errors: I messed with my tree and maybe sent the wrong patch, my apologies. Attached is another one, I've verified that it applies cleanly on top of origin/master, also no whitespace errors. Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-more-manpages.patch Type: text/x-patch Size: 27703 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jhrozek at redhat.com Mon Jun 1 12:31:48 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 01 Jun 2009 14:31:48 +0200 Subject: [Freeipa-devel] [PATCH] Add more manpages In-Reply-To: <1243845976.27557.33.camel@zeppelin.englab.brq.redhat.com> References: <1243545718.30689.6.camel@hendrix> <4A1FCF58.9010004@redhat.com> <1243600444.431.27.camel@zeppelin.englab.brq.redhat.com> <4A1FD865.3020003@redhat.com> <1243602901.431.32.camel@zeppelin.englab.brq.redhat.com> <4A1FE02C.7070904@redhat.com> <4A1FEF0A.3030608@redhat.com> <1243845976.27557.33.camel@zeppelin.englab.brq.redhat.com> Message-ID: <1243859508.27557.62.camel@zeppelin.englab.brq.redhat.com> On Mon, 2009-06-01 at 10:46 +0200, Jakub Hrozek wrote: > I messed with my tree and maybe sent the wrong patch, my apologies. > > Attached is another one, I've verified that it applies cleanly on top > of > origin/master, also no whitespace errors. > > Jakub There have been some problems with the patch probably related to a client mangling it. I'm resending the same patch in a tarball. Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-more-manpages.patch.tar Type: application/x-tar Size: 30720 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sgallagh at redhat.com Mon Jun 1 14:11:44 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 01 Jun 2009 10:11:44 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Suppress "rootdse" messages from confdb Message-ID: <4A23E1A0.2000107@redhat.com> In the earlier patch, I had meant to do this but I accidentally had the commands out of order, so the initial error message came through before they were suppressed. This will fix it. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Suppress-rootdse-error-messages-from-the-confdb.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Mon Jun 1 14:14:03 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 01 Jun 2009 10:14:03 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Do not statically link data provider plugins Message-ID: <4A23E22B.3030000@redhat.com> When I converted the SSSD to automake, I inadvertently left out the -export-dynamic flag for building the data provider backend executable. As a result, we were getting missing symbol errors, so as an (incorrect) fix, I had been statically linking our utility libraries into the plugins. This patch should fix them so that they correctly resolve these symbols from the sssd_be executable. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-Do-not-statically-link-data-provider-plugins.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Mon Jun 1 14:16:24 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 01 Jun 2009 10:16:24 -0400 Subject: [Freeipa-devel] [PATCH] Add more manpages In-Reply-To: <1243859508.27557.62.camel@zeppelin.englab.brq.redhat.com> References: <1243545718.30689.6.camel@hendrix> <4A1FCF58.9010004@redhat.com> <1243600444.431.27.camel@zeppelin.englab.brq.redhat.com> <4A1FD865.3020003@redhat.com> <1243602901.431.32.camel@zeppelin.englab.brq.redhat.com> <4A1FE02C.7070904@redhat.com> <4A1FEF0A.3030608@redhat.com> <1243845976.27557.33.camel@zeppelin.englab.brq.redhat.com> <1243859508.27557.62.camel@zeppelin.englab.brq.redhat.com> Message-ID: <4A23E2B8.1010905@redhat.com> On 06/01/2009 08:31 AM, Jakub Hrozek wrote: > On Mon, 2009-06-01 at 10:46 +0200, Jakub Hrozek wrote: >> I messed with my tree and maybe sent the wrong patch, my apologies. >> >> Attached is another one, I've verified that it applies cleanly on top >> of >> origin/master, also no whitespace errors. >> >> Jakub > > There have been some problems with the patch probably related to a > client mangling it. I'm resending the same patch in a tarball. > > Jakub Ack, working this time. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Jun 1 15:08:28 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 01 Jun 2009 11:08:28 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Suppress "rootdse" messages from confdb In-Reply-To: <4A23E1A0.2000107@redhat.com> References: <4A23E1A0.2000107@redhat.com> Message-ID: <1243868908.4093.29.camel@localhost.localdomain> On Mon, 2009-06-01 at 10:11 -0400, Stephen Gallagher wrote: > In the earlier patch, I had meant to do this but I accidentally had > the > commands out of order, so the initial error message came through > before > they were suppressed. This will fix it. Ack and pushed. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Jun 1 15:08:46 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 01 Jun 2009 11:08:46 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Do not statically link data provider plugins In-Reply-To: <4A23E22B.3030000@redhat.com> References: <4A23E22B.3030000@redhat.com> Message-ID: <1243868926.4093.30.camel@localhost.localdomain> On Mon, 2009-06-01 at 10:14 -0400, Stephen Gallagher wrote: > When I converted the SSSD to automake, I inadvertently left out the > -export-dynamic flag for building the data provider backend executable. > As a result, we were getting missing symbol errors, so as an (incorrect) > fix, I had been statically linking our utility libraries into the > plugins. This patch should fix them so that they correctly resolve these > symbols from the sssd_be executable. Ack and pushed. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Jun 1 15:09:00 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 01 Jun 2009 11:09:00 -0400 Subject: [Freeipa-devel] [PATCH] Add more manpages In-Reply-To: <4A23E2B8.1010905@redhat.com> References: <1243545718.30689.6.camel@hendrix> <4A1FCF58.9010004@redhat.com> <1243600444.431.27.camel@zeppelin.englab.brq.redhat.com> <4A1FD865.3020003@redhat.com> <1243602901.431.32.camel@zeppelin.englab.brq.redhat.com> <4A1FE02C.7070904@redhat.com> <4A1FEF0A.3030608@redhat.com> <1243845976.27557.33.camel@zeppelin.englab.brq.redhat.com> <1243859508.27557.62.camel@zeppelin.englab.brq.redhat.com> <4A23E2B8.1010905@redhat.com> Message-ID: <1243868940.4093.31.camel@localhost.localdomain> On Mon, 2009-06-01 at 10:16 -0400, Stephen Gallagher wrote: > On 06/01/2009 08:31 AM, Jakub Hrozek wrote: > > On Mon, 2009-06-01 at 10:46 +0200, Jakub Hrozek wrote: > >> I messed with my tree and maybe sent the wrong patch, my apologies. > >> > >> Attached is another one, I've verified that it applies cleanly on top > >> of > >> origin/master, also no whitespace errors. > >> > >> Jakub > > > > There have been some problems with the patch probably related to a > > client mangling it. I'm resending the same patch in a tarball. > > > > Jakub > > Ack, working this time. Pushed. Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Mon Jun 1 16:01:13 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 01 Jun 2009 12:01:13 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Enable quiet builds for SSSD Message-ID: <4A23FB49.4000700@redhat.com> With this patch, if automake >= 1.11 is available, the configure option '--enable-silent-rules' will suppress most make output and show only the object being compiled. Tested using the pre-F12 RPM from http://koji.fedoraproject.org/koji/buildinfo?buildID=103564 The catch: autoreconf will throw a warning about AM_SILENT_RULES on platforms with automake < 1.11, but I have added an m4_pattern_allow() to permit it to build anyway. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Enable-quiet-build-for-automake-1.11.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Mon Jun 1 18:17:11 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 01 Jun 2009 20:17:11 +0200 Subject: [Freeipa-devel] [PATCHES] Fix bug where List parameters were always cloned with keywords parsed from name. + Remove unused reference to old LDAP backend in join plugin. + Make delegation plugin consistent with plugin2 and use new Crud methods. + Fix DS ACI parsing. + Add ACI plugin port to new LDAP backend. Message-ID: <4A241B27.5010007@redhat.com> Patch 0001: Fix bug where List parameters were always cloned with keywords parsed from name. For example, required List options were always cloned as required in crud.Search. Patch 0002: Remove unused reference to old LDAP backend in join plugin. Patch 0003: Make delegation plugin consistent with plugin2 and use new Crud methods. The delegation plugin doesn't do anything at this point, but I think we should get rid of the old Crud methods. Patch 0004: Fix DS ACI parsing. Parsing of ACI strings was faulty and didn't want to make friends with unicode. Patch 0005: Add ACI plugin port to new LDAP backend. It's more of a complete rewrite actually. I dropped the showall command, use aci2-find with no parameters instead. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-bug-where-List-parameters-where-always-cloned-wi.patch Type: application/mbox Size: 1677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Remove-unused-reference-to-old-LDAP-backend-in-join.patch Type: application/mbox Size: 728 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Make-delegation-plugin-consistent-with-plugins2-and.patch Type: application/mbox Size: 2709 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Fix-DS-ACI-parsing.patch Type: application/mbox Size: 1755 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Add-ACI-plugin-port-to-new-LDAP-backend.patch Type: application/mbox Size: 12966 bytes Desc: not available URL: From rcritten at redhat.com Mon Jun 1 18:49:32 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 01 Jun 2009 14:49:32 -0400 Subject: [Freeipa-devel] [PATCH] 227 virtual operations Message-ID: <4A2422BC.7080601@redhat.com> There are some operations, like those for the certificate system, that don't need to write to the directory server. So instead we have an entry that we test against to determine whether the operation is allowed or not. This is done by attempting a write on the entry. If it would succeed then permission is granted. If not then denied. The write we attempt is actually invalid so the write itself will fail but the attempt will fail first if access is not permitted, so we can distinguish between the two without polluting the entry. To use this you subclass from the VirtualCommand class, then make a call to super() to invoke the ACI enforcement. You also need to create the virtual entry to test against, and perhaps set set of role and task groups for delegation purposes. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-227-virtual.patch Type: application/mbox Size: 13699 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Jun 1 21:11:02 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 01 Jun 2009 17:11:02 -0400 Subject: [Freeipa-devel] [PATCHES] minor stuff and a nasty surprise Message-ID: <1243890662.5965.11.camel@localhost.localdomain> See commit comments. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-add-utility-function-talloc_zfree.patch Type: text/x-patch Size: 765 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-nasty-bug-in-rendering-the-password-field.patch Type: text/x-patch Size: 1118 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Don-t-mix-strdup-and-static-strings.patch Type: text/x-patch Size: 810 bytes Desc: not available URL: From sbose at redhat.com Tue Jun 2 08:13:37 2009 From: sbose at redhat.com (Sumit Bose) Date: Tue, 02 Jun 2009 10:13:37 +0200 Subject: [Freeipa-devel] [PATCHES] minor stuff and a nasty surprise In-Reply-To: <1243890662.5965.11.camel@localhost.localdomain> References: <1243890662.5965.11.camel@localhost.localdomain> Message-ID: <4A24DF31.3010108@redhat.com> Simo Sorce schrieb: > See commit comments. > > Simo. > > ACK, ACK and ACK. bye, Sumit From sbose at redhat.com Tue Jun 2 12:17:28 2009 From: sbose at redhat.com (Sumit Bose) Date: Tue, 02 Jun 2009 14:17:28 +0200 Subject: [Freeipa-devel] [PATCH][SSSD] Enable quiet builds for SSSD In-Reply-To: <4A23FB49.4000700@redhat.com> References: <4A23FB49.4000700@redhat.com> Message-ID: <4A251858.2030300@redhat.com> Stephen Gallagher schrieb: > With this patch, if automake >= 1.11 is available, the configure option > '--enable-silent-rules' will suppress most make output and show only the > object being compiled. > > Tested using the pre-F12 RPM from > http://koji.fedoraproject.org/koji/buildinfo?buildID=103564 > > The catch: autoreconf will throw a warning about AM_SILENT_RULES on > platforms with automake < 1.11, but I have added an m4_pattern_allow() > to permit it to build anyway. > it doesn't break anything in my F10 system, but there are some warnings about AM_SILENT_RULES when running autoreconf and configure. I would recommend to add some explanations to BUILD.txt when adding the patch. bye, Sumit From mnagy at redhat.com Tue Jun 2 12:24:38 2009 From: mnagy at redhat.com (Martin Nagy) Date: Tue, 2 Jun 2009 14:24:38 +0200 Subject: [Freeipa-devel] [PATCH] Integrate the DNS LDAP back-end In-Reply-To: <4A1D4882.5050307@redhat.com> References: <20090512233222.2c5d79d8@notas> <20090522193739.5a427a4e@wolverine.englab.brq.redhat.com> <4A1D4882.5050307@redhat.com> Message-ID: <20090602142438.7b995c4c@wolverine.englab.brq.redhat.com> On Wed, 27 May 2009 10:04:50 -0400, Rob Crittenden wrote: > Martin Nagy wrote: > > New series. It's based on the current top of the tree. I removed the > > "recursion no" from named.conf, since right now it breaks the > > driver. Also some cosmetic changes, but otherwise the same.. > > > > Martin > > Looks good. ack x4. > > rob Pushed. > > > > > On Tue, 12 May 2009 23:32:22 +0200, Martin Nagy > > wrote: > > > >> Hi, > >> this patch series will integrate the LDAP driver into the FreeIPA > >> install script (better late than never..). To get the driver code: > >> > >> git clone git://github.com/mnagy/bind-dyndb-ldap.git > >> > >> There's a README file with instructions for building and > >> installing. The plug-in is available in F-11, but since getting > >> updates there is pretty hard, you'll be better off with the git > >> tree and make install, I won't be updating the package in F-11 > >> very often, at least not for now. Unfortunately, I found a bug > >> when testing the driver with IPA that will cause any read queries > >> to be denied. I'll try to fix that as soon as possible. > >> > >> You will also need the latest bind package either from the F-11 or > >> devel branch (at least version 9.6.1-0.3.b1). Or you can grab a > >> patch from http://github.com/mnagy/bind-dynamic_db/downloads > >> > >> For now the plug-in will bind anonymously and won't be able to > >> update. It could do that, but for now I would have to put the DS > >> password to the config file.. I don't expect that we want to be > >> able to dynamically update the initial zone, so hopefully this is > >> ok for now. > >> > >> I tried to install freeipa with this patch on a clean VM and didn't > >> hit any problems (well, yeah, I did, but I fixed them before > >> submitting ;). Any questions and criticism is welcome. Thanks. > >> > >> Martin > >> > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Freeipa-devel mailing list > >> Freeipa-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-devel > From rcritten at redhat.com Tue Jun 2 13:34:14 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 02 Jun 2009 09:34:14 -0400 Subject: [Freeipa-devel] [PATCH] jderose 010 improve epydoc generation In-Reply-To: <1243627844.6269.8.camel@jgd-dsk> References: <1243627844.6269.8.camel@jgd-dsk> Message-ID: <4A252A56.1010402@redhat.com> Jason Gerard DeRose wrote: > This patch cleans up the ./make-doc script and starts to incorporate it > into the Makefile. In summary, it: > > 1. Adds a doc/api/README file > > 2. Cleans up ./make-doc, which now outputs the epydoc pages in > doc/api > > 3. Adds a BuildRequires for `epydoc` and `python-docutils` to > ipa.spec.in > > 4. Adds a `doc` target in the Makefile > > Rob, when you have time could you incorporate this properly into the > Makefile and spec file? Or if you could walk me through the process on > IRC. ;) I discussed this with Simo in #freeipa-devel yesterday and we aren't sure that we want to ship the developer documentation. I think that just adding the make target is likely enough. You'll also need to rename the make target. Since there is a 'doc' subdirectory already a 'make doc' will report something like 'Nothing to be done for doc'. I think you'll need to name the target docs. And should this be added to the clean target? Also, I think the -f flag should be added to the rm command in make-doc when cleaning up before re-running epydoc. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Jun 2 13:49:18 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 02 Jun 2009 09:49:18 -0400 Subject: [Freeipa-devel] [PATCHES] minor stuff and a nasty surprise In-Reply-To: <4A24DF31.3010108@redhat.com> References: <1243890662.5965.11.camel@localhost.localdomain> <4A24DF31.3010108@redhat.com> Message-ID: <1243950558.3623.1.camel@localhost.localdomain> On Tue, 2009-06-02 at 10:13 +0200, Sumit Bose wrote: > Simo Sorce schrieb: > > See commit comments. > > > > Simo. > > > > > ACK, ACK and ACK. Pushed -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Jun 2 13:49:34 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 02 Jun 2009 09:49:34 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Enable quiet builds for SSSD In-Reply-To: <4A23FB49.4000700@redhat.com> References: <4A23FB49.4000700@redhat.com> Message-ID: <1243950574.3623.2.camel@localhost.localdomain> On Mon, 2009-06-01 at 12:01 -0400, Stephen Gallagher wrote: > > With this patch, if automake >= 1.11 is available, the configure > option > '--enable-silent-rules' will suppress most make output and show only > the > object being compiled. > > Tested using the pre-F12 RPM from > http://koji.fedoraproject.org/koji/buildinfo?buildID=103564 > > The catch: autoreconf will throw a warning about AM_SILENT_RULES on > platforms with automake < 1.11, but I have added an m4_pattern_allow() > to permit it to build anyway. Ack, and pushed. Simo. -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Tue Jun 2 14:57:42 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 02 Jun 2009 16:57:42 +0200 Subject: [Freeipa-devel] [PATCH] sssd.conf(5) man page Message-ID: <1243954662.27757.53.camel@zeppelin.englab.brq.redhat.com> Attached for discussion and review. To avoid problems with user agents, sent as a tarball. Backend-specific manual pages will come later today separately. Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-sssd.conf-5-man-page.patch.tar Type: application/x-tar Size: 30720 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sbose at redhat.com Tue Jun 2 16:16:50 2009 From: sbose at redhat.com (Sumit Bose) Date: Tue, 02 Jun 2009 18:16:50 +0200 Subject: [Freeipa-devel] [PATCH] added tls_reqcert option for native LDAP backend Message-ID: <4A255072.9010108@redhat.com> Hi, this patch should fix https://fedorahosted.org/sssd/ticket/31. bye, Sumit -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-added-tls_reqcert-option-for-native-LDAP-backend.patch Type: text/x-patch Size: 2719 bytes Desc: not available URL: From sgallagh at redhat.com Tue Jun 2 18:01:27 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 02 Jun 2009 14:01:27 -0400 Subject: [Freeipa-devel] [PATCH] sssd.conf(5) man page In-Reply-To: <1243954662.27757.53.camel@zeppelin.englab.brq.redhat.com> References: <1243954662.27757.53.camel@zeppelin.englab.brq.redhat.com> Message-ID: <4A2568F7.3080908@redhat.com> On 06/02/2009 10:57 AM, Jakub Hrozek wrote: > Attached for discussion and review. To avoid problems with user agents, > sent as a tarball. > > Backend-specific manual pages will come later today separately. > > Jakub > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Please see attached set of proposed cleanup. As before, this patch applies on top of the existing patch (to make it easy to see what changes I'm proposing). If you agree, please merge them in. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Proposed-cleanup-for-sssd.conf-5.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Tue Jun 2 18:05:04 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 02 Jun 2009 14:05:04 -0400 Subject: [Freeipa-devel] [PATCH] added tls_reqcert option for native LDAP backend In-Reply-To: <4A255072.9010108@redhat.com> References: <4A255072.9010108@redhat.com> Message-ID: <4A2569D0.5050206@redhat.com> On 06/02/2009 12:16 PM, Sumit Bose wrote: > Hi, > > this patch should fix https://fedorahosted.org/sssd/ticket/31. > > bye, > Sumit > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Looks good to me, except for one small typo. Please change: "DEBUG(1, ("Unknow value for tls_reqcert.\n"));" to "DEBUG(1, ("Unknown value for tls_reqcert.\n"));" -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sbose at redhat.com Tue Jun 2 18:24:19 2009 From: sbose at redhat.com (Sumit Bose) Date: Tue, 02 Jun 2009 20:24:19 +0200 Subject: [Freeipa-devel] [PATCH] added tls_reqcert option for native LDAP backend In-Reply-To: <4A2569D0.5050206@redhat.com> References: <4A255072.9010108@redhat.com> <4A2569D0.5050206@redhat.com> Message-ID: <4A256E53.30009@redhat.com> Stephen Gallagher schrieb: > On 06/02/2009 12:16 PM, Sumit Bose wrote: >> Hi, >> >> this patch should fix https://fedorahosted.org/sssd/ticket/31. >> >> bye, >> Sumit >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Looks good to me, except for one small typo. Please change: > "DEBUG(1, ("Unknow value for tls_reqcert.\n"));" > to > "DEBUG(1, ("Unknown value for tls_reqcert.\n"));" > > sorry, fixed -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-added-tls_reqcert-option-for-native-LDAP-backend.patch Type: text/x-patch Size: 2720 bytes Desc: not available URL: From jhrozek at redhat.com Tue Jun 2 18:28:57 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 02 Jun 2009 20:28:57 +0200 Subject: [Freeipa-devel] [PATCH] sssd.conf(5) man page In-Reply-To: <4A2568F7.3080908@redhat.com> References: <1243954662.27757.53.camel@zeppelin.englab.brq.redhat.com> <4A2568F7.3080908@redhat.com> Message-ID: <1243967337.27757.64.camel@zeppelin.englab.brq.redhat.com> On Tue, 2009-06-02 at 14:01 -0400, Stephen Gallagher wrote: > If you agree, please merge them in. Thank you, the changes look very good to me. Attached is a merged patch. Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-sssd.conf-5-man-page.patch Type: text/x-patch Size: 28577 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sgallagh at redhat.com Tue Jun 2 18:59:50 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 02 Jun 2009 14:59:50 -0400 Subject: [Freeipa-devel] [PATCH] added tls_reqcert option for native LDAP backend In-Reply-To: <4A256E53.30009@redhat.com> References: <4A255072.9010108@redhat.com> <4A2569D0.5050206@redhat.com> <4A256E53.30009@redhat.com> Message-ID: <4A2576A6.4090207@redhat.com> On 06/02/2009 02:24 PM, Sumit Bose wrote: > Stephen Gallagher schrieb: >> On 06/02/2009 12:16 PM, Sumit Bose wrote: >>> Hi, >>> >>> this patch should fix https://fedorahosted.org/sssd/ticket/31. >>> >>> bye, >>> Sumit >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Looks good to me, except for one small typo. Please change: >> "DEBUG(1, ("Unknow value for tls_reqcert.\n"));" >> to >> "DEBUG(1, ("Unknown value for tls_reqcert.\n"));" >> >> > > sorry, fixed > Ack -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Jun 2 19:33:59 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 02 Jun 2009 15:33:59 -0400 Subject: [Freeipa-devel] [PATCH] sssd.conf(5) man page In-Reply-To: <1243967337.27757.64.camel@zeppelin.englab.brq.redhat.com> References: <1243954662.27757.53.camel@zeppelin.englab.brq.redhat.com> <4A2568F7.3080908@redhat.com> <1243967337.27757.64.camel@zeppelin.englab.brq.redhat.com> Message-ID: <1243971239.3623.17.camel@localhost.localdomain> On Tue, 2009-06-02 at 20:28 +0200, Jakub Hrozek wrote: > On Tue, 2009-06-02 at 14:01 -0400, Stephen Gallagher wrote: > > If you agree, please merge them in. > > Thank you, the changes look very good to me. > > Attached is a merged patch. > ack and pushed Simo -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Jun 2 19:35:20 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 02 Jun 2009 15:35:20 -0400 Subject: [Freeipa-devel] [PATCH] added tls_reqcert option for native LDAP backend In-Reply-To: <4A256E53.30009@redhat.com> References: <4A255072.9010108@redhat.com> <4A2569D0.5050206@redhat.com> <4A256E53.30009@redhat.com> Message-ID: <1243971320.3623.18.camel@localhost.localdomain> On Tue, 2009-06-02 at 20:24 +0200, Sumit Bose wrote: > Stephen Gallagher schrieb: > > On 06/02/2009 12:16 PM, Sumit Bose wrote: > >> Hi, > >> > >> this patch should fix https://fedorahosted.org/sssd/ticket/31. > >> > > > > Looks good to me, except for one small typo. Please change: > > "DEBUG(1, ("Unknow value for tls_reqcert.\n"));" > > to > > "DEBUG(1, ("Unknown value for tls_reqcert.\n"));" > > > > > > sorry, fixed > ack and pushed. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Jun 2 19:39:54 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 02 Jun 2009 15:39:54 -0400 Subject: [Freeipa-devel] [PATCH] link sssd_be with -E In-Reply-To: <4A1FB6F5.2070202@redhat.com> References: <4A1FB32B.8000800@redhat.com> <4A1FB6F5.2070202@redhat.com> Message-ID: <1243971594.3623.19.camel@localhost.localdomain> On Fri, 2009-05-29 at 12:20 +0200, Sumit Bose wrote: > now with patch attached :) > Sumit Bose schrieb: > > Hi, > > > > I miss my debug messages :) > > > > This patch add -Wl,-E to the linker flags of sssd_be to restore the > > state before the autotools transition. > > > > But it might make sense to keep the backends self-contained and > allow a > > backend_debug_level parameter in the config file. If you prefer it > that > > way, please NACK this patch and I will provide a new one where this > > parameter is evaluated in the backend. > > > > bye, > > Sumit > > I think this patch is superseded by one of the latest patch from Steve, can you confirm Sumit ? Simo. -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Tue Jun 2 19:56:23 2009 From: sbose at redhat.com (Sumit Bose) Date: Tue, 02 Jun 2009 21:56:23 +0200 Subject: [Freeipa-devel] [PATCH] link sssd_be with -E In-Reply-To: <1243971594.3623.19.camel@localhost.localdomain> References: <4A1FB32B.8000800@redhat.com> <4A1FB6F5.2070202@redhat.com> <1243971594.3623.19.camel@localhost.localdomain> Message-ID: <4A2583E7.7040002@redhat.com> Simo Sorce schrieb: > On Fri, 2009-05-29 at 12:20 +0200, Sumit Bose wrote: >> now with patch attached :) >> Sumit Bose schrieb: >>> Hi, >>> >>> I miss my debug messages :) >>> >>> This patch add -Wl,-E to the linker flags of sssd_be to restore the >>> state before the autotools transition. >>> >>> But it might make sense to keep the backends self-contained and >> allow a >>> backend_debug_level parameter in the config file. If you prefer it >> that >>> way, please NACK this patch and I will provide a new one where this >>> parameter is evaluated in the backend. >>> >>> bye, >>> Sumit >>> > > I think this patch is superseded by one of the latest patch from Steve, > can you confirm Sumit ? > Yes, I can confirm. -E == --export-dynamic according to ld(1). bye, Sumit From rcritten at redhat.com Tue Jun 2 20:21:14 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 02 Jun 2009 16:21:14 -0400 Subject: [Freeipa-devel] [PATCHES] Fix bug where List parameters were always cloned with keywords parsed from name. + Remove unused reference to old LDAP backend in join plugin. + Make delegation plugin consistent with plugin2 and use new Crud methods. + Fix DS ACI parsing. + Add ACI plugin port to new LDAP backend. In-Reply-To: <4A241B27.5010007@redhat.com> References: <4A241B27.5010007@redhat.com> Message-ID: <4A2589BA.50106@redhat.com> Pavel Zuna wrote: > Patch 0001: Fix bug where List parameters were always cloned with > keywords parsed from name. > > For example, required List options were always cloned as required in > crud.Search. > > > Patch 0002: Remove unused reference to old LDAP backend in join plugin. > > > Patch 0003: Make delegation plugin consistent with plugin2 and use new > Crud methods. > > The delegation plugin doesn't do anything at this point, but I think we > should get rid of the old Crud methods. > > > Patch 0004: Fix DS ACI parsing. > > Parsing of ACI strings was faulty and didn't want to make friends with > unicode. > > > Patch 0005: Add ACI plugin port to new LDAP backend. > > It's more of a complete rewrite actually. I dropped the showall command, > use aci2-find with no parameters instead. > > > Pavel As a separate issue to the team, we have all been doing multiple patches per e-mail lately. I've found this to be difficult to review from time to time, particularly when one part of the patch gets nacked but the rest are ok (but perhaps related to the nack patch). Do we want to go back to 1-patch-per-e-mail? Patch 1-4 look fine. Pushed. I think the delegation plugin is going to go away though. It just does the "grant write on these attributes for group A to group B". The aci plugin can do much more (and is more dangerous too). Patch 5 nack. I think we really need a ListEnum but that's another story :-) Instead of normalize I think this should use a validate function for the permission types and not continue if unknown values are used. This silently drops unknown values so could have unknown side-effects. You're missing the dn argument when setting the target filter: + if 'memberof' in kw: + (dn, entry_attrs) = api.Command['group2_show'](kw['memberof']) + a.set_target_filter('memberOf=%s') The reason I didn't implement mod is that we don't currently have a way to say "remove this thing". So if you had an ACI that limited access by attributes there is no way to remove that. I suppose something is better than teasing with a command that is not implemented at all though. I'm still not sure I want to ship this with as a general-use plugin. I've used it to create the current set of ACIs but it is not for the faint of heart, that's for sure. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jhrozek at redhat.com Tue Jun 2 21:55:19 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 02 Jun 2009 23:55:19 +0200 Subject: [Freeipa-devel] [PATCH] man page for LDAP domains Message-ID: <1243979719.2469.4.camel@hendrix> As discussed, documentation for various domain types should come in their own manual page..so, attached is a manual page describing LDAP domain configuration options. It is in a tarball as it seems I've been hitting an Evolution bug when sending XML patches. As many of the configuration options correspond to those in OpenLDAP, description of these options is taken from their manual page, this is mentioned in NOTES section..I hope that is sufficient. Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-man-page-for-LDAP-domains.patch.tar Type: application/x-tar Size: 20480 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jhrozek at redhat.com Tue Jun 2 21:55:19 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 02 Jun 2009 23:55:19 +0200 Subject: [Freeipa-devel] [PATCH] man page for LDAP domains Message-ID: <1243979719.2469.4.camel@hendrix> As discussed, documentation for various domain types should come in their own manual page..so, attached is a manual page describing LDAP domain configuration options. It is in a tarball as it seems I've been hitting an Evolution bug when sending XML patches. As many of the configuration options correspond to those in OpenLDAP, description of these options is taken from their manual page, this is mentioned in NOTES section..I hope that is sufficient. Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-man-page-for-LDAP-domains.patch.tar Type: application/x-tar Size: 20480 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sgallagh at redhat.com Wed Jun 3 10:44:15 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 03 Jun 2009 06:44:15 -0400 Subject: Patch Process (Was: Re: [Freeipa-devel] [PATCHES] Fix bug where List parameters were always cloned with keywords parsed from name. + Remove unused reference to old LDAP backend in join plugin. + Make delegation plugin consistent with plugin2 and use new Crud methods. + Fix DS ACI parsing. + Add ACI plugin port to new LDAP backend.) In-Reply-To: <4A2589BA.50106@redhat.com> References: <4A241B27.5010007@redhat.com> <4A2589BA.50106@redhat.com> Message-ID: <4A2653FF.9070000@redhat.com> On 06/02/2009 04:21 PM, Rob Crittenden wrote: > As a separate issue to the team, we have all been doing multiple patches > per e-mail lately. I've found this to be difficult to review from time > to time, particularly when one part of the patch gets nacked but the > rest are ok (but perhaps related to the nack patch). Do we want to go > back to 1-patch-per-e-mail? I've been suggesting the following preferred patch process: One "logical set" per email. The idea is that the set of patches in an email should comprise a single fix or enhancement. There should only be more than one patch in an email if the others are direct pre-requisites on the final patch functioning and are small enough not to warrant their own separate mailing. E.g. One patch that adds an extra parameter to a function in order to support another patch that exposes this functionality to an external API (like XML-RPC) would be acceptable. On the other hand, having two patches that each provide a new API complete API implementation is far too much. I think a good general rule would be that the email should be based around the last patch in the set, and it should only include pre-requisites for that patch, no discrete functionality. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sbose at redhat.com Wed Jun 3 12:50:31 2009 From: sbose at redhat.com (Sumit Bose) Date: Wed, 03 Jun 2009 14:50:31 +0200 Subject: [Freeipa-devel] [PATCH] man page for LDAP domains In-Reply-To: <1243979719.2469.4.camel@hendrix> References: <1243979719.2469.4.camel@hendrix> Message-ID: <4A267197.1080002@redhat.com> Jakub Hrozek schrieb: > As discussed, documentation for various domain types should come in > their own manual page..so, attached is a manual page describing LDAP > domain configuration options. It is in a tarball as it seems I've been > hitting an Evolution bug when sending XML patches. > > As many of the configuration options correspond to those in OpenLDAP, > description of these options is taken from their manual page, this is > mentioned in NOTES section..I hope that is sufficient. > > Jakub > Hi Jakub, can you change "There can be more than one LDAP domain configured with SSSD, this is known as LDAP connection pooling." to "There can be more than one LDAP domain configured with SSSD." because I think "connection pooling" is not right in the context. bye, Sumit From pzuna at redhat.com Wed Jun 3 13:07:05 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 03 Jun 2009 15:07:05 +0200 Subject: [Freeipa-devel] [PATCHES] Fix bug where List parameters were always cloned with keywords parsed from name. + Remove unused reference to old LDAP backend in join plugin. + Make delegation plugin consistent with plugin2 and use new Crud methods. + Fix DS ACI parsing. + Add ACI plugin port to new LDAP backend. In-Reply-To: <4A2589BA.50106@redhat.com> References: <4A241B27.5010007@redhat.com> <4A2589BA.50106@redhat.com> Message-ID: <4A267579.4000805@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> Patch 0001: Fix bug where List parameters were always cloned with >> keywords parsed from name. >> >> For example, required List options were always cloned as required in >> crud.Search. >> >> >> Patch 0002: Remove unused reference to old LDAP backend in join plugin. >> >> >> Patch 0003: Make delegation plugin consistent with plugin2 and use new >> Crud methods. >> >> The delegation plugin doesn't do anything at this point, but I think >> we should get rid of the old Crud methods. >> >> >> Patch 0004: Fix DS ACI parsing. >> >> Parsing of ACI strings was faulty and didn't want to make friends with >> unicode. >> >> >> Patch 0005: Add ACI plugin port to new LDAP backend. >> >> It's more of a complete rewrite actually. I dropped the showall >> command, use aci2-find with no parameters instead. >> >> >> Pavel > > As a separate issue to the team, we have all been doing multiple patches > per e-mail lately. I've found this to be difficult to review from time > to time, particularly when one part of the patch gets nacked but the > rest are ok (but perhaps related to the nack patch). Do we want to go > back to 1-patch-per-e-mail? Fine by me. > Patch 1-4 look fine. Pushed. > > I think the delegation plugin is going to go away though. It just does > the "grant write on these attributes for group A to group B". The aci > plugin can do much more (and is more dangerous too). > > Patch 5 nack. > > I think we really need a ListEnum but that's another story :-) Actually, it might be another story, but it's related to the next issue. ListEnum would validate its values automatically. I was thinking about that and even tried to implement it, but then gave up, because sub-classing from both List and Enum was a bit tricky. > Instead of normalize I think this should use a validate function for the > permission types and not continue if unknown values are used. This > silently drops unknown values so could have unknown side-effects. The problem is that the List type overrides Param._validate_scalar and performs no validation of values at all (validate functions are not called). The only way around this I can think of now is to raise ValidationError in the current normalize function... or rewrite the List type. > You're missing the dn argument when setting the target filter: > > + if 'memberof' in kw: > + (dn, entry_attrs) = api.Command['group2_show'](kw['memberof']) > + a.set_target_filter('memberOf=%s') Ok. > The reason I didn't implement mod is that we don't currently have a way > to say "remove this thing". So if you had an ACI that limited access by > attributes there is no way to remove that. I suppose something is better > than teasing with a command that is not implemented at all though. I'm not sure I understand what you mean exactly, but my knowledge of ACIs and DS in general is limited. What I make of it is, that it's impossible to delete ACIs in certain cases. Because what I actually do in the -mod command is deleting the old ACI and creating a new one to take its place. > I'm still not sure I want to ship this with as a general-use plugin. > I've used it to create the current set of ACIs but it is not for the > faint of heart, that's for sure. I can see your point and it's not my decision to make anyway. I think that most admins will rather manipulate ACIs manually for the sake of safety. > rob Pavel From sgallagh at redhat.com Wed Jun 3 13:21:39 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 03 Jun 2009 09:21:39 -0400 Subject: [Freeipa-devel] [PATCH] man page for LDAP domains In-Reply-To: <4A267197.1080002@redhat.com> References: <1243979719.2469.4.camel@hendrix> <4A267197.1080002@redhat.com> Message-ID: <4A2678E3.6010005@redhat.com> On 06/03/2009 08:50 AM, Sumit Bose wrote: > Jakub Hrozek schrieb: >> As discussed, documentation for various domain types should come in >> their own manual page..so, attached is a manual page describing LDAP >> domain configuration options. It is in a tarball as it seems I've been >> hitting an Evolution bug when sending XML patches. >> >> As many of the configuration options correspond to those in OpenLDAP, >> description of these options is taken from their manual page, this is >> mentioned in NOTES section..I hope that is sufficient. >> >> Jakub >> > > Hi Jakub, > > can you change > > "There can be more than one LDAP domain configured with SSSD, this is > known as LDAP connection pooling." > > to > > "There can be more than one LDAP domain configured with SSSD." > > because I think "connection pooling" is not right in the context. > > bye, > Sumit > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Nack. This fails to build. You have the docbook generating sssd-ldap.conf.5, but the Makefile is expecting sssd-ldap.5. One or the other of these needs to change. Otherwise, I agree with Sumit's proposed change above. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Jun 3 13:41:49 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 03 Jun 2009 09:41:49 -0400 Subject: [Freeipa-devel] [PATCHES] Fix bug where List parameters were always cloned with keywords parsed from name. + Remove unused reference to old LDAP backend in join plugin. + Make delegation plugin consistent with plugin2 and use new Crud methods. + Fix DS ACI parsing. + Add ACI plugin port to new LDAP backend. In-Reply-To: <4A267579.4000805@redhat.com> References: <4A241B27.5010007@redhat.com> <4A2589BA.50106@redhat.com> <4A267579.4000805@redhat.com> Message-ID: <4A267D9D.9090807@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> Patch 0001: Fix bug where List parameters were always cloned with >>> keywords parsed from name. >>> >>> For example, required List options were always cloned as required in >>> crud.Search. >>> >>> >>> Patch 0002: Remove unused reference to old LDAP backend in join plugin. >>> >>> >>> Patch 0003: Make delegation plugin consistent with plugin2 and use >>> new Crud methods. >>> >>> The delegation plugin doesn't do anything at this point, but I think >>> we should get rid of the old Crud methods. >>> >>> >>> Patch 0004: Fix DS ACI parsing. >>> >>> Parsing of ACI strings was faulty and didn't want to make friends >>> with unicode. >>> >>> >>> Patch 0005: Add ACI plugin port to new LDAP backend. >>> >>> It's more of a complete rewrite actually. I dropped the showall >>> command, use aci2-find with no parameters instead. >>> >>> >>> Pavel >> >> As a separate issue to the team, we have all been doing multiple >> patches per e-mail lately. I've found this to be difficult to review >> from time to time, particularly when one part of the patch gets nacked >> but the rest are ok (but perhaps related to the nack patch). Do we >> want to go back to 1-patch-per-e-mail? > Fine by me. > >> Patch 1-4 look fine. Pushed. >> >> I think the delegation plugin is going to go away though. It just does >> the "grant write on these attributes for group A to group B". The aci >> plugin can do much more (and is more dangerous too). >> >> Patch 5 nack. >> >> I think we really need a ListEnum but that's another story :-) > Actually, it might be another story, but it's related to the next issue. > ListEnum would validate its values automatically. I was thinking about > that and even tried to implement it, but then gave up, because > sub-classing from both List and Enum was a bit tricky. > >> Instead of normalize I think this should use a validate function for >> the permission types and not continue if unknown values are used. This >> silently drops unknown values so could have unknown side-effects. > The problem is that the List type overrides Param._validate_scalar and > performs no validation of values at all (validate functions are not > called). The only way around this I can think of now is to raise > ValidationError in the current normalize function... or rewrite the List > type. > >> You're missing the dn argument when setting the target filter: >> >> + if 'memberof' in kw: >> + (dn, entry_attrs) = api.Command['group2_show'](kw['memberof']) >> + a.set_target_filter('memberOf=%s') > Ok. > >> The reason I didn't implement mod is that we don't currently have a >> way to say "remove this thing". So if you had an ACI that limited >> access by attributes there is no way to remove that. I suppose >> something is better than teasing with a command that is not >> implemented at all though. > I'm not sure I understand what you mean exactly, but my knowledge of > ACIs and DS in general is limited. What I make of it is, that it's > impossible to delete ACIs in certain cases. Because what I actually do > in the -mod command is deleting the old ACI and creating a new one to > take its place. This is a general problem in the framework right now, not specific to ACIs. We currently have no easy way to specify "remove this attribute" or "remove this attribute value". In the context of an ACI you could end up with targets you don't want. ACI's have a couple of different ways to target an ACI. You can set it to operate on a whole subtree (ldap:///uid=*, cn=users, ...) or a filter, such as being a member of a group (targetfilter="(memberOf=cn=bar,cn=groups...). So if when you created the ACI you had set a list of attributes you wanted to apply it to but then changed your mind, there is no way to remove them other than to drop the ACI and re-create it. When I initially worked on this I decided that is probably what most admins would do anyway but I left the mod command as a placeholder just in case we got to it. > >> I'm still not sure I want to ship this with as a general-use plugin. >> I've used it to create the current set of ACIs but it is not for the >> faint of heart, that's for sure. > I can see your point and it's not my decision to make anyway. I think > that most admins will rather manipulate ACIs manually for the sake of > safety. You have a say! But yes, manipulating ACIs can be dangerous. What I want to avoid is making it too easy to grant read access to passwords or overly broad write access, for example. What I hope to provide for in the new delegation system is enough low-level rights to manage the various components (users, groups, hosts, etc) that most of the work can be done at the "role" level where you only worry about defining who can do what, not what can be done. I think we may need a way to manage the list of attributes that can be operated on which is why I haven't completely dumped the delegation plugin yet, but I'm just not sure that we want to maintain both methods. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jhrozek at redhat.com Wed Jun 3 15:11:53 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 03 Jun 2009 17:11:53 +0200 Subject: [Freeipa-devel] [PATCH] man page for LDAP domains In-Reply-To: <4A2678E3.6010005@redhat.com> References: <1243979719.2469.4.camel@hendrix> <4A267197.1080002@redhat.com> <4A2678E3.6010005@redhat.com> Message-ID: <4A2692B9.5060102@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Gallagher wrote: > On 06/03/2009 08:50 AM, Sumit Bose wrote: >> Jakub Hrozek schrieb: >>> As discussed, documentation for various domain types should come in >>> their own manual page..so, attached is a manual page describing LDAP >>> domain configuration options. It is in a tarball as it seems I've been >>> hitting an Evolution bug when sending XML patches. >>> >>> As many of the configuration options correspond to those in OpenLDAP, >>> description of these options is taken from their manual page, this is >>> mentioned in NOTES section..I hope that is sufficient. >>> >>> Jakub >>> >> Hi Jakub, >> >> can you change >> >> "There can be more than one LDAP domain configured with SSSD, this is >> known as LDAP connection pooling." >> >> to >> >> "There can be more than one LDAP domain configured with SSSD." >> >> because I think "connection pooling" is not right in the context. >> >> bye, >> Sumit >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Nack. This fails to build. You have the docbook generating > sssd-ldap.conf.5, but the Makefile is expecting sssd-ldap.5. One or the > other of these needs to change. > > Otherwise, I agree with Sumit's proposed change above. > Thanks; I fixed the bad refname and refentrytitle as well as the sentence about multiple LDAP servers. New patch attached (and using a different MUA so not in tarball). Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkomkrkACgkQHsardTLnvCXQAwCfTz4pnmqtagNGKqoKYA+FYrCG jKYAn13GV/Zs4k0DdZPJ/MK52C/1rGRQ =hKO6 -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-man-page-for-LDAP-domains.patch URL: From sgallagh at redhat.com Wed Jun 3 16:43:19 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 03 Jun 2009 12:43:19 -0400 Subject: [Freeipa-devel] [PATCH] man page for LDAP domains In-Reply-To: <4A2692B9.5060102@redhat.com> References: <1243979719.2469.4.camel@hendrix> <4A267197.1080002@redhat.com> <4A2678E3.6010005@redhat.com> <4A2692B9.5060102@redhat.com> Message-ID: <4A26A827.3080408@redhat.com> On 06/03/2009 11:11 AM, Jakub Hrozek wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Stephen Gallagher wrote: >> On 06/03/2009 08:50 AM, Sumit Bose wrote: >>> Jakub Hrozek schrieb: >>>> As discussed, documentation for various domain types should come in >>>> their own manual page..so, attached is a manual page describing LDAP >>>> domain configuration options. It is in a tarball as it seems I've been >>>> hitting an Evolution bug when sending XML patches. >>>> >>>> As many of the configuration options correspond to those in OpenLDAP, >>>> description of these options is taken from their manual page, this is >>>> mentioned in NOTES section..I hope that is sufficient. >>>> >>>> Jakub >>>> >>> Hi Jakub, >>> >>> can you change >>> >>> "There can be more than one LDAP domain configured with SSSD, this is >>> known as LDAP connection pooling." >>> >>> to >>> >>> "There can be more than one LDAP domain configured with SSSD." >>> >>> because I think "connection pooling" is not right in the context. >>> >>> bye, >>> Sumit >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Nack. This fails to build. You have the docbook generating >> sssd-ldap.conf.5, but the Makefile is expecting sssd-ldap.5. One or the >> other of these needs to change. >> >> Otherwise, I agree with Sumit's proposed change above. >> > > Thanks; I fixed the bad refname and refentrytitle as well as the > sentence about multiple LDAP servers. > > New patch attached (and using a different MUA so not in tarball). > > Jakub > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkomkrkACgkQHsardTLnvCXQAwCfTz4pnmqtagNGKqoKYA+FYrCG > jKYAn13GV/Zs4k0DdZPJ/MK52C/1rGRQ > =hKO6 > -----END PGP SIGNATURE----- Ack -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Wed Jun 3 17:58:05 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 03 Jun 2009 13:58:05 -0400 Subject: [Freeipa-devel] [PATCH] man page for LDAP domains In-Reply-To: <4A26A827.3080408@redhat.com> References: <1243979719.2469.4.camel@hendrix> <4A267197.1080002@redhat.com> <4A2678E3.6010005@redhat.com> <4A2692B9.5060102@redhat.com> <4A26A827.3080408@redhat.com> Message-ID: <4A26B9AD.10805@redhat.com> On 06/03/2009 12:43 PM, Stephen Gallagher wrote: > On 06/03/2009 11:11 AM, Jakub Hrozek wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Stephen Gallagher wrote: >>> On 06/03/2009 08:50 AM, Sumit Bose wrote: >>>> Jakub Hrozek schrieb: >>>>> As discussed, documentation for various domain types should come in >>>>> their own manual page..so, attached is a manual page describing LDAP >>>>> domain configuration options. It is in a tarball as it seems I've been >>>>> hitting an Evolution bug when sending XML patches. >>>>> >>>>> As many of the configuration options correspond to those in OpenLDAP, >>>>> description of these options is taken from their manual page, this is >>>>> mentioned in NOTES section..I hope that is sufficient. >>>>> >>>>> Jakub >>>>> >>>> Hi Jakub, >>>> >>>> can you change >>>> >>>> "There can be more than one LDAP domain configured with SSSD, this is >>>> known as LDAP connection pooling." >>>> >>>> to >>>> >>>> "There can be more than one LDAP domain configured with SSSD." >>>> >>>> because I think "connection pooling" is not right in the context. >>>> >>>> bye, >>>> Sumit >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Nack. This fails to build. You have the docbook generating >>> sssd-ldap.conf.5, but the Makefile is expecting sssd-ldap.5. One or the >>> other of these needs to change. >>> >>> Otherwise, I agree with Sumit's proposed change above. >>> >> Thanks; I fixed the bad refname and refentrytitle as well as the >> sentence about multiple LDAP servers. >> >> New patch attached (and using a different MUA so not in tarball). >> >> Jakub >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org >> >> iEYEARECAAYFAkomkrkACgkQHsardTLnvCXQAwCfTz4pnmqtagNGKqoKYA+FYrCG >> jKYAn13GV/Zs4k0DdZPJ/MK52C/1rGRQ >> =hKO6 >> -----END PGP SIGNATURE----- > > Ack > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Pushed to master. Also pushed a fix to sssd.spec to support man(5) pages under the one-liner rule. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Wed Jun 3 21:08:31 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 03 Jun 2009 17:08:31 -0400 Subject: [Freeipa-devel] Announcing the release of SSSD 0.4.0 Message-ID: <4A26E64F.5090203@redhat.com> SSSD 0.4.0 is now available at https://fedorahosted.org/sssd/ List of changes include (but are not limited to) Elimination of "rootdse" error messages Many fixes to user and group enumeration in NSS Support in PAM for use_authtok Fixes for caching authentication in PAM Fixes for porting SSSD to Debian-based platforms First steps towards i18n support Conversion of the build system to automake and friends. Addition of manpages and many small bugfixes. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sbose at redhat.com Thu Jun 4 11:43:03 2009 From: sbose at redhat.com (Sumit Bose) Date: Thu, 04 Jun 2009 13:43:03 +0200 Subject: [Freeipa-devel] [PATCH] fix detection of authentication against LOCAL domain Message-ID: <4A27B347.4040305@redhat.com> Hi, if "provider=local" is set in sssd.conf the pam responder does not detect the shortcut for the LOCAL domain. This was found by Jakub and the attached patch should fix it. bye, Sumit -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fix-detection-of-authentication-against-LOCAL-domain.patch Type: text/x-patch Size: 858 bytes Desc: not available URL: From sgallagh at redhat.com Thu Jun 4 11:53:25 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 04 Jun 2009 07:53:25 -0400 Subject: [Freeipa-devel] [PATCH] fix detection of authentication against LOCAL domain In-Reply-To: <4A27B347.4040305@redhat.com> References: <4A27B347.4040305@redhat.com> Message-ID: <4A27B5B5.6050204@redhat.com> On 06/04/2009 07:43 AM, Sumit Bose wrote: > Hi, > > if "provider=local" is set in sssd.conf the pam responder does not > detect the shortcut for the LOCAL domain. This was found by Jakub and > the attached patch should fix it. > > bye, > Sumit > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Actually, since we switched to using provider=local, shouldn't the case where there's no provider available actually be an error? Do we really want to default to LOCAL? -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sbose at redhat.com Thu Jun 4 11:56:29 2009 From: sbose at redhat.com (Sumit Bose) Date: Thu, 04 Jun 2009 13:56:29 +0200 Subject: [Freeipa-devel] [PATCH] fix detection of authentication against LOCAL domain In-Reply-To: <4A27B347.4040305@redhat.com> References: <4A27B347.4040305@redhat.com> Message-ID: <4A27B66D.3020305@redhat.com> Sumit Bose schrieb: > Hi, > > if "provider=local" is set in sssd.conf the pam responder does not > detect the shortcut for the LOCAL domain. This was found by Jakub and > the attached patch should fix it. > > bye, > Sumit > > added a missing ) bye, Sumit -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fix-detection-of-authentication-against-LOCAL-domain.patch Type: text/x-patch Size: 859 bytes Desc: not available URL: From sbose at redhat.com Thu Jun 4 13:35:56 2009 From: sbose at redhat.com (Sumit Bose) Date: Thu, 04 Jun 2009 15:35:56 +0200 Subject: [Freeipa-devel] [PATCH] fix detection of authentication against LOCAL domain In-Reply-To: <4A27B66D.3020305@redhat.com> References: <4A27B347.4040305@redhat.com> <4A27B66D.3020305@redhat.com> Message-ID: <4A27CDBC.90008@redhat.com> Sumit Bose schrieb: > Sumit Bose schrieb: >> Hi, >> >> if "provider=local" is set in sssd.conf the pam responder does not >> detect the shortcut for the LOCAL domain. This was found by Jakub and >> the attached patch should fix it. >> >> bye, >> Sumit >> >> > added a missing ) > it turned out the there are two more places which needed fixing. bye, Sumit -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fix-detection-of-authentication-against-LOCAL-domain.patch Type: text/x-patch Size: 1790 bytes Desc: not available URL: From jhrozek at redhat.com Thu Jun 4 13:49:15 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 04 Jun 2009 15:49:15 +0200 Subject: [Freeipa-devel] [PATCH] fix detection of authentication against LOCAL domain In-Reply-To: <4A27CDBC.90008@redhat.com> References: <4A27B347.4040305@redhat.com> <4A27B66D.3020305@redhat.com> <4A27CDBC.90008@redhat.com> Message-ID: <4A27D0DB.8030909@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sumit Bose wrote: > Sumit Bose schrieb: >> Sumit Bose schrieb: >>> Hi, >>> >>> if "provider=local" is set in sssd.conf the pam responder does not >>> detect the shortcut for the LOCAL domain. This was found by Jakub and >>> the attached patch should fix it. >>> >>> bye, >>> Sumit >>> >>> >> added a missing ) >> > > it turned out the there are two more places which needed fixing. > > bye, > Sumit With this patch, I was able to authenticate a user in LOCAL, change his password as root and as the user. Ack from me. Altough I agree with Stephen that we could treat the case with no provider as an error now (but maybe this should be done post-0.4.0). Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkon0NsACgkQHsardTLnvCVZFACfYS6ofJqEC8ZzOn7zPt1F38FN 9bIAn3tpXb1v2emS4QUUwxG8FzpTG0op =3Jmy -----END PGP SIGNATURE----- From sgallagh at redhat.com Thu Jun 4 14:07:02 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 04 Jun 2009 10:07:02 -0400 Subject: [Freeipa-devel] [PATCH] fix detection of authentication against LOCAL domain In-Reply-To: <4A27D0DB.8030909@redhat.com> References: <4A27B347.4040305@redhat.com> <4A27B66D.3020305@redhat.com> <4A27CDBC.90008@redhat.com> <4A27D0DB.8030909@redhat.com> Message-ID: <4A27D506.604@redhat.com> On 06/04/2009 09:49 AM, Jakub Hrozek wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Sumit Bose wrote: >> Sumit Bose schrieb: >>> Sumit Bose schrieb: >>>> Hi, >>>> >>>> if "provider=local" is set in sssd.conf the pam responder does not >>>> detect the shortcut for the LOCAL domain. This was found by Jakub and >>>> the attached patch should fix it. >>>> >>>> bye, >>>> Sumit >>>> >>>> >>> added a missing ) >>> >> it turned out the there are two more places which needed fixing. >> >> bye, >> Sumit > > With this patch, I was able to authenticate a user in LOCAL, change his > password as root and as the user. > > Ack from me. > > Altough I agree with Stephen that we could treat the case with no > provider as an error now (but maybe this should be done post-0.4.0). > > Jakub > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkon0NsACgkQHsardTLnvCVZFACfYS6ofJqEC8ZzOn7zPt1F38FN > 9bIAn3tpXb1v2emS4QUUwxG8FzpTG0op > =3Jmy > -----END PGP SIGNATURE----- > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel 0.4.0 is released. Anything that goes in now will be 0.4.1 or 0.5.0 (whichever we are marching towards) -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Thu Jun 4 17:39:23 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 04 Jun 2009 13:39:23 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Fix invalid pointer in ldb_debug_message Message-ID: <4A2806CB.1090000@redhat.com> This will fix https://fedorahosted.org/sssd/ticket/54 -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Fix-invalid-pointer-error-in-ldb_debug_messages.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Jun 4 18:12:28 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 04 Jun 2009 14:12:28 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Fix invalid pointer in ldb_debug_message In-Reply-To: <4A2806CB.1090000@redhat.com> References: <4A2806CB.1090000@redhat.com> Message-ID: <1244139148.3623.72.camel@localhost.localdomain> On Thu, 2009-06-04 at 13:39 -0400, Stephen Gallagher wrote: > - DEBUG(loglevel, (fmt, ap)); > + vasprintf(&message, fmt, ap);'' NACK, you don't chek vasprintf return value or if message != NULL > + va_end(ap); NACK, the caller does this. Simo. -- Simo Sorce * Red Hat, Inc * New York From pzuna at redhat.com Thu Jun 4 18:17:20 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 04 Jun 2009 20:17:20 +0200 Subject: [Freeipa-devel] [PATCHES] Add new set of base classes for IPA plugins using LDAP. Message-ID: <4A280FB0.5040004@redhat.com> Dear freeipa-devel, I know we agreed that we're going to post one patch per email, but it this case I think it's justified. Patches 0001 through 0005 are prerequisites for the new base classes. Before describing the individual patches, let me explain a little bit of what I had in mind when implementing this addition. For the last few months, I've been mostly working the new LDAP backend and IPA plugins that use it (i.e. almost all IPA plugins). I tried to make the new backend more powerful and flexible. Unfortunately, to take full advantage of the new potential, old plugins had to be rewritten. As there were several inconsistencies across them (output, naming and sometimes even behavior) and about half of them were still using old features from IPAv1, I thought that some re-factoring couldn't hurt after all. After porting a few plugins to the new backend, I realized that most of them were doing pretty much the same thing - manipulating LDAP entries. The only difference was that some plugins were generating attributes in specific ways based on user input. So, I figured that most of the generic work could be done in one place and that's when I started working on these new base classes. Let's take a quick look at them: LDAPObject - extends frontend.Object - represents a type of LDAP entry (or sub-entry if a parent_key=True parameter is present) The following methods are to be used with LDAPObject, they are named after the CRUD methods they extend with an 'LDAP' prefix. They take 1 argument (the primary key) in the case their LDAPObject is an entry and 2 arguments (the parent and primary key, in that order) if their LDAPObject is a subentry: LDAPCreate LDAPRetrieve LDAPUpdate LDAPDelete Then there's LDAPSearch, which is a bit special. It takes only the optional criteria argument if its LDAPObject is an entry. If its LDAPObject is a sub-entry then it requires the parent key as the first argument. The search logic works as follows: 1) If there is no parameters (except for the parent key in the case of sub-entries), all entries of the given type are returned. 2) If there is only the criteria parameter, all entries of the given type with one or more of their default attributes containing the value of criteria are returned. 3) If there is an options specified, all entries of the given type with the corresponding attribute EQUAL to the value specified are returned. If more than one options is specified this way, only entries matching ALL the conditions are returned. 2) and 3) can be combined, so for example, we can make a search for entries who have a specific attribute equal to 'foo' and some of their other attributes containing 'bar'. All of these base classes implement a 'callback' method, that is called just before invoking python-ldap through the backend. Subclasses can use it to execute their specific code after all the boring stuff has been done for them. In the future I'm planning to write more base classes for other uses cases such as adding/removing values from multivalued attributes. Patches descriptions: --------------------- 0001: Make it possible for subclasses of Command and co. to use their own __public__. The problem was with PluginProxy only taking the base class' __public__ into consideration. 0002: Add parent_key to keyword arguments of Param base class. 0003: Add support for parent key in Object base class. 0004: Make CRUD base classes take parent key parameters into consideration when generating args. 0005: Add delete_tree method to ldap2 allowing recursive deletes of whole LDAP branches. Some plugins were doing this "manually", so I figured it might as well be provided by the LDAP API. 0006: Add new set of base classes for plugins using LDAP. To see the new bases classes in action, take a look at the next patch I'm about to send to freeipa-devel. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-it-possible-for-subclasses-of-Command-and-co.-t.patch Type: application/mbox Size: 963 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-parent_key-to-keyword-arguments-of-Param-base-cl.patch Type: application/mbox Size: 784 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-support-for-parent-key-in-Object-base-class.patch Type: application/mbox Size: 2865 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Make-CRUD-base-classes-take-parent-key-parameters-in.patch Type: application/mbox Size: 2188 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Add-delete_tree-method-to-ldap2-allowing-recursive-d.patch Type: application/mbox Size: 3114 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Add-new-set-of-base-classes-for-plugins-using-LDAP.patch Type: application/mbox Size: 9056 bytes Desc: not available URL: From pzuna at redhat.com Thu Jun 4 18:18:33 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 04 Jun 2009 20:18:33 +0200 Subject: [Freeipa-devel] [PATCH] Add automount plugin port to new LDAP backend. Message-ID: <4A280FF9.1090408@redhat.com> New base classes in action. Command names might require renaming... Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-Add-automount-plugin-port-to-new-LDAP-backend.patch Type: application/mbox Size: 9408 bytes Desc: not available URL: From sgallagh at redhat.com Thu Jun 4 18:23:28 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 04 Jun 2009 14:23:28 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Fix invalid pointer in ldb_debug_message In-Reply-To: <1244139148.3623.72.camel@localhost.localdomain> References: <4A2806CB.1090000@redhat.com> <1244139148.3623.72.camel@localhost.localdomain> Message-ID: <4A281120.3090808@redhat.com> On 06/04/2009 02:12 PM, Simo Sorce wrote: > On Thu, 2009-06-04 at 13:39 -0400, Stephen Gallagher wrote: >> - DEBUG(loglevel, (fmt, ap)); >> + vasprintf(&message, fmt, ap);'' > > NACK, you don't chek vasprintf return value or if message != NULL > >> + va_end(ap); > > NACK, the caller does this. > > Simo. > See attached new version (which also corrects the same vasprintf() issue in debug_fn(); -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Fix-invalid-pointer-error-in-ldb_debug_messages.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Jun 4 19:11:59 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 04 Jun 2009 15:11:59 -0400 Subject: [Freeipa-devel] [PATCHES] Add new set of base classes for IPA plugins using LDAP. In-Reply-To: <4A280FB0.5040004@redhat.com> References: <4A280FB0.5040004@redhat.com> Message-ID: <4A281C7F.8070000@redhat.com> Pavel Zuna wrote: > Dear freeipa-devel, > I know we agreed that we're going to post one patch per email, but it > this case I think it's justified. Patches 0001 through 0005 are > prerequisites for the new base classes. Before describing the individual > patches, let me explain a little bit of what I had in mind when > implementing this addition. > > For the last few months, I've been mostly working the new LDAP backend > and IPA plugins that use it (i.e. almost all IPA plugins). I tried to > make the new backend more powerful and flexible. Unfortunately, to take > full advantage of the new potential, old plugins had to be rewritten. As > there were several inconsistencies across them (output, naming and > sometimes even behavior) and about half of them were still using old > features from IPAv1, I thought that some re-factoring couldn't hurt > after all. > > After porting a few plugins to the new backend, I realized that most of > them were doing pretty much the same thing - manipulating LDAP entries. > The only difference was that some plugins were generating attributes in > specific ways based on user input. So, I figured that most of the > generic work could be done in one place and that's when I started > working on these new base classes. > > Let's take a quick look at them: > > LDAPObject > - extends frontend.Object > - represents a type of LDAP entry > (or sub-entry if a parent_key=True parameter is present) > > The following methods are to be used with LDAPObject, they are named > after the CRUD methods they extend with an 'LDAP' prefix. They take 1 > argument (the primary key) in the case their LDAPObject is an entry and > 2 arguments (the parent and primary key, in that order) if their > LDAPObject is a subentry: > > LDAPCreate > LDAPRetrieve > LDAPUpdate > LDAPDelete > > Then there's LDAPSearch, which is a bit special. It takes only the > optional criteria argument if its LDAPObject is an entry. If its > LDAPObject is a sub-entry then it requires the parent key as the first > argument. The search logic works as follows: > > 1) If there is no parameters (except for the parent key in the case of > sub-entries), all entries of the given type are returned. > > 2) If there is only the criteria parameter, all entries of the given > type with one or more of their default attributes containing the value > of criteria are returned. > > 3) If there is an options specified, all entries of the given type with > the corresponding attribute EQUAL to the value specified are returned. > If more than one options is specified this way, only entries matching > ALL the conditions are returned. > > 2) and 3) can be combined, so for example, we can make a search for > entries who have a specific attribute equal to 'foo' and some of their > other attributes containing 'bar'. > > All of these base classes implement a 'callback' method, that is called > just before invoking python-ldap through the backend. Subclasses can use > it to execute their specific code after all the boring stuff has been > done for them. > > In the future I'm planning to write more base classes for other uses > cases such as adding/removing values from multivalued attributes. > > > Patches descriptions: > --------------------- > > 0001: Make it possible for subclasses of Command and co. to use their > own __public__. > > The problem was with PluginProxy only taking the base class' __public__ > into consideration. > > > 0002: Add parent_key to keyword arguments of Param base class. > > > 0003: Add support for parent key in Object base class. > > > 0004: Make CRUD base classes take parent key parameters into > consideration when > generating args. > > > 0005: Add delete_tree method to ldap2 allowing recursive deletes of > whole LDAP branches. > > Some plugins were doing this "manually", so I figured it might as well > be provided by the LDAP API. > > > 0006: Add new set of base classes for plugins using LDAP. > > > To see the new bases classes in action, take a look at the next patch > I'm about to send to freeipa-devel. A few comments. I'd like Jason to comment on patch 0001 and 0002. It looks ok to me but he may balk at changing __public__. In LDAPObject you use a variable named keys. It isn't immediately clear what this is for (made clear after reading get_dn). If I understand parent_key and keys you are providing a general way of constructing the DN of the record, right? I'm not sure that parent_key and keys are very descriptive. It seems like primary_key is the rdn, parent_key is the next value in the DN and keys can contain either primary_key or both primary_key and parent_key. This is particularly confusing if you aren't using LDAPObject as a base class. Why would you want to return parent_key instead of primary_key when getting the arguments? I like the idea of a callback but is this limited by only returning the dn? What kinds of things do you envision this being used for? (e.g. what it if was smart enough to add in extra attributes the user didn't or couldn't ask for?). BTW this sort of callback was always envisioned, I'm glad you're adding it. We had thought about having a pre- and post- callback so you could manage the data going in and coming out. What do you think? You define backend_name in LDAPObject but I don't see it used anywhere. What did you have in mind for this? If this is going to essentially be the base class for all LDAP-based plugins I think I'd like to see some more inline documentation so the output of epydoc will be helpful. I wonder if delete_tree() isn't a bit dangerous. What if someone manages to pass in dc=example,dc=com? I think that ldap.passwd_s() will blow up if you pass in None as the old password. You made some changes to the modlist generator. Are you sure that this: modlist.append((_ldap.MOD_DELETE, k, None)) will work with python-ldap found on older systems (e.g. RHEL 5)? I guess the basegroup class could be re-based to work on this and be even simpler :-) Something that this will need at some point is a pointer to where in cn=ipaconfig the list of default objectclasses can be found. We may not end up defining this for every single object type but I think for many we will (users and groups at least). It would be nice if there was a way to just pass in an attribute name where this list can be found. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jhrozek at redhat.com Fri Jun 5 09:52:12 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 05 Jun 2009 11:52:12 +0200 Subject: [Freeipa-devel] [PATH] Fix passing of shadow-utils config variable in Makefile.am Message-ID: <4A28EACC.5000508@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The attached patch fixes a bug that was introduced probably during the conversion to Autotools - the variable was passed with wrong case. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkoo6swACgkQHsardTLnvCW6cACg6j5AzqCyzIGyxnrd+liZeKH8 On0AnijkimMQetKw6DiSWqB1CvOyivAg =ZDvF -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-fix-shadow-utils-base-path.patch URL: From sgallagh at redhat.com Fri Jun 5 10:43:06 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 05 Jun 2009 06:43:06 -0400 Subject: [Freeipa-devel] [PATH] Fix passing of shadow-utils config variable in Makefile.am In-Reply-To: <4A28EACC.5000508@redhat.com> References: <4A28EACC.5000508@redhat.com> Message-ID: <4A28F6BA.7010003@redhat.com> On 06/05/2009 05:52 AM, Jakub Hrozek wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The attached patch fixes a bug that was introduced probably during the > conversion to Autotools - the variable was passed with wrong case. > > Jakub > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkoo6swACgkQHsardTLnvCW6cACg6j5AzqCyzIGyxnrd+liZeKH8 > On0AnijkimMQetKw6DiSWqB1CvOyivAg > =ZDvF > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Ack. Good catch on that. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Mon Jun 8 12:38:08 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Mon, 08 Jun 2009 14:38:08 +0200 Subject: [Freeipa-devel] [PATCHES] Add new set of base classes for IPA plugins using LDAP. In-Reply-To: <4A281C7F.8070000@redhat.com> References: <4A280FB0.5040004@redhat.com> <4A281C7F.8070000@redhat.com> Message-ID: <4A2D0630.3050801@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> Dear freeipa-devel, >> I know we agreed that we're going to post one patch per email, but it >> this case I think it's justified. Patches 0001 through 0005 are >> prerequisites for the new base classes. Before describing the >> individual patches, let me explain a little bit of what I had in mind >> when implementing this addition. >> >> For the last few months, I've been mostly working the new LDAP backend >> and IPA plugins that use it (i.e. almost all IPA plugins). I tried to >> make the new backend more powerful and flexible. Unfortunately, to >> take full advantage of the new potential, old plugins had to be >> rewritten. As there were several inconsistencies across them (output, >> naming and sometimes even behavior) and about half of them were still >> using old features from IPAv1, I thought that some re-factoring >> couldn't hurt after all. >> >> After porting a few plugins to the new backend, I realized that most >> of them were doing pretty much the same thing - manipulating LDAP >> entries. The only difference was that some plugins were generating >> attributes in specific ways based on user input. So, I figured that >> most of the generic work could be done in one place and that's when I >> started working on these new base classes. >> >> Let's take a quick look at them: >> >> LDAPObject >> - extends frontend.Object >> - represents a type of LDAP entry >> (or sub-entry if a parent_key=True parameter is present) >> >> The following methods are to be used with LDAPObject, they are named >> after the CRUD methods they extend with an 'LDAP' prefix. They take 1 >> argument (the primary key) in the case their LDAPObject is an entry >> and 2 arguments (the parent and primary key, in that order) if their >> LDAPObject is a subentry: >> >> LDAPCreate >> LDAPRetrieve >> LDAPUpdate >> LDAPDelete >> >> Then there's LDAPSearch, which is a bit special. It takes only the >> optional criteria argument if its LDAPObject is an entry. If its >> LDAPObject is a sub-entry then it requires the parent key as the first >> argument. The search logic works as follows: >> >> 1) If there is no parameters (except for the parent key in the case of >> sub-entries), all entries of the given type are returned. >> >> 2) If there is only the criteria parameter, all entries of the given >> type with one or more of their default attributes containing the value >> of criteria are returned. >> >> 3) If there is an options specified, all entries of the given type >> with the corresponding attribute EQUAL to the value specified are >> returned. If more than one options is specified this way, only entries >> matching ALL the conditions are returned. >> >> 2) and 3) can be combined, so for example, we can make a search for >> entries who have a specific attribute equal to 'foo' and some of their >> other attributes containing 'bar'. >> >> All of these base classes implement a 'callback' method, that is >> called just before invoking python-ldap through the backend. >> Subclasses can use it to execute their specific code after all the >> boring stuff has been done for them. >> >> In the future I'm planning to write more base classes for other uses >> cases such as adding/removing values from multivalued attributes. >> >> >> Patches descriptions: >> --------------------- >> >> 0001: Make it possible for subclasses of Command and co. to use their >> own __public__. >> >> The problem was with PluginProxy only taking the base class' >> __public__ into consideration. >> >> >> 0002: Add parent_key to keyword arguments of Param base class. >> >> >> 0003: Add support for parent key in Object base class. >> >> >> 0004: Make CRUD base classes take parent key parameters into >> consideration when >> generating args. >> >> >> 0005: Add delete_tree method to ldap2 allowing recursive deletes of >> whole LDAP branches. >> >> Some plugins were doing this "manually", so I figured it might as well >> be provided by the LDAP API. >> >> >> 0006: Add new set of base classes for plugins using LDAP. >> >> >> To see the new bases classes in action, take a look at the next patch >> I'm about to send to freeipa-devel. > > A few comments. > > I'd like Jason to comment on patch 0001 and 0002. It looks ok to me but > he may balk at changing __public__. > > In LDAPObject you use a variable named keys. It isn't immediately clear > what this is for (made clear after reading get_dn). If I understand > parent_key and keys you are providing a general way of constructing the > DN of the record, right? I'm not sure that parent_key and keys are very > descriptive. It seems like primary_key is the rdn, parent_key is the > next value in the DN and keys can contain either primary_key or both > primary_key and parent_key. This is particularly confusing if you aren't > using LDAPObject as a base class. Why would you want to return > parent_key instead of primary_key when getting the arguments? I was trying to accomplish 2 things by introducing parent_key: 1) provide a generic way of constructing the DN 2) generate different arguments for CRUD methods of sub-entries Some plugins have to deal with entries and their direct sub-entries (DNS plugin: zone->resource, automount plugin: map->key). When accessing a sub-entry, we need to know its RDN (primary_key), but also its parent RDN (parent_key). parent_key is never returned instead of primary_key. If present, parent_key is returned first followed by primary_key. You're right that it can be confusing when not using LDAPObject as a base class, I'll change the CRUD base classes back and override get_args() in LDAP* methods. 'parent_key' and 'keys' might not be the most descriptive names, but I couldn't think of anything better - any suggestions? > I like the idea of a callback but is this limited by only returning the > dn? What kinds of things do you envision this being used for? (e.g. what > it if was smart enough to add in extra attributes the user didn't or > couldn't ask for?). Actually they are smarter than they look. :) Since parameters in python are passed by reference (well not exactly, it's actually pass by value, but names are the values and names are like references...) we can modify their contents in the callback. Unfortunately, this only applies to mutable types, so DN/filter (immutable strings) have to be returned. > BTW this sort of callback was always envisioned, I'm glad you're adding > it. We had thought about having a pre- and post- callback so you could > manage the data going in and coming out. What do you think? Sounds like a good idea. > You define backend_name in LDAPObject but I don't see it used anywhere. > What did you have in mind for this? backend_name is a forgotten feature I found in the depths of ipalib code. When the Object instance is being initialized, its 'backend' attribute is set to api.Backend.. > If this is going to essentially be the base class for all LDAP-based > plugins I think I'd like to see some more inline documentation so the > output of epydoc will be helpful. I'll add it to my TODO list. I was thinking about writing a general HOWTO for plugin authors anyway. > I wonder if delete_tree() isn't a bit dangerous. What if someone manages > to pass in dc=example,dc=com? I can see your point. I'll remove delete_tree and rewrite LDAPDelete to delete sub-entries "manually". > I think that ldap.passwd_s() will blow up if you pass in None as the old > password. Probably, old pass is supposed to default to '' not None... > You made some changes to the modlist generator. Are you sure that this: > > modlist.append((_ldap.MOD_DELETE, k, None)) > > will work with python-ldap found on older systems (e.g. RHEL 5)? To be honest, I don't know. python-ldap docs say nothing about older versions, but after some googling, I found code dating 2003 that was using this. > I guess the basegroup class could be re-based to work on this and be > even simpler :-) Yeah, most plugins could be re-based on this and would become a lot simpler. :) > Something that this will need at some point is a pointer to where in > cn=ipaconfig the list of default objectclasses can be found. We may not > end up defining this for every single object type but I think for many > we will (users and groups at least). It would be nice if there was a way > to just pass in an attribute name where this list can be found. Ok, that should be pretty straight forward. > rob I'm going to fix everything discussed in this e-mail and if it gets the green light from Jason, we might finally be ready to make the LDAP backend switch (at least for plugins). Pavel From sbose at redhat.com Mon Jun 8 14:01:42 2009 From: sbose at redhat.com (Sumit Bose) Date: Mon, 08 Jun 2009 16:01:42 +0200 Subject: [Freeipa-devel] [PATCH] fix detection of authentication against LOCAL domain In-Reply-To: <4A27B5B5.6050204@redhat.com> References: <4A27B347.4040305@redhat.com> <4A27B5B5.6050204@redhat.com> Message-ID: <4A2D19C6.8070104@redhat.com> Stephen Gallagher schrieb: > On 06/04/2009 07:43 AM, Sumit Bose wrote: >> Hi, >> >> if "provider=local" is set in sssd.conf the pam responder does not >> detect the shortcut for the LOCAL domain. This was found by Jakub and >> the attached patch should fix it. >> >> bye, >> Sumit >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Actually, since we switched to using provider=local, shouldn't the case > where there's no provider available actually be an error? Do we really > want to default to LOCAL? > Hi, this patch will generate an error if the provider is missing. bye, Sumit -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fix-detection-of-authentication-against-LOCAL-domain.patch Type: text/x-patch Size: 2011 bytes Desc: not available URL: From sgallagh at redhat.com Mon Jun 8 14:09:19 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 08 Jun 2009 10:09:19 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Treat missing provider entry as a config error Message-ID: <4A2D1B8F.9050205@redhat.com> -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Treat-a-missing-provider-entry-as-a-config-error.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Mon Jun 8 14:13:51 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 08 Jun 2009 10:13:51 -0400 Subject: [Freeipa-devel] [PATCH] fix detection of authentication against LOCAL domain In-Reply-To: <4A2D19C6.8070104@redhat.com> References: <4A27B347.4040305@redhat.com> <4A27B5B5.6050204@redhat.com> <4A2D19C6.8070104@redhat.com> Message-ID: <4A2D1C9F.9020701@redhat.com> On 06/08/2009 10:01 AM, Sumit Bose wrote: > Stephen Gallagher schrieb: >> On 06/04/2009 07:43 AM, Sumit Bose wrote: >>> Hi, >>> >>> if "provider=local" is set in sssd.conf the pam responder does not >>> detect the shortcut for the LOCAL domain. This was found by Jakub and >>> the attached patch should fix it. >>> >>> bye, >>> Sumit >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Actually, since we switched to using provider=local, shouldn't the case >> where there's no provider available actually be an error? Do we really >> want to default to LOCAL? >> > Hi, > > this patch will generate an error if the provider is missing. > > bye, > Sumit Ack -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From jhrozek at redhat.com Mon Jun 8 14:20:52 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 08 Jun 2009 16:20:52 +0200 Subject: [Freeipa-devel] [PATCH][SSSD] Treat missing provider entry as a config error In-Reply-To: <4A2D1B8F.9050205@redhat.com> References: <4A2D1B8F.9050205@redhat.com> Message-ID: <4A2D1E44.7080809@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Gallagher wrote: > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Ack. With the patch applied, a domain with no provider is skipped. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkotHkQACgkQHsardTLnvCXc+QCgl60h8KwF6xIijYXW4WhDt3Cs TUcAnRUwjSTrBHg6nkK9ySI/CzcCcxF7 =JyKT -----END PGP SIGNATURE----- From sgallagh at redhat.com Mon Jun 8 14:25:50 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 08 Jun 2009 10:25:50 -0400 Subject: [Freeipa-devel] [PATCH] fix detection of authentication against LOCAL domain In-Reply-To: <4A2D1C9F.9020701@redhat.com> References: <4A27B347.4040305@redhat.com> <4A27B5B5.6050204@redhat.com> <4A2D19C6.8070104@redhat.com> <4A2D1C9F.9020701@redhat.com> Message-ID: <4A2D1F6E.2050001@redhat.com> On 06/08/2009 10:13 AM, Stephen Gallagher wrote: > On 06/08/2009 10:01 AM, Sumit Bose wrote: >> Stephen Gallagher schrieb: >>> On 06/04/2009 07:43 AM, Sumit Bose wrote: >>>> Hi, >>>> >>>> if "provider=local" is set in sssd.conf the pam responder does not >>>> detect the shortcut for the LOCAL domain. This was found by Jakub and >>>> the attached patch should fix it. >>>> >>>> bye, >>>> Sumit >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Actually, since we switched to using provider=local, shouldn't the case >>> where there's no provider available actually be an error? Do we really >>> want to default to LOCAL? >>> >> Hi, >> >> this patch will generate an error if the provider is missing. >> >> bye, >> Sumit > > Ack > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Pushed to master. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Mon Jun 8 14:26:12 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 08 Jun 2009 10:26:12 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Treat missing provider entry as a config error In-Reply-To: <4A2D1E44.7080809@redhat.com> References: <4A2D1B8F.9050205@redhat.com> <4A2D1E44.7080809@redhat.com> Message-ID: <4A2D1F84.8050809@redhat.com> On 06/08/2009 10:20 AM, Jakub Hrozek wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Stephen Gallagher wrote: >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Ack. > > With the patch applied, a domain with no provider is skipped. > > Jakub > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkotHkQACgkQHsardTLnvCXc+QCgl60h8KwF6xIijYXW4WhDt3Cs > TUcAnRUwjSTrBHg6nkK9ySI/CzcCcxF7 > =JyKT > -----END PGP SIGNATURE----- Pushed to master. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Mon Jun 8 14:26:32 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 08 Jun 2009 10:26:32 -0400 Subject: [Freeipa-devel] [PATH] Fix passing of shadow-utils config variable in Makefile.am In-Reply-To: <4A28F6BA.7010003@redhat.com> References: <4A28EACC.5000508@redhat.com> <4A28F6BA.7010003@redhat.com> Message-ID: <4A2D1F98.5020505@redhat.com> On 06/05/2009 06:43 AM, Stephen Gallagher wrote: > On 06/05/2009 05:52 AM, Jakub Hrozek wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> The attached patch fixes a bug that was introduced probably during the >> conversion to Autotools - the variable was passed with wrong case. >> >> Jakub >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org >> >> iEYEARECAAYFAkoo6swACgkQHsardTLnvCW6cACg6j5AzqCyzIGyxnrd+liZeKH8 >> On0AnijkimMQetKw6DiSWqB1CvOyivAg >> =ZDvF >> -----END PGP SIGNATURE----- >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Ack. > > Good catch on that. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Pushed to master. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Mon Jun 8 14:50:04 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 08 Jun 2009 10:50:04 -0400 Subject: [Freeipa-devel] Announcing the release of SSSD 0.4.1 Message-ID: <4A2D251C.4040809@redhat.com> SSSD 0.4.1 is now available at https://fedorahosted.org/sssd/ After the release of 0.4.0, the SSSD team identified and fixed a serious bug related to the configuration of the native LOCAL domain. Also in this release is a fix to a minor bug in the build system that improperly reported the location of the shadow-utils binaries. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Jun 8 15:05:25 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Jun 2009 11:05:25 -0400 Subject: [Freeipa-devel] [PATCHES] Add new set of base classes for IPA plugins using LDAP. In-Reply-To: <4A2D0630.3050801@redhat.com> References: <4A280FB0.5040004@redhat.com> <4A281C7F.8070000@redhat.com> <4A2D0630.3050801@redhat.com> Message-ID: <4A2D28B5.5000900@redhat.com> Pavel Z?na wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> Dear freeipa-devel, >>> I know we agreed that we're going to post one patch per email, but it >>> this case I think it's justified. Patches 0001 through 0005 are >>> prerequisites for the new base classes. Before describing the >>> individual patches, let me explain a little bit of what I had in mind >>> when implementing this addition. >>> >>> For the last few months, I've been mostly working the new LDAP >>> backend and IPA plugins that use it (i.e. almost all IPA plugins). I >>> tried to make the new backend more powerful and flexible. >>> Unfortunately, to take full advantage of the new potential, old >>> plugins had to be rewritten. As there were several inconsistencies >>> across them (output, naming and sometimes even behavior) and about >>> half of them were still using old features from IPAv1, I thought that >>> some re-factoring couldn't hurt after all. >>> >>> After porting a few plugins to the new backend, I realized that most >>> of them were doing pretty much the same thing - manipulating LDAP >>> entries. The only difference was that some plugins were generating >>> attributes in specific ways based on user input. So, I figured that >>> most of the generic work could be done in one place and that's when I >>> started working on these new base classes. >>> >>> Let's take a quick look at them: >>> >>> LDAPObject >>> - extends frontend.Object >>> - represents a type of LDAP entry >>> (or sub-entry if a parent_key=True parameter is present) >>> >>> The following methods are to be used with LDAPObject, they are named >>> after the CRUD methods they extend with an 'LDAP' prefix. They take 1 >>> argument (the primary key) in the case their LDAPObject is an entry >>> and 2 arguments (the parent and primary key, in that order) if their >>> LDAPObject is a subentry: >>> >>> LDAPCreate >>> LDAPRetrieve >>> LDAPUpdate >>> LDAPDelete >>> >>> Then there's LDAPSearch, which is a bit special. It takes only the >>> optional criteria argument if its LDAPObject is an entry. If its >>> LDAPObject is a sub-entry then it requires the parent key as the >>> first argument. The search logic works as follows: >>> >>> 1) If there is no parameters (except for the parent key in the case >>> of sub-entries), all entries of the given type are returned. >>> >>> 2) If there is only the criteria parameter, all entries of the given >>> type with one or more of their default attributes containing the >>> value of criteria are returned. >>> >>> 3) If there is an options specified, all entries of the given type >>> with the corresponding attribute EQUAL to the value specified are >>> returned. If more than one options is specified this way, only >>> entries matching ALL the conditions are returned. >>> >>> 2) and 3) can be combined, so for example, we can make a search for >>> entries who have a specific attribute equal to 'foo' and some of >>> their other attributes containing 'bar'. >>> >>> All of these base classes implement a 'callback' method, that is >>> called just before invoking python-ldap through the backend. >>> Subclasses can use it to execute their specific code after all the >>> boring stuff has been done for them. >>> >>> In the future I'm planning to write more base classes for other uses >>> cases such as adding/removing values from multivalued attributes. >>> >>> >>> Patches descriptions: >>> --------------------- >>> >>> 0001: Make it possible for subclasses of Command and co. to use their >>> own __public__. >>> >>> The problem was with PluginProxy only taking the base class' >>> __public__ into consideration. >>> >>> >>> 0002: Add parent_key to keyword arguments of Param base class. >>> >>> >>> 0003: Add support for parent key in Object base class. >>> >>> >>> 0004: Make CRUD base classes take parent key parameters into >>> consideration when >>> generating args. >>> >>> >>> 0005: Add delete_tree method to ldap2 allowing recursive deletes of >>> whole LDAP branches. >>> >>> Some plugins were doing this "manually", so I figured it might as >>> well be provided by the LDAP API. >>> >>> >>> 0006: Add new set of base classes for plugins using LDAP. >>> >>> >>> To see the new bases classes in action, take a look at the next patch >>> I'm about to send to freeipa-devel. >> >> A few comments. >> >> I'd like Jason to comment on patch 0001 and 0002. It looks ok to me >> but he may balk at changing __public__. >> >> In LDAPObject you use a variable named keys. It isn't immediately >> clear what this is for (made clear after reading get_dn). If I >> understand parent_key and keys you are providing a general way of >> constructing the DN of the record, right? I'm not sure that parent_key >> and keys are very descriptive. It seems like primary_key is the rdn, >> parent_key is the next value in the DN and keys can contain either >> primary_key or both primary_key and parent_key. This is particularly >> confusing if you aren't using LDAPObject as a base class. Why would >> you want to return parent_key instead of primary_key when getting the >> arguments? > I was trying to accomplish 2 things by introducing parent_key: > 1) provide a generic way of constructing the DN > 2) generate different arguments for CRUD methods of sub-entries > > Some plugins have to deal with entries and their direct sub-entries (DNS > plugin: zone->resource, automount plugin: map->key). When accessing a > sub-entry, we need to know its RDN (primary_key), but also its parent > RDN (parent_key). parent_key is never returned instead of primary_key. > If present, parent_key is returned first followed by primary_key. I think Jason picked primary_key as the main operating attribute both because of his background in SQL and his goal to make the framework not IPA-specific. At some point we may well extract the framework into a package that ships separately. At this early stage though it is simpler to have everything together. I pondered on a better name before and punted, I couldn't think of anything either :-( I'm wondering if we need a parent_primary_key variable though. Wordy as it is it does convey more clearly what it's for. Or it could be that as long as it is well-documented then it won't be a big deal. Further, if you move it into the LDAPObject extension we can call it parent_rdn which is more descriptive. > > You're right that it can be confusing when not using LDAPObject as a > base class, I'll change the CRUD base classes back and override > get_args() in LDAP* methods. 'parent_key' and 'keys' might not be the > most descriptive names, but I couldn't think of anything better - any > suggestions? > >> I like the idea of a callback but is this limited by only returning >> the dn? What kinds of things do you envision this being used for? >> (e.g. what it if was smart enough to add in extra attributes the user >> didn't or couldn't ask for?). > Actually they are smarter than they look. :) Since parameters in python > are passed by reference (well not exactly, it's actually pass by value, > but names are the values and names are like references...) we can modify > their contents in the callback. Unfortunately, this only applies to > mutable types, so DN/filter (immutable strings) have to be returned. Ok, that's a good point. I think we'll need to document that this can happen so that installing some plugin later on doesn't cause unexpected side-effects because some expected keyword value is removed by the new plugin. > >> BTW this sort of callback was always envisioned, I'm glad you're >> adding it. We had thought about having a pre- and post- callback so >> you could manage the data going in and coming out. What do you think? > Sounds like a good idea. > >> You define backend_name in LDAPObject but I don't see it used >> anywhere. What did you have in mind for this? > backend_name is a forgotten feature I found in the depths of ipalib > code. When the Object instance is being initialized, its 'backend' > attribute is set to api.Backend.. Ok, yeah we never could think what other backend there might be for us. > >> If this is going to essentially be the base class for all LDAP-based >> plugins I think I'd like to see some more inline documentation so the >> output of epydoc will be helpful. > I'll add it to my TODO list. I was thinking about writing a general > HOWTO for plugin authors anyway. Sounds great. > >> I wonder if delete_tree() isn't a bit dangerous. What if someone >> manages to pass in dc=example,dc=com? > I can see your point. I'll remove delete_tree and rewrite LDAPDelete to > delete sub-entries "manually". Ok. > >> I think that ldap.passwd_s() will blow up if you pass in None as the >> old password. > Probably, old pass is supposed to default to '' not None... Right. You can try it but I seem to recall bad things happening either in python 2.4 or 2.5 or both when None was passed in. > >> You made some changes to the modlist generator. Are you sure that this: >> >> modlist.append((_ldap.MOD_DELETE, k, None)) >> >> will work with python-ldap found on older systems (e.g. RHEL 5)? > To be honest, I don't know. python-ldap docs say nothing about older > versions, but after some googling, I found code dating 2003 that was > using this. Alright, this just looks really strange :-) > >> I guess the basegroup class could be re-based to work on this and be >> even simpler :-) > Yeah, most plugins could be re-based on this and would become a lot > simpler. :) > >> Something that this will need at some point is a pointer to where in >> cn=ipaconfig the list of default objectclasses can be found. We may >> not end up defining this for every single object type but I think for >> many we will (users and groups at least). It would be nice if there >> was a way to just pass in an attribute name where this list can be found. > Ok, that should be pretty straight forward. > >> rob > > I'm going to fix everything discussed in this e-mail and if it gets the > green light from Jason, we might finally be ready to make the LDAP > backend switch (at least for plugins). > > Pavel Have you run the tests against this backend? They may need to be tuned a bit I suppose but in general they should be able to identify problem areas. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Jun 8 15:32:17 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 08 Jun 2009 11:32:17 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Fix invalid pointer in ldb_debug_message In-Reply-To: <4A281120.3090808@redhat.com> References: <4A2806CB.1090000@redhat.com> <1244139148.3623.72.camel@localhost.localdomain> <4A281120.3090808@redhat.com> Message-ID: <1244475138.6068.126.camel@localhost.localdomain> On Thu, 2009-06-04 at 14:23 -0400, Stephen Gallagher wrote: > > See attached new version (which also corrects the same vasprintf() > issue > in debug_fn(); ack Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Jun 8 15:33:02 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 08 Jun 2009 11:33:02 -0400 Subject: [Freeipa-devel] [PATCH] fix detection of authentication against LOCAL domain In-Reply-To: <4A27CDBC.90008@redhat.com> References: <4A27B347.4040305@redhat.com> <4A27B66D.3020305@redhat.com> <4A27CDBC.90008@redhat.com> Message-ID: <1244475182.6068.127.camel@localhost.localdomain> On Thu, 2009-06-04 at 15:35 +0200, Sumit Bose wrote: > Sumit Bose schrieb: > > Sumit Bose schrieb: > >> Hi, > >> > >> if "provider=local" is set in sssd.conf the pam responder does not > >> detect the shortcut for the LOCAL domain. This was found by Jakub and > >> the attached patch should fix it. > >> > >> bye, > >> Sumit > >> > >> > > added a missing ) > > > > it turned out the there are two more places which needed fixing. This has been pushed by Stephen. Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Mon Jun 8 15:35:17 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 08 Jun 2009 11:35:17 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Fix invalid pointer in ldb_debug_message In-Reply-To: <1244475138.6068.126.camel@localhost.localdomain> References: <4A2806CB.1090000@redhat.com> <1244139148.3623.72.camel@localhost.localdomain> <4A281120.3090808@redhat.com> <1244475138.6068.126.camel@localhost.localdomain> Message-ID: <4A2D2FB5.8030006@redhat.com> On 06/08/2009 11:32 AM, Simo Sorce wrote: > On Thu, 2009-06-04 at 14:23 -0400, Stephen Gallagher wrote: >> See attached new version (which also corrects the same vasprintf() >> issue >> in debug_fn(); > > ack > > Simo. > Pushed to master. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Mon Jun 8 15:56:28 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 08 Jun 2009 11:56:28 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Remove unnecessary cleanup lines from sssd.spec Message-ID: <4A2D34AC.6040606@redhat.com> This libtool cruft was being removed in %build and %install. It is only needed in %install. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Remove-unnecessary-.la-cleanup-from-sssd.spec.in.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Jun 8 15:59:27 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Jun 2009 11:59:27 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Remove unnecessary cleanup lines from sssd.spec In-Reply-To: <4A2D34AC.6040606@redhat.com> References: <4A2D34AC.6040606@redhat.com> Message-ID: <4A2D355F.8050103@redhat.com> Stephen Gallagher wrote: > This libtool cruft was being removed in %build and %install. It is only > needed in %install. > ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Mon Jun 8 16:02:39 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 08 Jun 2009 12:02:39 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Remove unnecessary cleanup lines from sssd.spec In-Reply-To: <4A2D355F.8050103@redhat.com> References: <4A2D34AC.6040606@redhat.com> <4A2D355F.8050103@redhat.com> Message-ID: <4A2D361F.80505@redhat.com> On 06/08/2009 11:59 AM, Rob Crittenden wrote: > Stephen Gallagher wrote: >> This libtool cruft was being removed in %build and %install. It is only >> needed in %install. >> > > ack Pushed to master. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sbose at redhat.com Mon Jun 8 20:07:15 2009 From: sbose at redhat.com (Sumit Bose) Date: Mon, 08 Jun 2009 22:07:15 +0200 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin Message-ID: <4A2D6F73.7040206@redhat.com> Hi, this is the rebased version of the kerberos backend patch I sent early April (https://www.redhat.com/archives/freeipa-devel/2009-April/msg00039.html) . It has the same functionality as the older version and is working with the ldap id backend. I'm planning to add some more features and would like to asked what would be the best way for you to review it. Shall I split it similar to the original one? Shall I add more features and send it later or should it be pushed as early as possible? bye, Sumit -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-added-kerberos-backend-and-kdc-locator-plugin.patch Type: text/x-patch Size: 27851 bytes Desc: not available URL: From rcritten at redhat.com Mon Jun 8 21:41:46 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Jun 2009 17:41:46 -0400 Subject: [Freeipa-devel] [PATCH] 228 add function to prompt for entry after multiple results in -find Message-ID: <4A2D859A.1040600@redhat.com> The -find commands right now just dump all the data that was found. This function can be used to display a list of the results so the user can select a specfic record that will be displayed. I think that we'll ultimitely implement this within the LDAPObject class to make it easier on plugin developers. What they will need to provide is the format line that will be used and the attributes to display. The code looks something like: selected = textui.select_entry(users, "%(givenname)s %(sn)s (%(uid)s)", ("givenname", "sn", "uid")) if selected == -2: # Don't show anything else return if selected >= 0: users = [users[selected]] counter = 1 for u in xrange(counter): cmd = api.Command['user_show'] result = cmd(users[u]['uid'].decode('UTF-8'), **options) if callable(cmd.output_for_cli): for param in cmd.params(): if param.password and param.name in options: del options[param.name] (args, options) = cmd.params_2_args_options(**options) cmd.output_for_cli(self.api.Backend.textui, result, *args, **options) This demonstrates the full code in output_for_cli() for the current user plugin. It looks like this to the user: % ipa user-find tim --------------- Found 3 matches --------------- 1: Tim User (tuser1) 2: Tim User (tuser2) 3: Tim User (tuser3) Choose one: (1 - 3), a for all, q to quit: By doing this in a higher-level class we'll save a lot of coding. We just need to pass in the format string, the list of attributes in that format string and the command to call to display a full entry. This also lets us centralize showing an entry to one function instead of splitting it between -find and -show. If this is called without a tty (like redirecting to a file) then all entries are returned. What this doesn't do is any sort of paging. I'm not sure if we want that or not. If 100 entries are returned this could get pretty ugly. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Jun 8 21:42:25 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Jun 2009 17:42:25 -0400 Subject: [Freeipa-devel] [PATCH] 228 add function to prompt for entry after multiple results in -find In-Reply-To: <4A2D859A.1040600@redhat.com> References: <4A2D859A.1040600@redhat.com> Message-ID: <4A2D85C1.7020800@redhat.com> Rob Crittenden wrote: > The -find commands right now just dump all the data that was found. This > function can be used to display a list of the results so the user can > select a specfic record that will be displayed. > > I think that we'll ultimitely implement this within the LDAPObject class > to make it easier on plugin developers. What they will need to provide > is the format line that will be used and the attributes to display. > > The code looks something like: > > selected = textui.select_entry(users, > "%(givenname)s %(sn)s (%(uid)s)", > ("givenname", "sn", "uid")) > if selected == -2: > # Don't show anything else > return > > if selected >= 0: > users = [users[selected]] > counter = 1 > > for u in xrange(counter): > cmd = api.Command['user_show'] > result = cmd(users[u]['uid'].decode('UTF-8'), **options) > if callable(cmd.output_for_cli): > for param in cmd.params(): > if param.password and param.name in options: > del options[param.name] > (args, options) = cmd.params_2_args_options(**options) > cmd.output_for_cli(self.api.Backend.textui, result, > *args, **options) > > This demonstrates the full code in output_for_cli() for the current user > plugin. It looks like this to the user: > > % ipa user-find tim > --------------- > Found 3 matches > --------------- > 1: Tim User (tuser1) > 2: Tim User (tuser2) > 3: Tim User (tuser3) > Choose one: (1 - 3), a for all, q to quit: > > By doing this in a higher-level class we'll save a lot of coding. We > just need to pass in the format string, the list of attributes in that > format string and the command to call to display a full entry. > > This also lets us centralize showing an entry to one function instead of > splitting it between -find and -show. > > If this is called without a tty (like redirecting to a file) then all > entries are returned. > > What this doesn't do is any sort of paging. I'm not sure if we want that > or not. If 100 entries are returned this could get pretty ugly. > > rob The patch is always helpful. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-228-select.patch Type: application/mbox Size: 4781 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Tue Jun 9 02:07:40 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 08 Jun 2009 20:07:40 -0600 Subject: [Freeipa-devel] [PATCHES] Add new set of base classes for IPA plugins using LDAP. In-Reply-To: <4A280FB0.5040004@redhat.com> References: <4A280FB0.5040004@redhat.com> Message-ID: <1244513260.1830.44.camel@jgd-dsk> Pavel, Sorry I was a bit slow to review this. Comments inline... On Thu, 2009-06-04 at 20:17 +0200, Pavel Zuna wrote: > Dear freeipa-devel, > I know we agreed that we're going to post one patch per email, but it this case > I think it's justified. Patches 0001 through 0005 are prerequisites for the new > base classes. Before describing the individual patches, let me explain a little > bit of what I had in mind when implementing this addition. > > For the last few months, I've been mostly working the new LDAP backend and IPA > plugins that use it (i.e. almost all IPA plugins). I tried to make the new > backend more powerful and flexible. Unfortunately, to take full advantage of the > new potential, old plugins had to be rewritten. As there were several > inconsistencies across them (output, naming and sometimes even behavior) and > about half of them were still using old features from IPAv1, I thought that some > re-factoring couldn't hurt after all. > > After porting a few plugins to the new backend, I realized that most of them > were doing pretty much the same thing - manipulating LDAP entries. The only > difference was that some plugins were generating attributes in specific ways > based on user input. So, I figured that most of the generic work could be done > in one place and that's when I started working on these new base classes. > > Let's take a quick look at them: > > LDAPObject > - extends frontend.Object > - represents a type of LDAP entry > (or sub-entry if a parent_key=True parameter is present) > > The following methods are to be used with LDAPObject, they are named after the > CRUD methods they extend with an 'LDAP' prefix. They take 1 argument (the > primary key) in the case their LDAPObject is an entry and 2 arguments (the > parent and primary key, in that order) if their LDAPObject is a subentry: > > LDAPCreate > LDAPRetrieve > LDAPUpdate > LDAPDelete > > Then there's LDAPSearch, which is a bit special. It takes only the optional > criteria argument if its LDAPObject is an entry. If its LDAPObject is a > sub-entry then it requires the parent key as the first argument. The search > logic works as follows: > > 1) If there is no parameters (except for the parent key in the case of > sub-entries), all entries of the given type are returned. > > 2) If there is only the criteria parameter, all entries of the given type with > one or more of their default attributes containing the value of criteria are > returned. > > 3) If there is an options specified, all entries of the given type with the > corresponding attribute EQUAL to the value specified are returned. If more than > one options is specified this way, only entries matching ALL the conditions are > returned. > > 2) and 3) can be combined, so for example, we can make a search for entries who > have a specific attribute equal to 'foo' and some of their other attributes > containing 'bar'. > > All of these base classes implement a 'callback' method, that is called just > before invoking python-ldap through the backend. Subclasses can use it to > execute their specific code after all the boring stuff has been done for them. > > In the future I'm planning to write more base classes for other uses cases such > as adding/removing values from multivalued attributes. > > > Patches descriptions: > --------------------- > > 0001: Make it possible for subclasses of Command and co. to use their own > __public__. > > The problem was with PluginProxy only taking the base class' __public__ into > consideration. ack. I'm actually planning to remove the use of PluginProxy, which would be another way to solve this problem. But you already wrote a fix that works for you and I want this to move forward without git monkey-business slowing us down, so I'll later submit a patch to remove PluginProxy related stuff throughout. I personally find an "always move forward" style of DVCS use to be much more productive. Anyway, despite the fact that PluginProxy is going bye-bye soon, I still want to by convention stay true to some of the things it was designed to enforce, which I'll explain a bit: The reason __public__ on the base class was used is so that a plugin's interface to the outside world is consistent in each namespace (Command, Object, etc.). Otherwise an outside consumer of ipalib (say the web UI or a hypothetical PyGTK UI) might need specific knowledge of which sub-class a, say, Command plugin is based on, which defeats the purpose of the whole architecture. The one exception is api.Backend, which doesn't get wrapped in a PluginProxy as it just doesn't make sense there. But there are two interfaces in question: 1) the interface to the outside world; and 2) the interface between plugins (i.e., in your case api.Command.foo calling methods on api.Object.bar to do work). The first should be used consistently so we can keep our components simple and agnostic, but it's fine for the second to have variability (i.e., it's fine for api.Command.user_add to employ methods on api.Object.user that aren't in the Object base class public API). Anyway, hopefully it didn't take too long to make the __public__ changes as they wouldn't be needed if I already removed PluginProxy. :( We should think of a better way to keep each other in the know about core-related changes we are working on or are in need of. I know Rob already acked the rest and I don't have any objections to anything. > 0002: Add parent_key to keyword arguments of Param base class. > > > 0003: Add support for parent key in Object base class. > > > 0004: Make CRUD base classes take parent key parameters into consideration when > generating args. > > > 0005: Add delete_tree method to ldap2 allowing recursive deletes of whole LDAP > branches. > > Some plugins were doing this "manually", so I figured it might as well be > provided by the LDAP API. > > > 0006: Add new set of base classes for plugins using LDAP. > > > To see the new bases classes in action, take a look at the next patch I'm about > to send to freeipa-devel. > > Pavel > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From jderose at redhat.com Tue Jun 9 16:39:15 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 09 Jun 2009 10:39:15 -0600 Subject: [Freeipa-devel] [PATCH] 228 add function to prompt for entry after multiple results in -find In-Reply-To: <4A2D859A.1040600@redhat.com> References: <4A2D859A.1040600@redhat.com> Message-ID: <1244565555.6533.11.camel@jgd-dsk> On Mon, 2009-06-08 at 17:41 -0400, Rob Crittenden wrote: > The -find commands right now just dump all the data that was found. This > function can be used to display a list of the results so the user can > select a specfic record that will be displayed. > > I think that we'll ultimitely implement this within the LDAPObject class > to make it easier on plugin developers. What they will need to provide > is the format line that will be used and the attributes to display. > > The code looks something like: > > selected = textui.select_entry(users, > "%(givenname)s %(sn)s (%(uid)s)", > ("givenname", "sn", "uid")) > if selected == -2: > # Don't show anything else > return > > if selected >= 0: > users = [users[selected]] > counter = 1 > > for u in xrange(counter): > cmd = api.Command['user_show'] > result = cmd(users[u]['uid'].decode('UTF-8'), **options) > if callable(cmd.output_for_cli): > for param in cmd.params(): > if param.password and param.name in options: > del options[param.name] > (args, options) = cmd.params_2_args_options(**options) > cmd.output_for_cli(self.api.Backend.textui, result, > *args, **options) > > This demonstrates the full code in output_for_cli() for the current user > plugin. It looks like this to the user: > > % ipa user-find tim > --------------- > Found 3 matches > --------------- > 1: Tim User (tuser1) > 2: Tim User (tuser2) > 3: Tim User (tuser3) > Choose one: (1 - 3), a for all, q to quit: I think this is a reasonable approach, although it would be nice to allow the user just display the details on all the entries also. This is important if you want to compare entries, like, "There are 10 Jason's where I work, I'll search for 'Jason' and find the one I'm looking for because I forgot the last name." Dumping all the results (the way we do now) probably has important scripting use-cases too. When you have less than 10 or so matches, IHMO the drill down approach is slower and more cumbersome for the user... it would be faster to scroll through the results to find the one you want. I personally feel we should keep the way we currently do things the default and add an option for this kind of drill down. Either way, there should be an option to switch from one behavior to another. Another nitpick: the "Found 3 matches" should really be at the bottom of the list as it's extremely useful in helping the user evaluate their search, so we don't want it to scroll off the top when there are many results. > By doing this in a higher-level class we'll save a lot of coding. We > just need to pass in the format string, the list of attributes in that > format string and the command to call to display a full entry. > > This also lets us centralize showing an entry to one function instead of > splitting it between -find and -show. > > If this is called without a tty (like redirecting to a file) then all > entries are returned. > > What this doesn't do is any sort of paging. I'm not sure if we want that > or not. If 100 entries are returned this could get pretty ugly. > > rob > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Tue Jun 9 17:22:39 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Jun 2009 13:22:39 -0400 Subject: [Freeipa-devel] [PATCH] 228 add function to prompt for entry after multiple results in -find In-Reply-To: <1244565555.6533.11.camel@jgd-dsk> References: <4A2D859A.1040600@redhat.com> <1244565555.6533.11.camel@jgd-dsk> Message-ID: <4A2E9A5F.4050709@redhat.com> Jason Gerard DeRose wrote: > On Mon, 2009-06-08 at 17:41 -0400, Rob Crittenden wrote: >> The -find commands right now just dump all the data that was found. This >> function can be used to display a list of the results so the user can >> select a specfic record that will be displayed. >> >> I think that we'll ultimitely implement this within the LDAPObject class >> to make it easier on plugin developers. What they will need to provide >> is the format line that will be used and the attributes to display. >> >> The code looks something like: >> >> selected = textui.select_entry(users, >> "%(givenname)s %(sn)s (%(uid)s)", >> ("givenname", "sn", "uid")) >> if selected == -2: >> # Don't show anything else >> return >> >> if selected >= 0: >> users = [users[selected]] >> counter = 1 >> >> for u in xrange(counter): >> cmd = api.Command['user_show'] >> result = cmd(users[u]['uid'].decode('UTF-8'), **options) >> if callable(cmd.output_for_cli): >> for param in cmd.params(): >> if param.password and param.name in options: >> del options[param.name] >> (args, options) = cmd.params_2_args_options(**options) >> cmd.output_for_cli(self.api.Backend.textui, result, >> *args, **options) >> >> This demonstrates the full code in output_for_cli() for the current user >> plugin. It looks like this to the user: >> >> % ipa user-find tim >> --------------- >> Found 3 matches >> --------------- >> 1: Tim User (tuser1) >> 2: Tim User (tuser2) >> 3: Tim User (tuser3) >> Choose one: (1 - 3), a for all, q to quit: > > I think this is a reasonable approach, although it would be nice to > allow the user just display the details on all the entries also. This > is important if you want to compare entries, like, "There are 10 Jason's > where I work, I'll search for 'Jason' and find the one I'm looking for > because I forgot the last name." Dumping all the results (the way we do > now) probably has important scripting use-cases too. Enter 'a' and all entries will be displayed. If there is no controlling API then all entries will be displayed as well. You can also pipe your choice in: echo "a" | ipa user-find jason > When you have less than 10 or so matches, IHMO the drill down approach > is slower and more cumbersome for the user... it would be faster to > scroll through the results to find the one you want. I personally feel > we should keep the way we currently do things the default and add an > option for this kind of drill down. Either way, there should be an > option to switch from one behavior to another. Ok, that should be doable. I still want to use the -show command to actually display any results to eliminate code duplication though. We'll have to see if it is worth the price of additional requests. It was pretty peppy on my system FWIW. > Another nitpick: the "Found 3 matches" should really be at the bottom of > the list as it's extremely useful in helping the user evaluate their > search, so we don't want it to scroll off the top when there are many > results. Ok, that's reasonable. I'll work on a fresh patch. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Jun 9 17:45:01 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Jun 2009 13:45:01 -0400 Subject: [Freeipa-devel] [PATCH] 228 add function to prompt for entry after multiple results in -find In-Reply-To: <4A2E9A5F.4050709@redhat.com> References: <4A2D859A.1040600@redhat.com> <1244565555.6533.11.camel@jgd-dsk> <4A2E9A5F.4050709@redhat.com> Message-ID: <4A2E9F9D.2020108@redhat.com> Rob Crittenden wrote: > Jason Gerard DeRose wrote: >> On Mon, 2009-06-08 at 17:41 -0400, Rob Crittenden wrote: >>> The -find commands right now just dump all the data that was found. >>> This function can be used to display a list of the results so the >>> user can select a specfic record that will be displayed. >>> >>> I think that we'll ultimitely implement this within the LDAPObject >>> class to make it easier on plugin developers. What they will need to >>> provide is the format line that will be used and the attributes to >>> display. >>> >>> The code looks something like: >>> >>> selected = textui.select_entry(users, >>> "%(givenname)s %(sn)s >>> (%(uid)s)", >>> ("givenname", "sn", "uid")) >>> if selected == -2: >>> # Don't show anything else >>> return >>> >>> if selected >= 0: >>> users = [users[selected]] >>> counter = 1 >>> >>> for u in xrange(counter): >>> cmd = api.Command['user_show'] >>> result = cmd(users[u]['uid'].decode('UTF-8'), **options) >>> if callable(cmd.output_for_cli): >>> for param in cmd.params(): >>> if param.password and param.name in options: >>> del options[param.name] >>> (args, options) = cmd.params_2_args_options(**options) >>> cmd.output_for_cli(self.api.Backend.textui, result, >>> *args, **options) >>> >>> This demonstrates the full code in output_for_cli() for the current >>> user plugin. It looks like this to the user: >>> >>> % ipa user-find tim >>> --------------- >>> Found 3 matches >>> --------------- >>> 1: Tim User (tuser1) >>> 2: Tim User (tuser2) >>> 3: Tim User (tuser3) >>> Choose one: (1 - 3), a for all, q to quit: >> >> I think this is a reasonable approach, although it would be nice to >> allow the user just display the details on all the entries also. This >> is important if you want to compare entries, like, "There are 10 Jason's >> where I work, I'll search for 'Jason' and find the one I'm looking for >> because I forgot the last name." Dumping all the results (the way we do >> now) probably has important scripting use-cases too. > > Enter 'a' and all entries will be displayed. If there is no controlling > API then all entries will be displayed as well. You can also pipe your > choice in: echo "a" | ipa user-find jason > >> When you have less than 10 or so matches, IHMO the drill down approach >> is slower and more cumbersome for the user... it would be faster to >> scroll through the results to find the one you want. I personally feel >> we should keep the way we currently do things the default and add an >> option for this kind of drill down. Either way, there should be an >> option to switch from one behavior to another. > > Ok, that should be doable. I still want to use the -show command to > actually display any results to eliminate code duplication though. We'll > have to see if it is worth the price of additional requests. It was > pretty peppy on my system FWIW. > >> Another nitpick: the "Found 3 matches" should really be at the bottom of >> the list as it's extremely useful in helping the user evaluate their >> search, so we don't want it to scroll off the top when there are many >> results. > > Ok, that's reasonable. I'll work on a fresh patch. All I can do with the patch thus far is to re-arrange where we print the search totals. The other work will be done once the new LDAP backend and baseclasses are committed. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-228-2-select.patch Type: application/mbox Size: 4781 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Jun 9 19:29:14 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Jun 2009 15:29:14 -0400 Subject: [Freeipa-devel] [PATCH] 229 standardized return values Message-ID: <4A2EB80A.8040904@redhat.com> We need to return somewhat standardized return values so that scripters can tell when something has gone wrong. Up to now it would return a mashup of the errno code set in the exception but this doesn't easily translate into a 0-255 values supported by the shell. The default value is 1 which means "general failure." A return value of 2 is for not found. 0 means success. This also fixes a long-standing bug with *-find where it would return a 0 if no entries were found. Once the new LDAP backend is integrated and we call the select_entry() method then it will return NotFound() if no matching values were found. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-229-exit.patch Type: application/mbox Size: 2959 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From kwade at redhat.com Wed Jun 10 04:49:52 2009 From: kwade at redhat.com (Karsten Wade) Date: Tue, 9 Jun 2009 21:49:52 -0700 Subject: [Freeipa-devel] Community action plan Message-ID: <20090610044952.GS4469@calliope.phig.org> OK, my subject is a bit misleading. First I want to share with you some ideas ... http://freeipa.org/page/User:Quaid/Community_action_ideas ... as a way to start discussions that become plans. There are a number of small items that are barriers to entry for new participants and contributors to FreeIPA. I've done some research regarding infrastructure and legal requirements, and think I see some ways we can shorten or lower those barriers. By focusing on making FreeIPA-the-project a great place for people to participate, anyone with an interest in IPA has even more reason to identify themselves with a stand-alone, common upstream. From those participants, the serious contributors emerge. I encourage you to read my whole wiki page, and for ease of discussion, here are the main action points: * Move freeipa.org to be within the Fedora Infrastructure under a more advanced agreement within the Fedora Hosted effort. * Make it easier to sign the CLA, tie that in to Fedora Account System (FAS) for easier project growth. * Have editing of the wiki be dynamically linked with FAS, and either permit editing simply by having the group 'cla_FreeIPA' or no CLA. * Make some noise around these changes so people see how much easier it is to contribute; use Linux distros to attract further attention by giving them a friendly and super-useful upstream to send people to. Let us know what you think, - Karsten -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pzuna at redhat.com Wed Jun 10 12:35:58 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 10 Jun 2009 14:35:58 +0200 Subject: [Freeipa-devel] [PATCH] Fix bug in Encoder where tuples were encoded into lists. Fix Encoder and Command.args_options_2_entry unit tests. Message-ID: <4A2FA8AE.8050409@redhat.com> [Re-post of forgotten patch.] Patch 0001: Fix bug in Encoder where tuples were encoded into lists. Fix Encoder and Command.args_options_2_entry unit tests. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-bug-in-Encoder-where-tuples-were-encoded-into-li.patch Type: application/mbox Size: 10182 bytes Desc: not available URL: From pzuna at redhat.com Wed Jun 10 12:36:55 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 10 Jun 2009 14:36:55 +0200 Subject: [Freeipa-devel] [PATCH] Fix bug in ldap2.normalize_dn. Message-ID: <4A2FA8E7.1070403@redhat.com> [Re-post of forgotten patch.] Patch 0001: Fix bug in ldap2.normalize_dn. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-bug-in-ldap2.normalize_dn.patch Type: application/mbox Size: 975 bytes Desc: not available URL: From pzuna at redhat.com Wed Jun 10 12:38:04 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 10 Jun 2009 14:38:04 +0200 Subject: [Freeipa-devel] [PATCH] Add service plugin port to new LDAP backend. Message-ID: <4A2FA92C.7020602@redhat.com> [Re-post of forgotten patch.] Patch 0003: Add service plugin port to new LDAP backend. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-service-plugin-port-to-new-LDAP-backend.patch Type: application/mbox Size: 11912 bytes Desc: not available URL: From pzuna at redhat.com Wed Jun 10 12:39:00 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 10 Jun 2009 14:39:00 +0200 Subject: [Freeipa-devel] [PATCH] Add host plugin port to new LDAP backend. Message-ID: <4A2FA964.2070603@redhat.com> [Re-post of forgotten patch.] Patch 0004: Add host plugin port to new LDAP backend. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Add-host-plugin-port-to-new-LDAP-backend.patch Type: application/mbox Size: 11887 bytes Desc: not available URL: From pzuna at redhat.com Wed Jun 10 12:40:37 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 10 Jun 2009 14:40:37 +0200 Subject: [Freeipa-devel] [PATCH] Fix bug in host plugins, where host*-mod on 'localityname' attribute were creating new values instead of modifying them. Message-ID: <4A2FA9C5.9020807@redhat.com> [Re-post of forgotten patch.] Depends on Patch 0004: Add host plugin port to new LDAP backend. Patch 0005: Fix bug in host plugins, where host*-mod on 'localityname' attribute were creating new values instead of modifying them. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Fix-bug-in-host-plugins-where-host-mod-on-localit.patch Type: application/mbox Size: 1833 bytes Desc: not available URL: From pzuna at redhat.com Wed Jun 10 12:49:50 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 10 Jun 2009 14:49:50 +0200 Subject: [Freeipa-devel] [PATCHES] Add new set of base classes for plugins using LDAP. Message-ID: <4A2FABEE.3020300@redhat.com> I rewritten the patches I posted last week according to the feedback I got. The changes are: - all the functionality specific to LDAP plugin base classes has been removed from Object and crud base classes. - there is now 2 types of callbacks: pre_callbacks (called before passing data to python-ldap throught the LDAP backend) and post_callbacks (called after getting output from python-ldap) - some bug fixes Patch 0006: Modify PluginProxy to use __public__ defined in derived classes instead of base classes. Patch 0007: Add 'parent_key' kwarg in Param class. Patch 0008: Make get_dn parameter list more generic. Fix Attribute name regex. The old name regex made it impossible to have Attribute instances with names composed of more than two words separated by underscores. Patch 0009: Generate crud.Search arguments with get_args. (This might not be required, but I wanted to make sure arguments are generated properly in subclasses.) (Patch 0010 is in a separate e-mail at Martin's request.) Patch 0011: Add new set of base classes for plugins using LDAP. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Modify-PluginProxy-to-use-__public__-defined-in-deri.patch Type: application/mbox Size: 973 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-Add-parent_key-kwarg-in-Param-class.patch Type: application/mbox Size: 767 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Make-get_dn-parameter-list-more-generic.-Fix-Attribu.patch Type: application/mbox Size: 1229 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0009-Generate-crud.Search-arguments-with-get_args.patch Type: application/mbox Size: 1517 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0011-Add-new-set-of-base-classes-for-plugins-using-LDAP.patch Type: application/mbox Size: 12263 bytes Desc: not available URL: From pzuna at redhat.com Wed Jun 10 12:53:05 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 10 Jun 2009 14:53:05 +0200 Subject: [Freeipa-devel] [PATCH] Fix bugs in ldap2. Message-ID: <4A2FACB1.9000702@redhat.com> Patch 0010: Fix bugs in ldap2. - NotFound exception were initialized with no arguments. - find_entry_by_attr returned more than one entry - modify_password had bad arguments and also a typo - removed some code rendered useless since the introduction of Encoder Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0010-Fix-bugs-in-ldap2.patch Type: application/mbox Size: 4121 bytes Desc: not available URL: From pzuna at redhat.com Wed Jun 10 12:54:54 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 10 Jun 2009 14:54:54 +0200 Subject: [Freeipa-devel] [PATCH] Add ACI plugin port to new LDAP backend. Message-ID: <4A2FAD1E.8020000@redhat.com> Patch 0012: Add ACI plugin port to new LDAP backend. ACI plugin port I posted before with bugs fixed. If we don't want to distribute this, it's fine. Just nack the patch. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0012-Add-ACI-plugin-port-to-new-LDAP-backend.patch Type: application/mbox Size: 12972 bytes Desc: not available URL: From pzuna at redhat.com Wed Jun 10 12:55:55 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 10 Jun 2009 14:55:55 +0200 Subject: [Freeipa-devel] [PATCH] Add automount plugin port to new LDAP backend. Message-ID: <4A2FAD5B.6060401@redhat.com> Patch 0013: Add automount plugin port to new LDAP backend. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0013-Add-automount-plugin-port-to-new-LDAP-backend.patch Type: application/mbox Size: 9424 bytes Desc: not available URL: From pzuna at redhat.com Wed Jun 10 12:57:32 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 10 Jun 2009 14:57:32 +0200 Subject: [Freeipa-devel] [PATCH] Add passwd plugin port to new LDAP backend. Message-ID: <4A2FADBC.2090402@redhat.com> Patch 0014: Add passwd plugin port to new LDAP backend. I thought I posted this patch before, but couldn't find it on the list, so I probably didn't. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0014-Add-passwd-plugin-port-to-new-LDAP-backend.patch Type: application/mbox Size: 3032 bytes Desc: not available URL: From pzuna at redhat.com Wed Jun 10 13:04:47 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 10 Jun 2009 15:04:47 +0200 Subject: [Freeipa-devel] [PATCHES] Add HBAC plugin port to new LDAP backend. Message-ID: <4A2FAF6F.5080501@redhat.com> I think this plugin is a good demonstration of what the new base classes for plugins using LDAP can do. The old plugin was considerebaly longer and a lot more complex. Patch 0015: Add GeneralisedTime parameter type. I moved time checking code from the old plugin and made a new auto-validating Param type. Patch 0016: Add HBAC plugin port to new LDAP backend. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0015-Add-GeneralisedTime-parameter-type.patch Type: application/mbox Size: 6879 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0016-Add-HBAC-plugin-port-to-new-LDAP-backend.patch Type: application/mbox Size: 11773 bytes Desc: not available URL: From pzuna at redhat.com Wed Jun 10 13:27:50 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 10 Jun 2009 15:27:50 +0200 Subject: [Freeipa-devel] Making the LDAP backend switch finally happen. Message-ID: <4A2FB4D6.6020409@redhat.com> Dear freeipa-devel, I know I said the LDAP backend switch is going to happen a week ago, but it turned out to be a very bad estimate. I didn't take into account the new base classes I was working on in parallel with porting plugins and also found out there are about 20 outstanding patches that still need acking (which is completely my fault for not keeping track of them). I went through all the outstanding patches, re-based my tree and made them all apply. Here's a list: 0001 Fix bug in Encoder where tuples were encoded into lists. Fix Encoder and Command.args_options_2_entry unit tests. 0002 Fix bug in ldap2.normalize_dn. 0003 Add service plugin port to new LDAP backend. 0004 Add host plugin port to new LDAP backend. 0005 Fix bug in host plugins, where host*-mod on 'localityname' attribute were creating new values instead of modifying them. 0006 Modify PluginProxy to use __public__ defined in derived classes instead of base classes. 0007 Add 'parent_key' kwarg in Param class. 0008 Make get_dn parameter list more generic. Fix Attribute name regex. 0009 Generate crud.Search arguments with get_args. 0010 Fix bugs in ldap2. 0011 Add new set of base classes for plugins using LDAP. 0012 Add ACI plugin port to new LDAP backend. 0013 Add automount plugin port to new LDAP backend. 0014 Add passwd plugin port to new LDAP backend. 0015 Add GeneralisedTime parameter type. 0016 Add HBAC plugin port to new LDAP backend. I (re-)posted all of them just before this e-mail. What's next after we get these patches into the tree? - remove all patches using the old backend - rename plugins2 to plugins - rename -create/-delete commands to -add/-del * complete switch for plugins, this should be pretty straight forward - I suggest we remove the old crud base classes (Add, Get, Mod, Del, Find) - the old backend is used in install scripts, I didn't get to change them yet, but I'm getting to it now - remove the old backend - rename ldap2 to ldap * complete switch, no traces of old backend left Pavel From rcritten at redhat.com Wed Jun 10 14:02:17 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Jun 2009 10:02:17 -0400 Subject: [Freeipa-devel] [PATCH] 230 enable VLV anonymous browsing Message-ID: <4A2FBCE9.6080606@redhat.com> Enable anonyomus VLV browsing so that automount on Solaris will work. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-230-vlv.patch Type: application/mbox Size: 1373 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Wed Jun 10 14:07:43 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 10 Jun 2009 10:07:43 -0400 Subject: [Freeipa-devel] Community action plan In-Reply-To: <20090610044952.GS4469@calliope.phig.org> References: <20090610044952.GS4469@calliope.phig.org> Message-ID: <4A2FBE2F.20604@redhat.com> Hi Karsten, I am glad that we finally got someone who will help us to evolve into a more open community. But I want to talk about two main problems: a) Technical problems b) Procedural problems The technical problems are related to CLI and its signing. I do not see big issue with following your suggestions about CLI and moving to Fedora infrastructure. I personally do not have a strong opinion about it. I just know, however, that freeIPA was launched outside of Fedora on purpose. One of the reasons is to avoid affiliation with a specific distribution and have a cross distribution community. We have not accomplished this so I am open to trying a different approach but I would liek to hear opinion of other developers on the matter. We can also improve the wiki and access to it. I do not see a big problem there either. With the documentation there are two parts - there is a development documentation and user documentation. The user documentation written by one doc person is the aggregated information from the development documentation plus this doc person's own research and experiments. If we get a better quality of the original developer written document and information we will solve biggest part of the problem so I would start there. But the biggest problem is that we are running the project "semi-open". We have IRC, email list and wiki. All possible information is exposed there but it still not enough. And I would say that it is my fault. I see several issues with me and with the team here: a) I come from the corporate culture. I know how to run the project efficiently if the development team is well defined and focused. I do not know how to run projects in the open ended community. And we do not have one so until no one from outside Red Hat gets involved I am running the project as I see most efficient. This is chicken and egg problem. I realize that while the project is run this way we might hardly get any contributors but we will move on and operate as a well oiled mechanism. Once we get someone involved we would have to adapt and adjust, but we will not attract anybody until we change the way the project is run. b) There is no culture of writing good designs or capturing information one got in a research of the code. "Go read the code" paradigm IMO is the key issue. But trying to change the attitude is like boiling the ocean. We can still work hard on keeping the designs up to date and pages updated. This would be a full time job. I do not have cycles to do it. Unfortunately developers do not have cycles to maintain the design pages too. I am open to suggestions here since I think that sufficient developer documentation is crucial for community involvement and quality of the software. I do not think that jumping around IRC logs, mail threads and wiki pages is efficient. I doubt that anyone new would ever go for such quest (until he is highly motivated for whatever reason). There should be one place where any new person can get a good jumpstart with the project including history of decision making, current status of things and future direction. But who will do this? Again chicken and egg problem: why would I spend cycles on this if nobody is reading; nobody will read until it is sufficient. So the bold changes should be: a) Solve technical problems b) Work with developers on improving the developer documentation c) Replace the manager -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Jun 10 15:12:40 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Jun 2009 11:12:40 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix bug in ldap2.normalize_dn. In-Reply-To: <4A2FA8E7.1070403@redhat.com> References: <4A2FA8E7.1070403@redhat.com> Message-ID: <4A2FCD68.7040604@redhat.com> Pavel Zuna wrote: > [Re-post of forgotten patch.] > > Patch 0001: Fix bug in ldap2.normalize_dn. > > Pavel I'm not sure I understand the commit comment about mixed case DNs. If this function is supposed to normalize DNs then they should all come out the same, right? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Jun 10 15:22:44 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Jun 2009 11:22:44 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix bug in host plugins, where host*-mod on 'localityname' attribute were creating new values instead of modifying them. In-Reply-To: <4A2FA9C5.9020807@redhat.com> References: <4A2FA9C5.9020807@redhat.com> Message-ID: <4A2FCFC4.8090804@redhat.com> Pavel Zuna wrote: > [Re-post of forgotten patch.] > > Depends on Patch 0004: Add host plugin port to new LDAP backend. > > Patch 0005: Fix bug in host plugins, where host*-mod on 'localityname' > attribute were creating new values instead of modifying them. > > Pavel Would it be better to just switch the attribute to 'l' in the plugin instead? This does bring up a general problem if we don't handle attribute aliasing. I believe that in the schema it lists the preferred order of the attributes (so 'l', 'locality', 'localityname'). Can we use the schema you load to do this attribute-name rewriting? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Wed Jun 10 15:32:49 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 10 Jun 2009 17:32:49 +0200 Subject: [Freeipa-devel] Re: [PATCH] Fix bug in ldap2.normalize_dn. In-Reply-To: <4A2FCD68.7040604@redhat.com> References: <4A2FA8E7.1070403@redhat.com> <4A2FCD68.7040604@redhat.com> Message-ID: <4A2FD221.2070505@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> [Re-post of forgotten patch.] >> >> Patch 0001: Fix bug in ldap2.normalize_dn. >> >> Pavel > > I'm not sure I understand the commit comment about mixed case DNs. If > this function is supposed to normalize DNs then they should all come out > the same, right? > > rob Well, I run into a problem with the service plugin (and it would probably cause problems in other plugins too). When creating the entry with a RDN attribute containing upper-case characters, 2 values were actually created. For example: # ipa service2-create DNS/test ---------------- service2-create: ---------------- dn: krbprincipalname=dns/test at pzuna,cn=services,cn=accounts,dc=pzuna krbprincipalname: DNS/test at PZUNA krbprincipalname: dns/test at pzuna objectclass: krbprincipal objectclass: krbprincipalaux objectclass: krbticketpolicyaux objectclass: ipaservice objectclass: pkiuser objectclass: top --------------------------- Created service "DNS/test. --------------------------- One of the value was entered by the plugin and the other one derived from the DN (which was actually build from the attribute value, but converted to lower-case) by DS. The old plugin wasn't converting DN to lower-case and let DS figure out the RDN attribute value from it. There might be a better way around this, but I couldn't find any. Pavel From pzuna at redhat.com Wed Jun 10 15:37:11 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 10 Jun 2009 17:37:11 +0200 Subject: [Freeipa-devel] Re: [PATCH] Fix bug in host plugins, where host*-mod on 'localityname' attribute were creating new values instead of modifying them. In-Reply-To: <4A2FCFC4.8090804@redhat.com> References: <4A2FA9C5.9020807@redhat.com> <4A2FCFC4.8090804@redhat.com> Message-ID: <4A2FD327.4040902@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> [Re-post of forgotten patch.] >> >> Depends on Patch 0004: Add host plugin port to new LDAP backend. >> >> Patch 0005: Fix bug in host plugins, where host*-mod on 'localityname' >> attribute were creating new values instead of modifying them. >> >> Pavel > > Would it be better to just switch the attribute to 'l' in the plugin > instead? It would, but we can't do that, because the IPA plugin framework doesn't allow parameter names to be this short. > This does bring up a general problem if we don't handle attribute > aliasing. I believe that in the schema it lists the preferred order of > the attributes (so 'l', 'locality', 'localityname'). Can we use the > schema you load to do this attribute-name rewriting? Why didn't I think of this? Good idea, I'll try to implement it. > rob Pavel From rcritten at redhat.com Wed Jun 10 15:53:14 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Jun 2009 11:53:14 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix bug in Encoder where tuples were encoded into lists. Fix Encoder and Command.args_options_2_entry unit tests. In-Reply-To: <4A2FA8AE.8050409@redhat.com> References: <4A2FA8AE.8050409@redhat.com> Message-ID: <4A2FD6EA.8030704@redhat.com> Pavel Zuna wrote: > [Re-post of forgotten patch.] > > Patch 0001: Fix bug in Encoder where tuples were encoded into lists. Fix > Encoder and Command.args_options_2_entry unit tests. > > Pavel ack, pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Jun 10 15:53:18 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Jun 2009 11:53:18 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix bug in ldap2.normalize_dn. In-Reply-To: <4A2FD221.2070505@redhat.com> References: <4A2FA8E7.1070403@redhat.com> <4A2FCD68.7040604@redhat.com> <4A2FD221.2070505@redhat.com> Message-ID: <4A2FD6EE.2070209@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> [Re-post of forgotten patch.] >>> >>> Patch 0001: Fix bug in ldap2.normalize_dn. >>> >>> Pavel >> >> I'm not sure I understand the commit comment about mixed case DNs. If >> this function is supposed to normalize DNs then they should all come >> out the same, right? >> >> rob > Well, I run into a problem with the service plugin (and it would > probably cause problems in other plugins too). When creating the entry > with a RDN attribute containing upper-case characters, 2 values were > actually created. For example: > > # ipa service2-create DNS/test > ---------------- > service2-create: > ---------------- > dn: krbprincipalname=dns/test at pzuna,cn=services,cn=accounts,dc=pzuna > krbprincipalname: DNS/test at PZUNA > krbprincipalname: dns/test at pzuna > objectclass: krbprincipal > objectclass: krbprincipalaux > objectclass: krbticketpolicyaux > objectclass: ipaservice > objectclass: pkiuser > objectclass: top > --------------------------- > Created service "DNS/test. > --------------------------- > > One of the value was entered by the plugin and the other one derived > from the DN (which was actually build from the attribute value, but > converted to lower-case) by DS. > > The old plugin wasn't converting DN to lower-case and let DS figure out > the RDN attribute value from it. > > There might be a better way around this, but I couldn't find any. > > Pavel Good point. ack, pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Jun 10 15:53:21 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Jun 2009 11:53:21 -0400 Subject: [Freeipa-devel] Re: [PATCH] Add service plugin port to new LDAP backend. In-Reply-To: <4A2FA92C.7020602@redhat.com> References: <4A2FA92C.7020602@redhat.com> Message-ID: <4A2FD6F1.5060608@redhat.com> Pavel Zuna wrote: > [Re-post of forgotten patch.] > > Patch 0003: Add service plugin port to new LDAP backend. > > Pavel ack, pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Jun 10 15:53:24 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Jun 2009 11:53:24 -0400 Subject: [Freeipa-devel] Re: [PATCH] Add host plugin port to new LDAP backend. In-Reply-To: <4A2FA964.2070603@redhat.com> References: <4A2FA964.2070603@redhat.com> Message-ID: <4A2FD6F4.2090908@redhat.com> Pavel Zuna wrote: > [Re-post of forgotten patch.] > > Patch 0004: Add host plugin port to new LDAP backend. > > Pavel ack, pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Jun 10 15:53:31 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Jun 2009 11:53:31 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Add new set of base classes for plugins using LDAP. In-Reply-To: <4A2FABEE.3020300@redhat.com> References: <4A2FABEE.3020300@redhat.com> Message-ID: <4A2FD6FB.5000308@redhat.com> Pavel Zuna wrote: > I rewritten the patches I posted last week according to the feedback I got. > > The changes are: > - all the functionality specific to LDAP plugin base classes has been > removed from Object and crud base classes. > - there is now 2 types of callbacks: pre_callbacks (called before > passing data to python-ldap throught the LDAP backend) and > post_callbacks (called after getting output from python-ldap) > - some bug fixes > > Patch 0006: Modify PluginProxy to use __public__ defined in derived > classes instead of base classes. ack > > Patch 0007: Add 'parent_key' kwarg in Param class. ack, still not super happy with the variable name but since I can't come up with anything better we'll stick with it :-) > > Patch 0008: Make get_dn parameter list more generic. Fix Attribute name > regex. > > The old name regex made it impossible to have Attribute instances with > names composed of more than two words separated by underscores. ack > > Patch 0009: Generate crud.Search arguments with get_args. > > (This might not be required, but I wanted to make sure arguments are > generated properly in subclasses.) ack > > (Patch 0010 is in a separate e-mail at Martin's request.) > > Patch 0011: Add new set of base classes for plugins using LDAP. nack. The reason that 2 values are returned in a list via the search in the current backend (and v1) is so you can tell whether a search failed because it exceeded either the size or time limits. We called this a "truncated" search. We return as much as we can though. I think we should retain this capability, even if we do it slightly differently. The 4 patches I acked I've pushed to master. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Jun 10 15:55:11 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Jun 2009 11:55:11 -0400 Subject: [Freeipa-devel] Re: [PATCH] Add ACI plugin port to new LDAP backend. In-Reply-To: <4A2FAD1E.8020000@redhat.com> References: <4A2FAD1E.8020000@redhat.com> Message-ID: <4A2FD75F.3030100@redhat.com> Pavel Zuna wrote: > Patch 0012: Add ACI plugin port to new LDAP backend. > > ACI plugin port I posted before with bugs fixed. > > If we don't want to distribute this, it's fine. Just nack the patch. > > Pavel I think we simply won't include it in the rpms we ship, it is fine for developers who realize they'll hose their systems if they misuse it to give it a go. ack, pushed to master rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Jun 10 15:55:23 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Jun 2009 11:55:23 -0400 Subject: [Freeipa-devel] Re: [PATCH] Add passwd plugin port to new LDAP backend. In-Reply-To: <4A2FADBC.2090402@redhat.com> References: <4A2FADBC.2090402@redhat.com> Message-ID: <4A2FD76B.30004@redhat.com> Pavel Zuna wrote: > Patch 0014: Add passwd plugin port to new LDAP backend. > > I thought I posted this patch before, but couldn't find it on the list, > so I probably didn't. > > Pavel ack, pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Jun 10 15:55:41 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Jun 2009 11:55:41 -0400 Subject: [Freeipa-devel] Re: [PATCH] Add automount plugin port to new LDAP backend. In-Reply-To: <4A2FAD5B.6060401@redhat.com> References: <4A2FAD5B.6060401@redhat.com> Message-ID: <4A2FD77D.2070203@redhat.com> Pavel Zuna wrote: > Patch 0013: Add automount plugin port to new LDAP backend. > > Pavel This looks ok but depends on a patch I just nacked so we'll have to remember to come back to this one. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Wed Jun 10 16:50:36 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 10 Jun 2009 18:50:36 +0200 Subject: [Freeipa-devel] Re: [PATCHES] Add new set of base classes for plugins using LDAP. In-Reply-To: <4A2FD6FB.5000308@redhat.com> References: <4A2FABEE.3020300@redhat.com> <4A2FD6FB.5000308@redhat.com> Message-ID: <4A2FE45C.3090708@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> I rewritten the patches I posted last week according to the feedback I >> got. >> >> The changes are: >> - all the functionality specific to LDAP plugin base classes has been >> removed from Object and crud base classes. >> - there is now 2 types of callbacks: pre_callbacks (called before >> passing data to python-ldap throught the LDAP backend) and >> post_callbacks (called after getting output from python-ldap) >> - some bug fixes >> >> Patch 0006: Modify PluginProxy to use __public__ defined in derived >> classes instead of base classes. > > ack > >> >> Patch 0007: Add 'parent_key' kwarg in Param class. > > ack, still not super happy with the variable name but since I can't come > up with anything better we'll stick with it :-) > >> >> Patch 0008: Make get_dn parameter list more generic. Fix Attribute >> name regex. >> >> The old name regex made it impossible to have Attribute instances with >> names composed of more than two words separated by underscores. > > ack > >> >> Patch 0009: Generate crud.Search arguments with get_args. >> >> (This might not be required, but I wanted to make sure arguments are >> generated properly in subclasses.) > > ack > >> >> (Patch 0010 is in a separate e-mail at Martin's request.) >> >> Patch 0011: Add new set of base classes for plugins using LDAP. > > nack. The reason that 2 values are returned in a list via the search in > the current backend (and v1) is so you can tell whether a search failed > because it exceeded either the size or time limits. We called this a > "truncated" search. We return as much as we can though. I think we > should retain this capability, even if we do it slightly differently. I played a bit with python-ldap and the only way to do this is to make an asynchronous search, then pull the entries one by one. I don't know what the common size/time limits are on DS, but pulling thousands of entries one by one didn't seem like a good idea. Although maybe it's not such a big deal as I think. At this point, if some limit is exceeded, an exception is raised and the user needs to narrow down his search criteria. If we want to retain the 'truncated' search capability, I'll implement it, but it will require small changes in a lot of places. If this is the only complain about the new bases classes, I think they should be pushed - the problem is actually in the LDAP backend itself. > The 4 patches I acked I've pushed to master. > > rob Pavel From rcritten at redhat.com Wed Jun 10 17:34:47 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Jun 2009 13:34:47 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Add new set of base classes for plugins using LDAP. In-Reply-To: <4A2FE45C.3090708@redhat.com> References: <4A2FABEE.3020300@redhat.com> <4A2FD6FB.5000308@redhat.com> <4A2FE45C.3090708@redhat.com> Message-ID: <4A2FEEB7.6090100@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> I rewritten the patches I posted last week according to the feedback >>> I got. >>> >>> The changes are: >>> - all the functionality specific to LDAP plugin base classes has been >>> removed from Object and crud base classes. >>> - there is now 2 types of callbacks: pre_callbacks (called before >>> passing data to python-ldap throught the LDAP backend) and >>> post_callbacks (called after getting output from python-ldap) >>> - some bug fixes >>> >>> Patch 0006: Modify PluginProxy to use __public__ defined in derived >>> classes instead of base classes. >> >> ack >> >>> >>> Patch 0007: Add 'parent_key' kwarg in Param class. >> >> ack, still not super happy with the variable name but since I can't >> come up with anything better we'll stick with it :-) >> >>> >>> Patch 0008: Make get_dn parameter list more generic. Fix Attribute >>> name regex. >>> >>> The old name regex made it impossible to have Attribute instances >>> with names composed of more than two words separated by underscores. >> >> ack >> >>> >>> Patch 0009: Generate crud.Search arguments with get_args. >>> >>> (This might not be required, but I wanted to make sure arguments are >>> generated properly in subclasses.) >> >> ack >> >>> >>> (Patch 0010 is in a separate e-mail at Martin's request.) >>> >>> Patch 0011: Add new set of base classes for plugins using LDAP. >> >> nack. The reason that 2 values are returned in a list via the search >> in the current backend (and v1) is so you can tell whether a search >> failed because it exceeded either the size or time limits. We called >> this a "truncated" search. We return as much as we can though. I think >> we should retain this capability, even if we do it slightly differently. > I played a bit with python-ldap and the only way to do this is to make > an asynchronous search, then pull the entries one by one. I don't know > what the common size/time limits are on DS, but pulling thousands of > entries one by one didn't seem like a good idea. Although maybe it's not > such a big deal as I think. Well, no guarantee that they will be returned one by one but yes, you need to continue a looping read until all the results are returned. You wouldn't end up pulling thousands of records unless the admin set the limits that high. But it does provide a nice degraded operation so that rather than getting a cryptic error message about limits being exceeded they get something to look at. > At this point, if some limit is exceeded, an exception is raised and the > user needs to narrow down his search criteria. If we want to retain the > 'truncated' search capability, I'll implement it, but it will require > small changes in a lot of places. If this is the only complain about the > new bases classes, I think they should be pushed - the problem is > actually in the LDAP backend itself. > It is actually fairly fundamental because it changes the data coming back out of the find commands. Rather than a list of entries it will be a tuple with the first value being the number of entries returned and the list of entries. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Wed Jun 10 18:04:18 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 10 Jun 2009 18:04:18 +0000 Subject: [Freeipa-devel] [PATCHES] minor fixes/enhancements Message-ID: <1244657058.25513.18.camel@localhost.localdomain> I had this patches for a while in my private tree. I think it's time to push them. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Link-crypt-functions-only-to-sssd-binaries.patch Type: text/x-patch Size: 932 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-warnings-in-stress-tests.c.patch Type: text/x-patch Size: 4627 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Turn-sssd_mem_takeover-into-sssd_mem_attach.patch Type: text/x-patch Size: 4574 bytes Desc: not available URL: From sgallagh at redhat.com Wed Jun 10 18:40:53 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 10 Jun 2009 14:40:53 -0400 Subject: [Freeipa-devel] [PATCHES] minor fixes/enhancements In-Reply-To: <1244657058.25513.18.camel@localhost.localdomain> References: <1244657058.25513.18.camel@localhost.localdomain> Message-ID: <4A2FFE35.8000307@redhat.com> On 06/10/2009 02:04 PM, Simo Sorce wrote: > I had this patches for a while in my private tree. > > I think it's time to push them. > > Simo. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel 0001: Ack 0002: Ack 0003: Ack, but shouldn't we consider getting something like this upstreamed to talloc instead? It seems to me that being able to talloc()-ify generic memory would be a good feature for libtalloc to have. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Wed Jun 10 18:56:23 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 10 Jun 2009 14:56:23 -0400 Subject: [Freeipa-devel] [PATCHES] minor fixes/enhancements In-Reply-To: <4A2FFE35.8000307@redhat.com> References: <1244657058.25513.18.camel@localhost.localdomain> <4A2FFE35.8000307@redhat.com> Message-ID: <1244660183.25513.21.camel@localhost.localdomain> On Wed, 2009-06-10 at 14:40 -0400, Stephen Gallagher wrote: > On 06/10/2009 02:04 PM, Simo Sorce wrote: > > I had this patches for a while in my private tree. > > > > I think it's time to push them. > 0001: Ack > 0002: Ack > 0003: Ack, pushed > but shouldn't we consider getting something like this > upstreamed to talloc instead? It seems to me that being able to > talloc()-ify generic memory would be a good feature for libtalloc to have. Not sure, I'll think about that. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Jun 10 19:25:50 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Jun 2009 15:25:50 -0400 Subject: [Freeipa-devel] [PATCH] 231 Add one-character option to cli Message-ID: <4A3008BE.7050204@redhat.com> Add support for single and double dashed options. The double-dashed options are the ones created by default, single ones can be added by defining cli_short_name in the Param. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-231-option.patch Type: application/mbox Size: 2021 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Jun 10 21:38:37 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Jun 2009 17:38:37 -0400 Subject: [Freeipa-devel] per-group password policy proposal Message-ID: <4A3027DD.5060107@redhat.com> One feature we want to add to v2 is per-group password policy. The IPA password policy is implemented completely separately from the DS password policy (because it is the KDC that does the enforcement, AFAICT). Currently it finds the password policy by searching the base for objectClass=krbPwdPolicy. What I propose is to leave that, it will become the "global" password policy, and add an search before that to look for the pwdpolicysubentry attribute in the user. This attribute is used for the DS password policy to tell it where in the tree the password policy for this entry exists. I'm not quite sure I want to re-use this attribute like this but it's a starting point anyway. The way I want to do per-group password policy is to create a Class of Service for it. Tread carefully when reading this, it is known to cause serious headaches. First, we set up a place to hold the policies: dn: cn=nsPwPolicyContainer,$SUFFIX objectClass: top objectClass: nsContainer cn: nsPwPolicyContainer And here is a sample policy: dn: cn="cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX objectClass: top objectClass: nsContainer objectClass: krbPwdPolicy cn: cn=group1,cn=groups,cn=accounts,$SUFFIX krbMinPwdLife: 3600 krbPwdMinDiffChars: 0 krbPwdMinLength: 8 krbPwdHistoryLength: 0 krbMaxPwdLife: 7776000 We start with a classic CoS entry that utilizes the existing CoS template infrastructure (for account locking): dn: cn=Password Policy,cn=accounts,$SUFFIX description: Password Policy based on group membership objectClass: top objectClass: ldapsubentry objectClass: cosSuperDefinition objectClass: cosClassicDefinition cosTemplateDn: cn=cosTemplates,cn=accounts,$SUFFIX cosAttribute: pwdpolicysubentry operational cosSpecifier: memberOf cn: Password Policy To make a policy for a specific group we just need to add a template for it. Here is what it would look like for group1: dn: cn="cn=group1,cn=groups,cn=accounts,$SUFFIX", cn=cosTemplates,cn=accounts,$SUFFIX objectClass: top objectClass: cosTemplate objectClass: extensibleobject pwdpolicysubentry: cn="cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX cosPriority: 1 So you add all this, and add a user to group1 and query for pwdpolicysubentry you get "cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX The ipa_pwd_extop plugin would search for this attribute and if it found one, would pull the policy from the attribute value, otherwise it would fall back to the global policy. Now we don't want to deal with overlapping policies but I'm not sure we can do a whole lot about it, particularly when a group is made a member of another group. It would be painful to recursively look at every single user to see if they already have a policy. The best we can do, I think, is to check when a user is added to a group whether they already have a policy and if so, quit. Or we can try to control which policy to use based on cosPriority. I'm not sure how we would expose this to the user interface but I think that the higher number winning is a pretty understandable concept. The problem would be having a way to know what the current highest value is. I'm not entirely sure yet how this would be managed. I suspect we could get away with a standard CRUD API to manage creating the policies and associating them with a group. We'd just need some special way to specify group or global. So am I on the right track here? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Thu Jun 11 03:32:14 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 10 Jun 2009 23:32:14 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <4A3027DD.5060107@redhat.com> References: <4A3027DD.5060107@redhat.com> Message-ID: <4A307ABE.3090409@redhat.com> Rob Crittenden wrote: > One feature we want to add to v2 is per-group password policy. The IPA > password policy is implemented completely separately from the DS > password policy (because it is the KDC that does the enforcement, > AFAICT). > > Currently it finds the password policy by searching the base for > objectClass=krbPwdPolicy. > > What I propose is to leave that, it will become the "global" password > policy, and add an search before that to look for the > pwdpolicysubentry attribute in the user. > > This attribute is used for the DS password policy to tell it where in > the tree the password policy for this entry exists. I'm not quite sure > I want to re-use this attribute like this but it's a starting point > anyway. > > The way I want to do per-group password policy is to create a Class of > Service for it. > > Tread carefully when reading this, it is known to cause serious > headaches. > > First, we set up a place to hold the policies: > > dn: cn=nsPwPolicyContainer,$SUFFIX > objectClass: top > objectClass: nsContainer > cn: nsPwPolicyContainer > > And here is a sample policy: > > dn: > cn="cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX > > objectClass: top > objectClass: nsContainer > objectClass: krbPwdPolicy > cn: cn=group1,cn=groups,cn=accounts,$SUFFIX > krbMinPwdLife: 3600 > krbPwdMinDiffChars: 0 > krbPwdMinLength: 8 > krbPwdHistoryLength: 0 > krbMaxPwdLife: 7776000 > > We start with a classic CoS entry that utilizes the existing CoS > template infrastructure (for account locking): > > dn: cn=Password Policy,cn=accounts,$SUFFIX > description: Password Policy based on group membership > objectClass: top > objectClass: ldapsubentry > objectClass: cosSuperDefinition > objectClass: cosClassicDefinition > cosTemplateDn: cn=cosTemplates,cn=accounts,$SUFFIX > cosAttribute: pwdpolicysubentry operational > cosSpecifier: memberOf > cn: Password Policy > > To make a policy for a specific group we just need to add a template > for it. Here is what it would look like for group1: > > dn: cn="cn=group1,cn=groups,cn=accounts,$SUFFIX", > cn=cosTemplates,cn=accounts,$SUFFIX > objectClass: top > objectClass: cosTemplate > objectClass: extensibleobject > pwdpolicysubentry: > cn="cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX > > cosPriority: 1 > > So you add all this, and add a user to group1 and query for > pwdpolicysubentry you get > "cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX > > The ipa_pwd_extop plugin would search for this attribute and if it > found one, would pull the policy from the attribute value, otherwise > it would fall back to the global policy. > > Now we don't want to deal with overlapping policies but I'm not sure > we can do a whole lot about it, particularly when a group is made a > member of another group. It would be painful to recursively look at > every single user to see if they already have a policy. > > The best we can do, I think, is to check when a user is added to a > group whether they already have a policy and if so, quit. > > Or we can try to control which policy to use based on cosPriority. I'm > not sure how we would expose this to the user interface but I think > that the higher number winning is a pretty understandable concept. The > problem would be having a way to know what the current highest value is. > > I'm not entirely sure yet how this would be managed. I suspect we > could get away with a standard CRUD API to manage creating the > policies and associating them with a group. We'd just need some > special way to specify group or global. > > So am I on the right track here? I am not sure. I was envisioning it quite differently. The ambiguity in this case critical and might be not acceptable since it would be hard to determine which policy should be used in case user is a member of different groups. Management of priorities is also a pain and creates complex UI and CLI. I was more thinking about having a specific policy per user. AFAIR the software can check the user related password policy attributes right now without any changes to the code. There attributes just not there. So we need to give admin the ability to set them. I was thinking that defining password policies is a bulk operation that updates specific users that belong to a group and creates the attributes in the user entries. If we do it this way we would be able to say: Password policy is XYZ. Apply this password policy to users in this group (including or not including sub groups) for those users that do not have the policy set or for all users in the given group. There might be other conditions for the query. In such case it is easy to control who gets the policy when the policy is defined and easy to determine what policy is active for the user (for audit purposes) since there is no ambiguity. > > rob > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From serejka at gmail.com Thu Jun 11 07:36:32 2009 From: serejka at gmail.com (Sergei V. Kovylov) Date: Thu, 11 Jun 2009 11:36:32 +0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <4A307ABE.3090409@redhat.com> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> Message-ID: <7870594c0906110036p4c259239x764bf4a54b682032@mail.gmail.com> Hello guys. I hope it's OK for devel if I share my point of view for this question. I think that Dmitri is right. It's usual situation, when user may exists in several groups and decision of which group's policy must be applied is hard to define (it must be on end-user side not on developers one). Moreover, password policy is just a top of iceberg, because there are lots of aspects which freeipa may cover, for example template for user creation (pre-defined home directories, access policy etc.). In this case usage of DS roles and CoS may provide flexible mechanism of manage. In part of password policy usage of filtered roles will do the same as per-group policy but without fixing them to special group and exclude some mechanism of group classes ( i mean password policy group, some other option group). In such case freeipa will provide policy mechanism which may be used not only for group but for some sub-entry, for some attribute in user account etc. With CoS we are able to define MAY or MUST one policy in nested group be replaced by parent one or not. Thanks. 2009/6/11 Dmitri Pal : > Rob Crittenden wrote: >> >> One feature we want to add to v2 is per-group password policy. The IPA >> password policy is implemented completely separately from the DS password >> policy (because it is the KDC that does the enforcement, AFAICT). >> >> Currently it finds the password policy by searching the base for >> objectClass=krbPwdPolicy. >> >> What I propose is to leave that, it will become the "global" password >> policy, and add an search before that to look for the pwdpolicysubentry >> attribute in the user. >> >> This attribute is used for the DS password policy to tell it where in the >> tree the password policy for this entry exists. I'm not quite sure I want to >> re-use this attribute like this but it's a starting point anyway. >> >> The way I want to do per-group password policy is to create a Class of >> Service for it. >> >> Tread carefully when reading this, it is known to cause serious headaches. >> >> First, we set up a place to hold the policies: >> >> dn: cn=nsPwPolicyContainer,$SUFFIX >> objectClass: top >> objectClass: nsContainer >> cn: nsPwPolicyContainer >> >> And here is a sample policy: >> >> dn: >> cn="cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX >> objectClass: top >> objectClass: nsContainer >> objectClass: krbPwdPolicy >> cn: cn=group1,cn=groups,cn=accounts,$SUFFIX >> krbMinPwdLife: 3600 >> krbPwdMinDiffChars: 0 >> krbPwdMinLength: 8 >> krbPwdHistoryLength: 0 >> krbMaxPwdLife: 7776000 >> >> We start with a classic CoS entry that utilizes the existing CoS template >> infrastructure (for account locking): >> >> dn: cn=Password Policy,cn=accounts,$SUFFIX >> description: Password Policy based on group membership >> objectClass: top >> objectClass: ldapsubentry >> objectClass: cosSuperDefinition >> objectClass: cosClassicDefinition >> cosTemplateDn: cn=cosTemplates,cn=accounts,$SUFFIX >> cosAttribute: pwdpolicysubentry operational >> cosSpecifier: memberOf >> cn: Password Policy >> >> To make a policy for a specific group we just need to add a template for >> it. Here is what it would look like for group1: >> >> dn: cn="cn=group1,cn=groups,cn=accounts,$SUFFIX", >> cn=cosTemplates,cn=accounts,$SUFFIX >> objectClass: top >> objectClass: cosTemplate >> objectClass: extensibleobject >> pwdpolicysubentry: >> cn="cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX >> cosPriority: 1 >> >> So you add all this, and add a user to group1 and query for >> pwdpolicysubentry you get >> "cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX >> >> The ipa_pwd_extop plugin would search for this attribute and if it found >> one, would pull the policy from the attribute value, otherwise it would fall >> back to the global policy. >> >> Now we don't want to deal with overlapping policies but I'm not sure we >> can do a whole lot about it, particularly when a group is made a member of >> another group. It would be painful to recursively look at every single user >> to see if they already have a policy. >> >> The best we can do, I think, is to check when a user is added to a group >> whether they already have a policy and if so, quit. >> >> Or we can try to control which policy to use based on cosPriority. I'm not >> sure how we would expose this to the user interface but I think that the >> higher number winning is a pretty understandable concept. The problem would >> be having a way to know what the current highest value is. >> >> I'm not entirely sure yet how this would be managed. I suspect we could >> get away with a standard CRUD API to manage creating the policies and >> associating them with a group. We'd just need some special way to specify >> group or global. >> >> So am I on the right track here? > > I am not sure. > I was envisioning it quite differently. > The ambiguity in this case critical and might be not acceptable since it > would be hard to determine which policy should be used in case user is a > member of different groups. > Management of priorities is also a pain and creates complex ?UI and CLI. > I was more thinking about having a specific policy per user. AFAIR the > software can check the user related password policy attributes right now > without any changes to the code. There attributes just not there. So we need > to give admin the ability to set them. I was thinking that defining password > policies is a bulk operation that updates specific users that belong to a > group and creates the attributes in the user entries. If we do it this way > we would be able to say: > > Password policy is XYZ. > Apply this password policy to users in this group (including or not > including sub groups) for those users that do not have the policy set or for > all users in the given group. > There might be other conditions for the query. > > In such case it is easy to control who gets the policy when the policy is > defined and easy to determine what policy is active for the user (for audit > purposes) since there is no ambiguity. > > >> >> rob >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > -- > Thank you, > Dmitri Pal > > Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > From sgallagh at redhat.com Thu Jun 11 11:55:19 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 11 Jun 2009 07:55:19 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <7870594c0906110036p4c259239x764bf4a54b682032@mail.gmail.com> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> <7870594c0906110036p4c259239x764bf4a54b682032@mail.gmail.com> Message-ID: <4A30F0A7.6040108@redhat.com> On 06/11/2009 03:36 AM, Sergei V. Kovylov wrote: > Hello guys. > I hope it's OK for devel if I share my point of view for this question. Sergei, thank you very much for your input. We always welcome additional points of view. > I think that Dmitri is right. It's usual situation, when user may > exists in several groups and decision of which group's policy must be > applied is hard to define (it must be on end-user side not on > developers one). I'm not sure I necessarily agree with this. On a previous project I worked on, we implemented group-based password policy as the merge of the most-restrictive requirements of all of the groups the user was a member of. In other words, if user U is in groups A and B, with the following policies: Group A: Length: 6 or more characters, maximum 32 Complexity: Must contain one number, one capital letter and one lower-case letter Group B: Length: Between 8 and 40 characters Complexity: Must contain one number and one special character The merge of these two groups for User A would be: Length: Between 8 and 32 characters Complexity: Must contain one number, one special character, one capital letter and one lower-case letter The problem with this approach is that it's possible to add someone to a set of groups that have incompatible settings. For example, if you have a maximum password of 8 characters and you require 3 numbers, 3 lower-case and 3 upper-case characters, then there is no way to satisfy the condition. I think we solved this in that previous project by making the maximum password length unnecessarily large and assuming that the customer wouldn't be foolish enough to set that many rules. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Thu Jun 11 12:52:19 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 11 Jun 2009 08:52:19 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Add missing configure check for getpgrp Message-ID: <4A30FE03.8010109@redhat.com> -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Add-missing-configure-check-for-getpgrp.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Thu Jun 11 12:53:18 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 11 Jun 2009 08:53:18 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Remove extra implementation of password_destructor Message-ID: <4A30FE3E.8030909@redhat.com> Was overlooked in an earlier patch, but it breaks the build. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-Remove-extra-implementation-of-password_destructor.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From chris.stromblad at hush.com Thu Jun 11 05:04:27 2009 From: chris.stromblad at hush.com (Christoffer =?ISO-8859-1?Q?Str=F6mblad?=) Date: Thu, 11 Jun 2009 07:04:27 +0200 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <4A3027DD.5060107@redhat.com> References: <4A3027DD.5060107@redhat.com> Message-ID: Could it perhaps be an idea to do some sort of aggregate policy? Say that there are a couple of groups, including subgroups and they all have different password policies. Perhaps when a new group is added, modified or deleted an "aggregate" password policy is created and stored in the "top" branch (forgive me, I'm not that familiar with LDAP). So the default will become some sort of common denominator using the highest requirements to set the policy. One group might have 30 day expiration and 7 min length. Another minimum 10 length and 60 day expiration. The final "aggregate policy" would become: Expiration: 30 days Min length: 10. My reasoning around this type of policy would be that a user, member of several groups have more access rights and should hence be treated as such. Hence a stronger password should be required from this particular user. Problems with aggregate policy I guess however that maintaining such a thing would require that the code would need to change each time a new attribute is added to the password policy. Which might need to happen anyways. It might be dumb, but I thought I'd share the idea nonetheless. Regards, Chris On Wed, 2009-06-10 at 17:38 -0400, Rob Crittenden wrote: > One feature we want to add to v2 is per-group password policy. The IPA > password policy is implemented completely separately from the DS > password policy (because it is the KDC that does the enforcement, AFAICT). > > Currently it finds the password policy by searching the base for > objectClass=krbPwdPolicy. > > What I propose is to leave that, it will become the "global" password > policy, and add an search before that to look for the pwdpolicysubentry > attribute in the user. > > This attribute is used for the DS password policy to tell it where in > the tree the password policy for this entry exists. I'm not quite sure I > want to re-use this attribute like this but it's a starting point anyway. > > The way I want to do per-group password policy is to create a Class of > Service for it. > > Tread carefully when reading this, it is known to cause serious headaches. > > First, we set up a place to hold the policies: > > dn: cn=nsPwPolicyContainer,$SUFFIX > objectClass: top > objectClass: nsContainer > cn: nsPwPolicyContainer > > And here is a sample policy: > > dn: > cn="cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX > objectClass: top > objectClass: nsContainer > objectClass: krbPwdPolicy > cn: cn=group1,cn=groups,cn=accounts,$SUFFIX > krbMinPwdLife: 3600 > krbPwdMinDiffChars: 0 > krbPwdMinLength: 8 > krbPwdHistoryLength: 0 > krbMaxPwdLife: 7776000 > > We start with a classic CoS entry that utilizes the existing CoS > template infrastructure (for account locking): > > dn: cn=Password Policy,cn=accounts,$SUFFIX > description: Password Policy based on group membership > objectClass: top > objectClass: ldapsubentry > objectClass: cosSuperDefinition > objectClass: cosClassicDefinition > cosTemplateDn: cn=cosTemplates,cn=accounts,$SUFFIX > cosAttribute: pwdpolicysubentry operational > cosSpecifier: memberOf > cn: Password Policy > > To make a policy for a specific group we just need to add a template for > it. Here is what it would look like for group1: > > dn: cn="cn=group1,cn=groups,cn=accounts,$SUFFIX", > cn=cosTemplates,cn=accounts,$SUFFIX > objectClass: top > objectClass: cosTemplate > objectClass: extensibleobject > pwdpolicysubentry: > cn="cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX > cosPriority: 1 > > So you add all this, and add a user to group1 and query for > pwdpolicysubentry you get > "cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX > > The ipa_pwd_extop plugin would search for this attribute and if it found > one, would pull the policy from the attribute value, otherwise it would > fall back to the global policy. > > Now we don't want to deal with overlapping policies but I'm not sure we > can do a whole lot about it, particularly when a group is made a member > of another group. It would be painful to recursively look at every > single user to see if they already have a policy. > > The best we can do, I think, is to check when a user is added to a group > whether they already have a policy and if so, quit. > > Or we can try to control which policy to use based on cosPriority. I'm > not sure how we would expose this to the user interface but I think that > the higher number winning is a pretty understandable concept. The > problem would be having a way to know what the current highest value is. > > I'm not entirely sure yet how this would be managed. I suspect we could > get away with a standard CRUD API to manage creating the policies and > associating them with a group. We'd just need some special way to > specify group or global. > > So am I on the right track here? > > rob > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 489 bytes Desc: This is a digitally signed message part URL: From rcritten at redhat.com Thu Jun 11 13:02:52 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Jun 2009 09:02:52 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <4A307ABE.3090409@redhat.com> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> Message-ID: <4A31007C.6060109@redhat.com> Dmitri Pal wrote: > Rob Crittenden wrote: >> So am I on the right track here? > > I am not sure. > I was envisioning it quite differently. > The ambiguity in this case critical and might be not acceptable since it > would be hard to determine which policy should be used in case user is a > member of different groups. Ok, the requirement that caused me to look at was: * Allow setting different password policies per different (non-overlapping) groups of users. > Management of priorities is also a pain and creates complex UI and CLI. > I was more thinking about having a specific policy per user. AFAIR the > software can check the user related password policy attributes right now > without any changes to the code. There attributes just not there. So we > need to give admin the ability to set them. I was thinking that defining > password policies is a bulk operation that updates specific users that > belong to a group and creates the attributes in the user entries. If we > do it this way we would be able to say: > > Password policy is XYZ. > Apply this password policy to users in this group (including or not > including sub groups) for those users that do not have the policy set or > for all users in the given group. > There might be other conditions for the query. This would be slow if a lot of users are affected. > In such case it is easy to control who gets the policy when the policy > is defined and easy to determine what policy is active for the user (for > audit purposes) since there is no ambiguity. There is no ambiguity in my method either though audit does bring up some interesting points because we don't track changes so knowing what the policy was at any given point in time is impossible. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jhrozek at redhat.com Thu Jun 11 13:09:17 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 11 Jun 2009 15:09:17 +0200 Subject: [Freeipa-devel] [PATCH][SSSD] Add missing configure check for getpgrp In-Reply-To: <4A30FE03.8010109@redhat.com> References: <4A30FE03.8010109@redhat.com> Message-ID: <4A3101FD.4050509@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Gallagher wrote: > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel With the patch applied, config.h now contains "#define HAVE_GETPGRP 1" - -> Ack -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkoxAf0ACgkQHsardTLnvCUxewCgtOyQL0Tp2J3V3oQjEFSJTkHG O3MAoLSe2LATC0c0h+ARKA4AiwoIL2Rh =5sPL -----END PGP SIGNATURE----- From rcritten at redhat.com Thu Jun 11 13:10:49 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Jun 2009 09:10:49 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <7870594c0906110036p4c259239x764bf4a54b682032@mail.gmail.com> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> <7870594c0906110036p4c259239x764bf4a54b682032@mail.gmail.com> Message-ID: <4A310259.7020201@redhat.com> Sergei V. Kovylov wrote: > Hello guys. > I hope it's OK for devel if I share my point of view for this question. Yeah, thanks for the feedback! > I think that Dmitri is right. It's usual situation, when user may > exists in several groups and decision of which group's policy must be > applied is hard to define (it must be on end-user side not on > developers one). Well, I agree that cosPriority is a bit of a clumsy way to do this but I do think that it is understandable to end-users, the higher number wins. The hard part would being able to see all the policy groups and their priorities. > Moreover, password policy is just a top of iceberg, > because there are lots of aspects which freeipa may cover, for example > template for user creation (pre-defined home directories, access > policy etc.). In this case usage of DS roles and CoS may provide > flexible mechanism of manage. In part of password policy usage of > filtered roles will do the same as per-group policy but without fixing > them to special group and exclude some mechanism of group classes ( i > mean password policy group, some other option group). In such case > freeipa will provide policy mechanism which may be used not only for > group but for some sub-entry, for some attribute in user account etc. > With CoS we are able to define MAY or MUST one policy in nested group > be replaced by parent one or not. > We have a flat DIT so subentry policies won't work for us (except as a default). I hadn't considered using DS roles, I'll take a look at that. I hadn't really thought a lot about what these groups would look like but in v2 we will support posix and non-posix groups. The password policies would be applicable to either, so if you wanted some sort of logical groupings you could use special non-posix groups. I guess the question is really how many different password policies would one organization have? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Jun 11 13:13:38 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Jun 2009 09:13:38 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <4A30F0A7.6040108@redhat.com> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> <7870594c0906110036p4c259239x764bf4a54b682032@mail.gmail.com> <4A30F0A7.6040108@redhat.com> Message-ID: <4A310302.7050809@redhat.com> Stephen Gallagher wrote: > On 06/11/2009 03:36 AM, Sergei V. Kovylov wrote: >> Hello guys. >> I hope it's OK for devel if I share my point of view for this question. > > Sergei, thank you very much for your input. We always welcome additional > points of view. > >> I think that Dmitri is right. It's usual situation, when user may >> exists in several groups and decision of which group's policy must be >> applied is hard to define (it must be on end-user side not on >> developers one). > > I'm not sure I necessarily agree with this. On a previous project I > worked on, we implemented group-based password policy as the merge of > the most-restrictive requirements of all of the groups the user was a > member of. > > In other words, if user U is in groups A and B, with the following policies: > > Group A: > Length: 6 or more characters, maximum 32 > Complexity: Must contain one number, one capital letter and one > lower-case letter > > Group B: > Length: Between 8 and 40 characters > Complexity: Must contain one number and one special character > > The merge of these two groups for User A would be: > Length: Between 8 and 32 characters > Complexity: Must contain one number, one special character, one capital > letter and one lower-case letter > > > The problem with this approach is that it's possible to add someone to a > set of groups that have incompatible settings. For example, if you have > a maximum password of 8 characters and you require 3 numbers, 3 > lower-case and 3 upper-case characters, then there is no way to satisfy > the condition. I think we solved this in that previous project by making > the maximum password length unnecessarily large and assuming that the > customer wouldn't be foolish enough to set that many rules. > > We don't have a mechanism to do this sort of password policy merge and we couldn't do it with CoS at all (it returns only the "winner"). Not that we have to do it with CoS :-) What would trip us up in this case are min and max life for the same reasons you point out for length. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From sbose at redhat.com Thu Jun 11 13:14:05 2009 From: sbose at redhat.com (Sumit Bose) Date: Thu, 11 Jun 2009 15:14:05 +0200 Subject: [Freeipa-devel] [PATCH][SSSD] Add missing configure check for getpgrp In-Reply-To: <4A30FE03.8010109@redhat.com> References: <4A30FE03.8010109@redhat.com> Message-ID: <4A31031D.4050303@redhat.com> Am 11.06.2009 14:52, schrieb Stephen Gallagher: > > ------------------------------------------------------------------------ > ACK bye, Sumit From ssorce at redhat.com Thu Jun 11 13:19:32 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 11 Jun 2009 09:19:32 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Remove extra implementation of password_destructor In-Reply-To: <4A30FE3E.8030909@redhat.com> References: <4A30FE3E.8030909@redhat.com> Message-ID: <1244726372.25513.29.camel@localhost.localdomain> On Thu, 2009-06-11 at 08:53 -0400, Stephen Gallagher wrote: > Was overlooked in an earlier patch, but it breaks the build. Oh, my fault, I have that part in a patch I am still finishing that touches ldap_auth.c :-( Full ack. Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Thu Jun 11 13:24:04 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 11 Jun 2009 09:24:04 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Add missing configure check for getpgrp In-Reply-To: <4A31031D.4050303@redhat.com> References: <4A30FE03.8010109@redhat.com> <4A31031D.4050303@redhat.com> Message-ID: <4A310574.2000305@redhat.com> On 06/11/2009 09:14 AM, Sumit Bose wrote: > Am 11.06.2009 14:52, schrieb Stephen Gallagher: >> ------------------------------------------------------------------------ >> > > ACK > > bye, > Sumit > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Pushed to master. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Thu Jun 11 13:24:19 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 11 Jun 2009 09:24:19 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Remove extra implementation of password_destructor In-Reply-To: <1244726372.25513.29.camel@localhost.localdomain> References: <4A30FE3E.8030909@redhat.com> <1244726372.25513.29.camel@localhost.localdomain> Message-ID: <4A310583.90805@redhat.com> On 06/11/2009 09:19 AM, Simo Sorce wrote: > On Thu, 2009-06-11 at 08:53 -0400, Stephen Gallagher wrote: >> Was overlooked in an earlier patch, but it breaks the build. > > Oh, my fault, I have that part in a patch I am still finishing that > touches ldap_auth.c :-( > > Full ack. > > Simo. > Pushed to master. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Jun 11 13:40:40 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 11 Jun 2009 09:40:40 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <4A310302.7050809@redhat.com> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> <7870594c0906110036p4c259239x764bf4a54b682032@mail.gmail.com> <4A30F0A7.6040108@redhat.com> <4A310302.7050809@redhat.com> Message-ID: <1244727640.25513.37.camel@localhost.localdomain> On Thu, 2009-06-11 at 09:13 -0400, Rob Crittenden wrote: > Stephen Gallagher wrote: > > On 06/11/2009 03:36 AM, Sergei V. Kovylov wrote: > >> Hello guys. > >> I hope it's OK for devel if I share my point of view for this question. > > > > Sergei, thank you very much for your input. We always welcome additional > > points of view. > > > >> I think that Dmitri is right. It's usual situation, when user may > >> exists in several groups and decision of which group's policy must be > >> applied is hard to define (it must be on end-user side not on > >> developers one). > > > > I'm not sure I necessarily agree with this. On a previous project I > > worked on, we implemented group-based password policy as the merge of > > the most-restrictive requirements of all of the groups the user was a > > member of. > > > > In other words, if user U is in groups A and B, with the following policies: > > > > Group A: > > Length: 6 or more characters, maximum 32 > > Complexity: Must contain one number, one capital letter and one > > lower-case letter > > > > Group B: > > Length: Between 8 and 40 characters > > Complexity: Must contain one number and one special character > > > > The merge of these two groups for User A would be: > > Length: Between 8 and 32 characters > > Complexity: Must contain one number, one special character, one capital > > letter and one lower-case letter > > > > > > The problem with this approach is that it's possible to add someone to a > > set of groups that have incompatible settings. For example, if you have > > a maximum password of 8 characters and you require 3 numbers, 3 > > lower-case and 3 upper-case characters, then there is no way to satisfy > > the condition. I think we solved this in that previous project by making > > the maximum password length unnecessarily large and assuming that the > > customer wouldn't be foolish enough to set that many rules. > > > > > > We don't have a mechanism to do this sort of password policy merge and > we couldn't do it with CoS at all (it returns only the "winner"). Not > that we have to do it with CoS :-) > > What would trip us up in this case are min and max life for the same > reasons you point out for length. I think CoS with CoS priority is the most understandable one. It's unlikely a company will have badly mixed policies, usually you have a weak and a strong policy applied to different and very separate groups of people. In some company you may have different levels of security required, but it is very unlikely you have policies of the same "strength" that employs different constraints, and it is also unlikely that the same person is in 2 different groups for pw policy purposes. In my experience security policies are classified by strength, so using a Cos Priority seem to be easy both to understand and to apply to real cases. So I'd go with Cos and Cos priority. If some admins feels that cos priority is not appropriate it will be easy to create pw-policy specific non-posix groups and apply them to non-overlapping set of users. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Jun 11 13:52:15 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 11 Jun 2009 09:52:15 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <4A3027DD.5060107@redhat.com> References: <4A3027DD.5060107@redhat.com> Message-ID: <1244728335.25513.49.camel@localhost.localdomain> On Wed, 2009-06-10 at 17:38 -0400, Rob Crittenden wrote: > One feature we want to add to v2 is per-group password policy. The IPA > password policy is implemented completely separately from the DS > password policy (because it is the KDC that does the enforcement, AFAICT). > > Currently it finds the password policy by searching the base for > objectClass=krbPwdPolicy. > > What I propose is to leave that, it will become the "global" password > policy, and add an search before that to look for the pwdpolicysubentry > attribute in the user. The only parts that enforce password policy in freeipa re really kadmin.local and our password plugin. Initially we decide to go for the MIT schema because we were unsure about letting kadmin run (it would obey only the MIT krb schema). But since we decided not to allow kadmin, and since kadmin.local is used only to manage keytabs in the bootstrap process and in emergency cases, I think we can easily drop that schema and fully embrace the DS one. It will require some work in the password plugin but nothing mind blowing. > This attribute is used for the DS password policy to tell it where in > the tree the password policy for this entry exists. I'm not quite sure I > want to re-use this attribute like this but it's a starting point anyway. > > The way I want to do per-group password policy is to create a Class of > Service for it. > > Tread carefully when reading this, it is known to cause serious headaches. No kidding :-) > First, we set up a place to hold the policies: > > dn: cn=nsPwPolicyContainer,$SUFFIX > objectClass: top > objectClass: nsContainer > cn: nsPwPolicyContainer I would put this under cn=etc or cn=accounts probably. > And here is a sample policy: > > dn: > cn="cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX > objectClass: top > objectClass: nsContainer > objectClass: krbPwdPolicy > cn: cn=group1,cn=groups,cn=accounts,$SUFFIX > krbMinPwdLife: 3600 > krbPwdMinDiffChars: 0 > krbPwdMinLength: 8 > krbPwdHistoryLength: 0 > krbMaxPwdLife: 7776000 As said above we can easily use the native DS policies which are richer. One question though, wht the name of the policy includes the whole group DN ? Is that what links the policy to the group ? Or is this just some CoS convention? Can that be changed and simplified ? Maybe reference the group nsUniqueId instead ? > We start with a classic CoS entry that utilizes the existing CoS > template infrastructure (for account locking): > > dn: cn=Password Policy,cn=accounts,$SUFFIX > description: Password Policy based on group membership > objectClass: top > objectClass: ldapsubentry > objectClass: cosSuperDefinition > objectClass: cosClassicDefinition > cosTemplateDn: cn=cosTemplates,cn=accounts,$SUFFIX > cosAttribute: pwdpolicysubentry operational > cosSpecifier: memberOf > cn: Password Policy > > To make a policy for a specific group we just need to add a template for > it. Here is what it would look like for group1: > > dn: cn="cn=group1,cn=groups,cn=accounts,$SUFFIX", > cn=cosTemplates,cn=accounts,$SUFFIX > objectClass: top > objectClass: cosTemplate > objectClass: extensibleobject > pwdpolicysubentry: > cn="cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX > cosPriority: 1 > > So you add all this, and add a user to group1 and query for > pwdpolicysubentry you get > "cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX > > The ipa_pwd_extop plugin would search for this attribute and if it found > one, would pull the policy from the attribute value, otherwise it would > fall back to the global policy. > > Now we don't want to deal with overlapping policies but I'm not sure we > can do a whole lot about it, particularly when a group is made a member > of another group. It would be painful to recursively look at every > single user to see if they already have a policy. > > The best we can do, I think, is to check when a user is added to a group > whether they already have a policy and if so, quit. No, we should just use cos priority, it's perfectly understandable. Also I guess an admin can query a user to see what applies to him like the password plugin would right ? > Or we can try to control which policy to use based on cosPriority. I'm > not sure how we would expose this to the user interface but I think that > the higher number winning is a pretty understandable concept. The > problem would be having a way to know what the current highest value is. > > I'm not entirely sure yet how this would be managed. I suspect we could > get away with a standard CRUD API to manage creating the policies and > associating them with a group. We'd just need some special way to > specify group or global. I guess we can define a global group that embodies the default policy ? "DefaultPwPolicyGroup" ? > So am I on the right track here? I like it. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Jun 11 14:05:40 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 11 Jun 2009 10:05:40 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: References: <4A3027DD.5060107@redhat.com> Message-ID: <1244729140.25513.50.camel@localhost.localdomain> On Thu, 2009-06-11 at 07:04 +0200, Christoffer Str?mblad wrote: > Could it perhaps be an idea to do some sort of aggregate policy? Say > that there are a couple of groups, including subgroups and they all have > different password policies. Perhaps when a new group is added, modified > or deleted an "aggregate" password policy is created and stored in the > "top" branch (forgive me, I'm not that familiar with LDAP). > > So the default will become some sort of common denominator using the > highest requirements to set the policy. > > One group might have 30 day expiration and 7 min length. Another minimum > 10 length and 60 day expiration. > > The final "aggregate policy" would become: > Expiration: 30 days > Min length: 10. > > My reasoning around this type of policy would be that a user, member of > several groups have more access rights and should hence be treated as > such. Hence a stronger password should be required from this particular > user. > > Problems with aggregate policy > I guess however that maintaining such a thing would require that the > code would need to change each time a new attribute is added to the > password policy. Which might need to happen anyways. > > It might be dumb, but I thought I'd share the idea nonetheless. It's not a dumb idea, but I think it presents more problems than it solves. Problem 1: incompatible settings in the aggregate Problem 2: understanding what pwd policy apply to a specific user N.2 depends on whether the aggregate policy is generated on the fly or stored at creation time. A priority based policy like Rob defined is probably easier to understand and use. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Jun 11 15:02:19 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Jun 2009 11:02:19 -0400 Subject: [Freeipa-devel] bash completion Message-ID: <4A311C7B.2080105@redhat.com> I'm not ready to check this in yet but here is something I've been tinkering with, a bash completion script for the ipa command. You need bash 2.05a or higher with programmable completion and extended pattern matching enabled (it is on Fedora anyway). All you need to do is source this file and then you can use tab completion on the IPA commands. This is currently limited to just the command names, not the options. I created the list of commands use the ipa help system, I'm attaching that screwy little script too. Usage looks like: ipa u[TAB] -> ipa user[TAB] -> user2-create user2-lock user2-unlock user-find user-show user2-delete user2-mod user-add user-lock user-unlock user2-find user2-show user-del user-mod rob -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa.sh Type: application/x-sh Size: 3243 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: make_completion URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mgregg at redhat.com Thu Jun 11 18:40:15 2009 From: mgregg at redhat.com (Michael Gregg) Date: Thu, 11 Jun 2009 11:40:15 -0700 Subject: [Freeipa-devel] bash completion In-Reply-To: <4A311C7B.2080105@redhat.com> References: <4A311C7B.2080105@redhat.com> Message-ID: <4A314F8F.20601@redhat.com> Rob Crittenden wrote: > I'm not ready to check this in yet but here is something I've been > tinkering with, a bash completion script for the ipa command. You need > bash 2.05a or higher with programmable completion and extended pattern > matching enabled (it is on Fedora anyway). > > All you need to do is source this file and then you can use tab > completion on the IPA commands. > > This is currently limited to just the command names, not the options. > > I created the list of commands use the ipa help system, I'm attaching > that screwy little script too. > > Usage looks like: > > ipa u[TAB] -> ipa user[TAB] -> > user2-create user2-lock user2-unlock user-find user-show > user2-delete user2-mod user-add user-lock user-unlock > user2-find user2-show user-del user-mod > > rob Thanks for the script Rob. I've been hoping that ipa would get this functionality. Michael- From rcritten at redhat.com Thu Jun 11 19:21:40 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Jun 2009 15:21:40 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <1244728335.25513.49.camel@localhost.localdomain> References: <4A3027DD.5060107@redhat.com> <1244728335.25513.49.camel@localhost.localdomain> Message-ID: <4A315944.7000600@redhat.com> Simo Sorce wrote: > On Wed, 2009-06-10 at 17:38 -0400, Rob Crittenden wrote: >> One feature we want to add to v2 is per-group password policy. The IPA >> password policy is implemented completely separately from the DS >> password policy (because it is the KDC that does the enforcement, AFAICT). >> >> Currently it finds the password policy by searching the base for >> objectClass=krbPwdPolicy. >> >> What I propose is to leave that, it will become the "global" password >> policy, and add an search before that to look for the pwdpolicysubentry >> attribute in the user. > > The only parts that enforce password policy in freeipa re really > kadmin.local and our password plugin. Initially we decide to go for the > MIT schema because we were unsure about letting kadmin run (it would > obey only the MIT krb schema). > But since we decided not to allow kadmin, and since kadmin.local is used > only to manage keytabs in the bootstrap process and in emergency cases, > I think we can easily drop that schema and fully embrace the DS one. > > It will require some work in the password plugin but nothing mind > blowing. If you say so :-) I don't think this will have any impact on my design, it is just a way to point to discrete policies. > >> This attribute is used for the DS password policy to tell it where in >> the tree the password policy for this entry exists. I'm not quite sure I >> want to re-use this attribute like this but it's a starting point anyway. >> >> The way I want to do per-group password policy is to create a Class of >> Service for it. >> >> Tread carefully when reading this, it is known to cause serious headaches. > > No kidding :-) > >> First, we set up a place to hold the policies: >> >> dn: cn=nsPwPolicyContainer,$SUFFIX >> objectClass: top >> objectClass: nsContainer >> cn: nsPwPolicyContainer > > I would put this under cn=etc or cn=accounts probably. Yeah, I guess cn=etc would make sense. > >> And here is a sample policy: >> >> dn: >> cn="cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX >> objectClass: top >> objectClass: nsContainer >> objectClass: krbPwdPolicy >> cn: cn=group1,cn=groups,cn=accounts,$SUFFIX >> krbMinPwdLife: 3600 >> krbPwdMinDiffChars: 0 >> krbPwdMinLength: 8 >> krbPwdHistoryLength: 0 >> krbMaxPwdLife: 7776000 > > As said above we can easily use the native DS policies which are richer. > > One question though, wht the name of the policy includes the whole group > DN ? Is that what links the policy to the group ? > Or is this just some CoS convention? > Can that be changed and simplified ? > Maybe reference the group nsUniqueId instead ? We use memberOf in the user entry to determine which CoS definition to use so it will be the DN of the group. > >> We start with a classic CoS entry that utilizes the existing CoS >> template infrastructure (for account locking): >> >> dn: cn=Password Policy,cn=accounts,$SUFFIX >> description: Password Policy based on group membership >> objectClass: top >> objectClass: ldapsubentry >> objectClass: cosSuperDefinition >> objectClass: cosClassicDefinition >> cosTemplateDn: cn=cosTemplates,cn=accounts,$SUFFIX >> cosAttribute: pwdpolicysubentry operational >> cosSpecifier: memberOf >> cn: Password Policy >> >> To make a policy for a specific group we just need to add a template for >> it. Here is what it would look like for group1: >> >> dn: cn="cn=group1,cn=groups,cn=accounts,$SUFFIX", >> cn=cosTemplates,cn=accounts,$SUFFIX >> objectClass: top >> objectClass: cosTemplate >> objectClass: extensibleobject >> pwdpolicysubentry: >> cn="cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX >> cosPriority: 1 >> >> So you add all this, and add a user to group1 and query for >> pwdpolicysubentry you get >> "cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX >> >> The ipa_pwd_extop plugin would search for this attribute and if it found >> one, would pull the policy from the attribute value, otherwise it would >> fall back to the global policy. >> >> Now we don't want to deal with overlapping policies but I'm not sure we >> can do a whole lot about it, particularly when a group is made a member >> of another group. It would be painful to recursively look at every >> single user to see if they already have a policy. >> >> The best we can do, I think, is to check when a user is added to a group >> whether they already have a policy and if so, quit. > > No, we should just use cos priority, it's perfectly understandable. > Also I guess an admin can query a user to see what applies to him like > the password plugin would right ? Yeah, I've been pondering the same thing, sort of a policy tool so an admin can see what policy would be applied for any given user (and truly trivial in 389 because we just query the pwdpolicysubentry attribute and display the contents of that entry). > >> Or we can try to control which policy to use based on cosPriority. I'm >> not sure how we would expose this to the user interface but I think that >> the higher number winning is a pretty understandable concept. The >> problem would be having a way to know what the current highest value is. >> >> I'm not entirely sure yet how this would be managed. I suspect we could >> get away with a standard CRUD API to manage creating the policies and >> associating them with a group. We'd just need some special way to >> specify group or global. > > I guess we can define a global group that embodies the default policy ? > "DefaultPwPolicyGroup" ? I guess we could apply the default policy to the ipausers group since all users are a member of that. We'd give it a 0 cosPriority so it would be the lowest. I was planning on just having the plugin fall back to use the root policy so that if the attribute wasn't there then it would just fall thru. > >> So am I on the right track here? > > I like it. > > Simo. > whew. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Thu Jun 11 21:22:34 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 11 Jun 2009 17:22:34 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <4A31007C.6060109@redhat.com> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> <4A31007C.6060109@redhat.com> Message-ID: <4A31759A.40500@redhat.com> Rob Crittenden wrote: > Dmitri Pal wrote: >> Rob Crittenden wrote: >>> So am I on the right track here? >> >> I am not sure. >> I was envisioning it quite differently. >> The ambiguity in this case critical and might be not acceptable since >> it would be hard to determine which policy should be used in case >> user is a member of different groups. > > Ok, the requirement that caused me to look at was: > > * Allow setting different password policies per different > (non-overlapping) groups of users. > I think the requirement was worded by me under the assumption of doing it the way I proposed. >> Management of priorities is also a pain and creates complex UI and CLI. >> I was more thinking about having a specific policy per user. AFAIR >> the software can check the user related password policy attributes >> right now without any changes to the code. There attributes just not >> there. So we need to give admin the ability to set them. I was >> thinking that defining password policies is a bulk operation that >> updates specific users that belong to a group and creates the >> attributes in the user entries. If we do it this way we would be able >> to say: >> >> Password policy is XYZ. >> Apply this password policy to users in this group (including or not >> including sub groups) for those users that do not have the policy set >> or for all users in the given group. >> There might be other conditions for the query. > > This would be slow if a lot of users are affected. Yes. But is is not a frequent operation so the admin should be aware. I think it is acceptable. > >> In such case it is easy to control who gets the policy when the >> policy is defined and easy to determine what policy is active for the >> user (for audit purposes) since there is no ambiguity. > > There is no ambiguity in my method either though audit does bring up > some interesting points because we don't track changes so knowing what > the policy was at any given point in time is impossible. > This is exactly my point. Knowing the policy that worked and having a clear change log is very important. One of my previous employers had the same problem with groups and policy ambiguity the customers could not pass audit because of that. > rob > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Thu Jun 11 21:34:32 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 11 Jun 2009 17:34:32 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <1244727640.25513.37.camel@localhost.localdomain> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> <7870594c0906110036p4c259239x764bf4a54b682032@mail.gmail.com> <4A30F0A7.6040108@redhat.com> <4A310302.7050809@redhat.com> <1244727640.25513.37.camel@localhost.localdomain> Message-ID: <4A317868.3000608@redhat.com> Simo Sorce wrote: > On Thu, 2009-06-11 at 09:13 -0400, Rob Crittenden wrote: > >> Stephen Gallagher wrote: >> >>> On 06/11/2009 03:36 AM, Sergei V. Kovylov wrote: >>> >>>> Hello guys. >>>> I hope it's OK for devel if I share my point of view for this question. >>>> >>> Sergei, thank you very much for your input. We always welcome additional >>> points of view. >>> >>> >>>> I think that Dmitri is right. It's usual situation, when user may >>>> exists in several groups and decision of which group's policy must be >>>> applied is hard to define (it must be on end-user side not on >>>> developers one). >>>> >>> I'm not sure I necessarily agree with this. On a previous project I >>> worked on, we implemented group-based password policy as the merge of >>> the most-restrictive requirements of all of the groups the user was a >>> member of. >>> >>> In other words, if user U is in groups A and B, with the following policies: >>> >>> Group A: >>> Length: 6 or more characters, maximum 32 >>> Complexity: Must contain one number, one capital letter and one >>> lower-case letter >>> >>> Group B: >>> Length: Between 8 and 40 characters >>> Complexity: Must contain one number and one special character >>> >>> The merge of these two groups for User A would be: >>> Length: Between 8 and 32 characters >>> Complexity: Must contain one number, one special character, one capital >>> letter and one lower-case letter >>> >>> >>> The problem with this approach is that it's possible to add someone to a >>> set of groups that have incompatible settings. For example, if you have >>> a maximum password of 8 characters and you require 3 numbers, 3 >>> lower-case and 3 upper-case characters, then there is no way to satisfy >>> the condition. I think we solved this in that previous project by making >>> the maximum password length unnecessarily large and assuming that the >>> customer wouldn't be foolish enough to set that many rules. >>> >>> >>> >> We don't have a mechanism to do this sort of password policy merge and >> we couldn't do it with CoS at all (it returns only the "winner"). Not >> that we have to do it with CoS :-) >> >> What would trip us up in this case are min and max life for the same >> reasons you point out for length. >> > > I think CoS with CoS priority is the most understandable one. > > It's unlikely a company will have badly mixed policies, usually you have > a weak and a strong policy applied to different and very separate groups > of people. In some company you may have different levels of security > required, but it is very unlikely you have policies of the same > "strength" that employs different constraints, and it is also unlikely > that the same person is in 2 different groups for pw policy purposes. > > In my experience security policies are classified by strength, so using > a Cos Priority seem to be easy both to understand and to apply to real > cases. > > So I'd go with Cos and Cos priority. > If some admins feels that cos priority is not appropriate it will be > easy to create pw-policy specific non-posix groups and apply them to > non-overlapping set of users. > > Simo. > > Sorry Simo I disagree. I think it is too complex, hard to mange and not deterministic enough. Add to it that it can have problems with access control. In bulk update proposal you have to explicitly update user records to apply the policies. So admin has to have the rights to do so. He will be able to only modify policies for the users that he can access. With Rob's proposal one can mess with the group nesting and not realize that he weakened the policies for the highly sensitive accounts. I think we can add this kind of functionality later on top of the direct updates if the users complain. I doubt they will. Keep in mind that the PRD item was written having bulk update in mind. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Thu Jun 11 21:56:42 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 11 Jun 2009 17:56:42 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <4A317868.3000608@redhat.com> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> <7870594c0906110036p4c259239x764bf4a54b682032@mail.gmail.com> <4A30F0A7.6040108@redhat.com> <4A310302.7050809@redhat.com> <1244727640.25513.37.camel@localhost.localdomain> <4A317868.3000608@redhat.com> Message-ID: <1244757402.21116.29.camel@localhost.localdomain> On Thu, 2009-06-11 at 17:34 -0400, Dmitri Pal wrote: > Sorry Simo I disagree. I think it is too complex, hard to mange and > not deterministic enough. Can you explain where you see a problem, it seem pretty simple to me. > Add to it that it can have problems with access control. In bulk > update proposal you have to explicitly update user records to apply > the policies. You need to be able to be able to write to groups to change users memberships, so I don't see where there is an access control problem. > So admin has to have the rights to do so. He will be able to only > modify policies for the users that he can access. I think that password policies should be managed primarily through groups that are used only to convey password policies. These groups should be manageable only by admins that have enough privileges to change password policies. I don't see an access control problem here. > With Rob's proposal one can mess with the group nesting and not > realize that he weakened the policies for the highly sensitive > accounts. You can't weaken policies, because weaker policies have a lower Cos Priority, so they will never "win" when multiple policies are available for the same user. Always the highest (== most restrictive wins). > I think we can add this kind of functionality later on top of the > direct updates if the users complain. Direct updates are cumbersome prone to fail and cause a lot of unnecessary traffic (therefore also slow). I really don't see any advantage. > I doubt they will. Keep in mind that the PRD item was written having > bulk update in mind. Yes, but I see no risk here. If you mess up managing groups or determining password policies or their priorities you can also mess up bulk updates. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Thu Jun 11 22:30:33 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 11 Jun 2009 18:30:33 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <1244757402.21116.29.camel@localhost.localdomain> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> <7870594c0906110036p4c259239x764bf4a54b682032@mail.gmail.com> <4A30F0A7.6040108@redhat.com> <4A310302.7050809@redhat.com> <1244727640.25513.37.camel@localhost.localdomain> <4A317868.3000608@redhat.com> <1244757402.21116.29.camel@localhost.localdomain> Message-ID: <4A318589.1050700@redhat.com> Simo Sorce wrote: > On Thu, 2009-06-11 at 17:34 -0400, Dmitri Pal wrote: > >> Sorry Simo I disagree. I think it is too complex, hard to mange and >> not deterministic enough. >> > > Can you explain where you see a problem, it seem pretty simple to me. > I see a problem in determining what policy was used when something happened in the past. Also the CoS is a complex notion and would be hard for admins to understand how to manage. What is simple to you does not mean simple for others. And you even acknowledged the complexity yourself. > >> Add to it that it can have problems with access control. In bulk >> update proposal you have to explicitly update user records to apply >> the policies. >> > > You need to be able to be able to write to groups to change users > memberships, so I don't see where there is an access control problem. > You might have a right to create and nest groups and you will mess your environment by not understanding the impact. With update case you can only ever affect users that you can access and you can't do the operation inadvertently. You have to actually go and apply the policy. With groups approach you can create a new nesting and not realize that it affected password policies in the way you did not expected or wanted. Finally to check what policy is active for the user you just quesry the user and see that if he has policy attributes this is the policy that applies, if he does not than the default one is used. Very simple, logical and easy to work with. > >> So admin has to have the rights to do so. He will be able to only >> modify policies for the users that he can access. >> > > I think that password policies should be managed primarily through > groups that are used only to convey password policies. These groups > should be manageable only by admins that have enough privileges to > change password policies. I don't see an access control problem here. > I agree with the statement. But difference is that the groups will be used to define the set of users to which the policies should apply. > >> With Rob's proposal one can mess with the group nesting and not >> realize that he weakened the policies for the highly sensitive >> accounts. >> > > You can't weaken policies, because weaker policies have a lower Cos > Priority, so they will never "win" when multiple policies are available > for the same user. Always the highest (== most restrictive wins). > > Poor auditor... >> I think we can add this kind of functionality later on top of the >> direct updates if the users complain. >> > > Direct updates are cumbersome prone to fail and cause a lot of > unnecessary traffic (therefore also slow). I really don't see any > advantage. > If it is done the plugin it is not remote. It is not a frequent operation so performance issues are not that important. It is a major security thing - it does not happen every day. It should not be dynamic as you propose and the price is even better to discourage admin to flip-flop and take this seriously. If the update failed the CLI or UI should just report it back letting admin to take a corrective action. > >> I doubt they will. Keep in mind that the PRD item was written having >> bulk update in mind. >> > > Yes, but I see no risk here. > If you mess up managing groups or determining password policies or their > priorities you can also mess up bulk updates. > I suggest we ask the freeipa-users about these two alternatives and see what the community will say. May be I am wrong but I have seen problems with the flexible group approach in the past so I do not like it. > Simo. > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Thu Jun 11 23:01:43 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 11 Jun 2009 19:01:43 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <4A318589.1050700@redhat.com> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> <7870594c0906110036p4c259239x764bf4a54b682032@mail.gmail.com> <4A30F0A7.6040108@redhat.com> <4A310302.7050809@redhat.com> <1244727640.25513.37.camel@localhost.localdomain> <4A317868.3000608@redhat.com> <1244757402.21116.29.camel@localhost.localdomain> <4A318589.1050700@redhat.com> Message-ID: <1244761303.21116.59.camel@localhost.localdomain> On Thu, 2009-06-11 at 18:30 -0400, Dmitri Pal wrote: > Simo Sorce wrote: > > On Thu, 2009-06-11 at 17:34 -0400, Dmitri Pal wrote: > > > >> Sorry Simo I disagree. I think it is too complex, hard to mange and > >> not deterministic enough. > >> > > > > Can you explain where you see a problem, it seem pretty simple to me. > > > I see a problem in determining what policy was used when something > happened in the past. Well unless you plan to keep track of all changes in DS you would have the same problem with either mechanism, so I would rule this consideration out as a decisive factor. > Also the CoS is a complex notion and would be hard for admins to > understand how to manage. Yes, but nobody is proposing that admins create the CoS objects by hand, just like we don't make them create taskgroups/rolegroups and delegation rules by hand. I assume Rob has a CLI/UI interface in mind where all you do is: 1. Create new password policy 2. Associate password policy to a group This looks quite simple to me :) > What is simple to you does not mean simple for others. And you even > acknowledged the complexity yourself. Yep the details of CoS can be complex, but we I do not think we plan to require admins to manually set up CoS. > > You need to be able to be able to write to groups to change users > > memberships, so I don't see where there is an access control problem. > > > You might have a right to create and nest groups and you will mess your > environment by not understanding the impact. If you do not understand how to mange groups you should not manage groups. However the worst that can happen with nesting is that some user get a stronger policy. So this is not a "security" problem. > With update case you can only ever affect users that you can access and > you can't do the operation inadvertently. This is true for anything handled through groups, HBAC for example. People that are given authority over managing groups must be trained people, and have enough "clearance" anyway. Remember that group memberships may also control access to files on disk on the ipa clients. If we want to allow junior admins to manage groups then we need to find a way to have some access control wrt what they can add to the 'member' attribute. > You have to actually go and apply the policy. With groups approach you > can create a new nesting and not realize that it affected password > policies in the way you did not expected or wanted. If you use password policy specific groups this is unlikely. If you nest password policy specific groups inadvertently then something is wrong in your training or in the security policies of your company. > Finally to check what policy is active for the user you just quesry the > user and see that if he has policy attributes this is the policy that > applies, if he does not than the default one is used. > Very simple, logical and easy to work with. This is the same with CoS. With a single query you know what policy applies to the user. No difference here. > >> So admin has to have the rights to do so. He will be able to only > >> modify policies for the users that he can access. > >> > > > > I think that password policies should be managed primarily through > > groups that are used only to convey password policies. These groups > > should be manageable only by admins that have enough privileges to > > change password policies. I don't see an access control problem here. > > > I agree with the statement. But difference is that the groups will be > used to define the set of users to which the policies should apply. Yes, this is what we are proposing, not sure if you are objecting to something here ? > >> With Rob's proposal one can mess with the group nesting and not > >> realize that he weakened the policies for the highly sensitive > >> accounts. > >> > > > > You can't weaken policies, because weaker policies have a lower Cos > > Priority, so they will never "win" when multiple policies are available > > for the same user. Always the highest (== most restrictive wins). > > > > > Poor auditor... I really don't understand. You can see, with a single query, what is the policy applied to a specific user. Why should the auditor have any problem ?? > >> I think we can add this kind of functionality later on top of the > >> direct updates if the users complain. > >> > > > > Direct updates are cumbersome prone to fail and cause a lot of > > unnecessary traffic (therefore also slow). I really don't see any > > advantage. > > > If it is done the plugin it is not remote. More code to build, when we already have a working infrastructure we just need to use. > It is not a frequent operation so performance issues are not that important. ok > It is a major security thing - it does not happen every day. Yes, in both cases. > It should not be dynamic as you propose and the price is even better to > discourage admin to flip-flop and take this seriously. I don't agree on this, managing password policies should be a privileged operation anyway, and any privileged operation should be taken seriously. If you don't making it more difficult will not make people take it more seriously, rather it will discourage people from using better policies and will encourage then to keep using default or even lax policies for everybody by changing only the default password policy. > If the update failed the CLI or UI should just report it back letting > admin to take a corrective action. You don't want to deal with failures on security features, this is one of the reasons I prefer CoS to bulk changes. > >> I doubt they will. Keep in mind that the PRD item was written having > >> bulk update in mind. > >> > > > > Yes, but I see no risk here. > > If you mess up managing groups or determining password policies or their > > priorities you can also mess up bulk updates. > > > I suggest we ask the freeipa-users about these two alternatives and see > what the community will say. > May be I am wrong but I have seen problems with the flexible group > approach in the past so I do not like it. Well, people interested in technical details should probably be subscribed to this list :-) But we can probably invite people on freeipa-users to look at this thread (point to the archives) and ask them to comment on this list if they have any strong opinions. Simo. -- Simo Sorce * Red Hat, Inc * New York From davido at redhat.com Fri Jun 12 00:26:22 2009 From: davido at redhat.com (David O'Brien) Date: Fri, 12 Jun 2009 10:26:22 +1000 Subject: [Freeipa-devel] bash completion In-Reply-To: <4A311C7B.2080105@redhat.com> References: <4A311C7B.2080105@redhat.com> Message-ID: <4A31A0AE.3060200@redhat.com> Rob Crittenden wrote: > I'm not ready to check this in yet but here is something I've been > tinkering with, a bash completion script for the ipa command. You need > bash 2.05a or higher with programmable completion and extended pattern > matching enabled (it is on Fedora anyway). > > All you need to do is source this file and then you can use tab > completion on the IPA commands. > > This is currently limited to just the command names, not the options. > > I created the list of commands use the ipa help system, I'm attaching > that screwy little script too. > > Usage looks like: > > ipa u[TAB] -> ipa user[TAB] -> > user2-create user2-lock user2-unlock user-find user-show > user2-delete user2-mod user-add user-lock user-unlock > user2-find user2-show user-del user-mod > > rob > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel How did we end up with all those "2s" in the commands? Version 2, sure, but it only appears in some commands. What can I expect to see by GA? thanks -- David O'Brien IPA Content Author Red Hat Asia Pacific +61 7 3514 8189 "The most valuable of all talents is that of never using two words when one will do." Thomas Jefferson From rcritten at redhat.com Fri Jun 12 12:59:41 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Jun 2009 08:59:41 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <4A31759A.40500@redhat.com> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> <4A31007C.6060109@redhat.com> <4A31759A.40500@redhat.com> Message-ID: <4A32513D.80701@redhat.com> Dmitri Pal wrote: > Rob Crittenden wrote: >> Dmitri Pal wrote: >>> Rob Crittenden wrote: >>>> So am I on the right track here? >>> >>> I am not sure. >>> I was envisioning it quite differently. >>> The ambiguity in this case critical and might be not acceptable since >>> it would be hard to determine which policy should be used in case >>> user is a member of different groups. >> >> Ok, the requirement that caused me to look at was: >> >> * Allow setting different password policies per different >> (non-overlapping) groups of users. >> > > I think the requirement was worded by me under the assumption of doing > it the way I proposed. > >>> Management of priorities is also a pain and creates complex UI and CLI. >>> I was more thinking about having a specific policy per user. AFAIR >>> the software can check the user related password policy attributes >>> right now without any changes to the code. There attributes just not >>> there. So we need to give admin the ability to set them. I was >>> thinking that defining password policies is a bulk operation that >>> updates specific users that belong to a group and creates the >>> attributes in the user entries. If we do it this way we would be able >>> to say: >>> >>> Password policy is XYZ. >>> Apply this password policy to users in this group (including or not >>> including sub groups) for those users that do not have the policy set >>> or for all users in the given group. >>> There might be other conditions for the query. >> >> This would be slow if a lot of users are affected. > > Yes. But is is not a frequent operation so the admin should be aware. > I think it is acceptable. I think we'll have to test against a large user base to see what the impact would be. How do you change/override a password policy? Are you proposing a switch that will let a user that has a policy to get a new one? We'll also need to make extremely clear that this is a one-off operation. Getting added to a group itself does not set the password policy. > >> >>> In such case it is easy to control who gets the policy when the >>> policy is defined and easy to determine what policy is active for the >>> user (for audit purposes) since there is no ambiguity. >> >> There is no ambiguity in my method either though audit does bring up >> some interesting points because we don't track changes so knowing what >> the policy was at any given point in time is impossible. >> > This is exactly my point. Knowing the policy that worked and having a > clear change log is very important. > One of my previous employers had the same problem with groups and policy > ambiguity the customers could not pass audit because of that. There is no change log (nor a requirement for one that I know of). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Fri Jun 12 13:18:25 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 12 Jun 2009 15:18:25 +0200 Subject: [Freeipa-devel] [PATCHES] Add support for incomplete (truncated) search results. Message-ID: <4A3255A1.4050307@redhat.com> Patch 0001: Add support for incomplete (truncated) search results. ldap2 didn't have the capability to return search results when a DS limitation got exceeded (an exception was raised). Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-incomplete-truncated-search-result.patch Type: application/mbox Size: 5170 bytes Desc: not available URL: From pzuna at redhat.com Fri Jun 12 13:21:55 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 12 Jun 2009 15:21:55 +0200 Subject: [Freeipa-devel] [PATCH] Change plugins2 using find_entries to support incomplete (truncated) search results. Message-ID: <4A325673.3010406@redhat.com> I forgot to include this in [PATCHES] Add support for incomplete (truncated) search results. Note that this patch won't apply until baseldap.py and plugins using it get pushed. Patch 0002: Change plugins2 using find_entries to support incomplete (truncated) search results. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Change-plugins2-using-find_entries-to-support-incomp.patch Type: application/mbox Size: 15325 bytes Desc: not available URL: From pzuna at redhat.com Fri Jun 12 13:24:06 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 12 Jun 2009 15:24:06 +0200 Subject: [Freeipa-devel] [PATCH] Add conversion of attribute name synonyms when generating modlists. Message-ID: <4A3256F6.1010306@redhat.com> Patch 0003: Add conversion of attribute name synonyms when generating modlists. Fixes the bug with 'localityname' in host plugins and prevents similar bugs from happening. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-conversion-of-attribute-name-synonyms-when-gener.patch Type: application/mbox Size: 2456 bytes Desc: not available URL: From serejka at gmail.com Fri Jun 12 14:16:03 2009 From: serejka at gmail.com (Sergei V. Kovylov) Date: Fri, 12 Jun 2009 18:16:03 +0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <4A32513D.80701@redhat.com> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> <4A31007C.6060109@redhat.com> <4A31759A.40500@redhat.com> <4A32513D.80701@redhat.com> Message-ID: <7870594c0906120716t3483b567n83e173ee964329ec@mail.gmail.com> Hi all again. As for usage of COS and user's understanding: we must understand, that COS is just underlayer of IPA and user has no idea what is it. Another words user has some virtual term, like policy/security group, user group etc and what is under this term is out-of-mind of administration only for deep structure understanding if needs. In such case you are free to use any mechanism in back-end to provide necessary functionality. Usage of CoS just provide one of such mechanisms and give you an opportunity not to overload server with reqests. So for default password policy across entire LDAP tree, in my opinion, will be pointer CoS with "Does not override target entry attribute" on top DN of tree (ex. dc=domain,dc=dom). Moreover such mechanism doesn't require to create any attribute inside object/user/group entry and any definition of attribute automatically remove default policy because of pre-defined restriction "not to override user's entry attribute". Such mechanism also a good solution for "policy per sub-tree". So maybe it will be a good solution to create some types of group: 1. Policy/Security group which will store some pre-defined security/configuratio data (like password policy, user creation policy, user HBA policy etc). It's just a virtual group and has under it role with necessary actions. 2. User's group - which will provide an opportunity of groupping accounts under some circumstance. Also by the doc about DS 8.0 term "groups" stored for compatibility mode and for the rest of it offers to use roles. Also it's necessary to controll count of special policy attributes: = + + <= And in policy combination use MAX(min.pol1,min.pol2) and MAX(max.pol1, max.pol2) (min - min. length of polX, max - max. length of polX) and MIN(attr.pol1, attr.pol2) (attr - attribute like count of somewhat of polX). We are not necessary to take care about existed user's password, just new one. 3. Do not allow to use policy combination. From rcritten at redhat.com Fri Jun 12 14:33:16 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Jun 2009 10:33:16 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Add support for incomplete (truncated) search results. In-Reply-To: <4A3255A1.4050307@redhat.com> References: <4A3255A1.4050307@redhat.com> Message-ID: <4A32672C.7040503@redhat.com> Pavel Zuna wrote: > Patch 0001: Add support for incomplete (truncated) search results. > > ldap2 didn't have the capability to return search results when a DS > limitation got exceeded (an exception was raised). > > Pavel I think truncated should be initialized to False, not None. It looks like this could actually be transported across XML-RPC and I don't believe we've enabled the NULL option (and I'd rather avoid doing so). If this is ok I can make this change before committing the patch. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jun 12 14:49:19 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Jun 2009 10:49:19 -0400 Subject: [Freeipa-devel] Re: [PATCH] Add conversion of attribute name synonyms when generating modlists. In-Reply-To: <4A3256F6.1010306@redhat.com> References: <4A3256F6.1010306@redhat.com> Message-ID: <4A326AEF.5070902@redhat.com> Pavel Zuna wrote: > Patch 0003: Add conversion of attribute name synonyms when generating > modlists. > > Fixes the bug with 'localityname' in host plugins and prevents similar > bugs from happening. > > Pavel I'm not sure I understand this patch. What is the purpose of preferred_names? It looks that if this is set the the translation doesn't actually happen (and this is always set). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jun 12 15:04:05 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Jun 2009 11:04:05 -0400 Subject: [Freeipa-devel] bash completion In-Reply-To: <4A31A0AE.3060200@redhat.com> References: <4A311C7B.2080105@redhat.com> <4A31A0AE.3060200@redhat.com> Message-ID: <4A326E65.8040302@redhat.com> David O'Brien wrote: > Rob Crittenden wrote: >> I'm not ready to check this in yet but here is something I've been >> tinkering with, a bash completion script for the ipa command. You need >> bash 2.05a or higher with programmable completion and extended pattern >> matching enabled (it is on Fedora anyway). >> >> All you need to do is source this file and then you can use tab >> completion on the IPA commands. >> >> This is currently limited to just the command names, not the options. >> >> I created the list of commands use the ipa help system, I'm attaching >> that screwy little script too. >> >> Usage looks like: >> >> ipa u[TAB] -> ipa user[TAB] -> >> user2-create user2-lock user2-unlock user-find user-show >> user2-delete user2-mod user-add user-lock user-unlock >> user2-find user2-show user-del user-mod >> >> rob >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > How did we end up with all those "2s" in the commands? Version 2, sure, > but it only appears in some commands. What can I expect to see by GA? > This is temporary while we transition from an older LDAP backend to a newer one. This will all work itself out shortly. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Fri Jun 12 15:08:51 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 12 Jun 2009 11:08:51 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <1244761303.21116.59.camel@localhost.localdomain> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> <7870594c0906110036p4c259239x764bf4a54b682032@mail.gmail.com> <4A30F0A7.6040108@redhat.com> <4A310302.7050809@redhat.com> <1244727640.25513.37.camel@localhost.localdomain> <4A317868.3000608@redhat.com> <1244757402.21116.29.camel@localhost.localdomain> <4A318589.1050700@redhat.com> <1244761303.21116.59.camel@localhost.localdomain> Message-ID: <4A326F83.40905@redhat.com> Simo, We have some disagreements and some agreements. The fundamental disagreement is about doing it dynamically by CoS or putting the policy right into the user entry. I think we will have troubles with CoS with auditing down the road. I assume that all the changes are tracked in the audit logs and it would be much easier to correlate the change of the policy directly on the user entry than indirectly by changing group membership. I think this is very important for compliance (PCI, SOX etc) to be able to correlate the change in the policy to specific security event. The "update" scheme makes the forensic analysis much easier. This is the main argument. But if others do not see it as important I am not going to argue any more. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Fri Jun 12 15:20:18 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 12 Jun 2009 11:20:18 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <4A326F83.40905@redhat.com> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> <7870594c0906110036p4c259239x764bf4a54b682032@mail.gmail.com> <4A30F0A7.6040108@redhat.com> <4A310302.7050809@redhat.com> <1244727640.25513.37.camel@localhost.localdomain> <4A317868.3000608@redhat.com> <1244757402.21116.29.camel@localhost.localdomain> <4A318589.1050700@redhat.com> <1244761303.21116.59.camel@localhost.localdomain> <4A326F83.40905@redhat.com> Message-ID: <1244820018.21116.91.camel@localhost.localdomain> On Fri, 2009-06-12 at 11:08 -0400, Dmitri Pal wrote: > Simo, > > We have some disagreements and some agreements. > The fundamental disagreement is about doing it dynamically by CoS or > putting the policy right into the user entry. > I think we will have troubles with CoS with auditing down the road. > I assume that all the changes are tracked in the audit logs and it would > be much easier to correlate the change of the policy directly on the > user entry than indirectly by changing group membership. > I think this is very important for compliance (PCI, SOX etc) to be able > to correlate the change in the policy to specific security event. > The "update" scheme makes the forensic analysis much easier. This is the > main argument. > > But if others do not see it as important I am not going to argue any more. The point is this, if auditing is the only issue, which I recognize it is important, I think we should simply add auditing to the password change plugin. Upon a password change request we log not only what user asked a password change, but also what password policy was used in the process. I think this would much better satisfy any auditing request than any correlation mechanism. What do you think ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pzuna at redhat.com Fri Jun 12 15:27:33 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Fri, 12 Jun 2009 17:27:33 +0200 Subject: [Freeipa-devel] Re: [PATCHES] Add support for incomplete (truncated) search results. In-Reply-To: <4A32672C.7040503@redhat.com> References: <4A3255A1.4050307@redhat.com> <4A32672C.7040503@redhat.com> Message-ID: <4A3273E5.8030402@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> Patch 0001: Add support for incomplete (truncated) search results. >> >> ldap2 didn't have the capability to return search results when a DS >> limitation got exceeded (an exception was raised). >> >> Pavel > > I think truncated should be initialized to False, not None. It looks > like this could actually be transported across XML-RPC and I don't > believe we've enabled the NULL option (and I'd rather avoid doing so). > > If this is ok I can make this change before committing the patch. > > rob It is set to None, because otherwise it gets encoded into a string by the decode_retval decorator. If that's a problem I'll rework decode_retval. Pavel From rcritten at redhat.com Fri Jun 12 15:31:49 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Jun 2009 11:31:49 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Add support for incomplete (truncated) search results. In-Reply-To: <4A3273E5.8030402@redhat.com> References: <4A3255A1.4050307@redhat.com> <4A32672C.7040503@redhat.com> <4A3273E5.8030402@redhat.com> Message-ID: <4A3274E5.1030402@redhat.com> Pavel Z?na wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> Patch 0001: Add support for incomplete (truncated) search results. >>> >>> ldap2 didn't have the capability to return search results when a DS >>> limitation got exceeded (an exception was raised). >>> >>> Pavel >> >> I think truncated should be initialized to False, not None. It looks >> like this could actually be transported across XML-RPC and I don't >> believe we've enabled the NULL option (and I'd rather avoid doing so). >> >> If this is ok I can make this change before committing the patch. >> >> rob > > It is set to None, because otherwise it gets encoded into a string by > the decode_retval decorator. If that's a problem I'll rework decode_retval. > > Pavel Well, in general it would be nice if we could return booleans as welll, that is a supported XML-RPC data type. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Fri Jun 12 15:37:11 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Fri, 12 Jun 2009 17:37:11 +0200 Subject: [Freeipa-devel] Re: [PATCH] Add conversion of attribute name synonyms when generating modlists. In-Reply-To: <4A326AEF.5070902@redhat.com> References: <4A3256F6.1010306@redhat.com> <4A326AEF.5070902@redhat.com> Message-ID: <4A327627.7010405@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> Patch 0003: Add conversion of attribute name synonyms when generating >> modlists. >> >> Fixes the bug with 'localityname' in host plugins and prevents similar >> bugs from happening. >> >> Pavel > > I'm not sure I understand this patch. What is the purpose of > preferred_names? It looks that if this is set the the translation > doesn't actually happen (and this is always set). > > rob If preferred_names evaluate to True (if not None and not and empty list), then all attribute names equivalent to those in preferred names are converted to them. Otherwise all attributes are converted to their preferred synonym according to the schema. For example: a = {'locality': 'Brno'} ldap.convert_attr_synonyms(a, ['localityname']) # a == {'localityname': 'Brno'} ldap.convert_attr_synonyms(a) # a == {'l': 'Brno'} I did it this way, so when generating a modlist, we can convert attributes as returned by python-ldap to what the plugin uses. Pavel From pzuna at redhat.com Fri Jun 12 15:43:44 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Fri, 12 Jun 2009 17:43:44 +0200 Subject: [Freeipa-devel] Re: [PATCHES] Add support for incomplete (truncated) search results. In-Reply-To: <4A3274E5.1030402@redhat.com> References: <4A3255A1.4050307@redhat.com> <4A32672C.7040503@redhat.com> <4A3273E5.8030402@redhat.com> <4A3274E5.1030402@redhat.com> Message-ID: <4A3277B0.3000306@redhat.com> Rob Crittenden wrote: > Pavel Z?na wrote: >> Rob Crittenden wrote: >>> Pavel Zuna wrote: >>>> Patch 0001: Add support for incomplete (truncated) search results. >>>> >>>> ldap2 didn't have the capability to return search results when a DS >>>> limitation got exceeded (an exception was raised). >>>> >>>> Pavel >>> >>> I think truncated should be initialized to False, not None. It looks >>> like this could actually be transported across XML-RPC and I don't >>> believe we've enabled the NULL option (and I'd rather avoid doing so). >>> >>> If this is ok I can make this change before committing the patch. >>> >>> rob >> >> It is set to None, because otherwise it gets encoded into a string by >> the decode_retval decorator. If that's a problem I'll rework >> decode_retval. >> >> Pavel > > Well, in general it would be nice if we could return booleans as welll, > that is a supported XML-RPC data type. > > rob > The decode_retval decorator currently decodes everything returned by the decorated function into the python unicode type except None (unless configured otherwise). There is no option to only decode a certain part, but it shouldn't be hard to rework it to be similar to encode_args. I didn't think of this, because it is only used by find_entries at this point. Pavel From rcritten at redhat.com Fri Jun 12 15:44:33 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Jun 2009 11:44:33 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <4A326F83.40905@redhat.com> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> <7870594c0906110036p4c259239x764bf4a54b682032@mail.gmail.com> <4A30F0A7.6040108@redhat.com> <4A310302.7050809@redhat.com> <1244727640.25513.37.camel@localhost.localdomain> <4A317868.3000608@redhat.com> <1244757402.21116.29.camel@localhost.localdomain> <4A318589.1050700@redhat.com> <1244761303.21116.59.camel@localhost.localdomain> <4A326F83.40905@redhat.com> Message-ID: <4A3277E1.70403@redhat.com> Dmitri Pal wrote: > Simo, > > We have some disagreements and some agreements. > The fundamental disagreement is about doing it dynamically by CoS or > putting the policy right into the user entry. > I think we will have troubles with CoS with auditing down the road. > I assume that all the changes are tracked in the audit logs and it would > be much easier to correlate the change of the policy directly on the > user entry than indirectly by changing group membership. I want to state again that we have no audit logs on the attribute level. We will know that someone has touched a record but not necessarily what was done to it. Here I'm changing the user's last name: [12/Jun/2009:11:23:38 -0400] conn=258 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [12/Jun/2009:11:23:38 -0400] conn=258 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com" [12/Jun/2009:11:24:54 -0400] conn=258 op=11 MOD dn="uid=tuser1,cn=users,cn=accounts,dc=example,dc=com" [12/Jun/2009:11:24:54 -0400] conn=258 op=11 RESULT err=0 tag=103 nentries=0 etime=0 [12/Jun/2009:11:24:54 -0400] conn=258 op=12 SRCH base="uid=tuser1,cn=users,cn=accounts,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [12/Jun/2009:11:24:54 -0400] conn=258 op=12 RESULT err=0 tag=101 nentries=1 etime=0 All we have is a MOD operation. A password change is similarly opaque: [12/Jun/2009:11:35:00 -0400] conn=258 op=15 EXT oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop" [12/Jun/2009:11:35:00 -0400] conn=258 op=15 RESULT err=0 tag=120 nentries=0 etime=0 > I think this is very important for compliance (PCI, SOX etc) to be able > to correlate the change in the policy to specific security event. Ok then a lot more logging will need to be added to DS. > The "update" scheme makes the forensic analysis much easier. This is the > main argument. > > But if others do not see it as important I am not going to argue any more. > It isn't a matter of importance, I just think we can obtain the same results using CoS with a lot less work. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jun 12 15:49:57 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Jun 2009 11:49:57 -0400 Subject: [Freeipa-devel] Re: [PATCH] Add conversion of attribute name synonyms when generating modlists. In-Reply-To: <4A327627.7010405@redhat.com> References: <4A3256F6.1010306@redhat.com> <4A326AEF.5070902@redhat.com> <4A327627.7010405@redhat.com> Message-ID: <4A327925.4020106@redhat.com> Pavel Z?na wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> Patch 0003: Add conversion of attribute name synonyms when generating >>> modlists. >>> >>> Fixes the bug with 'localityname' in host plugins and prevents >>> similar bugs from happening. >>> >>> Pavel >> >> I'm not sure I understand this patch. What is the purpose of >> preferred_names? It looks that if this is set the the translation >> doesn't actually happen (and this is always set). >> >> rob > > If preferred_names evaluate to True (if not None and not and empty > list), then all attribute names equivalent to those in preferred names > are converted to them. Otherwise all attributes are converted to their > preferred synonym according to the schema. > > For example: > > a = {'locality': 'Brno'} > ldap.convert_attr_synonyms(a, ['localityname']) > # a == {'localityname': 'Brno'} > ldap.convert_attr_synonyms(a) > # a == {'l': 'Brno'} > > I did it this way, so when generating a modlist, we can convert > attributes as returned by python-ldap to what the plugin uses. > > Pavel > Ok, this is where I got confused. You don't actually make that second call (without the preferred_names) anywhere in the patch. I'm not sure we need to do the preferred name though, we'll still end up with extra MOD operations this way. Take an example: I add a host: % ipa host-add --locality=Brno h1.example.com When the record is added 389 is going to change the attribute to 'l'. dn: fqdn=h1.example.com,cn=computers,cn=accounts,dc=example,dc=com cn: h1.example.com fqdn: h1.example.com l: Brno The machine moves so I modify the entry: % ipa host-mod --locality=Berlin h1.example.com Your first call will leave the attribute as localityname and it will try to compare it to 'l', right? So it is still going to add a new value. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Fri Jun 12 15:57:29 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 12 Jun 2009 11:57:29 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <4A3277E1.70403@redhat.com> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> <7870594c0906110036p4c259239x764bf4a54b682032@mail.gmail.com> <4A30F0A7.6040108@redhat.com> <4A310302.7050809@redhat.com> <1244727640.25513.37.camel@localhost.localdomain> <4A317868.3000608@redhat.com> <1244757402.21116.29.camel@localhost.localdomain> <4A318589.1050700@redhat.com> <1244761303.21116.59.camel@localhost.localdomain> <4A326F83.40905@redhat.com> <4A3277E1.70403@redhat.com> Message-ID: <1244822249.21116.93.camel@localhost.localdomain> On Fri, 2009-06-12 at 11:44 -0400, Rob Crittenden wrote: > Dmitri Pal wrote: > > Simo, > > > > We have some disagreements and some agreements. > > The fundamental disagreement is about doing it dynamically by CoS or > > putting the policy right into the user entry. > > I think we will have troubles with CoS with auditing down the road. > > I assume that all the changes are tracked in the audit logs and it would > > be much easier to correlate the change of the policy directly on the > > user entry than indirectly by changing group membership. > > I want to state again that we have no audit logs on the attribute level. > We will know that someone has touched a record but not necessarily what > was done to it. Here I'm changing the user's last name: > > [12/Jun/2009:11:23:38 -0400] conn=258 op=2 BIND dn="" method=sasl > version=3 mech=GSSAPI > [12/Jun/2009:11:23:38 -0400] conn=258 op=2 RESULT err=0 tag=97 > nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com" > > [12/Jun/2009:11:24:54 -0400] conn=258 op=11 MOD > dn="uid=tuser1,cn=users,cn=accounts,dc=example,dc=com" > [12/Jun/2009:11:24:54 -0400] conn=258 op=11 RESULT err=0 tag=103 > nentries=0 etime=0 > [12/Jun/2009:11:24:54 -0400] conn=258 op=12 SRCH > base="uid=tuser1,cn=users,cn=accounts,dc=example,dc=com" scope=0 > filter="(objectClass=*)" attrs=ALL > [12/Jun/2009:11:24:54 -0400] conn=258 op=12 RESULT err=0 tag=101 > nentries=1 etime=0 > > All we have is a MOD operation. > > A password change is similarly opaque: > [12/Jun/2009:11:35:00 -0400] conn=258 op=15 EXT > oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop" > [12/Jun/2009:11:35:00 -0400] conn=258 op=15 RESULT err=0 tag=120 > nentries=0 etime=0 > > > I think this is very important for compliance (PCI, SOX etc) to be able > > to correlate the change in the policy to specific security event. > > Ok then a lot more logging will need to be added to DS. As I proposed in my mail, we should probably have the password plugin perform this logging at password change time, that should solve all issues and will be agnostic to the method used to provide the policy. > > The "update" scheme makes the forensic analysis much easier. This is the > > main argument. > > > > But if others do not see it as important I am not going to argue any more. > > > > It isn't a matter of importance, I just think we can obtain the same > results using CoS with a lot less work. I concur, and a lot less error prone. Simo. -- Simo Sorce * Red Hat, Inc * New York From rmeggins at redhat.com Fri Jun 12 16:00:45 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 12 Jun 2009 10:00:45 -0600 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <4A3277E1.70403@redhat.com> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> <7870594c0906110036p4c259239x764bf4a54b682032@mail.gmail.com> <4A30F0A7.6040108@redhat.com> <4A310302.7050809@redhat.com> <1244727640.25513.37.camel@localhost.localdomain> <4A317868.3000608@redhat.com> <1244757402.21116.29.camel@localhost.localdomain> <4A318589.1050700@redhat.com> <1244761303.21116.59.camel@localhost.localdomain> <4A326F83.40905@redhat.com> <4A3277E1.70403@redhat.com> Message-ID: <4A327BAD.40001@redhat.com> Rob Crittenden wrote: > Dmitri Pal wrote: >> Simo, >> >> We have some disagreements and some agreements. >> The fundamental disagreement is about doing it dynamically by CoS or >> putting the policy right into the user entry. >> I think we will have troubles with CoS with auditing down the road. >> I assume that all the changes are tracked in the audit logs and it >> would be much easier to correlate the change of the policy directly >> on the user entry than indirectly by changing group membership. > > I want to state again that we have no audit logs on the attribute > level. We will know that someone has touched a record but not > necessarily what was done to it. Here I'm changing the user's last name: > > [12/Jun/2009:11:23:38 -0400] conn=258 op=2 BIND dn="" method=sasl > version=3 mech=GSSAPI > [12/Jun/2009:11:23:38 -0400] conn=258 op=2 RESULT err=0 tag=97 > nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com" > > [12/Jun/2009:11:24:54 -0400] conn=258 op=11 MOD > dn="uid=tuser1,cn=users,cn=accounts,dc=example,dc=com" > [12/Jun/2009:11:24:54 -0400] conn=258 op=11 RESULT err=0 tag=103 > nentries=0 etime=0 > [12/Jun/2009:11:24:54 -0400] conn=258 op=12 SRCH > base="uid=tuser1,cn=users,cn=accounts,dc=example,dc=com" scope=0 > filter="(objectClass=*)" attrs=ALL > [12/Jun/2009:11:24:54 -0400] conn=258 op=12 RESULT err=0 tag=101 > nentries=1 etime=0 > > All we have is a MOD operation. If you enable the audit log, you can get the full ldap mod operation. > > A password change is similarly opaque: > [12/Jun/2009:11:35:00 -0400] conn=258 op=15 EXT > oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop" > [12/Jun/2009:11:35:00 -0400] conn=258 op=15 RESULT err=0 tag=120 > nentries=0 etime=0 > >> I think this is very important for compliance (PCI, SOX etc) to be >> able to correlate the change in the policy to specific security event. > > Ok then a lot more logging will need to be added to DS. I'm not sure if extops are logged to the audit log, or what information is contained there. > >> The "update" scheme makes the forensic analysis much easier. This is >> the main argument. >> >> But if others do not see it as important I am not going to argue any >> more. >> > > It isn't a matter of importance, I just think we can obtain the same > results using CoS with a lot less work. > > rob > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-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 pzuna at redhat.com Fri Jun 12 16:02:29 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Fri, 12 Jun 2009 18:02:29 +0200 Subject: [Freeipa-devel] Re: [PATCH] Add conversion of attribute name synonyms when generating modlists. In-Reply-To: <4A327925.4020106@redhat.com> References: <4A3256F6.1010306@redhat.com> <4A326AEF.5070902@redhat.com> <4A327627.7010405@redhat.com> <4A327925.4020106@redhat.com> Message-ID: <4A327C15.3040309@redhat.com> Rob Crittenden wrote: > Pavel Z?na wrote: >> Rob Crittenden wrote: >>> Pavel Zuna wrote: >>>> Patch 0003: Add conversion of attribute name synonyms when >>>> generating modlists. >>>> >>>> Fixes the bug with 'localityname' in host plugins and prevents >>>> similar bugs from happening. >>>> >>>> Pavel >>> >>> I'm not sure I understand this patch. What is the purpose of >>> preferred_names? It looks that if this is set the the translation >>> doesn't actually happen (and this is always set). >>> >>> rob >> >> If preferred_names evaluate to True (if not None and not and empty >> list), then all attribute names equivalent to those in preferred names >> are converted to them. Otherwise all attributes are converted to their >> preferred synonym according to the schema. >> >> For example: >> >> a = {'locality': 'Brno'} >> ldap.convert_attr_synonyms(a, ['localityname']) >> # a == {'localityname': 'Brno'} >> ldap.convert_attr_synonyms(a) >> # a == {'l': 'Brno'} >> >> I did it this way, so when generating a modlist, we can convert >> attributes as returned by python-ldap to what the plugin uses. >> >> Pavel >> > > Ok, this is where I got confused. You don't actually make that second > call (without the preferred_names) anywhere in the patch. > > I'm not sure we need to do the preferred name though, we'll still end up > with extra MOD operations this way. Take an example: > > I add a host: > > % ipa host-add --locality=Brno h1.example.com > > When the record is added 389 is going to change the attribute to 'l'. > > dn: fqdn=h1.example.com,cn=computers,cn=accounts,dc=example,dc=com > cn: h1.example.com > fqdn: h1.example.com > l: Brno > > > The machine moves so I modify the entry: > > % ipa host-mod --locality=Berlin h1.example.com > > Your first call will leave the attribute as localityname and it will try > to compare it to 'l', right? So it is still going to add a new value. > > rob > If converting entry attributes received from *-mod commands, then yes. But I took another approach to it. When generating a modlist, I first retrieve the original entry attributes and convert their names this way: ldap.convert_attr_synonyms(original_entry_attrs, new_entry_attrs.keys()) It doesn't matter if I convert the original entry attributes or the new attributes before making the comparison, but the later is a bit faster, because there's always more attributes in the original entry (resulting in more iterations when performing the conversion). Oh, and it only works for plugins2, because it all happens inside ldap2. Pavel From pzuna at redhat.com Fri Jun 12 16:08:29 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Fri, 12 Jun 2009 18:08:29 +0200 Subject: [Freeipa-devel] Re: [PATCH] Add conversion of attribute name synonyms when generating modlists. In-Reply-To: <4A327C15.3040309@redhat.com> References: <4A3256F6.1010306@redhat.com> <4A326AEF.5070902@redhat.com> <4A327627.7010405@redhat.com> <4A327925.4020106@redhat.com> <4A327C15.3040309@redhat.com> Message-ID: <4A327D7D.9090304@redhat.com> Pavel Z?na wrote: > Rob Crittenden wrote: >> Pavel Z?na wrote: >>> Rob Crittenden wrote: >>>> Pavel Zuna wrote: >>>>> Patch 0003: Add conversion of attribute name synonyms when >>>>> generating modlists. >>>>> >>>>> Fixes the bug with 'localityname' in host plugins and prevents >>>>> similar bugs from happening. >>>>> >>>>> Pavel >>>> >>>> I'm not sure I understand this patch. What is the purpose of >>>> preferred_names? It looks that if this is set the the translation >>>> doesn't actually happen (and this is always set). >>>> >>>> rob >>> >>> If preferred_names evaluate to True (if not None and not and empty >>> list), then all attribute names equivalent to those in preferred >>> names are converted to them. Otherwise all attributes are converted >>> to their preferred synonym according to the schema. >>> >>> For example: >>> >>> a = {'locality': 'Brno'} >>> ldap.convert_attr_synonyms(a, ['localityname']) >>> # a == {'localityname': 'Brno'} >>> ldap.convert_attr_synonyms(a) >>> # a == {'l': 'Brno'} >>> >>> I did it this way, so when generating a modlist, we can convert >>> attributes as returned by python-ldap to what the plugin uses. >>> >>> Pavel >>> >> >> Ok, this is where I got confused. You don't actually make that second >> call (without the preferred_names) anywhere in the patch. >> >> I'm not sure we need to do the preferred name though, we'll still end >> up with extra MOD operations this way. Take an example: >> >> I add a host: >> >> % ipa host-add --locality=Brno h1.example.com >> >> When the record is added 389 is going to change the attribute to 'l'. >> >> dn: fqdn=h1.example.com,cn=computers,cn=accounts,dc=example,dc=com >> cn: h1.example.com >> fqdn: h1.example.com >> l: Brno >> >> >> The machine moves so I modify the entry: >> >> % ipa host-mod --locality=Berlin h1.example.com >> >> Your first call will leave the attribute as localityname and it will >> try to compare it to 'l', right? So it is still going to add a new value. >> >> rob >> > > If converting entry attributes received from *-mod commands, then yes. > But I took another approach to it. When generating a modlist, I first > retrieve the original entry attributes and convert their names this way: > > ldap.convert_attr_synonyms(original_entry_attrs, new_entry_attrs.keys()) > > It doesn't matter if I convert the original entry attributes or the new > attributes before making the comparison, but the later is a bit faster, > because there's always more attributes in the original entry (resulting > in more iterations when performing the conversion). > > Oh, and it only works for plugins2, because it all happens inside ldap2. > > Pavel > Another advantage of using preferred_names argument is that we know for sure, what we're going to get. Without it, it depends on the order of the names in the schema and if the LDAP server doesn't respect this order, comparisons while generating modlists will go bad. Pavel From rcritten at redhat.com Fri Jun 12 17:09:01 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Jun 2009 13:09:01 -0400 Subject: [Freeipa-devel] Re: [PATCH] Add conversion of attribute name synonyms when generating modlists. In-Reply-To: <4A327C15.3040309@redhat.com> References: <4A3256F6.1010306@redhat.com> <4A326AEF.5070902@redhat.com> <4A327627.7010405@redhat.com> <4A327925.4020106@redhat.com> <4A327C15.3040309@redhat.com> Message-ID: <4A328BAD.8060801@redhat.com> Pavel Z?na wrote: > Rob Crittenden wrote: >> Pavel Z?na wrote: >>> Rob Crittenden wrote: >>>> Pavel Zuna wrote: >>>>> Patch 0003: Add conversion of attribute name synonyms when >>>>> generating modlists. >>>>> >>>>> Fixes the bug with 'localityname' in host plugins and prevents >>>>> similar bugs from happening. >>>>> >>>>> Pavel >>>> >>>> I'm not sure I understand this patch. What is the purpose of >>>> preferred_names? It looks that if this is set the the translation >>>> doesn't actually happen (and this is always set). >>>> >>>> rob >>> >>> If preferred_names evaluate to True (if not None and not and empty >>> list), then all attribute names equivalent to those in preferred >>> names are converted to them. Otherwise all attributes are converted >>> to their preferred synonym according to the schema. >>> >>> For example: >>> >>> a = {'locality': 'Brno'} >>> ldap.convert_attr_synonyms(a, ['localityname']) >>> # a == {'localityname': 'Brno'} >>> ldap.convert_attr_synonyms(a) >>> # a == {'l': 'Brno'} >>> >>> I did it this way, so when generating a modlist, we can convert >>> attributes as returned by python-ldap to what the plugin uses. >>> >>> Pavel >>> >> >> Ok, this is where I got confused. You don't actually make that second >> call (without the preferred_names) anywhere in the patch. >> >> I'm not sure we need to do the preferred name though, we'll still end >> up with extra MOD operations this way. Take an example: >> >> I add a host: >> >> % ipa host-add --locality=Brno h1.example.com >> >> When the record is added 389 is going to change the attribute to 'l'. >> >> dn: fqdn=h1.example.com,cn=computers,cn=accounts,dc=example,dc=com >> cn: h1.example.com >> fqdn: h1.example.com >> l: Brno >> >> >> The machine moves so I modify the entry: >> >> % ipa host-mod --locality=Berlin h1.example.com >> >> Your first call will leave the attribute as localityname and it will >> try to compare it to 'l', right? So it is still going to add a new value. >> >> rob >> > > If converting entry attributes received from *-mod commands, then yes. > But I took another approach to it. When generating a modlist, I first > retrieve the original entry attributes and convert their names this way: > > ldap.convert_attr_synonyms(original_entry_attrs, new_entry_attrs.keys()) > > It doesn't matter if I convert the original entry attributes or the new > attributes before making the comparison, but the later is a bit faster, > because there's always more attributes in the original entry (resulting > in more iterations when performing the conversion). > > Oh, and it only works for plugins2, because it all happens inside ldap2. > > Pavel Ok, that makes sense but you didn't include this call in the patch. Do you need to make an updated patch? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jun 12 17:27:51 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Jun 2009 13:27:51 -0400 Subject: [Freeipa-devel] [PATCH] 232 add topics and commands argument to help Message-ID: <4A329017.6090404@redhat.com> Adds 2 new arguments to help command: ipa help topics will show all topics ipa help commands will list all available commands rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-232-help.patch Type: application/mbox Size: 1428 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Fri Jun 12 18:19:40 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 12 Jun 2009 14:19:40 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <1244822249.21116.93.camel@localhost.localdomain> References: <4A3027DD.5060107@redhat.com> <4A307ABE.3090409@redhat.com> <7870594c0906110036p4c259239x764bf4a54b682032@mail.gmail.com> <4A30F0A7.6040108@redhat.com> <4A310302.7050809@redhat.com> <1244727640.25513.37.camel@localhost.localdomain> <4A317868.3000608@redhat.com> <1244757402.21116.29.camel@localhost.localdomain> <4A318589.1050700@redhat.com> <1244761303.21116.59.camel@localhost.localdomain> <4A326F83.40905@redhat.com> <4A3277E1.70403@redhat.com> <1244822249.21116.93.camel@localhost.localdomain> Message-ID: <4A329C3C.10206@redhat.com> Simo Sorce wrote: > On Fri, 2009-06-12 at 11:44 -0400, Rob Crittenden wrote: > >> Dmitri Pal wrote: >> >>> Simo, >>> >>> We have some disagreements and some agreements. >>> The fundamental disagreement is about doing it dynamically by CoS or >>> putting the policy right into the user entry. >>> I think we will have troubles with CoS with auditing down the road. >>> I assume that all the changes are tracked in the audit logs and it would >>> be much easier to correlate the change of the policy directly on the >>> user entry than indirectly by changing group membership. >>> >> I want to state again that we have no audit logs on the attribute level. >> We will know that someone has touched a record but not necessarily what >> was done to it. Here I'm changing the user's last name: >> >> [12/Jun/2009:11:23:38 -0400] conn=258 op=2 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [12/Jun/2009:11:23:38 -0400] conn=258 op=2 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com" >> >> [12/Jun/2009:11:24:54 -0400] conn=258 op=11 MOD >> dn="uid=tuser1,cn=users,cn=accounts,dc=example,dc=com" >> [12/Jun/2009:11:24:54 -0400] conn=258 op=11 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [12/Jun/2009:11:24:54 -0400] conn=258 op=12 SRCH >> base="uid=tuser1,cn=users,cn=accounts,dc=example,dc=com" scope=0 >> filter="(objectClass=*)" attrs=ALL >> [12/Jun/2009:11:24:54 -0400] conn=258 op=12 RESULT err=0 tag=101 >> nentries=1 etime=0 >> >> All we have is a MOD operation. >> >> A password change is similarly opaque: >> [12/Jun/2009:11:35:00 -0400] conn=258 op=15 EXT >> oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop" >> [12/Jun/2009:11:35:00 -0400] conn=258 op=15 RESULT err=0 tag=120 >> nentries=0 etime=0 >> >> >>> I think this is very important for compliance (PCI, SOX etc) to be able >>> to correlate the change in the policy to specific security event. >>> >> Ok then a lot more logging will need to be added to DS. >> > > As I proposed in my mail, we should probably have the password plugin > perform this logging at password change time, that should solve all > issues and will be agnostic to the method used to provide the policy. > > It should probably be done by the audit plugin that will integrate DS with the Audit system. Remember we talked about something like this. But it is down the road. For now I think that recording the policy information in the log by password plugin will make sense. This rises a different question which grants a separate thread. So I agree with CoS approach now. >>> The "update" scheme makes the forensic analysis much easier. This is the >>> main argument. >>> >>> But if others do not see it as important I am not going to argue any more. >>> >>> >> It isn't a matter of importance, I just think we can obtain the same >> results using CoS with a lot less work. >> > > I concur, and a lot less error prone. > > Simo. > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Jun 12 18:28:53 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 12 Jun 2009 14:28:53 -0400 Subject: [Freeipa-devel] what about IPA operational logging? Message-ID: <4A329E65.5080602@redhat.com> Hi, In IPA we have kerberos logs, DS logs, web logs, CA logs etc. They are all subsystem specific and disjoint. I think we need an IPA log that will contain things like: a) Object (meaning user, host, map, group, HBAC rule) was modified (added/deleted/edited may be even viewed) b) Certificate issued/revoked/refreshed c) Entity authenticated d) Password changed e) Policy changed f) Configuration changed This is a much better feed than many low level logs. It can be correlated with low level logs if needed but for system monitoring it is best. That means that we should start thinking about logging into one log from all those components. The ultimate goal will be to emit the ELAPI events and forward them directly to the audit subsystem. This is not for v2 but let us keep this in mind for v3. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Jun 12 19:10:33 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Jun 2009 15:10:33 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix bugs in ldap2. In-Reply-To: <4A2FACB1.9000702@redhat.com> References: <4A2FACB1.9000702@redhat.com> Message-ID: <4A32A829.3060507@redhat.com> Pavel Zuna wrote: > Patch 0010: Fix bugs in ldap2. > > - NotFound exception were initialized with no arguments. > - find_entry_by_attr returned more than one entry > - modify_password had bad arguments and also a typo > - removed some code rendered useless since the introduction of Encoder > > Pavel ack, pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jun 12 19:16:51 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Jun 2009 15:16:51 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Add support for incomplete (truncated) search results. In-Reply-To: <4A3277B0.3000306@redhat.com> References: <4A3255A1.4050307@redhat.com> <4A32672C.7040503@redhat.com> <4A3273E5.8030402@redhat.com> <4A3274E5.1030402@redhat.com> <4A3277B0.3000306@redhat.com> Message-ID: <4A32A9A3.1090806@redhat.com> Pavel Z?na wrote: > Rob Crittenden wrote: >> Pavel Z?na wrote: >>> Rob Crittenden wrote: >>>> Pavel Zuna wrote: >>>>> Patch 0001: Add support for incomplete (truncated) search results. >>>>> >>>>> ldap2 didn't have the capability to return search results when a DS >>>>> limitation got exceeded (an exception was raised). >>>>> >>>>> Pavel >>>> >>>> I think truncated should be initialized to False, not None. It looks >>>> like this could actually be transported across XML-RPC and I don't >>>> believe we've enabled the NULL option (and I'd rather avoid doing so). >>>> >>>> If this is ok I can make this change before committing the patch. >>>> >>>> rob >>> >>> It is set to None, because otherwise it gets encoded into a string by >>> the decode_retval decorator. If that's a problem I'll rework >>> decode_retval. >>> >>> Pavel >> >> Well, in general it would be nice if we could return booleans as >> welll, that is a supported XML-RPC data type. >> >> rob >> > > The decode_retval decorator currently decodes everything returned by the > decorated function into the python unicode type except None (unless > configured otherwise). There is no option to only decode a certain part, > but it shouldn't be hard to rework it to be similar to encode_args. I > didn't think of this, because it is only used by find_entries at this > point. > > Pavel Why convert int, bool, long, etc into a unicode at all? Why not just return them as-is? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jun 12 20:30:07 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Jun 2009 16:30:07 -0400 Subject: [Freeipa-devel] Re: [PATCH] Change plugins2 using find_entries to support incomplete (truncated) search results. In-Reply-To: <4A325673.3010406@redhat.com> References: <4A325673.3010406@redhat.com> Message-ID: <4A32BACF.5000106@redhat.com> Pavel Zuna wrote: > I forgot to include this in [PATCHES] Add support for incomplete > (truncated) search results. > > Note that this patch won't apply until baseldap.py and plugins using it > get pushed. > > Patch 0002: Change plugins2 using find_entries to support incomplete > (truncated) search results. > > Pavel nack. I've only really looked closely at user2 but I think this applies to all the plugins. In output_for_cli() you split out entries and truncated but continue to use results when displaying and counting the entries. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From sbose at redhat.com Mon Jun 15 13:43:41 2009 From: sbose at redhat.com (Sumit Bose) Date: Mon, 15 Jun 2009 15:43:41 +0200 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin In-Reply-To: <4A2D6F73.7040206@redhat.com> References: <4A2D6F73.7040206@redhat.com> Message-ID: <4A36500D.3030804@redhat.com> Am 08.06.2009 22:07, schrieb Sumit Bose: > Hi, > > this is the rebased version of the kerberos backend patch I sent early > April > (https://www.redhat.com/archives/freeipa-devel/2009-April/msg00039.html) > . It has the same functionality as the older version and is working with > the ldap id backend. I'm planning to add some more features and would > like to asked what would be the best way for you to review it. Shall I > split it similar to the original one? Shall I add more features and send > it later or should it be pushed as early as possible? > Hi, I have put the locator plugin and the kerberos backend in two different patches. I also changed the event handling in the backend to the tevent_req style. Simo, can you please review the tevent_req stuff. If I've done it right I will try and change the waitpid call to tevent_req. bye, Sumit -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-added-kerberos-locator-plugin.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-added-kerberos-backend-with-tevent_req-event-handlin.patch URL: From pzuna at redhat.com Mon Jun 15 14:04:25 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 15 Jun 2009 16:04:25 +0200 Subject: [Freeipa-devel] Re: [PATCH] Add conversion of attribute name synonyms when generating modlists. In-Reply-To: <4A328BAD.8060801@redhat.com> References: <4A3256F6.1010306@redhat.com> <4A326AEF.5070902@redhat.com> <4A327627.7010405@redhat.com> <4A327925.4020106@redhat.com> <4A327C15.3040309@redhat.com> <4A328BAD.8060801@redhat.com> Message-ID: <4A3654E9.70802@redhat.com> Rob Crittenden wrote: > Pavel Z?na wrote: >> Rob Crittenden wrote: >>> Pavel Z?na wrote: >>>> Rob Crittenden wrote: >>>>> Pavel Zuna wrote: >>>>>> Patch 0003: Add conversion of attribute name synonyms when >>>>>> generating modlists. >>>>>> >>>>>> Fixes the bug with 'localityname' in host plugins and prevents >>>>>> similar bugs from happening. >>>>>> >>>>>> Pavel >>>>> >>>>> I'm not sure I understand this patch. What is the purpose of >>>>> preferred_names? It looks that if this is set the the translation >>>>> doesn't actually happen (and this is always set). >>>>> >>>>> rob >>>> >>>> If preferred_names evaluate to True (if not None and not and empty >>>> list), then all attribute names equivalent to those in preferred >>>> names are converted to them. Otherwise all attributes are converted >>>> to their preferred synonym according to the schema. >>>> >>>> For example: >>>> >>>> a = {'locality': 'Brno'} >>>> ldap.convert_attr_synonyms(a, ['localityname']) >>>> # a == {'localityname': 'Brno'} >>>> ldap.convert_attr_synonyms(a) >>>> # a == {'l': 'Brno'} >>>> >>>> I did it this way, so when generating a modlist, we can convert >>>> attributes as returned by python-ldap to what the plugin uses. >>>> >>>> Pavel >>>> >>> >>> Ok, this is where I got confused. You don't actually make that second >>> call (without the preferred_names) anywhere in the patch. >>> >>> I'm not sure we need to do the preferred name though, we'll still end >>> up with extra MOD operations this way. Take an example: >>> >>> I add a host: >>> >>> % ipa host-add --locality=Brno h1.example.com >>> >>> When the record is added 389 is going to change the attribute to 'l'. >>> >>> dn: fqdn=h1.example.com,cn=computers,cn=accounts,dc=example,dc=com >>> cn: h1.example.com >>> fqdn: h1.example.com >>> l: Brno >>> >>> >>> The machine moves so I modify the entry: >>> >>> % ipa host-mod --locality=Berlin h1.example.com >>> >>> Your first call will leave the attribute as localityname and it will >>> try to compare it to 'l', right? So it is still going to add a new >>> value. >>> >>> rob >>> >> >> If converting entry attributes received from *-mod commands, then yes. >> But I took another approach to it. When generating a modlist, I first >> retrieve the original entry attributes and convert their names this way: >> >> ldap.convert_attr_synonyms(original_entry_attrs, new_entry_attrs.keys()) >> >> It doesn't matter if I convert the original entry attributes or the >> new attributes before making the comparison, but the later is a bit >> faster, because there's always more attributes in the original entry >> (resulting in more iterations when performing the conversion). >> >> Oh, and it only works for plugins2, because it all happens inside ldap2. >> >> Pavel > > Ok, that makes sense but you didn't include this call in the patch. Do > you need to make an updated patch? > > rob > I think I did, it's hidden in comments. ;-) 47 @@ -477,6 +503,8 @@ class ldap2(CrudBackend, Encoder): 48 # we could call search_s directly, but this saves a lot of code at 49 # the expense of a little bit of performace 50 entry_attrs_old = self.encode(entry_attrs_old) 51 + # we also need to make sure that attribute names match 52 + self.convert_attr_synonyms(entry_attrs_old, entry_attrs.keys()) 53 # generate modlist, we don't want any MOD_REPLACE operations 54 # to handle simultaneous updates better 55 modlist = [] Pavel From pzuna at redhat.com Mon Jun 15 14:08:41 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 15 Jun 2009 16:08:41 +0200 Subject: [Freeipa-devel] Re: [PATCHES] Add support for incomplete (truncated) search results. In-Reply-To: <4A32A9A3.1090806@redhat.com> References: <4A3255A1.4050307@redhat.com> <4A32672C.7040503@redhat.com> <4A3273E5.8030402@redhat.com> <4A3274E5.1030402@redhat.com> <4A3277B0.3000306@redhat.com> <4A32A9A3.1090806@redhat.com> Message-ID: <4A3655E9.3050402@redhat.com> Rob Crittenden wrote: > Pavel Z?na wrote: >> Rob Crittenden wrote: >>> Pavel Z?na wrote: >>>> Rob Crittenden wrote: >>>>> Pavel Zuna wrote: >>>>>> Patch 0001: Add support for incomplete (truncated) search results. >>>>>> >>>>>> ldap2 didn't have the capability to return search results when a >>>>>> DS limitation got exceeded (an exception was raised). >>>>>> >>>>>> Pavel >>>>> >>>>> I think truncated should be initialized to False, not None. It >>>>> looks like this could actually be transported across XML-RPC and I >>>>> don't believe we've enabled the NULL option (and I'd rather avoid >>>>> doing so). >>>>> >>>>> If this is ok I can make this change before committing the patch. >>>>> >>>>> rob >>>> >>>> It is set to None, because otherwise it gets encoded into a string >>>> by the decode_retval decorator. If that's a problem I'll rework >>>> decode_retval. >>>> >>>> Pavel >>> >>> Well, in general it would be nice if we could return booleans as >>> welll, that is a supported XML-RPC data type. >>> >>> rob >>> >> >> The decode_retval decorator currently decodes everything returned by >> the decorated function into the python unicode type except None >> (unless configured otherwise). There is no option to only decode a >> certain part, but it shouldn't be hard to rework it to be similar to >> encode_args. I didn't think of this, because it is only used by >> find_entries at this point. >> >> Pavel > > Why convert int, bool, long, etc into a unicode at all? Why not just > return them as-is? > > rob > No reason really - I was just converting everything. I removed the conversion of non-string scalar types. Here's an updated patch. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-imcomplete-truncated-search-result.patch Type: application/mbox Size: 6246 bytes Desc: not available URL: From pzuna at redhat.com Mon Jun 15 14:10:01 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 15 Jun 2009 16:10:01 +0200 Subject: [Freeipa-devel] Re: [PATCH] Change plugins2 using find_entries to support incomplete (truncated) search results. In-Reply-To: <4A32BACF.5000106@redhat.com> References: <4A325673.3010406@redhat.com> <4A32BACF.5000106@redhat.com> Message-ID: <4A365639.7070407@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> I forgot to include this in [PATCHES] Add support for incomplete >> (truncated) search results. >> >> Note that this patch won't apply until baseldap.py and plugins using >> it get pushed. >> >> Patch 0002: Change plugins2 using find_entries to support incomplete >> (truncated) search results. >> >> Pavel > > nack. > > I've only really looked closely at user2 but I think this applies to all > the plugins. > > In output_for_cli() you split out entries and truncated but continue to > use results when displaying and counting the entries. > > rob My mistake, here's a fixed patch. It should also apply right away - no dependencies anymore. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Change-plugins2-using-find_entries-to-support-incomp.patch Type: application/mbox Size: 13072 bytes Desc: not available URL: From pzuna at redhat.com Mon Jun 15 14:11:44 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 15 Jun 2009 16:11:44 +0200 Subject: [Freeipa-devel] Re: [PATCHES] Add new set of base classes for plugins using LDAP. In-Reply-To: <4A2FEEB7.6090100@redhat.com> References: <4A2FABEE.3020300@redhat.com> <4A2FD6FB.5000308@redhat.com> <4A2FE45C.3090708@redhat.com> <4A2FEEB7.6090100@redhat.com> Message-ID: <4A3656A0.1020907@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> Rob Crittenden wrote: >>> Pavel Zuna wrote: >>>> I rewritten the patches I posted last week according to the feedback >>>> I got. >>>> >>>> The changes are: >>>> - all the functionality specific to LDAP plugin base classes has >>>> been removed from Object and crud base classes. >>>> - there is now 2 types of callbacks: pre_callbacks (called before >>>> passing data to python-ldap throught the LDAP backend) and >>>> post_callbacks (called after getting output from python-ldap) >>>> - some bug fixes >>>> >>>> Patch 0006: Modify PluginProxy to use __public__ defined in derived >>>> classes instead of base classes. >>> >>> ack >>> >>>> >>>> Patch 0007: Add 'parent_key' kwarg in Param class. >>> >>> ack, still not super happy with the variable name but since I can't >>> come up with anything better we'll stick with it :-) >>> >>>> >>>> Patch 0008: Make get_dn parameter list more generic. Fix Attribute >>>> name regex. >>>> >>>> The old name regex made it impossible to have Attribute instances >>>> with names composed of more than two words separated by underscores. >>> >>> ack >>> >>>> >>>> Patch 0009: Generate crud.Search arguments with get_args. >>>> >>>> (This might not be required, but I wanted to make sure arguments are >>>> generated properly in subclasses.) >>> >>> ack >>> >>>> >>>> (Patch 0010 is in a separate e-mail at Martin's request.) >>>> >>>> Patch 0011: Add new set of base classes for plugins using LDAP. >>> >>> nack. The reason that 2 values are returned in a list via the search >>> in the current backend (and v1) is so you can tell whether a search >>> failed because it exceeded either the size or time limits. We called >>> this a "truncated" search. We return as much as we can though. I >>> think we should retain this capability, even if we do it slightly >>> differently. >> I played a bit with python-ldap and the only way to do this is to make >> an asynchronous search, then pull the entries one by one. I don't know >> what the common size/time limits are on DS, but pulling thousands of >> entries one by one didn't seem like a good idea. Although maybe it's >> not such a big deal as I think. > > Well, no guarantee that they will be returned one by one but yes, you > need to continue a looping read until all the results are returned. You > wouldn't end up pulling thousands of records unless the admin set the > limits that high. > > But it does provide a nice degraded operation so that rather than > getting a cryptic error message about limits being exceeded they get > something to look at. > >> At this point, if some limit is exceeded, an exception is raised and >> the user needs to narrow down his search criteria. If we want to >> retain the 'truncated' search capability, I'll implement it, but it >> will require small changes in a lot of places. If this is the only >> complain about the new bases classes, I think they should be pushed - >> the problem is actually in the LDAP backend itself. >> > > It is actually fairly fundamental because it changes the data coming > back out of the find commands. Rather than a list of entries it will be > a tuple with the first value being the number of entries returned and > the list of entries. > > rob I did some re-basing and here's patch 0011 with truncated search results support. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-new-set-of-base-classes-for-plugins-using-LDAP.patch Type: application/mbox Size: 12707 bytes Desc: not available URL: From pzuna at redhat.com Mon Jun 15 14:24:29 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 15 Jun 2009 16:24:29 +0200 Subject: [Freeipa-devel] [PATCH] 232 add topics and commands argument to help In-Reply-To: <4A329017.6090404@redhat.com> References: <4A329017.6090404@redhat.com> Message-ID: <4A36599D.4050409@redhat.com> Rob Crittenden wrote: > Adds 2 new arguments to help command: > > ipa help topics will show all topics > ipa help commands will list all available commands > > rob > ack. Pavel From rcritten at redhat.com Mon Jun 15 14:39:49 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Jun 2009 10:39:49 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Add support for incomplete (truncated) search results. In-Reply-To: <4A3655E9.3050402@redhat.com> References: <4A3255A1.4050307@redhat.com> <4A32672C.7040503@redhat.com> <4A3273E5.8030402@redhat.com> <4A3274E5.1030402@redhat.com> <4A3277B0.3000306@redhat.com> <4A32A9A3.1090806@redhat.com> <4A3655E9.3050402@redhat.com> Message-ID: <4A365D35.5050201@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Z?na wrote: >>> Rob Crittenden wrote: >>>> Pavel Z?na wrote: >>>>> Rob Crittenden wrote: >>>>>> Pavel Zuna wrote: >>>>>>> Patch 0001: Add support for incomplete (truncated) search results. >>>>>>> >>>>>>> ldap2 didn't have the capability to return search results when a >>>>>>> DS limitation got exceeded (an exception was raised). >>>>>>> >>>>>>> Pavel >>>>>> >>>>>> I think truncated should be initialized to False, not None. It >>>>>> looks like this could actually be transported across XML-RPC and I >>>>>> don't believe we've enabled the NULL option (and I'd rather avoid >>>>>> doing so). >>>>>> >>>>>> If this is ok I can make this change before committing the patch. >>>>>> >>>>>> rob >>>>> >>>>> It is set to None, because otherwise it gets encoded into a string >>>>> by the decode_retval decorator. If that's a problem I'll rework >>>>> decode_retval. >>>>> >>>>> Pavel >>>> >>>> Well, in general it would be nice if we could return booleans as >>>> welll, that is a supported XML-RPC data type. >>>> >>>> rob >>>> >>> >>> The decode_retval decorator currently decodes everything returned by >>> the decorated function into the python unicode type except None >>> (unless configured otherwise). There is no option to only decode a >>> certain part, but it shouldn't be hard to rework it to be similar to >>> encode_args. I didn't think of this, because it is only used by >>> find_entries at this point. >>> >>> Pavel >> >> Why convert int, bool, long, etc into a unicode at all? Why not just >> return them as-is? >> >> rob >> > No reason really - I was just converting everything. I removed the > conversion of non-string scalar types. Here's an updated patch. > > Pavel Still doesn't work. I get the error on the server-side: ipa: ERROR: non-public: TypeError: ("python built-in type expected, got '%s'", ) My diff to your pathc looks like: diff --git a/ipalib/encoder.py b/ipalib/encoder.py index f5899a4..9d9d735 100644 --- a/ipalib/encoder.py +++ b/ipalib/encoder.py @@ -126,8 +126,8 @@ class Encoder(object): return self.encoder_settings.decode_postprocessor( var.decode(self.encoder_settings.decode_from) ) - # elif isinstance(var, (bool, float, int, long)): - # return self.encoder_settings.decode_postprocessor(unicode(var)) + elif isinstance(var, (bool, float, int, long)): + return var elif isinstance(var, list): return [self.decode(m) for m in var] elif isinstance(var, tuple): Can I fix this before committing or is it going to subtly break something else? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Mon Jun 15 14:48:06 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 15 Jun 2009 16:48:06 +0200 Subject: [Freeipa-devel] Re: [PATCHES] Add support for incomplete (truncated) search results. In-Reply-To: <4A365D35.5050201@redhat.com> References: <4A3255A1.4050307@redhat.com> <4A32672C.7040503@redhat.com> <4A3273E5.8030402@redhat.com> <4A3274E5.1030402@redhat.com> <4A3277B0.3000306@redhat.com> <4A32A9A3.1090806@redhat.com> <4A3655E9.3050402@redhat.com> <4A365D35.5050201@redhat.com> Message-ID: <4A365F26.7000206@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> Rob Crittenden wrote: >>> Pavel Z?na wrote: >>>> Rob Crittenden wrote: >>>>> Pavel Z?na wrote: >>>>>> Rob Crittenden wrote: >>>>>>> Pavel Zuna wrote: >>>>>>>> Patch 0001: Add support for incomplete (truncated) search results. >>>>>>>> >>>>>>>> ldap2 didn't have the capability to return search results when a >>>>>>>> DS limitation got exceeded (an exception was raised). >>>>>>>> >>>>>>>> Pavel >>>>>>> >>>>>>> I think truncated should be initialized to False, not None. It >>>>>>> looks like this could actually be transported across XML-RPC and >>>>>>> I don't believe we've enabled the NULL option (and I'd rather >>>>>>> avoid doing so). >>>>>>> >>>>>>> If this is ok I can make this change before committing the patch. >>>>>>> >>>>>>> rob >>>>>> >>>>>> It is set to None, because otherwise it gets encoded into a string >>>>>> by the decode_retval decorator. If that's a problem I'll rework >>>>>> decode_retval. >>>>>> >>>>>> Pavel >>>>> >>>>> Well, in general it would be nice if we could return booleans as >>>>> welll, that is a supported XML-RPC data type. >>>>> >>>>> rob >>>>> >>>> >>>> The decode_retval decorator currently decodes everything returned by >>>> the decorated function into the python unicode type except None >>>> (unless configured otherwise). There is no option to only decode a >>>> certain part, but it shouldn't be hard to rework it to be similar to >>>> encode_args. I didn't think of this, because it is only used by >>>> find_entries at this point. >>>> >>>> Pavel >>> >>> Why convert int, bool, long, etc into a unicode at all? Why not just >>> return them as-is? >>> >>> rob >>> >> No reason really - I was just converting everything. I removed the >> conversion of non-string scalar types. Here's an updated patch. >> >> Pavel > > Still doesn't work. I get the error on the server-side: > > ipa: ERROR: non-public: TypeError: ("python built-in type expected, got > '%s'", ) > > My diff to your pathc looks like: > > diff --git a/ipalib/encoder.py b/ipalib/encoder.py > index f5899a4..9d9d735 100644 > --- a/ipalib/encoder.py > +++ b/ipalib/encoder.py > @@ -126,8 +126,8 @@ class Encoder(object): > return self.encoder_settings.decode_postprocessor( > var.decode(self.encoder_settings.decode_from) > ) > - # elif isinstance(var, (bool, float, int, long)): > - # return > self.encoder_settings.decode_postprocessor(unicode(var)) > + elif isinstance(var, (bool, float, int, long)): > + return var > elif isinstance(var, list): > return [self.decode(m) for m in var] > elif isinstance(var, tuple): > > Can I fix this before committing or is it going to subtly break > something else? > > rob > Sure, it won't break anything. Pavel From pzuna at redhat.com Mon Jun 15 14:50:43 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 15 Jun 2009 16:50:43 +0200 Subject: [Freeipa-devel] Re: [PATCHES] Add support for incomplete (truncated) search results. In-Reply-To: <4A365F26.7000206@redhat.com> References: <4A3255A1.4050307@redhat.com> <4A32672C.7040503@redhat.com> <4A3273E5.8030402@redhat.com> <4A3274E5.1030402@redhat.com> <4A3277B0.3000306@redhat.com> <4A32A9A3.1090806@redhat.com> <4A3655E9.3050402@redhat.com> <4A365D35.5050201@redhat.com> <4A365F26.7000206@redhat.com> Message-ID: <4A365FC3.5040409@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> Rob Crittenden wrote: >>>> Pavel Z?na wrote: >>>>> Rob Crittenden wrote: >>>>>> Pavel Z?na wrote: >>>>>>> Rob Crittenden wrote: >>>>>>>> Pavel Zuna wrote: >>>>>>>>> Patch 0001: Add support for incomplete (truncated) search results. >>>>>>>>> >>>>>>>>> ldap2 didn't have the capability to return search results when >>>>>>>>> a DS limitation got exceeded (an exception was raised). >>>>>>>>> >>>>>>>>> Pavel >>>>>>>> >>>>>>>> I think truncated should be initialized to False, not None. It >>>>>>>> looks like this could actually be transported across XML-RPC and >>>>>>>> I don't believe we've enabled the NULL option (and I'd rather >>>>>>>> avoid doing so). >>>>>>>> >>>>>>>> If this is ok I can make this change before committing the patch. >>>>>>>> >>>>>>>> rob >>>>>>> >>>>>>> It is set to None, because otherwise it gets encoded into a >>>>>>> string by the decode_retval decorator. If that's a problem I'll >>>>>>> rework decode_retval. >>>>>>> >>>>>>> Pavel >>>>>> >>>>>> Well, in general it would be nice if we could return booleans as >>>>>> welll, that is a supported XML-RPC data type. >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> The decode_retval decorator currently decodes everything returned >>>>> by the decorated function into the python unicode type except None >>>>> (unless configured otherwise). There is no option to only decode a >>>>> certain part, but it shouldn't be hard to rework it to be similar >>>>> to encode_args. I didn't think of this, because it is only used by >>>>> find_entries at this point. >>>>> >>>>> Pavel >>>> >>>> Why convert int, bool, long, etc into a unicode at all? Why not just >>>> return them as-is? >>>> >>>> rob >>>> >>> No reason really - I was just converting everything. I removed the >>> conversion of non-string scalar types. Here's an updated patch. >>> >>> Pavel >> >> Still doesn't work. I get the error on the server-side: >> >> ipa: ERROR: non-public: TypeError: ("python built-in type expected, >> got '%s'", ) >> >> My diff to your pathc looks like: >> >> diff --git a/ipalib/encoder.py b/ipalib/encoder.py >> index f5899a4..9d9d735 100644 >> --- a/ipalib/encoder.py >> +++ b/ipalib/encoder.py >> @@ -126,8 +126,8 @@ class Encoder(object): >> return self.encoder_settings.decode_postprocessor( >> var.decode(self.encoder_settings.decode_from) >> ) >> - # elif isinstance(var, (bool, float, int, long)): >> - # return >> self.encoder_settings.decode_postprocessor(unicode(var)) >> + elif isinstance(var, (bool, float, int, long)): >> + return var >> elif isinstance(var, list): >> return [self.decode(m) for m in var] >> elif isinstance(var, tuple): >> >> Can I fix this before committing or is it going to subtly break >> something else? >> >> rob >> > Sure, it won't break anything. > > Pavel > Thanks to your e-mail, I also noticed there's '%'s missing when printing errors. You can add them as well, if you don't I'll do it in a future patch anyway. Pavel From rcritten at redhat.com Mon Jun 15 15:18:48 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Jun 2009 11:18:48 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Add support for incomplete (truncated) search results. In-Reply-To: <4A365FC3.5040409@redhat.com> References: <4A3255A1.4050307@redhat.com> <4A32672C.7040503@redhat.com> <4A3273E5.8030402@redhat.com> <4A3274E5.1030402@redhat.com> <4A3277B0.3000306@redhat.com> <4A32A9A3.1090806@redhat.com> <4A3655E9.3050402@redhat.com> <4A365D35.5050201@redhat.com> <4A365F26.7000206@redhat.com> <4A365FC3.5040409@redhat.com> Message-ID: <4A366658.7020309@redhat.com> Pavel Zuna wrote: > Pavel Zuna wrote: >> Rob Crittenden wrote: >>> Pavel Zuna wrote: >>>> Rob Crittenden wrote: >>>>> Pavel Z?na wrote: >>>>>> Rob Crittenden wrote: >>>>>>> Pavel Z?na wrote: >>>>>>>> Rob Crittenden wrote: >>>>>>>>> Pavel Zuna wrote: >>>>>>>>>> Patch 0001: Add support for incomplete (truncated) search >>>>>>>>>> results. >>>>>>>>>> >>>>>>>>>> ldap2 didn't have the capability to return search results when >>>>>>>>>> a DS limitation got exceeded (an exception was raised). >>>>>>>>>> >>>>>>>>>> Pavel >>>>>>>>> >>>>>>>>> I think truncated should be initialized to False, not None. It >>>>>>>>> looks like this could actually be transported across XML-RPC >>>>>>>>> and I don't believe we've enabled the NULL option (and I'd >>>>>>>>> rather avoid doing so). >>>>>>>>> >>>>>>>>> If this is ok I can make this change before committing the patch. >>>>>>>>> >>>>>>>>> rob >>>>>>>> >>>>>>>> It is set to None, because otherwise it gets encoded into a >>>>>>>> string by the decode_retval decorator. If that's a problem I'll >>>>>>>> rework decode_retval. >>>>>>>> >>>>>>>> Pavel >>>>>>> >>>>>>> Well, in general it would be nice if we could return booleans as >>>>>>> welll, that is a supported XML-RPC data type. >>>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> The decode_retval decorator currently decodes everything returned >>>>>> by the decorated function into the python unicode type except None >>>>>> (unless configured otherwise). There is no option to only decode a >>>>>> certain part, but it shouldn't be hard to rework it to be similar >>>>>> to encode_args. I didn't think of this, because it is only used by >>>>>> find_entries at this point. >>>>>> >>>>>> Pavel >>>>> >>>>> Why convert int, bool, long, etc into a unicode at all? Why not >>>>> just return them as-is? >>>>> >>>>> rob >>>>> >>>> No reason really - I was just converting everything. I removed the >>>> conversion of non-string scalar types. Here's an updated patch. >>>> >>>> Pavel >>> >>> Still doesn't work. I get the error on the server-side: >>> >>> ipa: ERROR: non-public: TypeError: ("python built-in type expected, >>> got '%s'", ) >>> >>> My diff to your pathc looks like: >>> >>> diff --git a/ipalib/encoder.py b/ipalib/encoder.py >>> index f5899a4..9d9d735 100644 >>> --- a/ipalib/encoder.py >>> +++ b/ipalib/encoder.py >>> @@ -126,8 +126,8 @@ class Encoder(object): >>> return self.encoder_settings.decode_postprocessor( >>> var.decode(self.encoder_settings.decode_from) >>> ) >>> - # elif isinstance(var, (bool, float, int, long)): >>> - # return >>> self.encoder_settings.decode_postprocessor(unicode(var)) >>> + elif isinstance(var, (bool, float, int, long)): >>> + return var >>> elif isinstance(var, list): >>> return [self.decode(m) for m in var] >>> elif isinstance(var, tuple): >>> >>> Can I fix this before committing or is it going to subtly break >>> something else? >>> >>> rob >>> >> Sure, it won't break anything. >> >> Pavel >> > Thanks to your e-mail, I also noticed there's '%'s missing when printing > errors. You can add them as well, if you don't I'll do it in a future > patch anyway. > > Pavel Ok, I just fixed the return part, we can address the rest in a future patch. Pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Jun 15 15:19:14 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Jun 2009 11:19:14 -0400 Subject: [Freeipa-devel] Re: [PATCH] Change plugins2 using find_entries to support incomplete (truncated) search results. In-Reply-To: <4A365639.7070407@redhat.com> References: <4A325673.3010406@redhat.com> <4A32BACF.5000106@redhat.com> <4A365639.7070407@redhat.com> Message-ID: <4A366672.6080208@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> I forgot to include this in [PATCHES] Add support for incomplete >>> (truncated) search results. >>> >>> Note that this patch won't apply until baseldap.py and plugins using >>> it get pushed. >>> >>> Patch 0002: Change plugins2 using find_entries to support incomplete >>> (truncated) search results. >>> >>> Pavel >> >> nack. >> >> I've only really looked closely at user2 but I think this applies to >> all the plugins. >> >> In output_for_cli() you split out entries and truncated but continue >> to use results when displaying and counting the entries. >> >> rob > My mistake, here's a fixed patch. It should also apply right away - no > dependencies anymore. > > Pavel > Ack, pushed to master rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Jun 15 15:19:49 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Jun 2009 11:19:49 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Add new set of base classes for plugins using LDAP. In-Reply-To: <4A3656A0.1020907@redhat.com> References: <4A2FABEE.3020300@redhat.com> <4A2FD6FB.5000308@redhat.com> <4A2FE45C.3090708@redhat.com> <4A2FEEB7.6090100@redhat.com> <4A3656A0.1020907@redhat.com> Message-ID: <4A366695.8080101@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> Rob Crittenden wrote: >>>> Pavel Zuna wrote: >>>>> I rewritten the patches I posted last week according to the >>>>> feedback I got. >>>>> >>>>> The changes are: >>>>> - all the functionality specific to LDAP plugin base classes has >>>>> been removed from Object and crud base classes. >>>>> - there is now 2 types of callbacks: pre_callbacks (called before >>>>> passing data to python-ldap throught the LDAP backend) and >>>>> post_callbacks (called after getting output from python-ldap) >>>>> - some bug fixes >>>>> >>>>> Patch 0006: Modify PluginProxy to use __public__ defined in derived >>>>> classes instead of base classes. >>>> >>>> ack >>>> >>>>> >>>>> Patch 0007: Add 'parent_key' kwarg in Param class. >>>> >>>> ack, still not super happy with the variable name but since I can't >>>> come up with anything better we'll stick with it :-) >>>> >>>>> >>>>> Patch 0008: Make get_dn parameter list more generic. Fix Attribute >>>>> name regex. >>>>> >>>>> The old name regex made it impossible to have Attribute instances >>>>> with names composed of more than two words separated by underscores. >>>> >>>> ack >>>> >>>>> >>>>> Patch 0009: Generate crud.Search arguments with get_args. >>>>> >>>>> (This might not be required, but I wanted to make sure arguments >>>>> are generated properly in subclasses.) >>>> >>>> ack >>>> >>>>> >>>>> (Patch 0010 is in a separate e-mail at Martin's request.) >>>>> >>>>> Patch 0011: Add new set of base classes for plugins using LDAP. >>>> >>>> nack. The reason that 2 values are returned in a list via the search >>>> in the current backend (and v1) is so you can tell whether a search >>>> failed because it exceeded either the size or time limits. We called >>>> this a "truncated" search. We return as much as we can though. I >>>> think we should retain this capability, even if we do it slightly >>>> differently. >>> I played a bit with python-ldap and the only way to do this is to >>> make an asynchronous search, then pull the entries one by one. I >>> don't know what the common size/time limits are on DS, but pulling >>> thousands of entries one by one didn't seem like a good idea. >>> Although maybe it's not such a big deal as I think. >> >> Well, no guarantee that they will be returned one by one but yes, you >> need to continue a looping read until all the results are returned. >> You wouldn't end up pulling thousands of records unless the admin set >> the limits that high. >> >> But it does provide a nice degraded operation so that rather than >> getting a cryptic error message about limits being exceeded they get >> something to look at. >> >>> At this point, if some limit is exceeded, an exception is raised and >>> the user needs to narrow down his search criteria. If we want to >>> retain the 'truncated' search capability, I'll implement it, but it >>> will require small changes in a lot of places. If this is the only >>> complain about the new bases classes, I think they should be pushed - >>> the problem is actually in the LDAP backend itself. >>> >> >> It is actually fairly fundamental because it changes the data coming >> back out of the find commands. Rather than a list of entries it will >> be a tuple with the first value being the number of entries returned >> and the list of entries. >> >> rob > > I did some re-basing and here's patch 0011 with truncated search results > support. > > Pavel Ack, pushed to master. I do wonder if the pre/post callbacks should be moved up a level so they are part of the general framework but we can argue that later. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Mon Jun 15 15:59:56 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 15 Jun 2009 11:59:56 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Implement gettext framework for server and tools Message-ID: <4A366FFC.3090405@redhat.com> $TOPIC -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Create-gettext-framework-for-SSSD-daemon.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Jun 15 17:11:20 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Jun 2009 13:11:20 -0400 Subject: [Freeipa-devel] Re: [PATCH] Add conversion of attribute name synonyms when generating modlists. In-Reply-To: <4A3654E9.70802@redhat.com> References: <4A3256F6.1010306@redhat.com> <4A326AEF.5070902@redhat.com> <4A327627.7010405@redhat.com> <4A327925.4020106@redhat.com> <4A327C15.3040309@redhat.com> <4A328BAD.8060801@redhat.com> <4A3654E9.70802@redhat.com> Message-ID: <4A3680B8.6060205@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Z?na wrote: >>> Rob Crittenden wrote: >>>> Pavel Z?na wrote: >>>>> Rob Crittenden wrote: >>>>>> Pavel Zuna wrote: >>>>>>> Patch 0003: Add conversion of attribute name synonyms when >>>>>>> generating modlists. >>>>>>> >>>>>>> Fixes the bug with 'localityname' in host plugins and prevents >>>>>>> similar bugs from happening. >>>>>>> >>>>>>> Pavel >>>>>> >>>>>> I'm not sure I understand this patch. What is the purpose of >>>>>> preferred_names? It looks that if this is set the the translation >>>>>> doesn't actually happen (and this is always set). >>>>>> >>>>>> rob >>>>> >>>>> If preferred_names evaluate to True (if not None and not and empty >>>>> list), then all attribute names equivalent to those in preferred >>>>> names are converted to them. Otherwise all attributes are converted >>>>> to their preferred synonym according to the schema. >>>>> >>>>> For example: >>>>> >>>>> a = {'locality': 'Brno'} >>>>> ldap.convert_attr_synonyms(a, ['localityname']) >>>>> # a == {'localityname': 'Brno'} >>>>> ldap.convert_attr_synonyms(a) >>>>> # a == {'l': 'Brno'} >>>>> >>>>> I did it this way, so when generating a modlist, we can convert >>>>> attributes as returned by python-ldap to what the plugin uses. >>>>> >>>>> Pavel >>>>> >>>> >>>> Ok, this is where I got confused. You don't actually make that >>>> second call (without the preferred_names) anywhere in the patch. >>>> >>>> I'm not sure we need to do the preferred name though, we'll still >>>> end up with extra MOD operations this way. Take an example: >>>> >>>> I add a host: >>>> >>>> % ipa host-add --locality=Brno h1.example.com >>>> >>>> When the record is added 389 is going to change the attribute to 'l'. >>>> >>>> dn: fqdn=h1.example.com,cn=computers,cn=accounts,dc=example,dc=com >>>> cn: h1.example.com >>>> fqdn: h1.example.com >>>> l: Brno >>>> >>>> >>>> The machine moves so I modify the entry: >>>> >>>> % ipa host-mod --locality=Berlin h1.example.com >>>> >>>> Your first call will leave the attribute as localityname and it will >>>> try to compare it to 'l', right? So it is still going to add a new >>>> value. >>>> >>>> rob >>>> >>> >>> If converting entry attributes received from *-mod commands, then >>> yes. But I took another approach to it. When generating a modlist, I >>> first retrieve the original entry attributes and convert their names >>> this way: >>> >>> ldap.convert_attr_synonyms(original_entry_attrs, new_entry_attrs.keys()) >>> >>> It doesn't matter if I convert the original entry attributes or the >>> new attributes before making the comparison, but the later is a bit >>> faster, because there's always more attributes in the original entry >>> (resulting in more iterations when performing the conversion). >>> >>> Oh, and it only works for plugins2, because it all happens inside ldap2. >>> >>> Pavel >> >> Ok, that makes sense but you didn't include this call in the patch. Do >> you need to make an updated patch? >> >> rob >> > I think I did, it's hidden in comments. ;-) > > 47 @@ -477,6 +503,8 @@ class ldap2(CrudBackend, Encoder): > 48 # we could call search_s directly, but this saves a lot of > code at > 49 # the expense of a little bit of performace > 50 entry_attrs_old = self.encode(entry_attrs_old) > 51 + # we also need to make sure that attribute names match > 52 + self.convert_attr_synonyms(entry_attrs_old, > entry_attrs.keys()) > 53 # generate modlist, we don't want any MOD_REPLACE operations > 54 # to handle simultaneous updates better > 55 modlist = [] > > Pavel No, I saw that but didn't quite grok what it was doing, I was assuming you'd do the reverse, change the incoming data to match the server. As you say, it doesn't really matter which one we choose. Can you beef up the comment to say what you said above, that you are converting the existing entry attribute names to match the current names for the purposes of generating a modlist? ack and pushed to master. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Mon Jun 15 17:38:28 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 15 Jun 2009 13:38:28 -0400 Subject: [Freeipa-devel] [Fwd: [Freeipa-users] [PATCH][SSSD] Install SysV script as executable] Message-ID: <4A368714.7020206@redhat.com> Sent this to the wrong list... -------- Original Message -------- Subject: [Freeipa-users] [PATCH][SSSD] Install SysV script as executable Date: Mon, 15 Jun 2009 13:33:31 -0400 From: Stephen Gallagher To: freeipa-users at redhat.com We had the SysV init script in Makefile.am as _DATA rather than _SCRIPTS. There was also a special permission exception made in sssd.spec.in which has now been rolled back. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Make-SysV-script-install-executable.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Attached Message Part URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Jun 15 18:01:59 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Jun 2009 14:01:59 -0400 Subject: [Freeipa-devel] [PATCH] 233 use class variable for SSL Message-ID: <4A368C97.1010200@redhat.com> Use a class variable to indicate SSL usage instead of using ldap.get_option(). On my Fedora 9 system this was causing the service to fail within the python-ldap library. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-233-ldap2.patch Type: application/mbox Size: 1738 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Jun 15 18:02:46 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Jun 2009 14:02:46 -0400 Subject: [Freeipa-devel] [PATCH] 232 add topics and commands argument to help In-Reply-To: <4A36599D.4050409@redhat.com> References: <4A329017.6090404@redhat.com> <4A36599D.4050409@redhat.com> Message-ID: <4A368CC6.8040708@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Adds 2 new arguments to help command: >> >> ipa help topics will show all topics >> ipa help commands will list all available commands >> >> rob >> > ack. > > Pavel pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Jun 15 18:09:55 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Jun 2009 14:09:55 -0400 Subject: [Freeipa-devel] [PATCH] 229 set shell return value Message-ID: <4A368E73.3080104@redhat.com> Returning the exception value doesn't work because a shell return value is in the range of 0-255. The default return value is 1 which means "something went wrong." The only specific return value implemented so far is 2 which is "not found". rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-229-exit.patch Type: application/mbox Size: 2959 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Jun 15 18:56:56 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Jun 2009 14:56:56 -0400 Subject: [Freeipa-devel] what about IPA operational logging? In-Reply-To: <4A329E65.5080602@redhat.com> References: <4A329E65.5080602@redhat.com> Message-ID: <4A369978.7010206@redhat.com> Dmitri Pal wrote: > Hi, > > In IPA we have kerberos logs, DS logs, web logs, CA logs etc. > They are all subsystem specific and disjoint. I think we need an IPA log > that will contain things like: > > a) Object (meaning user, host, map, group, HBAC rule) was modified > (added/deleted/edited may be even viewed) > b) Certificate issued/revoked/refreshed > c) Entity authenticated > d) Password changed > e) Policy changed > f) Configuration changed > > This is a much better feed than many low level logs. It can be > correlated with low level logs if needed but for system monitoring it is > best. > > That means that we should start thinking about logging into one log from > all those components. > The ultimate goal will be to emit the ELAPI events and forward them > directly to the audit subsystem. > This is not for v2 but let us keep this in mind for v3. > The IPA server logs to the Apache server logs. We do some limited reporting presently, mostly for debugging purposes but it can tell you what functions were called and with what arguments. We can customize that for audit logging as needed. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Mon Jun 15 22:25:13 2009 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 15 Jun 2009 18:25:13 -0400 Subject: [Freeipa-devel] What we can do better? Message-ID: <4A36CA49.9090005@redhat.com> Hello, We are looking for some ideas about potential improvements to the processes we use in the IPA project and information we share. What would be really helpful for you? Realistically we can't do everything so this is an attempt to identify the most important improvements we can make in a sort term. Here are some options that came to mind. Feel free to share your own ideas! Wiki: - More information on wiki - More detailed information on wiki - More high level information on wiki - Better information organization on wiki - More relevant information on Wiki - ... Process: - More discussion in emails on the list - Weekly/monthly digest of the work/decisions/design changes? - Share who does what during current month - More discussions on the IRC - ... -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Mon Jun 15 22:49:14 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 15 Jun 2009 18:49:14 -0400 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin In-Reply-To: <4A36500D.3030804@redhat.com> References: <4A2D6F73.7040206@redhat.com> <4A36500D.3030804@redhat.com> Message-ID: <1245106154.14254.62.camel@localhost.localdomain> On Mon, 2009-06-15 at 15:43 +0200, Sumit Bose wrote: > Simo, can you please review the tevent_req stuff. If > I've done it right I will try and change the waitpid call to > tevent_req. Nope, not right according to the strict style. Catch me on IRC tomorrow and we will go through an example. Simo. -- Simo Sorce * Red Hat, Inc * New York From pzuna at redhat.com Tue Jun 16 12:49:53 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 16 Jun 2009 14:49:53 +0200 Subject: [Freeipa-devel] [PATCH] Switch LDAP backend for plugins. Message-ID: <4A3794F1.2010506@redhat.com> Dear freeipa-devel, these patches make a step by step switch between LDAP backends for plugins. I think the names are descriptive enough. After they get into the tree, old plugins won't be available anymore and plugins2 will take their place. Patch 0001: Delete plugins using old LDAP backend. Patch 0002: Always use new LDAP backend when creating context. Patch 0003: Remove all references to use_ldap2. Patch 0004: Remove use_ldap2 constant. Patch 0005: Rename plugins2 files (remove '2' suffix). Patch 0006: Rename plugins2 to plugins. By the way, there's still two plugins2 waiting to get acked, namely: HBAC and automount Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Delete-plugins-using-old-LDAP-backend.patch Type: application/mbox Size: 139060 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Always-use-new-LDAP-backend-when-creating-context.patch Type: application/mbox Size: 871 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Remove-all-references-to-use_ldap2.patch Type: application/mbox Size: 24702 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Remove-use_ldap2-constant.patch Type: application/mbox Size: 2009 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Rename-plugins2-files-remove-2-suffix.patch Type: application/mbox Size: 4120 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Rename-plugins2-to-plugins.patch Type: application/mbox Size: 36644 bytes Desc: not available URL: From pronix.service at gmail.com Tue Jun 16 13:07:06 2009 From: pronix.service at gmail.com (dima vasiletc) Date: Tue, 16 Jun 2009 17:07:06 +0400 Subject: [Freeipa-devel] SSL Library Error: -12271 SSL client cannot verify your certificate Message-ID: <4A3798FA.5020608@gmail.com> Hello all encryption connections finished with error (Error code: sec_error_reused_issuer_and_serial) And server write to log SSL Library Error: -12271 SSL client cannot verify your certificate First i think need check dns querys. I see many A querys for example.com May be i must regenerate certificate ? Where i can read about that . Thanks. -- ? ?????????, ??????? From rcritten at redhat.com Tue Jun 16 13:12:08 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 16 Jun 2009 09:12:08 -0400 Subject: [Freeipa-devel] SSL Library Error: -12271 SSL client cannot verify your certificate In-Reply-To: <4A3798FA.5020608@gmail.com> References: <4A3798FA.5020608@gmail.com> Message-ID: <4A379A28.5070304@redhat.com> dima vasiletc wrote: > Hello > all encryption connections finished with error (Error code: > sec_error_reused_issuer_and_serial) > And server write to log SSL Library Error: -12271 SSL client cannot > verify your certificate > First i think need check dns querys. > I see many A querys for example.com > May be i must regenerate certificate ? Where i can read about that . > Thanks. > You're seeing this in Firefox, right? Did you recently re-install freeIPA? You probably just need to remove the CA and server from your browser security database: Edit->Preferences->Advanced->View Certificates Look under 3 tabs, Servers, Authorities and Others for "IPA Test Certificate Authority" or specific references to your IPA web server and delete them. Restarting your browser is probably a good idea too, then it should work fine. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Tue Jun 16 13:27:14 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 16 Jun 2009 15:27:14 +0200 Subject: [Freeipa-devel] Re: [PATCH] Switch LDAP backend for plugins. In-Reply-To: <4A3794F1.2010506@redhat.com> References: <4A3794F1.2010506@redhat.com> Message-ID: <4A379DB2.8020204@redhat.com> Pavel Zuna wrote: > Dear freeipa-devel, > these patches make a step by step switch between LDAP backends for > plugins. I think the names are descriptive enough. After they get into > the tree, old plugins won't be available anymore and plugins2 will take > their place. > > Patch 0001: Delete plugins using old LDAP backend. > > Patch 0002: Always use new LDAP backend when creating context. > > Patch 0003: Remove all references to use_ldap2. > > Patch 0004: Remove use_ldap2 constant. > > Patch 0005: Rename plugins2 files (remove '2' suffix). > > Patch 0006: Rename plugins2 to plugins. > > > By the way, there's still two plugins2 waiting to get acked, namely: > HBAC and automount > > Pavel I forgot about basegroup2 references in taskgroup plugin... Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Replace-references-to-basegroup2-in-taskgroup-plugin.patch Type: application/mbox Size: 3017 bytes Desc: not available URL: From rcritten at redhat.com Tue Jun 16 13:31:47 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 16 Jun 2009 09:31:47 -0400 Subject: [Freeipa-devel] Re: [PATCH] Switch LDAP backend for plugins. In-Reply-To: <4A379DB2.8020204@redhat.com> References: <4A3794F1.2010506@redhat.com> <4A379DB2.8020204@redhat.com> Message-ID: <4A379EC3.9040300@redhat.com> Pavel Zuna wrote: > Pavel Zuna wrote: >> Dear freeipa-devel, >> these patches make a step by step switch between LDAP backends for >> plugins. I think the names are descriptive enough. After they get into >> the tree, old plugins won't be available anymore and plugins2 will >> take their place. >> >> Patch 0001: Delete plugins using old LDAP backend. >> >> Patch 0002: Always use new LDAP backend when creating context. >> >> Patch 0003: Remove all references to use_ldap2. >> >> Patch 0004: Remove use_ldap2 constant. >> >> Patch 0005: Rename plugins2 files (remove '2' suffix). >> >> Patch 0006: Rename plugins2 to plugins. >> >> >> By the way, there's still two plugins2 waiting to get acked, namely: >> HBAC and automount >> >> Pavel > > I forgot about basegroup2 references in taskgroup plugin... > > Pavel Before we can proceed with this you also need to: - rename create to add and delete to del - get the tests working Note that the tests will rely heavily on how the data is presented so we need to work out the returned-as tuples or as scalars question first. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pronix.service at gmail.com Tue Jun 16 13:35:54 2009 From: pronix.service at gmail.com (dima vasiletc) Date: Tue, 16 Jun 2009 17:35:54 +0400 Subject: [Freeipa-devel] SSL Library Error: -12271 SSL client cannot verify your certificate In-Reply-To: <4A379A28.5070304@redhat.com> References: <4A3798FA.5020608@gmail.com> <4A379A28.5070304@redhat.com> Message-ID: <4A379FBA.8030808@gmail.com> On 06/16/2009 05:12 PM, Rob Crittenden wrote: > dima vasiletc wrote: >> Hello >> all encryption connections finished with error (Error code: >> sec_error_reused_issuer_and_serial) >> And server write to log SSL Library Error: -12271 SSL client cannot >> verify your certificate >> First i think need check dns querys. >> I see many A querys for example.com >> May be i must regenerate certificate ? Where i can read about that . >> Thanks. >> > > You're seeing this in Firefox, right? Did you recently re-install > freeIPA? > > You probably just need to remove the CA and server from your browser > security database: > > Edit->Preferences->Advanced->View Certificates > > Look under 3 tabs, Servers, Authorities and Others for "IPA Test > Certificate Authority" or specific references to your IPA web server > and delete them. Restarting your browser is probably a good idea too, > then it should work fine. > > rob Thanks i found ipa test certificate and remove it. After restart browser all fixed. -- ? ?????????, ??????? From sgallagh at redhat.com Tue Jun 16 14:26:25 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 16 Jun 2009 10:26:25 -0400 Subject: [Freeipa-devel] [Fwd: [Freeipa-users] [PATCH][SSSD] Install SysV script as executable] In-Reply-To: <4A368714.7020206@redhat.com> References: <4A368714.7020206@redhat.com> Message-ID: <4A37AB91.400@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/15/2009 01:38 PM, Stephen Gallagher wrote: > Sent this to the wrong list... > > -------- Original Message -------- > Subject: [Freeipa-users] [PATCH][SSSD] Install SysV script as executable > Date: Mon, 15 Jun 2009 13:33:31 -0400 > From: Stephen Gallagher > To: freeipa-users at redhat.com > > We had the SysV init script in Makefile.am as _DATA rather than _SCRIPTS. > > There was also a special permission exception made in sssd.spec.in which > has now been rolled back. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Pushed under one-liner rule. (Well, two lines) - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAko3q40ACgkQeiVVYja6o6PznQCgk8awNVkRscF7MvvX25stw6uc pJAAnjz36IzdaSs7oAUSDtboev20s7l+ =b5/f -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Tue Jun 16 14:55:26 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 16 Jun 2009 16:55:26 +0200 Subject: [Freeipa-devel] [PATCH] Fix Encoder.decode test. Message-ID: <4A37B25E.3040005@redhat.com> Patch 0001: Fix Encoder.decode test. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-Encoder.decode-test.patch Type: application/mbox Size: 928 bytes Desc: not available URL: From pzuna at redhat.com Tue Jun 16 14:56:37 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 16 Jun 2009 16:56:37 +0200 Subject: [Freeipa-devel] [PATCH] Rename *-create/*-delete commands to *-add/*-del respectively. Message-ID: <4A37B2A5.9070906@redhat.com> Patch 0002: Rename *-create/*-delete commands to *-add/*-del respectively. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Rename-create-delete-commands-to-add-del-res.patch Type: application/mbox Size: 14662 bytes Desc: not available URL: From rcritten at redhat.com Tue Jun 16 18:04:34 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 16 Jun 2009 14:04:34 -0400 Subject: [Freeipa-devel] [PATCH] fix ipa_webgui on F11 Message-ID: <4A37DEB2.5080802@redhat.com> ipa-webgui is in freeIPA v1.2.1 is failing to start on Fedora 11 because it is importing the wrong python-cherrypy when both python-cherrypy and python-cherrypy2 are installed. This patch includes 2 fixes. The first is for that issue and the second I suspect is related to python 2.6. We open the log file in ipa_webgui so we can report any failures of importing TurboGears. We close the log before starting TG. The way we were shutting down the logging worked in python 2.4 and 2.5 but doesn't work in 2.6 so I came up with another method, run through the log handlers and close them that way. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: webui.patch Type: application/mbox Size: 721 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Tue Jun 16 19:21:25 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 16 Jun 2009 15:21:25 -0400 Subject: [Freeipa-devel] [SSSD][PATCHES] Control exported symbols Message-ID: <4A37F0B5.2030008@redhat.com> 0001-0002: Adds a configure option '--with-aux-info' to enable -aux-info output of .c as .o.X 0003-0004: Adds an export map for sssd_be and the sss_client libraries to control the exposed function list. In this patch, the map exposes all functions. We will trim it down once the ABI gets more stable. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Add-with-aux-info-config-option-to-SSSD-daemon.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-Add-with-aux-info-config-option-to-SSS-client.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0003-Control-sssd_be-exported-functions.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0004-Control-sss_client-exports.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From sgallagh at redhat.com Tue Jun 16 19:29:03 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 16 Jun 2009 15:29:03 -0400 Subject: [Freeipa-devel] [SSSD][PATCHES] Control exported symbols In-Reply-To: <4A37F0B5.2030008@redhat.com> References: <4A37F0B5.2030008@redhat.com> Message-ID: <4A37F27F.8090507@redhat.com> On 06/16/2009 03:21 PM, Stephen Gallagher wrote: > 0001-0002: Adds a configure option '--with-aux-info' to enable -aux-info > output of .c as .o.X > > 0003-0004: Adds an export map for sssd_be and the sss_client libraries > to control the exposed function list. In this patch, the map exposes all > functions. We will trim it down once the ABI gets more stable. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel During a discussion on IRC, I realized that we already had an available exports file for NSS. I have updated the fourth patch accordingly. (Attached). -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0004-Control-sss_client-exports.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From ssorce at redhat.com Tue Jun 16 19:31:50 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 16 Jun 2009 15:31:50 -0400 Subject: [Freeipa-devel] [SSSD][PATCHES] Control exported symbols In-Reply-To: <4A37F27F.8090507@redhat.com> References: <4A37F0B5.2030008@redhat.com> <4A37F27F.8090507@redhat.com> Message-ID: <1245180710.14254.118.camel@localhost.localdomain> On Tue, 2009-06-16 at 15:29 -0400, Stephen Gallagher wrote: > On 06/16/2009 03:21 PM, Stephen Gallagher wrote: > > 0001-0002: Adds a configure option '--with-aux-info' to enable -aux-info > > output of .c as .o.X > > > > 0003-0004: Adds an export map for sssd_be and the sss_client libraries > > to control the exposed function list. In this patch, the map exposes all > > functions. We will trim it down once the ABI gets more stable. > During a discussion on IRC, I realized that we already had an available > exports file for NSS. I have updated the fourth patch accordingly. > (Attached). Ack to all 4 patches. Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Tue Jun 16 19:45:18 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 16 Jun 2009 15:45:18 -0400 Subject: [Freeipa-devel] [SSSD][PATCHES] Control exported symbols In-Reply-To: <1245180710.14254.118.camel@localhost.localdomain> References: <4A37F0B5.2030008@redhat.com> <4A37F27F.8090507@redhat.com> <1245180710.14254.118.camel@localhost.localdomain> Message-ID: <4A37F64E.4010603@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/16/2009 03:31 PM, Simo Sorce wrote: > On Tue, 2009-06-16 at 15:29 -0400, Stephen Gallagher wrote: >> On 06/16/2009 03:21 PM, Stephen Gallagher wrote: >>> 0001-0002: Adds a configure option '--with-aux-info' to enable -aux-info >>> output of .c as .o.X >>> >>> 0003-0004: Adds an export map for sssd_be and the sss_client libraries >>> to control the exposed function list. In this patch, the map exposes all >>> functions. We will trim it down once the ABI gets more stable. > >> During a discussion on IRC, I realized that we already had an available >> exports file for NSS. I have updated the fourth patch accordingly. >> (Attached). > > Ack to all 4 patches. > > Simo. > Pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAko39kkACgkQeiVVYja6o6O0uwCeKW7cgYNJKoSFledbBaha62O6 R7kAoKpUu0q1H3LNYJTccPKrqGAOrms9 =HpMS -----END PGP SIGNATURE----- From rcritten at redhat.com Tue Jun 16 20:10:30 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 16 Jun 2009 16:10:30 -0400 Subject: [Freeipa-devel] Re: [PATCH] Add automount plugin port to new LDAP backend. In-Reply-To: <4A2FAD5B.6060401@redhat.com> References: <4A2FAD5B.6060401@redhat.com> Message-ID: <4A37FC36.1050300@redhat.com> Pavel Zuna wrote: > Patch 0013: Add automount plugin port to new LDAP backend. > > Pavel There are some problems with this port from the old mechanism. I'm ok with renaming the functions I suppose, we'll have to see through usage which one is better. But it doesn't seem to actually be working. automount2-tofiles doesn't work at all and automount2-create-indirect doesn't create the maps properly. I was originally a little worried that when deleting a map you were removing the connection to the parent in the pre callback but it looks like the keys aren't being removed either. I think the parent connection should be removed after the entry is removed. Can you take another look? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Jun 16 20:17:02 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 16 Jun 2009 16:17:02 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Add HBAC plugin port to new LDAP backend. In-Reply-To: <4A2FAF6F.5080501@redhat.com> References: <4A2FAF6F.5080501@redhat.com> Message-ID: <4A37FDBE.2010709@redhat.com> Pavel Zuna wrote: > I think this plugin is a good demonstration of what the new base classes > for plugins using LDAP can do. The old plugin was considerebaly longer > and a lot more complex. > > Patch 0015: Add GeneralisedTime parameter type. Not sure if it is a Queens english vs American english but shouldn't generalized be spelled with a 'z' instead of an 's' at the end? > > I moved time checking code from the old plugin and made a new > auto-validating Param type. > > Patch 0016: Add HBAC plugin port to new LDAP backend. Looks ok, ack once we work out the spelling. rob > > Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From davido at redhat.com Tue Jun 16 23:04:51 2009 From: davido at redhat.com (David O'Brien) Date: Wed, 17 Jun 2009 09:04:51 +1000 Subject: [Freeipa-devel] Re: [PATCHES] Add HBAC plugin port to new LDAP backend. In-Reply-To: <4A37FDBE.2010709@redhat.com> References: <4A2FAF6F.5080501@redhat.com> <4A37FDBE.2010709@redhat.com> Message-ID: <4A382513.2000301@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> I think this plugin is a good demonstration of what the new base >> classes for plugins using LDAP can do. The old plugin was >> considerebaly longer and a lot more complex. >> >> Patch 0015: Add GeneralisedTime parameter type. > > Not sure if it is a Queens english vs American english but shouldn't > generalized be spelled with a 'z' instead of an 's' at the end? All RH documentation uses US English - and consequently "z" here - so it would be nice if the docstrings, parameter names, etc., followed suit wherever possible. /David > >> >> I moved time checking code from the old plugin and made a new >> auto-validating Param type. >> >> Patch 0016: Add HBAC plugin port to new LDAP backend. > > > Looks ok, ack once we work out the spelling. > > rob > >> >> Pavel > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- David O'Brien IPA Content Author Red Hat Asia Pacific +61 7 3514 8189 "The most valuable of all talents is that of never using two words when one will do." Thomas Jefferson From ssorce at redhat.com Wed Jun 17 04:28:05 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 17 Jun 2009 00:28:05 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Add HBAC plugin port to new LDAP backend. In-Reply-To: <4A382513.2000301@redhat.com> References: <4A2FAF6F.5080501@redhat.com> <4A37FDBE.2010709@redhat.com> <4A382513.2000301@redhat.com> Message-ID: <1245212885.14254.122.camel@localhost.localdomain> On Wed, 2009-06-17 at 09:04 +1000, David O'Brien wrote: > Rob Crittenden wrote: > > Pavel Zuna wrote: > >> I think this plugin is a good demonstration of what the new base > >> classes for plugins using LDAP can do. The old plugin was > >> considerebaly longer and a lot more complex. > >> > >> Patch 0015: Add GeneralisedTime parameter type. > > > > Not sure if it is a Queens english vs American english but shouldn't > > generalized be spelled with a 'z' instead of an 's' at the end? > All RH documentation uses US English - and consequently "z" here - so it > would be nice if the docstrings, parameter names, etc., followed suit > wherever possible. This referes to an LDAP attribute type, we need to use the same name used in the schema/RFCs even if it was spelled generalixed :-) (And yes I think it is GeneralizedTime) Simo. -- Simo Sorce * Red Hat, Inc * New York From davido at redhat.com Wed Jun 17 05:05:38 2009 From: davido at redhat.com (David O'Brien) Date: Wed, 17 Jun 2009 15:05:38 +1000 Subject: [Freeipa-devel] Re: [PATCHES] Add HBAC plugin port to new LDAP backend. In-Reply-To: <1245212885.14254.122.camel@localhost.localdomain> References: <4A2FAF6F.5080501@redhat.com> <4A37FDBE.2010709@redhat.com> <4A382513.2000301@redhat.com> <1245212885.14254.122.camel@localhost.localdomain> Message-ID: <4A3879A2.7000304@redhat.com> Simo Sorce wrote: > On Wed, 2009-06-17 at 09:04 +1000, David O'Brien wrote: > >> Rob Crittenden wrote: >> >>> Pavel Zuna wrote: >>> >>>> I think this plugin is a good demonstration of what the new base >>>> classes for plugins using LDAP can do. The old plugin was >>>> considerebaly longer and a lot more complex. >>>> >>>> Patch 0015: Add GeneralisedTime parameter type. >>>> >>> Not sure if it is a Queens english vs American english but shouldn't >>> generalized be spelled with a 'z' instead of an 's' at the end? >>> >> All RH documentation uses US English - and consequently "z" here - so it >> would be nice if the docstrings, parameter names, etc., followed suit >> wherever possible. >> > > This referes to an LDAP attribute type, we need to use the same name > used in the schema/RFCs even if it was spelled generalixed :-) > > (And yes I think it is GeneralizedTime) > > Simo. > > Yes, thought as much, hence the "wherever possible". We have enough "discussions", thankfully with minimal blood-letting, over spelling and style issues just in doc without getting too involved in the code side as well :-) -- David O'Brien IPA Content Author Red Hat Asia Pacific +61 7 3514 8189 "The most valuable of all talents is that of never using two words when one will do." Thomas Jefferson From sbose at redhat.com Wed Jun 17 11:20:07 2009 From: sbose at redhat.com (Sumit Bose) Date: Wed, 17 Jun 2009 13:20:07 +0200 Subject: [Freeipa-devel] [PATCH][SSSD] Implement gettext framework for server and tools In-Reply-To: <4A366FFC.3090405@redhat.com> References: <4A366FFC.3090405@redhat.com> Message-ID: <4A38D167.7040701@redhat.com> Am 15.06.2009 17:59, schrieb Stephen Gallagher: > $TOPIC > > ACK bye, Sumit From sgallagh at redhat.com Wed Jun 17 11:23:53 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 17 Jun 2009 07:23:53 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Implement gettext framework for server and tools In-Reply-To: <4A38D167.7040701@redhat.com> References: <4A366FFC.3090405@redhat.com> <4A38D167.7040701@redhat.com> Message-ID: <4A38D249.40206@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/17/2009 07:20 AM, Sumit Bose wrote: > Am 15.06.2009 17:59, schrieb Stephen Gallagher: >> $TOPIC >> >> > > ACK > > bye, > Sumit > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAko40kUACgkQeiVVYja6o6NLggCgnfmr16ofJAulBWPnpl3ZBcdW msYAoKqOx5OAEUfaq8KY4HTchON6fTOe =abOH -----END PGP SIGNATURE----- From rcritten at redhat.com Wed Jun 17 14:15:07 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 17 Jun 2009 10:15:07 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <1244728335.25513.49.camel@localhost.localdomain> References: <4A3027DD.5060107@redhat.com> <1244728335.25513.49.camel@localhost.localdomain> Message-ID: <4A38FA6B.9030606@redhat.com> Simo Sorce wrote: > On Wed, 2009-06-10 at 17:38 -0400, Rob Crittenden wrote: >> One feature we want to add to v2 is per-group password policy. The IPA >> password policy is implemented completely separately from the DS >> password policy (because it is the KDC that does the enforcement, AFAICT). >> >> Currently it finds the password policy by searching the base for >> objectClass=krbPwdPolicy. >> >> What I propose is to leave that, it will become the "global" password >> policy, and add an search before that to look for the pwdpolicysubentry >> attribute in the user. > > The only parts that enforce password policy in freeipa re really > kadmin.local and our password plugin. Initially we decide to go for the > MIT schema because we were unsure about letting kadmin run (it would > obey only the MIT krb schema). > But since we decided not to allow kadmin, and since kadmin.local is used > only to manage keytabs in the bootstrap process and in emergency cases, > I think we can easily drop that schema and fully embrace the DS one. Ok, I've been reading some code and it looks relatively straightforward, but I do have a couple of questions. What enforces an expired password? I assume the KDC currently does this enforcement. Do we want 389 doing this instead, using passwordExpirationTime? There are some special cases in the current code so I'm not sure if that still would apply. If we switch to the 389 password policy we may inherit certain capabilities and not necessarily in a good way. Password retry counts, for example, will be enforced by the server itself. I'm mostly concerned about where we will store the policies vs where the server will look for them. It could be that this sort of thing doesn't get applied evenly because we may end up storing it differently. I still have a lot of code to read. > It will require some work in the password plugin but nothing mind > blowing. Depends on your perspective I suppose :-) rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Wed Jun 17 14:27:25 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 17 Jun 2009 10:27:25 -0400 Subject: [Freeipa-devel] Some clarifications about IPA and SSSD Message-ID: <4A38FD4D.1030606@redhat.com> Hello, It seems that there is a fair bit of confusion about IPA and SSSD. It is to some extent my fault since the freeIPA site is not frequently updated and information is not well organized there. The site does not reflect the state of the project so I am planning a cleanup in August. Meanwhile I wanted to try to make things a bit clearer. Here are some Q & A. What is IPA 2.0 about? Originally we planned a lot [1] but as it usually happens things change and we reduced the scope a bit. It is not because we do not want to deliver the functionality but because it is just too much to chew in one release. Also our view of P and A parts of IPA changed a bit. For P we were originally thinking about a broader set of the system management capabilities. It turned out that there is a big overlap between what we were planning to do and some very flexible configuration management solutions that already exist. We decided not to reinvent the wheel and try to integrate with such solutions. To do this effectively it made sense to separate this effort form IPA v2 and do it a bit later focusing right now on I of API and A of IPA. In IPA v2 the P will be represented by robust centrally managed host based access control. The A of IPA is the audit server. From the very beginning we realized that it would make sense to build A in such a way that it can be installed independently from I of IPA. This independence allows different delivery schedules for audit server than for the I part of IPA that consists of KDC, DS and management framework. So IPA can be viewed as a group of related sub projects that might have different schedules. One of such sub projects is SSSD which stands for System Security Services Daemon. It is a client side framework that allows caching of the identity information for offline use and support of multiple sources of the identity information at the same time. There are some misconceptions about SSSD that I will comment on below. So here is the core list of features that IPA v2 project family will provide: I of IPA * Host Identity, host enrollment, host keytab provisioning * Integration with CA * Issuing certs and tracking certs that need auto renewal * More robust services management * New management framework, more flexible and extensible * Rich UI and CLI interfaces * NIS and DS to IPA migration with NIS support of legacy systems * Integration between IPA users, groups, hosts, host groups and netgroups for NIS * Automount as LDAP map and more... P of IPA * Host based access control A of IPA * Collection of the log files and individual events, delivery of them to the audit server and storage on the server for the analysis with the third party tools. We plan to build out tools in v3. The functionality that we want to deliver required a client component. But instead of building a specific IPA client we split the client side into common part that can be used with different identity solutions and specific IPA part. This common component is SSSD. It provides a framework for identity services. It allows multiple back ends. IPA is just one of them. Others would include LDAP, NIS, Local files. There is no limitation of what can be an identity provider. There are plans to make Samba winbind be a back end in future. Any third party authentication vendors are welcome to build their own identity provider back ends. SSSD solves several important issues. The first one is caching identity data for offline authentication and NSS lookups. Second is the ability to get data from multiple identity sources at the same time. There are other benefits that lay foundation for the future better user login experience and support of contemporary authentication methods and multi factor authentication policies. Does SSSD require IPA? No. SSSD can have other data providers. IPA is not required. We view the SSSD is a core part of an OS. There is already interest from some distributions to port it. We start with Fedora but it is just one of the distros we are targeting. SSSD is written in C. It does not have a lot of dependencies. Most of them have been already ported to different distros so broad support of SSSD is possible and realistic. Does IPA require SSSD? To take advantage of the full IPA v2 functionality SSSD is required. But it is clear that it is not possible to put SSSD everywhere. For the systems that can only support NIS IPA server will act asd a NIS server, for systems that can have pam_krb5 or pam_ldap and nss_ldap IPA can still be an authentication and identity server as it was in v1. What is relation between NSS_LDAP and SSSD? Nss_ldap is known to have performance and scalability issues. SSSD addresses these issues by creating a robust caching mechanism. However SSSD can't replace NSS_LDAP everywhere right away. It is unrealistic. This is one of the reasons why nss_ldap issues are still being addressed. It might appear that the two hands do not know what the other is doing. They actually do and we intentionally clean the old solution - nss_ldap , providing nss_ldapd for better performance and scalability, and build a new one - SSSD that will eventually replace the nss_ldap in a long run. Any feedback is welcome! [1] http://www.freeipa.org/page/V2BPRD Thank you, Dmitri Pal From ssorce at redhat.com Wed Jun 17 15:37:45 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 17 Jun 2009 11:37:45 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <4A38FA6B.9030606@redhat.com> References: <4A3027DD.5060107@redhat.com> <1244728335.25513.49.camel@localhost.localdomain> <4A38FA6B.9030606@redhat.com> Message-ID: <1245253065.14254.130.camel@localhost.localdomain> On Wed, 2009-06-17 at 10:15 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Wed, 2009-06-10 at 17:38 -0400, Rob Crittenden wrote: > >> One feature we want to add to v2 is per-group password policy. The IPA > >> password policy is implemented completely separately from the DS > >> password policy (because it is the KDC that does the enforcement, AFAICT). > >> > >> Currently it finds the password policy by searching the base for > >> objectClass=krbPwdPolicy. > >> > >> What I propose is to leave that, it will become the "global" password > >> policy, and add an search before that to look for the pwdpolicysubentry > >> attribute in the user. > > > > The only parts that enforce password policy in freeipa re really > > kadmin.local and our password plugin. Initially we decide to go for the > > MIT schema because we were unsure about letting kadmin run (it would > > obey only the MIT krb schema). > > But since we decided not to allow kadmin, and since kadmin.local is used > > only to manage keytabs in the bootstrap process and in emergency cases, > > I think we can easily drop that schema and fully embrace the DS one. > > Ok, I've been reading some code and it looks relatively straightforward, > but I do have a couple of questions. > > What enforces an expired password? I assume the KDC currently does this > enforcement. Do we want 389 doing this instead, using > passwordExpirationTime? There are some special cases in the current code > so I'm not sure if that still would apply. We should still store expiration times also in the attributes the KDC knows about, or we need to patch the ldap driver to look at the DS policy attributes. > If we switch to the 389 password policy we may inherit certain > capabilities and not necessarily in a good way. Password retry counts, > for example, will be enforced by the server itself. Not sure how that would work, the KDC doesn't tell DS anything about retries. Or am I missing something/misunderstanding here ? > I'm mostly concerned about where we will store the policies vs where the > server will look for them. It could be that this sort of thing doesn't > get applied evenly because we may end up storing it differently. I still > have a lot of code to read. Keep the questions coming, we need to make sure we don't forget any feature while transitioning :-) > > It will require some work in the password plugin but nothing mind > > blowing. > > Depends on your perspective I suppose :-) I guess so :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Jun 17 16:02:41 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 17 Jun 2009 12:02:41 -0400 Subject: [Freeipa-devel] per-group password policy proposal In-Reply-To: <1245253065.14254.130.camel@localhost.localdomain> References: <4A3027DD.5060107@redhat.com> <1244728335.25513.49.camel@localhost.localdomain> <4A38FA6B.9030606@redhat.com> <1245253065.14254.130.camel@localhost.localdomain> Message-ID: <4A3913A1.7020401@redhat.com> Simo Sorce wrote: > On Wed, 2009-06-17 at 10:15 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Wed, 2009-06-10 at 17:38 -0400, Rob Crittenden wrote: >>>> One feature we want to add to v2 is per-group password policy. The IPA >>>> password policy is implemented completely separately from the DS >>>> password policy (because it is the KDC that does the enforcement, AFAICT). >>>> >>>> Currently it finds the password policy by searching the base for >>>> objectClass=krbPwdPolicy. >>>> >>>> What I propose is to leave that, it will become the "global" password >>>> policy, and add an search before that to look for the pwdpolicysubentry >>>> attribute in the user. >>> The only parts that enforce password policy in freeipa re really >>> kadmin.local and our password plugin. Initially we decide to go for the >>> MIT schema because we were unsure about letting kadmin run (it would >>> obey only the MIT krb schema). >>> But since we decided not to allow kadmin, and since kadmin.local is used >>> only to manage keytabs in the bootstrap process and in emergency cases, >>> I think we can easily drop that schema and fully embrace the DS one. >> Ok, I've been reading some code and it looks relatively straightforward, >> but I do have a couple of questions. >> >> What enforces an expired password? I assume the KDC currently does this >> enforcement. Do we want 389 doing this instead, using >> passwordExpirationTime? There are some special cases in the current code >> so I'm not sure if that still would apply. > > We should still store expiration times also in the attributes the KDC > knows about, or we need to patch the ldap driver to look at the DS > policy attributes. I think we should keep it since this is sort of an IPA-only requirement. I guess I need to keep krbLastPwdChange as well then. >> If we switch to the 389 password policy we may inherit certain >> capabilities and not necessarily in a good way. Password retry counts, >> for example, will be enforced by the server itself. > > Not sure how that would work, the KDC doesn't tell DS anything about > retries. Or am I missing something/misunderstanding here ? People can still authenticate with simple auth. By using the DS password policy we could enable features like limiting the number of password retries. Note that we don't have to expose it though. In fact, this is probably a good thing. For example, when you add a new user their password starts out expired but they can still bind with LDAP single auth. My fear is that we'd be doing policy in 2 places and we'd need to be sure to keep several attributes in sync. There may be competing options as well. For example, DS has passwordMustChange which if set to on requires the user to change their password on first login or if DM has reset it. We do something similar already. >> I'm mostly concerned about where we will store the policies vs where the >> server will look for them. It could be that this sort of thing doesn't >> get applied evenly because we may end up storing it differently. I still >> have a lot of code to read. > > Keep the questions coming, we need to make sure we don't forget any > feature while transitioning :-) After reading some more it looks as if policy is pulled from the pwdpolicysubentry value so even if we use groups instead of storing it a sub entry we should be ok. > >>> It will require some work in the password plugin but nothing mind >>> blowing. >> Depends on your perspective I suppose :-) > > I guess so :-) > > Simo. > cheers rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Wed Jun 17 18:05:37 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 17 Jun 2009 14:05:37 -0400 Subject: [Freeipa-devel] [PATCHES][SSSD] Patches for supporting non-Fedora builds Message-ID: <4A393071.6020806@redhat.com> 0001: Remove -Werror from the build. This can be added manually during development, but it causes builds to fail on warnings when running older versions of GCC. These warnings will be addressed separately. 0002: Add configure check for libpcre > 7. Currently we are using some 7+ features. This causes the build to fail on RHEL 5, for example. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Do-not-treat-warnings-as-errors.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-Add-configure-check-for-PCRE-7.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From kwade at redhat.com Wed Jun 17 23:43:40 2009 From: kwade at redhat.com (Karsten Wade) Date: Wed, 17 Jun 2009 16:43:40 -0700 Subject: [Freeipa-devel] Community action plan In-Reply-To: <4A2FBE2F.20604@redhat.com> References: <20090610044952.GS4469@calliope.phig.org> <4A2FBE2F.20604@redhat.com> Message-ID: <20090617234340.GU7591@calliope.phig.org> On Wed, Jun 10, 2009 at 10:07:43AM -0400, Dmitri Pal wrote: > Hi Karsten, > > I am glad that we finally got someone who will help us to evolve into a > more open community. And thanks for taking this as an open discussion. (I've obviously got to funnel anything with PATCH in the subject from this list to a sub-folder, I keep losing the topics I am most interested in; sorry for the delay in response.) > But I want to talk about two main problems: > a) Technical problems > b) Procedural problems > > The technical problems are related to CLI and its signing. I do not see > big issue with following your suggestions about CLI and moving to Fedora > infrastructure. > > I personally do not have a strong opinion about it. I just know, > however, that freeIPA was launched outside of Fedora on purpose. > One of the reasons is to avoid affiliation with a specific distribution > and have a cross distribution community. We have not accomplished this > so I am open to trying a different approach but I would liek to hear > opinion of other developers on the matter. The most visible part of FreeIPA associated with Fedora is the code repository on fedorahosted.org. Getting hosting from a Linux distro is not unusual for a codebase, and there are a lot of packages in Fedora, Debian, OpenSUSE, Mandriva, and so on where the canonical project is hosted by one of those communities. The FreeIPA branding is strong enough to stand alone. This is worth keeping an eye on, but I don't think I'm too worried about that. > We can also improve the wiki and access to it. I do not see a big > problem there either. For increasing the potential for participation, that will help a lot. > With the documentation there are two parts - there is a development > documentation and user documentation. The user documentation written by > one doc person is the aggregated information from the development > documentation plus this doc person's own research and experiments. Right, I understand that model. The same Content Services team is now working in the Fedora community on pre-RHEL content, and while most of their work is still DocBook, they are learning how to utilize community work done via the wiki. So, there are some pathways FreeIPA can follow where Fedora has set or is setting a way forward, which won't interfere with the branding and should add to the experience for new contributors and users in general. > If we get a better quality of the original developer written > document and information we will solve biggest part of the problem > so I would start there. I see that, let's talk about that. Mozilla, for example, gained a lot of documentation from their own developers by making a wiki that was structured for them to document in to. The same developers who knew how but wouldn't check out and edit DocBook XML would edit a wiki page. The fact that we can snapshot that wiki in to DocBook is a good thing; translation, upload in to a stand-alone hosted project for collaboration (as we do with the other Linux content), etc. I keep driving back to the wiki here because it's an easy solution that could solve some of these developer documentation issues in ways that grow participation. > But the biggest problem is that we are running the project "semi-open". > We have IRC, email list and wiki. All possible information is exposed > there but it still not enough. And I would say that it is my fault. I > see several issues with me and with the team here: > a) I come from the corporate culture. I know how to run the project > efficiently if the development team is well defined and focused. I do > not know how to run projects in the open ended community. And we do not > have one so until no one from outside Red Hat gets involved I am running > the project as I see most efficient. This is chicken and egg problem. I > realize that while the project is run this way we might hardly get any > contributors but we will move on and operate as a well oiled mechanism. > Once we get someone involved we would have to adapt and adjust, but we > will not attract anybody until we change the way the project is run. This is true, and a very good self-analysis. I won't fool you; it does take change that has to include the team leaders. There are some practices that help, though. The basic idea is to i) make all information open and public unless there is a clear distinction that it is confidential/private; ii) put all that information in open and public locations. So, even if all you have are 1/2 of the developer docs and 1/3 of the roadmap written down somewhere, just moving all that to an open and public location is a good idea. Exposing everything helps _others_ write up to-do lists and start plucking the low and ripe fruit. > b) There is no culture of writing good designs or capturing information > one got in a research of the code. "Go read the code" paradigm IMO is > the key issue. But trying to change the attitude is like boiling the > ocean. We can still work hard on keeping the designs up to date and > pages updated. This would be a full time job. I do not have cycles to do > it. Unfortunately developers do not have cycles to maintain the design > pages too. I am open to suggestions here since I think that sufficient > developer documentation is crucial for community involvement and quality > of the software. I do not think that jumping around IRC logs, mail > threads and wiki pages is efficient. I doubt that anyone new would ever > go for such quest (until he is highly motivated for whatever reason). > There should be one place where any new person can get a good jumpstart > with the project including history of decision making, current status of > things and future direction. But who will do this? Again chicken and egg > problem: why would I spend cycles on this if nobody is reading; nobody > will read until it is sufficient. Yes, and part of the hard decision that we have to make at Red Hat is to lay the egg, early and often. This is really the responsibility of the core developers of a project, to get developer docs far enough that others can actually assist; it's a problem I'm sure you know that exists far beyond Red Hat. The kind of thing we might find right away is a community person interested in wrangling the documentation. With everyone following a page of naming rules and category conventions[1], we can create some structure and stubs that developers can fill out via the wiki in much shorter bursts than $other_methods. One thing I can do is create that structure to make it possible for a community docs wrangler to get easy and early success. > So the bold changes should be: > a) Solve technical problems > b) Work with developers on improving the developer documentation > c) Replace the manager Thankfully, as humans our thinking can evolve. Extinction isn't the only answer. :) - Karsten [1] Like these: https://fedoraproject.org/wiki/Help:Wiki_structure and some of these: https://fedoraproject.org/wiki/Help:Editing In particular, this that makes conversion to DocBook XML easier: https://fedoraproject.org/wiki/Help:Editing#Marking_Technical_Terms Heck, we can just borrow and adapt those. :) -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dpal at redhat.com Thu Jun 18 02:29:01 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 17 Jun 2009 22:29:01 -0400 Subject: [Freeipa-devel] Community action plan In-Reply-To: <20090617234340.GU7591@calliope.phig.org> References: <20090610044952.GS4469@calliope.phig.org> <4A2FBE2F.20604@redhat.com> <20090617234340.GU7591@calliope.phig.org> Message-ID: <4A39A66D.4000503@redhat.com> ... >> So the bold changes should be: >> a) Solve technical problems >> b) Work with developers on improving the developer documentation >> c) Replace the manager >> > > Thankfully, as humans our thinking can evolve. Extinction isn't the > only answer. :) > > Well, it seems my management have not made its mind about letting me go. That means I have to adapt. I have a lot of pressing issues related to Fedora 12 next month so I suspect I will hardly be able to change anything before August. In August I will start working on restructuring the wiki and cleaning it up. That is when the links below will become pretty handy. Thanks for those. Dmitri > - Karsten > > [1] Like these: > > https://fedoraproject.org/wiki/Help:Wiki_structure > > and some of these: > > https://fedoraproject.org/wiki/Help:Editing > > In particular, this that makes conversion to DocBook XML easier: > > https://fedoraproject.org/wiki/Help:Editing#Marking_Technical_Terms > > Heck, we can just borrow and adapt those. :) > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sbose at redhat.com Thu Jun 18 09:07:03 2009 From: sbose at redhat.com (Sumit Bose) Date: Thu, 18 Jun 2009 11:07:03 +0200 Subject: [Freeipa-devel] [PATCHES][SSSD] Patches for supporting non-Fedora builds In-Reply-To: <4A393071.6020806@redhat.com> References: <4A393071.6020806@redhat.com> Message-ID: <4A3A03B7.9040207@redhat.com> Am 17.06.2009 20:05, schrieb Stephen Gallagher: > 0001: Remove -Werror from the build. This can be added manually during > development, but it causes builds to fail on warnings when running older > versions of GCC. These warnings will be addressed separately. ACK > > 0002: Add configure check for libpcre > 7. Currently we are using some > 7+ features. This causes the build to fail on RHEL 5, for example. > Wouldn't it be more flexible to test for the feature? bye, Sumit From sbose at redhat.com Thu Jun 18 09:20:38 2009 From: sbose at redhat.com (Sumit Bose) Date: Thu, 18 Jun 2009 11:20:38 +0200 Subject: [Freeipa-devel] [PATCH] let .gitignore only filter autogenerated m4 files Message-ID: <4A3A06E6.9060602@redhat.com> Hi, this patch makes our own m4 files visible again. bye, Sumit -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-let-.gitignore-only-filter-autogenerated-m4-files.patch URL: From sgallagh at redhat.com Thu Jun 18 11:38:38 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 18 Jun 2009 07:38:38 -0400 Subject: [Freeipa-devel] [PATCHES][SSSD] Patches for supporting non-Fedora builds In-Reply-To: <4A3A03B7.9040207@redhat.com> References: <4A393071.6020806@redhat.com> <4A3A03B7.9040207@redhat.com> Message-ID: <4A3A273E.6020607@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/18/2009 05:07 AM, Sumit Bose wrote: > Am 17.06.2009 20:05, schrieb Stephen Gallagher: >> 0001: Remove -Werror from the build. This can be added manually during >> development, but it causes builds to fail on warnings when running older >> versions of GCC. These warnings will be addressed separately. > > ACK > >> 0002: Add configure check for libpcre > 7. Currently we are using some >> 7+ features. This causes the build to fail on RHEL 5, for example. >> > > Wouldn't it be more flexible to test for the feature? I would, but I'm not sure how to. The specific error that fails on RHEL5 is looking for a particular macro definition that is only available with version 7 on (PCRE_DUPNAMES). It's not a function call, so AC_CHECK_LIBS can't check it. Testing for the version was the only way I was sure it would work. > > bye, > Sumit - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAko6JzkACgkQeiVVYja6o6OYAwCgnLG34pZ4D1u+SXJeeTIUyK1M k8oAoKJh7uqqKkXKAji0MH7j21A4ICL6 =OZII -----END PGP SIGNATURE----- From sgallagh at redhat.com Thu Jun 18 11:39:10 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 18 Jun 2009 07:39:10 -0400 Subject: [Freeipa-devel] [PATCH] let .gitignore only filter autogenerated m4 files In-Reply-To: <4A3A06E6.9060602@redhat.com> References: <4A3A06E6.9060602@redhat.com> Message-ID: <4A3A275E.6000202@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/18/2009 05:20 AM, Sumit Bose wrote: > Hi, > > this patch makes our own m4 files visible again. > > bye, > Sumit > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Ack - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAko6J14ACgkQeiVVYja6o6NSegCfYTJ7+N5HQkddAhjbfe6wMZLb N7YAn1s7k8i5m61k24GqAO3r3AJczGqz =/k85 -----END PGP SIGNATURE----- From sbose at redhat.com Thu Jun 18 12:40:54 2009 From: sbose at redhat.com (Sumit Bose) Date: Thu, 18 Jun 2009 14:40:54 +0200 Subject: [Freeipa-devel] [PATCHES][SSSD] Patches for supporting non-Fedora builds In-Reply-To: <4A3A273E.6020607@redhat.com> References: <4A393071.6020806@redhat.com> <4A3A03B7.9040207@redhat.com> <4A3A273E.6020607@redhat.com> Message-ID: <4A3A35D6.9010005@redhat.com> Am 18.06.2009 13:38, schrieb Stephen Gallagher: > On 06/18/2009 05:07 AM, Sumit Bose wrote: >> Am 17.06.2009 20:05, schrieb Stephen Gallagher: >>> 0001: Remove -Werror from the build. This can be added manually during >>> development, but it causes builds to fail on warnings when running older >>> versions of GCC. These warnings will be addressed separately. >> ACK > >>> 0002: Add configure check for libpcre > 7. Currently we are using some >>> 7+ features. This causes the build to fail on RHEL 5, for example. >>> >> Wouldn't it be more flexible to test for the feature? > > I would, but I'm not sure how to. The specific error that fails on RHEL5 > is looking for a particular macro definition that is only available with > version 7 on (PCRE_DUPNAMES). It's not a function call, so AC_CHECK_LIBS > can't check it. Testing for the version was the only way I was sure it > would work. > As I have just learned it is planned to remove the pcre 7 feature (https://fedorahosted.org/sssd/ticket/61). ACK From sgallagh at redhat.com Thu Jun 18 12:43:09 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 18 Jun 2009 08:43:09 -0400 Subject: [Freeipa-devel] [PATCHES][SSSD] Patches for supporting non-Fedora builds In-Reply-To: <4A3A35D6.9010005@redhat.com> References: <4A393071.6020806@redhat.com> <4A3A03B7.9040207@redhat.com> <4A3A273E.6020607@redhat.com> <4A3A35D6.9010005@redhat.com> Message-ID: <4A3A365D.6080703@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/18/2009 08:40 AM, Sumit Bose wrote: > Am 18.06.2009 13:38, schrieb Stephen Gallagher: >> On 06/18/2009 05:07 AM, Sumit Bose wrote: >>> Am 17.06.2009 20:05, schrieb Stephen Gallagher: >>>> 0001: Remove -Werror from the build. This can be added manually during >>>> development, but it causes builds to fail on warnings when running older >>>> versions of GCC. These warnings will be addressed separately. >>> ACK >>>> 0002: Add configure check for libpcre > 7. Currently we are using some >>>> 7+ features. This causes the build to fail on RHEL 5, for example. >>>> >>> Wouldn't it be more flexible to test for the feature? >> I would, but I'm not sure how to. The specific error that fails on RHEL5 >> is looking for a particular macro definition that is only available with >> version 7 on (PCRE_DUPNAMES). It's not a function call, so AC_CHECK_LIBS >> can't check it. Testing for the version was the only way I was sure it >> would work. >> > > As I have just learned it is planned to remove the pcre 7 feature > (https://fedorahosted.org/sssd/ticket/61). > > ACK Pushed both to master. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAko6NlYACgkQeiVVYja6o6OLYgCcCsYjeF0Es75XcV8ftehn5DjQ KtUAoJAM7eOwXeU3pi6Duno8zD1+QBoq =xXHU -----END PGP SIGNATURE----- From sgallagh at redhat.com Thu Jun 18 15:32:32 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 18 Jun 2009 11:32:32 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Allow the use of custom CFLAGS on the make command line Message-ID: <4A3A5E10.6000608@redhat.com> Setting CFLAGS explicitly in configure.ac means that they would be overwritten when using e.g. make CFLAGS="-O0 -g" This replaces the explicit setting of CFLAGS with an AM_CONDITIONAL to have Makefile.am set these instead. Also fixes a missing #include that was coincidentally obscured because gcc's -O2 happened to be able to locate it. Setting -O0 revealed the problem. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Allow-the-use-of-custom-CFLAGS-on-the-make-command-l.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From mpcolino at gmail.com Thu Jun 18 16:10:58 2009 From: mpcolino at gmail.com (Miguel P.C.) Date: Thu, 18 Jun 2009 18:10:58 +0200 Subject: [Freeipa-devel] Self-intro: Karsten Wade In-Reply-To: <20090617234650.GA32180@calliope.phig.org> References: <20090529143950.GW4333@calliope.phig.org> <1243610488.7279.192.camel@localhost.localdomain> <20090617234650.GA32180@calliope.phig.org> Message-ID: Hi Karsten, Miguel, hello, thanks for your email; my apologies for the delay, I > forgot I hadn't replied. > No problem. > > > If you could share a bit of the info on your plans to grow this > > community beyond the RedHat environment, I'll be very pleased. > > It would be even better if you allow me to include some of that info > > in my PFM as a reference. Could that be possible?. > > > Yes, definitely, whatever I can do. Would you like to meet sometime > on #freeipa and discuss with me in more detail? > I'm so sorry, I had to give all the documents for the masters' final project on the 14th so, now that is over. Anyway, now I'm catching up with my current work but in a week or less I'll be glad to see if I can help with "communication tasks" around FreeIPA. > > - Karsten M* > > -- > Karsten 'quaid' Wade, Community Gardener > http://quaid.fedorapeople.org > AD0E0C41 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pzuna at redhat.com Thu Jun 18 17:30:58 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Thu, 18 Jun 2009 19:30:58 +0200 Subject: [Freeipa-devel] [PATCH] Fix bug in basegroup and passwd plugins (incorrect use of find_entry_by_attr). Message-ID: <4A3A79D2.7020404@redhat.com> Patch 0001: Fix bug in basegroup and passwd plugins (incorrect use of find_entry_attr). Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-bug-in-basegroup-and-passwd-plugins-incorrect-u.patch Type: application/mbox Size: 3617 bytes Desc: not available URL: From pzuna at redhat.com Thu Jun 18 17:31:30 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Thu, 18 Jun 2009 19:31:30 +0200 Subject: [Freeipa-devel] Re: [PATCH] Add automount plugin port to new LDAP backend. In-Reply-To: <4A37FC36.1050300@redhat.com> References: <4A2FAD5B.6060401@redhat.com> <4A37FC36.1050300@redhat.com> Message-ID: <4A3A79F2.3080303@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> Patch 0013: Add automount plugin port to new LDAP backend. >> >> Pavel > > There are some problems with this port from the old mechanism. > > I'm ok with renaming the functions I suppose, we'll have to see through > usage which one is better. Renaming was necessary, because Method to Object association is created according to plugin names. If we want an -add method for the automountkey object, its name has to start with 'automountkey'. > But it doesn't seem to actually be working. automount2-tofiles doesn't > work at all and automount2-create-indirect doesn't create the maps > properly. Yeah, looks like I didn't understand correctly how automount entries are organized in LDAP. > I was originally a little worried that when deleting a map you were > removing the connection to the parent in the pre callback but it looks > like the keys aren't being removed either. I think the parent connection > should be removed after the entry is removed. > > Can you take another look? > > rob I did an updated version. I also renamed the -create methods to -add, but forgot about -delete before making the commit. I will rename those later, the plugin name had to stay suffixed with 2 for now anyway. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-automount-plugin-port-to-new-LDAP-backend.patch Type: application/mbox Size: 9413 bytes Desc: not available URL: From rcritten at redhat.com Thu Jun 18 19:13:24 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Jun 2009 15:13:24 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix bug in basegroup and passwd plugins (incorrect use of find_entry_by_attr). In-Reply-To: <4A3A79D2.7020404@redhat.com> References: <4A3A79D2.7020404@redhat.com> Message-ID: <4A3A91D4.9010902@redhat.com> Pavel Z?na wrote: > Patch 0001: Fix bug in basegroup and passwd plugins (incorrect use of > find_entry_attr). > > Pavel Does this address the tests? I'm not comfortable moving forward with previous patches that this relies on until the updated plugins pass the minimal in-tree tests. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Jun 18 19:16:08 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 18 Jun 2009 15:16:08 -0400 Subject: [Freeipa-devel] [PATCH] fix ipa_webgui on F11 In-Reply-To: <4A37DEB2.5080802@redhat.com> References: <4A37DEB2.5080802@redhat.com> Message-ID: <1245352568.14254.142.camel@localhost.localdomain> On Tue, 2009-06-16 at 14:04 -0400, Rob Crittenden wrote: > ipa-webgui is in freeIPA v1.2.1 is failing to start on Fedora 11 > because > it is importing the wrong python-cherrypy when both python-cherrypy > and > python-cherrypy2 are installed. > > This patch includes 2 fixes. The first is for that issue and the > second > I suspect is related to python 2.6. We open the log file in > ipa_webgui > so we can report any failures of importing TurboGears. We close the > log > before starting TG. The way we were shutting down the logging worked > in > python 2.4 and 2.5 but doesn't work in 2.6 so I came up with another > method, run through the log handlers and close them that way. Ack. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Jun 18 19:38:30 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Jun 2009 15:38:30 -0400 Subject: [Freeipa-devel] Re: [PATCH] Add automount plugin port to new LDAP backend. In-Reply-To: <4A3A79F2.3080303@redhat.com> References: <4A2FAD5B.6060401@redhat.com> <4A37FC36.1050300@redhat.com> <4A3A79F2.3080303@redhat.com> Message-ID: <4A3A97B6.9010000@redhat.com> Pavel Z?na wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> Patch 0013: Add automount plugin port to new LDAP backend. >>> >>> Pavel >> >> There are some problems with this port from the old mechanism. >> >> I'm ok with renaming the functions I suppose, we'll have to see >> through usage which one is better. > Renaming was necessary, because Method to Object association is created > according to plugin names. If we want an -add method for the > automountkey object, its name has to start with 'automountkey'. > >> But it doesn't seem to actually be working. automount2-tofiles doesn't >> work at all and automount2-create-indirect doesn't create the maps >> properly. > Yeah, looks like I didn't understand correctly how automount entries are > organized in LDAP. > >> I was originally a little worried that when deleting a map you were >> removing the connection to the parent in the pre callback but it looks >> like the keys aren't being removed either. I think the parent >> connection should be removed after the entry is removed. >> >> Can you take another look? >> >> rob > I did an updated version. I also renamed the -create methods to -add, > but forgot about -delete before making the commit. I will rename those > later, the plugin name had to stay suffixed with 2 for now anyway. > > Pavel > Ok, better but not quite there yet. There is a typo in a variable name: --- a/ipalib/plugins/automount2.py +++ b/ipalib/plugins/automount2.py @@ -302,7 +302,7 @@ class automount2_tofiles(Command): automountmapname=info ) if keys_tmp: - keys[info] += keys_tmps + keys[info] += keys_tmp return (maps, keys) I can add an indirect map now and show maps the way they would look in files but it seems to show the maps multiple times, at least auto.master: $ ./ipa automount2-tofiles /etc/auto.master: /- /etc/auto.direct /stuf /etc/auto.master /things /etc/auto.things --------------------------- /etc/auto.direct: --------------------------- /etc/auto.master: /- auto.direct /stuf auto.master /things auto.things --------------------------- /etc/auto.things: /somewhere rw Also, automuntkey2-delete seems broken. I ran it and let it hang for a couple of minutes, not seeming to do anything. The DS logs have a lot of repeated searches: [18/Jun/2009:15:38:09 -0400] conn=951 op=180016 SRCH base="automountkey=/place2,automountmapname=auto.stuff,cn=automount,dc=example,dc=com" scope=1 filter="(objectClass=*)" attrs="" [18/Jun/2009:15:38:09 -0400] conn=951 op=180016 RESULT err=0 tag=101 nentries=0 etime=0 notes=U [18/Jun/2009:15:38:09 -0400] conn=951 op=180017 SRCH base="automountkey=/place2,automountmapname=auto.stuff,cn=automount,dc=example,dc=com" scope=1 filter="(objectClass=*)" attrs="" [18/Jun/2009:15:38:09 -0400] conn=951 op=180017 RESULT err=0 tag=101 nentries=0 etime=0 notes=U [18/Jun/2009:15:38:09 -0400] conn=951 op=180018 SRCH base="automountkey=/place2,automountmapname=auto.stuff,cn=automount,dc=example,dc=com" scope=1 filter="(objectClass=*)" attrs="" rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Jun 18 20:01:12 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 18 Jun 2009 16:01:12 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Allow the use of custom CFLAGS on the make command line In-Reply-To: <4A3A5E10.6000608@redhat.com> References: <4A3A5E10.6000608@redhat.com> Message-ID: <1245355272.14254.149.camel@localhost.localdomain> On Thu, 2009-06-18 at 11:32 -0400, Stephen Gallagher wrote: > Setting CFLAGS explicitly in configure.ac means that they would be > overwritten when using e.g. make CFLAGS="-O0 -g" > This replaces the explicit setting of CFLAGS with an > AM_CONDITIONAL to have Makefile.am set these instead. I would lean to think that being able to override the default CFLAGS with make CFLAGS="-O0 -g" is a feature not a bug. Is it not ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Jun 18 20:29:58 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Jun 2009 16:29:58 -0400 Subject: [Freeipa-devel] [PATCH] fix ipa_webgui on F11 In-Reply-To: <1245352568.14254.142.camel@localhost.localdomain> References: <4A37DEB2.5080802@redhat.com> <1245352568.14254.142.camel@localhost.localdomain> Message-ID: <4A3AA3C6.7090802@redhat.com> Simo Sorce wrote: > On Tue, 2009-06-16 at 14:04 -0400, Rob Crittenden wrote: >> ipa-webgui is in freeIPA v1.2.1 is failing to start on Fedora 11 >> because >> it is importing the wrong python-cherrypy when both python-cherrypy >> and >> python-cherrypy2 are installed. >> >> This patch includes 2 fixes. The first is for that issue and the >> second >> I suspect is related to python 2.6. We open the log file in >> ipa_webgui >> so we can report any failures of importing TurboGears. We close the >> log >> before starting TG. The way we were shutting down the logging worked >> in >> python 2.4 and 2.5 but doesn't work in 2.6 so I came up with another >> method, run through the log handlers and close them that way. > > Ack. > > Simo. > Pushed to ipa-1-2 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Fri Jun 19 11:14:16 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 19 Jun 2009 07:14:16 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Allow the use of custom CFLAGS on the make command line In-Reply-To: <1245355272.14254.149.camel@localhost.localdomain> References: <4A3A5E10.6000608@redhat.com> <1245355272.14254.149.camel@localhost.localdomain> Message-ID: <4A3B7308.40601@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/18/2009 04:01 PM, Simo Sorce wrote: > On Thu, 2009-06-18 at 11:32 -0400, Stephen Gallagher wrote: >> Setting CFLAGS explicitly in configure.ac means that they would be >> overwritten when using e.g. make CFLAGS="-O0 -g" >> This replaces the explicit setting of CFLAGS with an >> AM_CONDITIONAL to have Makefile.am set these instead. > > I would lean to think that being able to override the default CFLAGS > with make CFLAGS="-O0 -g" is a feature not a bug. > Is it not ? > > Simo. > I think you missed the point of this. That's the feature I was adding :) What it was doing before this point was replacing the following CFLAGS as well: - -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-qual - -Wcast-align -Wwrite-strings Now the CFLAGS= argument to make will append to those (overriding any conflicting ones such as -O2). - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAko7cwQACgkQeiVVYja6o6PTxACgnculeLsF0ZaNEwHLQwsQEl+v E4oAoJl5iR49Ia2VPMkqSY25Sumhzedf =XkaR -----END PGP SIGNATURE----- From sbose at redhat.com Fri Jun 19 11:39:26 2009 From: sbose at redhat.com (Sumit Bose) Date: Fri, 19 Jun 2009 13:39:26 +0200 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin In-Reply-To: <1245106154.14254.62.camel@localhost.localdomain> References: <4A2D6F73.7040206@redhat.com> <4A36500D.3030804@redhat.com> <1245106154.14254.62.camel@localhost.localdomain> Message-ID: <4A3B78EE.3090302@redhat.com> Am 16.06.2009 00:49, schrieb Simo Sorce: > On Mon, 2009-06-15 at 15:43 +0200, Sumit Bose wrote: >> Simo, can you please review the tevent_req stuff. If >> I've done it right I will try and change the waitpid call to >> tevent_req. > > Nope, not right according to the strict style. > Catch me on IRC tomorrow and we will go through an example. > Here is another try. Currently the tgt_req_* tevent_req is not really needed because the main pam handler could call read_pipe_* tvent_req directy. But I thought it might give us some more flexibility for future changes. bye, Sumit -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-added-kerberos-backend-with-tevent_req-event-handlin.patch URL: From sbose at redhat.com Fri Jun 19 11:50:34 2009 From: sbose at redhat.com (Sumit Bose) Date: Fri, 19 Jun 2009 13:50:34 +0200 Subject: [Freeipa-devel] [PATCH] add missing locale.h Message-ID: <4A3B7B8A.3060703@redhat.com> Hi, I found this when running make without -O2. bye, Sumit -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-add-missing-locale.h.patch URL: From sgallagh at redhat.com Fri Jun 19 12:06:13 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 19 Jun 2009 08:06:13 -0400 Subject: [Freeipa-devel] [PATCH] add missing locale.h In-Reply-To: <4A3B7B8A.3060703@redhat.com> References: <4A3B7B8A.3060703@redhat.com> Message-ID: <4A3B7F35.4070702@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/19/2009 07:50 AM, Sumit Bose wrote: > Hi, > > I found this when running make without -O2. > > bye, > Sumit > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel That's already fixed in the CFLAGS patch I submitted yesterday. I added #include to the sssd-i18n.h so any gettext-enabled source file will pick it up. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAko7fy4ACgkQeiVVYja6o6NOggCfVsDSLU/zFet9oFfiKghtfywV OJUAnRbCzvtc/Thrtu9zxuV9cCKWhw9d =r+QV -----END PGP SIGNATURE----- From sbose at redhat.com Fri Jun 19 12:14:43 2009 From: sbose at redhat.com (Sumit Bose) Date: Fri, 19 Jun 2009 14:14:43 +0200 Subject: [Freeipa-devel] [PATCH] add missing locale.h In-Reply-To: <4A3B7F35.4070702@redhat.com> References: <4A3B7B8A.3060703@redhat.com> <4A3B7F35.4070702@redhat.com> Message-ID: <4A3B8133.5040209@redhat.com> Am 19.06.2009 14:06, schrieb Stephen Gallagher: > On 06/19/2009 07:50 AM, Sumit Bose wrote: >> Hi, > >> I found this when running make without -O2. > >> bye, >> Sumit > > >> ------------------------------------------------------------------------ > >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > That's already fixed in the CFLAGS patch I submitted yesterday. I added > #include to the sssd-i18n.h so any gettext-enabled source > file will pick it up. > ah, sorry, I missed the last hunk of your patch. bye, Sumit From ssorce at redhat.com Fri Jun 19 13:22:29 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 19 Jun 2009 09:22:29 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Allow the use of custom CFLAGS on the make command line In-Reply-To: <4A3B7308.40601@redhat.com> References: <4A3A5E10.6000608@redhat.com> <1245355272.14254.149.camel@localhost.localdomain> <4A3B7308.40601@redhat.com> Message-ID: <1245417749.11682.1.camel@localhost.localdomain> On Fri, 2009-06-19 at 07:14 -0400, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 06/18/2009 04:01 PM, Simo Sorce wrote: > > On Thu, 2009-06-18 at 11:32 -0400, Stephen Gallagher wrote: > >> Setting CFLAGS explicitly in configure.ac means that they would be > >> overwritten when using e.g. make CFLAGS="-O0 -g" > >> This replaces the explicit setting of CFLAGS with an > >> AM_CONDITIONAL to have Makefile.am set these instead. > > > > I would lean to think that being able to override the default CFLAGS > > with make CFLAGS="-O0 -g" is a feature not a bug. > > Is it not ? > > > > Simo. > > > I think you missed the point of this. That's the feature I was adding :) > What it was doing before this point was replacing the following CFLAGS > as well: > - -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-qual > - -Wcast-align -Wwrite-strings > > Now the CFLAGS= argument to make will append to those (overriding any > conflicting ones such as -O2). Yeah I understood that, but I thought being able to completely override also the warnings might have been a feature. On a second thought though, better to always warn on issues so that developers don't get sloppy by suppress warnings and forgetting about them. Ack. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Fri Jun 19 13:26:12 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 19 Jun 2009 09:26:12 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Allow the use of custom CFLAGS on the make command line In-Reply-To: <1245417749.11682.1.camel@localhost.localdomain> References: <4A3A5E10.6000608@redhat.com> <1245355272.14254.149.camel@localhost.localdomain> <4A3B7308.40601@redhat.com> <1245417749.11682.1.camel@localhost.localdomain> Message-ID: <4A3B91F4.7040401@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/19/2009 09:22 AM, Simo Sorce wrote: > On Fri, 2009-06-19 at 07:14 -0400, Stephen Gallagher wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 06/18/2009 04:01 PM, Simo Sorce wrote: >>> On Thu, 2009-06-18 at 11:32 -0400, Stephen Gallagher wrote: >>>> Setting CFLAGS explicitly in configure.ac means that they would be >>>> overwritten when using e.g. make CFLAGS="-O0 -g" >>>> This replaces the explicit setting of CFLAGS with an >>>> AM_CONDITIONAL to have Makefile.am set these instead. >>> I would lean to think that being able to override the default CFLAGS >>> with make CFLAGS="-O0 -g" is a feature not a bug. >>> Is it not ? >>> >>> Simo. >>> >> I think you missed the point of this. That's the feature I was adding :) >> What it was doing before this point was replacing the following CFLAGS >> as well: >> - -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-qual >> - -Wcast-align -Wwrite-strings >> >> Now the CFLAGS= argument to make will append to those (overriding any >> conflicting ones such as -O2). > > Yeah I understood that, but I thought being able to completely override > also the warnings might have been a feature. > On a second thought though, better to always warn on issues so that > developers don't get sloppy by suppress warnings and forgetting about > them. > > Ack. > Pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAko7kewACgkQeiVVYja6o6OlRwCdHXOLH4M4bCV2eXbmzGbnsJ1H UakAnReQhNojpV5DbLzBG6e+9H/B0pSr =eHIP -----END PGP SIGNATURE----- From jhrozek at redhat.com Fri Jun 19 13:55:16 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 19 Jun 2009 15:55:16 +0200 Subject: [Freeipa-devel] [PATCH] Gettextize the sss_ tools Message-ID: <4A3B98C4.6060209@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The attached patch converts the static strings in the tools into gettext _("strings"). Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAko7mMQACgkQHsardTLnvCU9FACeM4iYBeQYwXngYnU0jW/qS7hI mjYAoMSeetSfi5ex6QXKpYXlf/ZH+GhH =baM2 -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Gettextize-the-sss_-tools.patch URL: From sgallagh at redhat.com Fri Jun 19 15:35:26 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 19 Jun 2009 11:35:26 -0400 Subject: [Freeipa-devel] [PATCHES][SSSD] Fix two segfaults related to config file reloading Message-ID: <4A3BB03E.1070702@redhat.com> 0001: This segfault was caused by only talloc_steal()ing the first entry in a linked list. The other entries were freed, causing a segfault the next time they were accessed. I've added a memory context for the whole linked list that can be passed to the new config in order to bring along all of the entries in the list. 0002: There is a race condition (that is fairly involved and will be dealt with separately) where signal_service_reload will attempt to signal a child process that does not yet have an active sbus channel. In that case, we'll just skip signaling it (since it won't get its initial configuration until it's up anyway). -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Fix-segfault-in-update_monitor_config.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-Protect-against-segfault-in-service_signal_reload.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From ssorce at redhat.com Fri Jun 19 15:50:25 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 19 Jun 2009 11:50:25 -0400 Subject: [Freeipa-devel] [PATCHES][SSSD] Fix two segfaults related to config file reloading In-Reply-To: <4A3BB03E.1070702@redhat.com> References: <4A3BB03E.1070702@redhat.com> Message-ID: <1245426625.11682.5.camel@localhost.localdomain> On Fri, 2009-06-19 at 11:35 -0400, Stephen Gallagher wrote: > 0001: This segfault was caused by only talloc_steal()ing the first > entry > in a linked list. The other entries were freed, causing a segfault the > next time they were accessed. I've added a memory context for the > whole > linked list that can be passed to the new config in order to bring > along > all of the entries in the list. ack, but remove the redundant domain->next = NULL before pushing > 0002: There is a race condition (that is fairly involved and will be > dealt with separately) where signal_service_reload will attempt to > signal a child process that does not yet have an active sbus channel. > In > that case, we'll just skip signaling it (since it won't get its > initial > configuration until it's up anyway). ack, but the debug statements say "deferring" while the function is actually skipping, please remove the "Deferring." part before pushing. Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Fri Jun 19 15:58:50 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 19 Jun 2009 11:58:50 -0400 Subject: [Freeipa-devel] [PATCHES][SSSD] Fix two segfaults related to config file reloading In-Reply-To: <1245426625.11682.5.camel@localhost.localdomain> References: <4A3BB03E.1070702@redhat.com> <1245426625.11682.5.camel@localhost.localdomain> Message-ID: <4A3BB5BA.2060504@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/19/2009 11:50 AM, Simo Sorce wrote: > On Fri, 2009-06-19 at 11:35 -0400, Stephen Gallagher wrote: >> 0001: This segfault was caused by only talloc_steal()ing the first >> entry >> in a linked list. The other entries were freed, causing a segfault the >> next time they were accessed. I've added a memory context for the >> whole >> linked list that can be passed to the new config in order to bring >> along >> all of the entries in the list. > > ack, but remove the redundant domain->next = NULL before pushing > >> 0002: There is a race condition (that is fairly involved and will be >> dealt with separately) where signal_service_reload will attempt to >> signal a child process that does not yet have an active sbus channel. >> In >> that case, we'll just skip signaling it (since it won't get its >> initial >> configuration until it's up anyway). > > ack, but the debug statements say "deferring" while the function is > actually skipping, please remove the "Deferring." part before pushing. > > Simo. > Pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAko7ta8ACgkQeiVVYja6o6NhCQCgjf3oVi85B6hIdolIXJ7xTtj1 s0YAn1s3VN8EUOaUKqwv6Ctrl47bd638 =BtnI -----END PGP SIGNATURE----- From jdennis at redhat.com Fri Jun 19 16:34:54 2009 From: jdennis at redhat.com (John Dennis) Date: Fri, 19 Jun 2009 12:34:54 -0400 Subject: [Freeipa-devel] C++ Style Guide Message-ID: <4A3BBE2E.6010801@redhat.com> Our coding style guides are referenced on our wiki here: http://freeipa.com/page/Contribute#Developer_Documentation However they do not discuss C++ style. Since I'm writing a fair amount of C++ code (in part forced by the fact the AMQP client code only has a C++ binding, not C) it's time define our style conventions for C++. I propose is following the Google C++ style guide: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml It seems reasonable and it's influential. It seems to follow many common conventions and eschews the junk associated with the Microsoft C++ conventions. Since I don't want to write a style guide from scratch and the Google C++ style guide seems like a reasonable pick I propose we just reference the Google guide and be done with it. Anybody have any problems with this proposal? Comments? Flames? If not I'll just update the wiki to point to the Google guide. P.S.: C and C++ are such different languages despite superficial similarities it would be inappropriate IMHO for our C++ style to derive from our C style guide, they should be independent reflecting the inherent differences between the languages. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sgallagh at redhat.com Fri Jun 19 16:38:33 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 19 Jun 2009 12:38:33 -0400 Subject: [Freeipa-devel] [SSSD] SSSD Release Process Message-ID: <4A3BBF09.6090505@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have created a page on the SSSD wiki: https://fedorahosted.org/sssd/wiki/ReleaseProcess to describe in detail the release process for the SSSD. I believe I have captured all of the main points, but if I have missed anything, please update the page or the attached discussion page. Regarding translations, my thought is that we should postpone committing updates to the .po and .pot files until the commit where we bump the version number just prior to signing the version tag. It will be easier to update these files once at release time, rather than pushing the updates each time an affected .c or .h file is changed. It is easy enough when building the code for a developer to run 'make dist' if they need access to the updated translations between releases. Discussion welcome. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAko7vwAACgkQeiVVYja6o6PTIACfQ/43DWtBPrUlelrs55Yjjf8A zzgAn1M4JvWucLg0WJHiE4y0kb2iI7Tr =aZMf -----END PGP SIGNATURE----- From sgallagh at redhat.com Fri Jun 19 16:40:57 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 19 Jun 2009 12:40:57 -0400 Subject: [Freeipa-devel] [PATCH] Gettextize the sss_ tools In-Reply-To: <4A3B98C4.6060209@redhat.com> References: <4A3B98C4.6060209@redhat.com> Message-ID: <4A3BBF99.9070203@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/19/2009 09:55 AM, Jakub Hrozek wrote: > The attached patch converts the static strings in the tools into gettext > _("strings"). > > Jakub Ack. - ------------------------------------------------------------------------ _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAko7v5kACgkQeiVVYja6o6N/ugCeOZ+i/rthYsnpFxCfz+ZZVpHv 4ZsAoIFBfKNhvfiPWweoYIZm8vOqN3aL =TRe1 -----END PGP SIGNATURE----- From ssorce at redhat.com Fri Jun 19 16:50:36 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 19 Jun 2009 12:50:36 -0400 Subject: [Freeipa-devel] [SSSD] SSSD Release Process In-Reply-To: <4A3BBF09.6090505@redhat.com> References: <4A3BBF09.6090505@redhat.com> Message-ID: <1245430236.11682.8.camel@localhost.localdomain> On Fri, 2009-06-19 at 12:38 -0400, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I have created a page on the SSSD wiki: > https://fedorahosted.org/sssd/wiki/ReleaseProcess to describe in detail > the release process for the SSSD. I believe I have captured all of the > main points, but if I have missed anything, please update the page or > the attached discussion page. > > Regarding translations, my thought is that we should postpone committing > updates to the .po and .pot files until the commit where we bump the > version number just prior to signing the version tag. It will be easier > to update these files once at release time, rather than pushing the > updates each time an affected .c or .h file is changed. > > It is easy enough when building the code for a developer to run 'make > dist' if they need access to the updated translations between releases. > > Discussion welcome. why the md5sum and the shasum when we already have the .asc ? And why both ? Simo. -- Simo Sorce * Red Hat, Inc * New York From yzhang at redhat.com Fri Jun 19 16:53:30 2009 From: yzhang at redhat.com (yi zhang) Date: Fri, 19 Jun 2009 09:53:30 -0700 Subject: [Freeipa-devel] Re: [PATCH] Add automount plugin port to new LDAP backend. In-Reply-To: <4A3A97B6.9010000@redhat.com> References: <4A2FAD5B.6060401@redhat.com> <4A37FC36.1050300@redhat.com> <4A3A79F2.3080303@redhat.com> <4A3A97B6.9010000@redhat.com> Message-ID: <4A3BC28A.6060300@redhat.com> Rob: When possible (and when this feature is completed) please give me some hints of what is this doing. I need follow it up and make necessary changes to test plan and automation. Thanks Yi Rob Crittenden wrote: > Pavel Z?na wrote: >> Rob Crittenden wrote: >>> Pavel Zuna wrote: >>>> Patch 0013: Add automount plugin port to new LDAP backend. >>>> >>>> Pavel >>> >>> There are some problems with this port from the old mechanism. >>> >>> I'm ok with renaming the functions I suppose, we'll have to see >>> through usage which one is better. >> Renaming was necessary, because Method to Object association is >> created according to plugin names. If we want an -add method for the >> automountkey object, its name has to start with 'automountkey'. >> >>> But it doesn't seem to actually be working. automount2-tofiles >>> doesn't work at all and automount2-create-indirect doesn't create >>> the maps properly. >> Yeah, looks like I didn't understand correctly how automount entries >> are organized in LDAP. >> >>> I was originally a little worried that when deleting a map you were >>> removing the connection to the parent in the pre callback but it >>> looks like the keys aren't being removed either. I think the parent >>> connection should be removed after the entry is removed. >>> >>> Can you take another look? >>> >>> rob >> I did an updated version. I also renamed the -create methods to -add, >> but forgot about -delete before making the commit. I will rename >> those later, the plugin name had to stay suffixed with 2 for now anyway. >> >> Pavel >> > > Ok, better but not quite there yet. There is a typo in a variable name: > > --- a/ipalib/plugins/automount2.py > +++ b/ipalib/plugins/automount2.py > @@ -302,7 +302,7 @@ class automount2_tofiles(Command): > automountmapname=info > ) > if keys_tmp: > - keys[info] += keys_tmps > + keys[info] += keys_tmp > > return (maps, keys) > > I can add an indirect map now and show maps the way they would look in > files but it seems to show the maps multiple times, at least auto.master: > > $ ./ipa automount2-tofiles > /etc/auto.master: > /- /etc/auto.direct > /stuf /etc/auto.master > /things /etc/auto.things > --------------------------- > /etc/auto.direct: > --------------------------- > /etc/auto.master: > /- auto.direct > /stuf auto.master > /things auto.things > --------------------------- > /etc/auto.things: > /somewhere rw > > Also, automuntkey2-delete seems broken. I ran it and let it hang for a > couple of minutes, not seeming to do anything. The DS logs have a lot > of repeated searches: > > [18/Jun/2009:15:38:09 -0400] conn=951 op=180016 SRCH > base="automountkey=/place2,automountmapname=auto.stuff,cn=automount,dc=example,dc=com" > scope=1 filter="(objectClass=*)" attrs="" > [18/Jun/2009:15:38:09 -0400] conn=951 op=180016 RESULT err=0 tag=101 > nentries=0 etime=0 notes=U > [18/Jun/2009:15:38:09 -0400] conn=951 op=180017 SRCH > base="automountkey=/place2,automountmapname=auto.stuff,cn=automount,dc=example,dc=com" > scope=1 filter="(objectClass=*)" attrs="" > [18/Jun/2009:15:38:09 -0400] conn=951 op=180017 RESULT err=0 tag=101 > nentries=0 etime=0 notes=U > [18/Jun/2009:15:38:09 -0400] conn=951 op=180018 SRCH > base="automountkey=/place2,automountmapname=auto.stuff,cn=automount,dc=example,dc=com" > scope=1 filter="(objectClass=*)" attrs="" > > rob > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Fri Jun 19 16:58:15 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 19 Jun 2009 12:58:15 -0400 Subject: [Freeipa-devel] [SSSD] SSSD Release Process In-Reply-To: <1245430236.11682.8.camel@localhost.localdomain> References: <4A3BBF09.6090505@redhat.com> <1245430236.11682.8.camel@localhost.localdomain> Message-ID: <4A3BC3A7.1080604@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/19/2009 12:50 PM, Simo Sorce wrote: > On Fri, 2009-06-19 at 12:38 -0400, Stephen Gallagher wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Discussion welcome. > > why the md5sum and the shasum when we already have the .asc ? > And why both ? > > Simo. > I always prefer paranoia when it comes to security. I wanted to have at least one other method of verifying the tarball provided on our wiki (since it's possible that someone on Fedorahosted.org could replace our .asc and tarball with ones of their own devising, and the chances of them doing so in both the release fileserver and on our wiki are smaller) Also, if we're going to provide a hash, providing both means that even if someone actually managed to force a hash-collision to provide a fake tarball, they'd have to fake BOTH the md5 and sha1 sums. This is so unlikely as to be effectively impossible. And yes, there's a slight possibility that I'm too paranoid. I consider that a plus when working on security software. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAko7w54ACgkQeiVVYja6o6PSZACfYrna45ppXejyi2WBwpVAIcPT eSQAoLA//DI4+RtuYVh6rU6WS5MxX5gd =2qau -----END PGP SIGNATURE----- From dpal at redhat.com Fri Jun 19 17:12:22 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 19 Jun 2009 13:12:22 -0400 Subject: [Freeipa-devel] C++ Style Guide In-Reply-To: <4A3BBE2E.6010801@redhat.com> References: <4A3BBE2E.6010801@redhat.com> Message-ID: <4A3BC6F6.8030803@redhat.com> John Dennis wrote: > Our coding style guides are referenced on our wiki here: > http://freeipa.com/page/Contribute#Developer_Documentation > > However they do not discuss C++ style. Since I'm writing a fair amount > of C++ code (in part forced by the fact the AMQP client code only has > a C++ binding, not C) it's time define our style conventions for C++. > > I propose is following the Google C++ style guide: > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml > > It seems reasonable and it's influential. It seems to follow many > common conventions and eschews the junk associated with the Microsoft > C++ conventions. > > Since I don't want to write a style guide from scratch and the Google > C++ style guide seems like a reasonable pick I propose we just > reference the Google guide and be done with it. > > Anybody have any problems with this proposal? Comments? Flames? > > If not I'll just update the wiki to point to the Google guide. > > P.S.: C and C++ are such different languages despite superficial > similarities it would be inappropriate IMHO for our C++ style to > derive from our C style guide, they should be independent reflecting > the inherent differences between the languages. > Couple points. It would be a bit easy to understand and check if there were a sample code snippet that would match the style guide. I scanned through the guide and a bit concerned about names for methods and variables. I think these should be consistent between C and C++ otherwise we will be creating problems for ourselves. Also we should use same rules about spaces indentation positioning of braces and brackets. If we have different styles for those we will create hard time for ourselves. So I woulds suggest that we use this style guide only for specific things relates to C++ and define naming convention for methods and classes based on the style we already use. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Fri Jun 19 17:17:18 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 19 Jun 2009 13:17:18 -0400 Subject: [Freeipa-devel] C++ Style Guide In-Reply-To: <4A3BC6F6.8030803@redhat.com> References: <4A3BBE2E.6010801@redhat.com> <4A3BC6F6.8030803@redhat.com> Message-ID: <1245431838.11682.9.camel@localhost.localdomain> On Fri, 2009-06-19 at 13:12 -0400, Dmitri Pal wrote: > Couple points. > It would be a bit easy to understand and check if there were a sample > code snippet that would match the style guide. > > I scanned through the guide and a bit concerned about names for > methods > and variables. > I think these should be consistent between C and C++ otherwise we will > be creating problems for ourselves. > Also we should use same rules about spaces indentation positioning of > braces and brackets. > If we have different styles for those we will create hard time for > ourselves. > So I woulds suggest that we use this style guide only for specific > things relates to C++ and define naming convention for methods and > classes based on the style we already use. +1 -- Simo Sorce * Red Hat, Inc * New York From smooge at gmail.com Fri Jun 19 17:27:07 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 19 Jun 2009 11:27:07 -0600 Subject: [Freeipa-devel] [SSSD] SSSD Release Process In-Reply-To: <4A3BC3A7.1080604@redhat.com> References: <4A3BBF09.6090505@redhat.com> <1245430236.11682.8.camel@localhost.localdomain> <4A3BC3A7.1080604@redhat.com> Message-ID: <80d7e4090906191027y5c44a7b1p69f414b01f33f453@mail.gmail.com> On Fri, Jun 19, 2009 at 10:58 AM, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 06/19/2009 12:50 PM, Simo Sorce wrote: >> On Fri, 2009-06-19 at 12:38 -0400, Stephen Gallagher wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Discussion welcome. >> >> why the md5sum and the shasum when we already have the .asc ? >> And why both ? >> >> Simo. >> > > I always prefer paranoia when it comes to security. I wanted to have at > least one other method of verifying the tarball provided on our wiki > (since it's possible that someone on Fedorahosted.org could replace our > .asc and tarball with ones of their own devising, and the chances of > them doing so in both the release fileserver and on our wiki are smaller) > > Also, if we're going to provide a hash, providing both means that even > if someone actually managed to force a hash-collision to provide a fake > tarball, they'd have to fake BOTH the md5 and sha1 sums. This is so > unlikely as to be effectively impossible. I have heard from a couple of crypto-analysts this may not always be effectively impossible anymore. However I have heard the opposite also :). The bigger issue is to use checksums that are available to people and currently 'secure'. Those would be SHA1SUM til 2010/2012 and SHA2(256) and using the appropriate GPG asc signature. The bigger issue is how often people check those sums. Normally people will be checking things that aren't recent so keeping older sums and signatures are as important as new ones. > And yes, there's a slight possibility that I'm too paranoid. I consider > that a plus when working on security software. > > - -- > Stephen Gallagher > RHCE 804006346421761 > > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAko7w54ACgkQeiVVYja6o6PSZACfYrna45ppXejyi2WBwpVAIcPT > eSQAoLA//DI4+RtuYVh6rU6WS5MxX5gd > =2qau > -----END PGP SIGNATURE----- > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jdennis at redhat.com Fri Jun 19 17:43:43 2009 From: jdennis at redhat.com (John Dennis) Date: Fri, 19 Jun 2009 13:43:43 -0400 Subject: [Freeipa-devel] C++ Style Guide In-Reply-To: <4A3BC6F6.8030803@redhat.com> References: <4A3BBE2E.6010801@redhat.com> <4A3BC6F6.8030803@redhat.com> Message-ID: <4A3BCE4F.4070207@redhat.com> On 06/19/2009 01:12 PM, Dmitri Pal wrote: > Couple points. > It would be a bit easy to understand and check if there were a sample > code snippet that would match the style guide. There are, you just have to click on the > box to expand the topic, once you do you'll see examples. > I scanned through the guide and a bit concerned about names for methods > and variables. > I think these should be consistent between C and C++ otherwise we will > be creating problems for ourselves. That's why I said C != C++. C++ has a lot more kinds of things which have to be distinguished by syntax style. Trying to make all the naming guidelines in C++ match those in C++ defeats the purpose. Note, there is some amount of overlap. I don't see why having coding conventions unique to C++ would create problems for ourselves. Can you explain why that would be the case? We don't impose C conventions on our Python code, why should we impose C conventions on C++? Python has about as much in common with C as C++ has in common with C. > Also we should use same rules about spaces indentation positioning of > braces and brackets. I agree with keeping the same conventions for braces, indentation, etc. That makes sense. I'm really more concerned with naming conventions so when someone looks at the C++ code they can distinguish a class from other names, mutators vs. accessors vs. member functions in classes, public members vs. private members, templates, etc. Because C has none of these distinctions the C guidelines lump everything into one naming bucket. > If we have different styles for those we will create hard time for > ourselves. > So I woulds suggest that we use this style guide only for specific > things relates to C++ and define naming convention for methods and > classes based on the style we already use. Well, I don't really want to sit down and derive all the places where the two guidelines diverge and in which circumstances one trumps the other, it doesn't seem like a good use of time to me. As I said above I don't see the value in trying to bring two distinct bodies of code into stylistic convergence. Maybe we should tell Jason he has to write Python so it looks just like C :-) -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Fri Jun 19 18:59:02 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 19 Jun 2009 14:59:02 -0400 Subject: [Freeipa-devel] [PATCH] Gettextize the sss_ tools In-Reply-To: <4A3B98C4.6060209@redhat.com> References: <4A3B98C4.6060209@redhat.com> Message-ID: <1245437942.11682.21.camel@localhost.localdomain> On Fri, 2009-06-19 at 15:55 +0200, Jakub Hrozek wrote: > > > The attached patch converts the static strings in the tools into > gettext > _("strings"). Looking at this patch I realize that we used DEBUG() improperly here. DEBUG() shouldn't be used to return errors, but to aid in debugging. So we should probably split the DEBUG statements used here in 2. 1. A set of PRINT() statements for messages intended to be returned to users, these messages will be localized, and localization should be part of the macro itself. Also any time more than 2 parameters are required, we should use positionals because the position of an expanded parameter may vary depending on the language. 2. A set of DEBUG() statements for messages intended to be seen only during debugging. These *should not* be translated. Comments ? Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Jun 19 19:27:02 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 19 Jun 2009 15:27:02 -0400 Subject: [Freeipa-devel] C++ Style Guide In-Reply-To: <4A3BCE4F.4070207@redhat.com> References: <4A3BBE2E.6010801@redhat.com> <4A3BC6F6.8030803@redhat.com> <4A3BCE4F.4070207@redhat.com> Message-ID: <4A3BE686.1070901@redhat.com> John Dennis wrote: > On 06/19/2009 01:12 PM, Dmitri Pal wrote: >> Couple points. >> It would be a bit easy to understand and check if there were a sample >> code snippet that would match the style guide. > > There are, you just have to click on the > box to expand the topic, > once you do you'll see examples. > >> I scanned through the guide and a bit concerned about names for methods >> and variables. >> I think these should be consistent between C and C++ otherwise we will >> be creating problems for ourselves. > > That's why I said C != C++. > > C++ has a lot more kinds of things which have to be distinguished by > syntax style. Trying to make all the naming guidelines in C++ match > those in C++ defeats the purpose. Note, there is some amount of > overlap. I don't see why having coding conventions unique to C++ would > create problems for ourselves. Can you explain why that would be the > case? We don't impose C conventions on our Python code, why should we > impose C conventions on C++? Python has about as much in common with C > as C++ has in common with C. > >> Also we should use same rules about spaces indentation positioning of >> braces and brackets. > > I agree with keeping the same conventions for braces, indentation, > etc. That makes sense. I'm really more concerned with naming > conventions so when someone looks at the C++ code they can distinguish > a class from other names, mutators vs. accessors vs. member functions > in classes, public members vs. private members, templates, etc. > Because C has none of these distinctions the C guidelines lump > everything into one naming bucket. > >> If we have different styles for those we will create hard time for >> ourselves. >> So I woulds suggest that we use this style guide only for specific >> things relates to C++ and define naming convention for methods and >> classes based on the style we already use. > > Well, I don't really want to sit down and derive all the places where > the two guidelines diverge and in which circumstances one trumps the > other, it doesn't seem like a good use of time to me. As I said above > I don't see the value in trying to bring two distinct bodies of code > into stylistic convergence. Maybe we should tell Jason he has to write > Python so it looks just like C :-) > John the idea is to make it simpler rather than harder. If this style says that when you write a method the "{" should be on the same line and in C style we have it on the next line we got a problem. It would be very annoying switching from C to C++ development and back. I anticipate that there will be fair amount of code where C and C++ are mixed. After looking at examples I see only couple things that I do not like: a) Constants starting with "k" - should be same as in our guide b) Private members ending with "_" - I prefer suffixes on the parameters of the functions like _in or _out rather than _ on the member. But I am open to discussion. Capitalization in class names and absence of _ is Ok. But for regular functions I think we should use same notation as for normal C functions. So instead of HashTable::AddTeableEntry() have HashTable::add_table_entry(). There is not much difference between regular functions and accessors/modifiers that usually start with set_ and get_ so I do not see a reason to distinguish them in style guide. Name bears enough information All the spacing and CRs will be taken from the C style guide. That is pretty much it. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sgallagh at redhat.com Mon Jun 22 14:13:03 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 22 Jun 2009 10:13:03 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Improvements to config file updates Message-ID: <4A3F916F.5050808@redhat.com> 1) Some text editors will create a new file and move it into place on top of the existing file. When this happens, the kernel issues an IN_IGNORE inotify event and automatically removes the watch descriptor for that file. We'll handle the event and create a new watch descriptor for the new file. 2) Some scripts may append new data to the config file in several steps (such as calling echo "foo" >> sssd.conf several times). In order to handle these scripts safely, we'll defer processing of inotify events for one second after the first is detected. This should be ample time for the remainder of the script to complete. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Improvements-to-config-file-updates.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From sbose at redhat.com Tue Jun 23 10:34:41 2009 From: sbose at redhat.com (Sumit Bose) Date: Tue, 23 Jun 2009 12:34:41 +0200 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin In-Reply-To: <4A3B78EE.3090302@redhat.com> References: <4A2D6F73.7040206@redhat.com> <4A36500D.3030804@redhat.com> <1245106154.14254.62.camel@localhost.localdomain> <4A3B78EE.3090302@redhat.com> Message-ID: <4A40AFC1.9090109@redhat.com> Am 19.06.2009 13:39, schrieb Sumit Bose: > Am 16.06.2009 00:49, schrieb Simo Sorce: >> On Mon, 2009-06-15 at 15:43 +0200, Sumit Bose wrote: >>> Simo, can you please review the tevent_req stuff. If >>> I've done it right I will try and change the waitpid call to >>> tevent_req. >> Nope, not right according to the strict style. >> Catch me on IRC tomorrow and we will go through an example. >> > > Here is another try. Currently the tgt_req_* tevent_req is not really > needed because the main pam handler could call read_pipe_* tvent_req > directy. But I thought it might give us some more flexibility for future > changes. > A few more changes as discussed on irc. bye, Sumit -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-added-kerberos-backend-with-tevent_req-event-handlin.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-added-kerberos-locator-plugin.patch URL: From sgallagh at redhat.com Tue Jun 23 11:53:33 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 23 Jun 2009 07:53:33 -0400 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin In-Reply-To: <4A40AFC1.9090109@redhat.com> References: <4A2D6F73.7040206@redhat.com> <4A36500D.3030804@redhat.com> <1245106154.14254.62.camel@localhost.localdomain> <4A3B78EE.3090302@redhat.com> <4A40AFC1.9090109@redhat.com> Message-ID: <4A40C23D.3020705@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/23/2009 06:34 AM, Sumit Bose wrote: > Am 19.06.2009 13:39, schrieb Sumit Bose: >> Am 16.06.2009 00:49, schrieb Simo Sorce: >>> On Mon, 2009-06-15 at 15:43 +0200, Sumit Bose wrote: >>>> Simo, can you please review the tevent_req stuff. If >>>> I've done it right I will try and change the waitpid call to >>>> tevent_req. >>> Nope, not right according to the strict style. >>> Catch me on IRC tomorrow and we will go through an example. >>> >> Here is another try. Currently the tgt_req_* tevent_req is not really >> needed because the main pam handler could call read_pipe_* tvent_req >> directy. But I thought it might give us some more flexibility for future >> changes. >> > > A few more changes as discussed on irc. > > bye, > Sumit > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Sumit, please update sssd.spec.in as well. This patch breaks it (unpackaged files). - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpAwjUACgkQeiVVYja6o6NxWwCeN9m4/BoY5dtNKbpR4NQUbAUd yz8An0NjTPaJsZ/J/xdilZJVnVF3ySe9 =wp5t -----END PGP SIGNATURE----- From sbose at redhat.com Tue Jun 23 12:51:02 2009 From: sbose at redhat.com (Sumit Bose) Date: Tue, 23 Jun 2009 14:51:02 +0200 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin In-Reply-To: <4A40C23D.3020705@redhat.com> References: <4A2D6F73.7040206@redhat.com> <4A36500D.3030804@redhat.com> <1245106154.14254.62.camel@localhost.localdomain> <4A3B78EE.3090302@redhat.com> <4A40AFC1.9090109@redhat.com> <4A40C23D.3020705@redhat.com> Message-ID: <4A40CFB6.20502@redhat.com> Am 23.06.2009 13:53, schrieb Stephen Gallagher: > On 06/23/2009 06:34 AM, Sumit Bose wrote: >> Am 19.06.2009 13:39, schrieb Sumit Bose: >>> Am 16.06.2009 00:49, schrieb Simo Sorce: >>>> On Mon, 2009-06-15 at 15:43 +0200, Sumit Bose wrote: >>>>> Simo, can you please review the tevent_req stuff. If >>>>> I've done it right I will try and change the waitpid call to >>>>> tevent_req. >>>> Nope, not right according to the strict style. >>>> Catch me on IRC tomorrow and we will go through an example. >>>> >>> Here is another try. Currently the tgt_req_* tevent_req is not really >>> needed because the main pam handler could call read_pipe_* tvent_req >>> directy. But I thought it might give us some more flexibility for future >>> changes. >>> >> A few more changes as discussed on irc. > >> bye, >> Sumit > > >> ------------------------------------------------------------------------ > >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Sumit, please update sssd.spec.in as well. This patch breaks it > (unpackaged files). > Now, the *.la files are removed. bye, Sumit -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-added-kerberos-backend-with-tevent_req-event-handlin.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-added-kerberos-locator-plugin.patch URL: From sbose at redhat.com Tue Jun 23 13:05:24 2009 From: sbose at redhat.com (Sumit Bose) Date: Tue, 23 Jun 2009 15:05:24 +0200 Subject: [Freeipa-devel] [PATCH] check pending_return after dbus_connection_send_with_reply Message-ID: <4A40D314.8040404@redhat.com> Hi, according to http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusConnection.html#ga951b2a6f6c4069fa392752000b24ebe dbus_connection_send_with_reply can return TRUE, but set pending_return to NULL. This patch adds a check to protect the following call which try to use pending_return. I have found this while running some load tests with >40 parallel authentication requests. bye, Sumit -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-check-pending_return-after-dbus_connection_send_with.patch URL: From sgallagh at redhat.com Tue Jun 23 13:35:44 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 23 Jun 2009 09:35:44 -0400 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin In-Reply-To: <4A40CFB6.20502@redhat.com> References: <4A2D6F73.7040206@redhat.com> <4A36500D.3030804@redhat.com> <1245106154.14254.62.camel@localhost.localdomain> <4A3B78EE.3090302@redhat.com> <4A40AFC1.9090109@redhat.com> <4A40C23D.3020705@redhat.com> <4A40CFB6.20502@redhat.com> Message-ID: <4A40DA30.8080701@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/23/2009 08:51 AM, Sumit Bose wrote: > Am 23.06.2009 13:53, schrieb Stephen Gallagher: >> On 06/23/2009 06:34 AM, Sumit Bose wrote: >>> Am 19.06.2009 13:39, schrieb Sumit Bose: >>>> Am 16.06.2009 00:49, schrieb Simo Sorce: >>>>> On Mon, 2009-06-15 at 15:43 +0200, Sumit Bose wrote: >>>>>> Simo, can you please review the tevent_req stuff. If >>>>>> I've done it right I will try and change the waitpid call to >>>>>> tevent_req. >>>>> Nope, not right according to the strict style. >>>>> Catch me on IRC tomorrow and we will go through an example. >>>>> >>>> Here is another try. Currently the tgt_req_* tevent_req is not really >>>> needed because the main pam handler could call read_pipe_* tvent_req >>>> directy. But I thought it might give us some more flexibility for future >>>> changes. >>>> >>> A few more changes as discussed on irc. >>> bye, >>> Sumit >> >>> ------------------------------------------------------------------------ >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Sumit, please update sssd.spec.in as well. This patch breaks it >> (unpackaged files). >> > > Now, the *.la files are removed. > > bye, > Sumit Nack: make[3]: Entering directory `/home/sgallagh/workspace/sssd/x64/server' /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. - -I../../server -Wall -Iinclude -I.. -I-I/usr/include/dbus-1.0 - -I/usr/lib64/dbus-1.0/include -I../../server/include -Iinclude -I. -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I ../../server/../replace -I../../server/../common/collection - -I../../server/../common/trace -I../../server/../common/ini - -DLIBDIR=\"/home/sgallagh/workspace/sssd/x64/chroot/lib\" - -DVARDIR=\"/home/sgallagh/workspace/sssd/x64/chroot/var\" - -DSHLIBEXT=\"\" - -DSSSD_LIBEXEC_PATH=\"/home/sgallagh/workspace/sssd/x64/chroot/libexec/sssd\" - -DSHADOW_UTILS_PATH=\"/home/sgallagh/workspace/sssd/x64/chroot/sbin\" - -DSSSD_INTROSPECT_PATH=\"\" - -DSSSD_CONF_DIR=\"/home/sgallagh/workspace/sssd/x64/chroot/etc/sssd\" - -DUSE_MMAP=1 - -DLOCALEDIR=\"\/home/sgallagh/workspace/sssd/x64/chroot/share/locale\" -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-qual - -Wcast-align -Wwrite-strings -g -O2 -MT krb5_plugin/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.lo -MD - -MP -MF krb5_plugin/.deps/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.Tpo - -c -o krb5_plugin/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.lo `test -f 'krb5_plugin/sssd_krb5_locator_plugin.c' || echo '../../server/'`krb5_plugin/sssd_krb5_locator_plugin.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../server -Wall - -Iinclude -I.. -I-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include - -I../../server/include -Iinclude -I. -I/usr/include/dbus-1.0 - -I/usr/lib64/dbus-1.0/include -I ../../server/../replace - -I../../server/../common/collection -I../../server/../common/trace - -I../../server/../common/ini - -DLIBDIR=\"/home/sgallagh/workspace/sssd/x64/chroot/lib\" - -DVARDIR=\"/home/sgallagh/workspace/sssd/x64/chroot/var\" - -DSHLIBEXT=\"\" - -DSSSD_LIBEXEC_PATH=\"/home/sgallagh/workspace/sssd/x64/chroot/libexec/sssd\" - -DSHADOW_UTILS_PATH=\"/home/sgallagh/workspace/sssd/x64/chroot/sbin\" - -DSSSD_INTROSPECT_PATH=\"\" - -DSSSD_CONF_DIR=\"/home/sgallagh/workspace/sssd/x64/chroot/etc/sssd\" - -DUSE_MMAP=1 - -DLOCALEDIR=\"/home/sgallagh/workspace/sssd/x64/chroot/share/locale\" - -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-qual - -Wcast-align -Wwrite-strings -g -O2 -MT krb5_plugin/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.lo -MD - -MP -MF krb5_plugin/.deps/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.Tpo - -c ../../server/krb5_plugin/sssd_krb5_locator_plugin.c -fPIC -DPIC -o krb5_plugin/.libs/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.o ../../server/krb5_plugin/sssd_krb5_locator_plugin.c:9:32: error: krb5/locate_plugin.h: No such file or directory ../../server/krb5_plugin/sssd_krb5_locator_plugin.c:18: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?sssd_krb5_locator_init? ../../server/krb5_plugin/sssd_krb5_locator_plugin.c:64: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?sssd_krb5_locator_lookup? ../../server/krb5_plugin/sssd_krb5_locator_plugin.c:126: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?service_locator? make[3]: *** [krb5_plugin/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.lo] Error 1 make[3]: Leaving directory `/home/sgallagh/workspace/sssd/x64/server' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/sgallagh/workspace/sssd/x64/server' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/sgallagh/workspace/sssd/x64/server' make: *** [all-recursive] Error 1 - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpA2ioACgkQeiVVYja6o6MoCwCcD5EwwhGYj5ZHpR94PjK7O+yN QlMAn3u5jqKLxSpbqySo9n0v7gakVgDw =3eZb -----END PGP SIGNATURE----- From sbose at redhat.com Tue Jun 23 14:07:37 2009 From: sbose at redhat.com (Sumit Bose) Date: Tue, 23 Jun 2009 16:07:37 +0200 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin In-Reply-To: <4A40DA30.8080701@redhat.com> References: <4A2D6F73.7040206@redhat.com> <4A36500D.3030804@redhat.com> <1245106154.14254.62.camel@localhost.localdomain> <4A3B78EE.3090302@redhat.com> <4A40AFC1.9090109@redhat.com> <4A40C23D.3020705@redhat.com> <4A40CFB6.20502@redhat.com> <4A40DA30.8080701@redhat.com> Message-ID: <4A40E1A9.6040403@redhat.com> Am 23.06.2009 15:35, schrieb Stephen Gallagher: > On 06/23/2009 08:51 AM, Sumit Bose wrote: >> Am 23.06.2009 13:53, schrieb Stephen Gallagher: >>> On 06/23/2009 06:34 AM, Sumit Bose wrote: >>>> Am 19.06.2009 13:39, schrieb Sumit Bose: >>>>> Am 16.06.2009 00:49, schrieb Simo Sorce: >>>>>> On Mon, 2009-06-15 at 15:43 +0200, Sumit Bose wrote: >>>>>>> Simo, can you please review the tevent_req stuff. If >>>>>>> I've done it right I will try and change the waitpid call to >>>>>>> tevent_req. >>>>>> Nope, not right according to the strict style. >>>>>> Catch me on IRC tomorrow and we will go through an example. >>>>>> >>>>> Here is another try. Currently the tgt_req_* tevent_req is not really >>>>> needed because the main pam handler could call read_pipe_* tvent_req >>>>> directy. But I thought it might give us some more flexibility for future >>>>> changes. >>>>> >>>> A few more changes as discussed on irc. >>>> bye, >>>> Sumit >>>> ------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Sumit, please update sssd.spec.in as well. This patch breaks it >>> (unpackaged files). >>> >> Now, the *.la files are removed. > >> bye, >> Sumit > > Nack: > > make[3]: Entering directory `/home/sgallagh/workspace/sssd/x64/server' > /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. > -I../../server -Wall -Iinclude -I.. -I-I/usr/include/dbus-1.0 > -I/usr/lib64/dbus-1.0/include -I../../server/include -Iinclude -I. > -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I > ../../server/../replace -I../../server/../common/collection > -I../../server/../common/trace -I../../server/../common/ini > -DLIBDIR=\"/home/sgallagh/workspace/sssd/x64/chroot/lib\" > -DVARDIR=\"/home/sgallagh/workspace/sssd/x64/chroot/var\" > -DSHLIBEXT=\"\" > - > -DSSSD_LIBEXEC_PATH=\"/home/sgallagh/workspace/sssd/x64/chroot/libexec/sssd\" > -DSHADOW_UTILS_PATH=\"/home/sgallagh/workspace/sssd/x64/chroot/sbin\" > -DSSSD_INTROSPECT_PATH=\"\" > -DSSSD_CONF_DIR=\"/home/sgallagh/workspace/sssd/x64/chroot/etc/sssd\" > -DUSE_MMAP=1 > -DLOCALEDIR=\"\/home/sgallagh/workspace/sssd/x64/chroot/share/locale\" > -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-qual > -Wcast-align -Wwrite-strings -g -O2 -MT > krb5_plugin/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.lo -MD > -MP -MF > krb5_plugin/.deps/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.Tpo > -c -o > krb5_plugin/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.lo > `test -f 'krb5_plugin/sssd_krb5_locator_plugin.c' || echo > '../../server/'`krb5_plugin/sssd_krb5_locator_plugin.c > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../server -Wall > -Iinclude -I.. -I-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include > -I../../server/include -Iinclude -I. -I/usr/include/dbus-1.0 > -I/usr/lib64/dbus-1.0/include -I ../../server/../replace > -I../../server/../common/collection -I../../server/../common/trace > -I../../server/../common/ini > -DLIBDIR=\"/home/sgallagh/workspace/sssd/x64/chroot/lib\" > -DVARDIR=\"/home/sgallagh/workspace/sssd/x64/chroot/var\" > -DSHLIBEXT=\"\" > - > -DSSSD_LIBEXEC_PATH=\"/home/sgallagh/workspace/sssd/x64/chroot/libexec/sssd\" > -DSHADOW_UTILS_PATH=\"/home/sgallagh/workspace/sssd/x64/chroot/sbin\" > -DSSSD_INTROSPECT_PATH=\"\" > -DSSSD_CONF_DIR=\"/home/sgallagh/workspace/sssd/x64/chroot/etc/sssd\" > -DUSE_MMAP=1 > -DLOCALEDIR=\"/home/sgallagh/workspace/sssd/x64/chroot/share/locale\" > -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-qual > -Wcast-align -Wwrite-strings -g -O2 -MT > krb5_plugin/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.lo -MD > -MP -MF > krb5_plugin/.deps/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.Tpo > -c ../../server/krb5_plugin/sssd_krb5_locator_plugin.c -fPIC -DPIC -o > krb5_plugin/.libs/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.o > ../../server/krb5_plugin/sssd_krb5_locator_plugin.c:9:32: error: > krb5/locate_plugin.h: No such file or directory > ../../server/krb5_plugin/sssd_krb5_locator_plugin.c:18: error: expected > ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?sssd_krb5_locator_init? > ../../server/krb5_plugin/sssd_krb5_locator_plugin.c:64: error: expected > ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?sssd_krb5_locator_lookup? > ../../server/krb5_plugin/sssd_krb5_locator_plugin.c:126: error: expected > ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?service_locator? > make[3]: *** > [krb5_plugin/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.lo] > Error 1 > make[3]: Leaving directory `/home/sgallagh/workspace/sssd/x64/server' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/home/sgallagh/workspace/sssd/x64/server' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/home/sgallagh/workspace/sssd/x64/server' > make: *** [all-recursive] Error 1 > > added krb5-devel to BuildRequires, configure stops when krb5-config is missing. bye, Sumit -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-added-kerberos-locator-plugin.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-added-kerberos-backend-with-tevent_req-event-handlin.patch URL: From sbose at redhat.com Tue Jun 23 14:49:48 2009 From: sbose at redhat.com (Sumit Bose) Date: Tue, 23 Jun 2009 16:49:48 +0200 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin In-Reply-To: <4A40E1A9.6040403@redhat.com> References: <4A2D6F73.7040206@redhat.com> <4A36500D.3030804@redhat.com> <1245106154.14254.62.camel@localhost.localdomain> <4A3B78EE.3090302@redhat.com> <4A40AFC1.9090109@redhat.com> <4A40C23D.3020705@redhat.com> <4A40CFB6.20502@redhat.com> <4A40DA30.8080701@redhat.com> <4A40E1A9.6040403@redhat.com> Message-ID: <4A40EB8C.2070302@redhat.com> Am 23.06.2009 16:07, schrieb Sumit Bose: > Am 23.06.2009 15:35, schrieb Stephen Gallagher: >> On 06/23/2009 08:51 AM, Sumit Bose wrote: >>> Am 23.06.2009 13:53, schrieb Stephen Gallagher: >>>> On 06/23/2009 06:34 AM, Sumit Bose wrote: >>>>> Am 19.06.2009 13:39, schrieb Sumit Bose: >>>>>> Am 16.06.2009 00:49, schrieb Simo Sorce: >>>>>>> On Mon, 2009-06-15 at 15:43 +0200, Sumit Bose wrote: >>>>>>>> Simo, can you please review the tevent_req stuff. If >>>>>>>> I've done it right I will try and change the waitpid call to >>>>>>>> tevent_req. >>>>>>> Nope, not right according to the strict style. >>>>>>> Catch me on IRC tomorrow and we will go through an example. >>>>>>> >>>>>> Here is another try. Currently the tgt_req_* tevent_req is not really >>>>>> needed because the main pam handler could call read_pipe_* tvent_req >>>>>> directy. But I thought it might give us some more flexibility for future >>>>>> changes. >>>>>> >>>>> A few more changes as discussed on irc. >>>>> bye, >>>>> Sumit >>>>> ------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> Sumit, please update sssd.spec.in as well. This patch breaks it >>>> (unpackaged files). >>>> >>> Now, the *.la files are removed. >>> bye, >>> Sumit >> Nack: >> >> make[3]: Entering directory `/home/sgallagh/workspace/sssd/x64/server' >> /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. >> -I../../server -Wall -Iinclude -I.. -I-I/usr/include/dbus-1.0 >> -I/usr/lib64/dbus-1.0/include -I../../server/include -Iinclude -I. >> -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I >> ../../server/../replace -I../../server/../common/collection >> -I../../server/../common/trace -I../../server/../common/ini >> -DLIBDIR=\"/home/sgallagh/workspace/sssd/x64/chroot/lib\" >> -DVARDIR=\"/home/sgallagh/workspace/sssd/x64/chroot/var\" >> -DSHLIBEXT=\"\" >> - >> -DSSSD_LIBEXEC_PATH=\"/home/sgallagh/workspace/sssd/x64/chroot/libexec/sssd\" >> -DSHADOW_UTILS_PATH=\"/home/sgallagh/workspace/sssd/x64/chroot/sbin\" >> -DSSSD_INTROSPECT_PATH=\"\" >> -DSSSD_CONF_DIR=\"/home/sgallagh/workspace/sssd/x64/chroot/etc/sssd\" >> -DUSE_MMAP=1 >> -DLOCALEDIR=\"\/home/sgallagh/workspace/sssd/x64/chroot/share/locale\" >> -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-qual >> -Wcast-align -Wwrite-strings -g -O2 -MT >> krb5_plugin/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.lo -MD >> -MP -MF >> krb5_plugin/.deps/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.Tpo >> -c -o >> krb5_plugin/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.lo >> `test -f 'krb5_plugin/sssd_krb5_locator_plugin.c' || echo >> '../../server/'`krb5_plugin/sssd_krb5_locator_plugin.c >> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../server -Wall >> -Iinclude -I.. -I-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include >> -I../../server/include -Iinclude -I. -I/usr/include/dbus-1.0 >> -I/usr/lib64/dbus-1.0/include -I ../../server/../replace >> -I../../server/../common/collection -I../../server/../common/trace >> -I../../server/../common/ini >> -DLIBDIR=\"/home/sgallagh/workspace/sssd/x64/chroot/lib\" >> -DVARDIR=\"/home/sgallagh/workspace/sssd/x64/chroot/var\" >> -DSHLIBEXT=\"\" >> - >> -DSSSD_LIBEXEC_PATH=\"/home/sgallagh/workspace/sssd/x64/chroot/libexec/sssd\" >> -DSHADOW_UTILS_PATH=\"/home/sgallagh/workspace/sssd/x64/chroot/sbin\" >> -DSSSD_INTROSPECT_PATH=\"\" >> -DSSSD_CONF_DIR=\"/home/sgallagh/workspace/sssd/x64/chroot/etc/sssd\" >> -DUSE_MMAP=1 >> -DLOCALEDIR=\"/home/sgallagh/workspace/sssd/x64/chroot/share/locale\" >> -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-qual >> -Wcast-align -Wwrite-strings -g -O2 -MT >> krb5_plugin/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.lo -MD >> -MP -MF >> krb5_plugin/.deps/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.Tpo >> -c ../../server/krb5_plugin/sssd_krb5_locator_plugin.c -fPIC -DPIC -o >> krb5_plugin/.libs/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.o >> ../../server/krb5_plugin/sssd_krb5_locator_plugin.c:9:32: error: >> krb5/locate_plugin.h: No such file or directory >> ../../server/krb5_plugin/sssd_krb5_locator_plugin.c:18: error: expected >> ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?sssd_krb5_locator_init? >> ../../server/krb5_plugin/sssd_krb5_locator_plugin.c:64: error: expected >> ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?sssd_krb5_locator_lookup? >> ../../server/krb5_plugin/sssd_krb5_locator_plugin.c:126: error: expected >> ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?service_locator? >> make[3]: *** >> [krb5_plugin/sssd_krb5_locator_plugin_la-sssd_krb5_locator_plugin.lo] >> Error 1 >> make[3]: Leaving directory `/home/sgallagh/workspace/sssd/x64/server' >> make[2]: *** [all-recursive] Error 1 >> make[2]: Leaving directory `/home/sgallagh/workspace/sssd/x64/server' >> make[1]: *** [all] Error 2 >> make[1]: Leaving directory `/home/sgallagh/workspace/sssd/x64/server' >> make: *** [all-recursive] Error 1 >> >> > > added krb5-devel to BuildRequires, configure stops when krb5-config is > missing. > fixed krb5pluginpath for different $libdir. bye, Sumit -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-added-kerberos-locator-plugin.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-added-kerberos-backend-with-tevent_req-event-handlin.patch URL: From sgallagh at redhat.com Tue Jun 23 15:05:57 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 23 Jun 2009 11:05:57 -0400 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin In-Reply-To: <4A40EB8C.2070302@redhat.com> References: <4A2D6F73.7040206@redhat.com> <4A36500D.3030804@redhat.com> <1245106154.14254.62.camel@localhost.localdomain> <4A3B78EE.3090302@redhat.com> <4A40AFC1.9090109@redhat.com> <4A40C23D.3020705@redhat.com> <4A40CFB6.20502@redhat.com> <4A40DA30.8080701@redhat.com> <4A40E1A9.6040403@redhat.com> <4A40EB8C.2070302@redhat.com> Message-ID: <4A40EF55.2090504@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/23/2009 10:49 AM, Sumit Bose wrote: > > fixed krb5pluginpath for different $libdir. > > bye, > Sumit Ack. I think that's the last of the issues I've seen. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpA71AACgkQeiVVYja6o6OhMQCdH/OfJHEY/5b2IsEiaF8MggVo J9EAoJbkjj2LMEC92+YQKbbikaN2Jfi8 =Rc+T -----END PGP SIGNATURE----- From sgallagh at redhat.com Tue Jun 23 18:27:39 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 23 Jun 2009 14:27:39 -0400 Subject: [Freeipa-devel] [PATCH] check pending_return after dbus_connection_send_with_reply In-Reply-To: <4A40D314.8040404@redhat.com> References: <4A40D314.8040404@redhat.com> Message-ID: <4A411E9B.4080005@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/23/2009 09:05 AM, Sumit Bose wrote: > Hi, > > according to > http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusConnection.html#ga951b2a6f6c4069fa392752000b24ebe > dbus_connection_send_with_reply can return TRUE, but set pending_return > to NULL. This patch adds a check to protect the following call which try > to use pending_return. > > I have found this while running some load tests with >40 parallel > authentication requests. > > bye, > Sumit > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Ack. Good catch. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpBHpcACgkQeiVVYja6o6NhPgCfbmxwUC4ZPrC3pZkPylwO+ffG zIIAn2f5dQrPQ4QZTUvDHhg9toqVb+8v =lsn1 -----END PGP SIGNATURE----- From ssorce at redhat.com Tue Jun 23 21:18:30 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 23 Jun 2009 17:18:30 -0400 Subject: [Freeipa-devel] [PATCH] check pending_return after dbus_connection_send_with_reply In-Reply-To: <4A40D314.8040404@redhat.com> References: <4A40D314.8040404@redhat.com> Message-ID: <1245791910.5479.18.camel@localhost.localdomain> On Tue, 2009-06-23 at 15:05 +0200, Sumit Bose wrote: > Hi, > > according to > http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusConnection.html#ga951b2a6f6c4069fa392752000b24ebe > dbus_connection_send_with_reply can return TRUE, but set pending_return > to NULL. This patch adds a check to protect the following call which try > to use pending_return. > > I have found this while running some load tests with >40 parallel > authentication requests. Your patch will cacth it but the effect is the same (we will ourselves). Do you know in what cases this can happen and what it means ? Why does it return true if pending_return is null ? Is there anything we can do, like loop back and retry 2-3 times before giving up ? Simo. -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Wed Jun 24 07:37:43 2009 From: sbose at redhat.com (Sumit Bose) Date: Wed, 24 Jun 2009 09:37:43 +0200 Subject: [Freeipa-devel] [PATCH] check pending_return after dbus_connection_send_with_reply In-Reply-To: <1245791910.5479.18.camel@localhost.localdomain> References: <4A40D314.8040404@redhat.com> <1245791910.5479.18.camel@localhost.localdomain> Message-ID: <4A41D7C7.3060300@redhat.com> Am 23.06.2009 23:18, schrieb Simo Sorce: > On Tue, 2009-06-23 at 15:05 +0200, Sumit Bose wrote: >> Hi, >> >> according to >> http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusConnection.html#ga951b2a6f6c4069fa392752000b24ebe >> dbus_connection_send_with_reply can return TRUE, but set pending_return >> to NULL. This patch adds a check to protect the following call which try >> to use pending_return. >> >> I have found this while running some load tests with >40 parallel >> authentication requests. > > Your patch will cacth it but the effect is the same (we will ourselves). > Do you know in what cases this can happen and what it means ? According to the url above pending_return == NULL means that the connection is disconnected. > > Why does it return true if pending_return is null ? > dbus at lists.freedesktop.org ? > Is there anything we can do, like loop back and retry 2-3 times before > giving up ? > I do not know if it makes sense here. If the connection is disconnected the reason might be that the other side of the connection died. If the other side is restarted by the monitor can we use the old connection or it is necessary to reconnect? bye, Sumit From sgallagh at redhat.com Wed Jun 24 10:06:53 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 24 Jun 2009 06:06:53 -0400 Subject: [Freeipa-devel] [PATCH] check pending_return after dbus_connection_send_with_reply In-Reply-To: <4A41D7C7.3060300@redhat.com> References: <4A40D314.8040404@redhat.com> <1245791910.5479.18.camel@localhost.localdomain> <4A41D7C7.3060300@redhat.com> Message-ID: <4A41FABD.5040909@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/24/2009 03:37 AM, Sumit Bose wrote: > Am 23.06.2009 23:18, schrieb Simo Sorce: >> On Tue, 2009-06-23 at 15:05 +0200, Sumit Bose wrote: >>> Hi, >>> >>> according to >>> http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusConnection.html#ga951b2a6f6c4069fa392752000b24ebe >>> dbus_connection_send_with_reply can return TRUE, but set pending_return >>> to NULL. This patch adds a check to protect the following call which try >>> to use pending_return. >>> >>> I have found this while running some load tests with >40 parallel >>> authentication requests. >> Your patch will cacth it but the effect is the same (we will ourselves). >> Do you know in what cases this can happen and what it means ? > > According to the url above pending_return == NULL means that the > connection is disconnected. > >> Why does it return true if pending_return is null ? >> Simo, the function only returns false if there was a memory allocation error. > > dbus at lists.freedesktop.org ? > >> Is there anything we can do, like loop back and retry 2-3 times before >> giving up ? >> > > I do not know if it makes sense here. If the connection is disconnected > the reason might be that the other side of the connection died. If the > other side is restarted by the monitor can we use the old connection or > it is necessary to reconnect? > I agree with Sumit. The only reason a peer-to-peer D-BUS connection would be disconnected is if one end of it exited. So retrying is just wasting cycles. It's better to just kill it off and let the monitor restart the offending process. > bye, > Sumit > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpB+rkACgkQeiVVYja6o6OknwCgmS1ojXkX18xiTsFSnPDF+DaF iS4AnRGEajLOa8Ze1isn/2XFSCfTMK1M =x81v -----END PGP SIGNATURE----- From ssorce at redhat.com Wed Jun 24 12:16:28 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 24 Jun 2009 08:16:28 -0400 Subject: [Freeipa-devel] [PATCH] check pending_return after dbus_connection_send_with_reply In-Reply-To: <4A41D7C7.3060300@redhat.com> References: <4A40D314.8040404@redhat.com> <1245791910.5479.18.camel@localhost.localdomain> <4A41D7C7.3060300@redhat.com> Message-ID: <1245845788.5479.19.camel@localhost.localdomain> On Wed, 2009-06-24 at 09:37 +0200, Sumit Bose wrote: > Am 23.06.2009 23:18, schrieb Simo Sorce: > > On Tue, 2009-06-23 at 15:05 +0200, Sumit Bose wrote: > >> Hi, > >> > >> according to > >> http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusConnection.html#ga951b2a6f6c4069fa392752000b24ebe > >> dbus_connection_send_with_reply can return TRUE, but set pending_return > >> to NULL. This patch adds a check to protect the following call which try > >> to use pending_return. > >> > >> I have found this while running some load tests with >40 parallel > >> authentication requests. > > > > Your patch will cacth it but the effect is the same (we will ourselves). > > Do you know in what cases this can happen and what it means ? > > According to the url above pending_return == NULL means that the > connection is disconnected. > > > > > Why does it return true if pending_return is null ? > > > > dbus at lists.freedesktop.org ? > > > Is there anything we can do, like loop back and retry 2-3 times before > > giving up ? > > > > I do not know if it makes sense here. If the connection is disconnected > the reason might be that the other side of the connection died. If the > other side is restarted by the monitor can we use the old connection or > it is necessary to reconnect? We need to reconnect, so I guess your patch is ok. Thanks, Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Wed Jun 24 12:24:32 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 24 Jun 2009 08:24:32 -0400 Subject: [Freeipa-devel] [PATCHES][SSSD] Config monitoring patches Message-ID: <4A421B00.8060907@redhat.com> Patch 0001: Improvements to config file updates 1) Some text editors will create a new file and move it into place on top of the existing file. When this happens, the kernel issues an IN_IGNORE inotify event and automatically removes the watch descriptor for that file. We'll handle the event and create a new watch descriptor for the new file. 2) Some scripts may append new data to the config file in several steps (such as calling echo "foo" >> sssd.conf several times). In order to handle these scripts safely, we'll defer processing of inotify events for one second after the first is detected. This should be ample time for the remainder of the script to complete. * This patch was submitted several days ago, but has not yet been reviewed. I'm including it here because the other two patches depend on it Patch 0002: Monitor resolv.conf for changes This patch updates the monitor_config_file() functions so that they can monitor any number of files and invoke a specified callback whenever they are modified. When inotify is available, we will add an additional watch descriptor to the inotify file descriptor. When inotify is not available, the polling function will simply loop to check each file in the monitor list. When changes are discovered in resolv.conf, the monitor will send a "resInit" signal to all of its known children. They are only required to handle this function if they need updated DNS information. Services that do not implement resInit should return DBUS_ERROR_UNKNOWN_METHOD (rather than timing out) with no ill effects. Patch 0003: Implement resInit for monitor, NSS, PAM, DP and the backends -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Improvements-to-config-file-updates.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-Monitor-resolv.conf-for-changes.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0003-Implement-resInit-for-monitor-NSS-PAM-DP-and-the.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From ssorce at redhat.com Wed Jun 24 12:43:32 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 24 Jun 2009 08:43:32 -0400 Subject: [Freeipa-devel] [PATCH] check pending_return after dbus_connection_send_with_reply In-Reply-To: <4A41FABD.5040909@redhat.com> References: <4A40D314.8040404@redhat.com> <1245791910.5479.18.camel@localhost.localdomain> <4A41D7C7.3060300@redhat.com> <4A41FABD.5040909@redhat.com> Message-ID: <1245847412.5479.22.camel@localhost.localdomain> On Wed, 2009-06-24 at 06:06 -0400, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 06/24/2009 03:37 AM, Sumit Bose wrote: > > Am 23.06.2009 23:18, schrieb Simo Sorce: > >> On Tue, 2009-06-23 at 15:05 +0200, Sumit Bose wrote: > >>> Hi, > >>> > >>> according to > >>> http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusConnection.html#ga951b2a6f6c4069fa392752000b24ebe > >>> dbus_connection_send_with_reply can return TRUE, but set pending_return > >>> to NULL. This patch adds a check to protect the following call which try > >>> to use pending_return. > >>> > >>> I have found this while running some load tests with >40 parallel > >>> authentication requests. > >> Your patch will cacth it but the effect is the same (we will ourselves). > >> Do you know in what cases this can happen and what it means ? > > > > According to the url above pending_return == NULL means that the > > connection is disconnected. > > > >> Why does it return true if pending_return is null ? > >> > Simo, the function only returns false if there was a memory allocation > error. > > > > dbus at lists.freedesktop.org ? > > > >> Is there anything we can do, like loop back and retry 2-3 times before > >> giving up ? > >> > > > > I do not know if it makes sense here. If the connection is disconnected > > the reason might be that the other side of the connection died. If the > > other side is restarted by the monitor can we use the old connection or > > it is necessary to reconnect? > > > > I agree with Sumit. The only reason a peer-to-peer D-BUS connection > would be disconnected is if one end of it exited. So retrying is just > wasting cycles. It's better to just kill it off and let the monitor > restart the offending process. I'd rather reconnect if possible. Killing off a backend would entail reconnecting to remote servers or perform other initialization, etc.. It would be nice if we could avoid that when possible, and leave deadly measures to when we can't do anything else. Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Wed Jun 24 12:45:51 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 24 Jun 2009 08:45:51 -0400 Subject: [Freeipa-devel] [PATCH] check pending_return after dbus_connection_send_with_reply In-Reply-To: <1245847412.5479.22.camel@localhost.localdomain> References: <4A40D314.8040404@redhat.com> <1245791910.5479.18.camel@localhost.localdomain> <4A41D7C7.3060300@redhat.com> <4A41FABD.5040909@redhat.com> <1245847412.5479.22.camel@localhost.localdomain> Message-ID: <4A421FFF.9030408@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/24/2009 08:43 AM, Simo Sorce wrote: > On Wed, 2009-06-24 at 06:06 -0400, Stephen Gallagher wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 06/24/2009 03:37 AM, Sumit Bose wrote: >>> Am 23.06.2009 23:18, schrieb Simo Sorce: >>>> On Tue, 2009-06-23 at 15:05 +0200, Sumit Bose wrote: >>>>> Hi, >>>>> >>>>> according to >>>>> http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusConnection.html#ga951b2a6f6c4069fa392752000b24ebe >>>>> dbus_connection_send_with_reply can return TRUE, but set pending_return >>>>> to NULL. This patch adds a check to protect the following call which try >>>>> to use pending_return. >>>>> >>>>> I have found this while running some load tests with >40 parallel >>>>> authentication requests. >>>> Your patch will cacth it but the effect is the same (we will ourselves). >>>> Do you know in what cases this can happen and what it means ? >>> According to the url above pending_return == NULL means that the >>> connection is disconnected. >>> >>>> Why does it return true if pending_return is null ? >>>> >> Simo, the function only returns false if there was a memory allocation >> error. >>> dbus at lists.freedesktop.org ? >>> >>>> Is there anything we can do, like loop back and retry 2-3 times before >>>> giving up ? >>>> >>> I do not know if it makes sense here. If the connection is disconnected >>> the reason might be that the other side of the connection died. If the >>> other side is restarted by the monitor can we use the old connection or >>> it is necessary to reconnect? >>> >> I agree with Sumit. The only reason a peer-to-peer D-BUS connection >> would be disconnected is if one end of it exited. So retrying is just >> wasting cycles. It's better to just kill it off and let the monitor >> restart the offending process. > > I'd rather reconnect if possible. > Killing off a backend would entail reconnecting to remote servers or > perform other initialization, etc.. It would be nice if we could avoid > that when possible, and leave deadly measures to when we can't do > anything else. > > Simo. > Simo, what I was saying is that if the connection has disconnected, then the service has already exited. (I.E. the backend has already died and needs to re-init anyway) - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpCH+gACgkQeiVVYja6o6OePACfWGqUouWf9C9VmXJbMF5/39ov VoEAnAoNbvOvLywTNZfxpXdw+PJFwz6H =UtTG -----END PGP SIGNATURE----- From ssorce at redhat.com Wed Jun 24 13:21:40 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 24 Jun 2009 09:21:40 -0400 Subject: [Freeipa-devel] [PATCH] configure bind+ldap driver Message-ID: <1245849700.5479.23.camel@localhost.localdomain> This creates also role/task groups to authorize the ldap driver to perform DNS updates using its service principal. Does not support yet installing replicas. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Basic-changes-to-get-a-default-principal-for-DNS.patch Type: text/x-patch Size: 19645 bytes Desc: not available URL: From pzuna at redhat.com Wed Jun 24 13:46:59 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 24 Jun 2009 15:46:59 +0200 Subject: [Freeipa-devel] Re: [PATCH] Fix bug in basegroup and passwd plugins (incorrect use of find_entry_by_attr). In-Reply-To: <4A3A91D4.9010902@redhat.com> References: <4A3A79D2.7020404@redhat.com> <4A3A91D4.9010902@redhat.com> Message-ID: <4A422E53.4000807@redhat.com> Rob Crittenden wrote: > Pavel Z?na wrote: >> Patch 0001: Fix bug in basegroup and passwd plugins (incorrect use of >> find_entry_attr). >> >> Pavel > > Does this address the tests? I'm not comfortable moving forward with > previous patches that this relies on until the updated plugins pass the > minimal in-tree tests. > > rob > This is required, otherwise the new plugins won't pass the tests. I know it depends on previous patches, but re-doing everything is a bit complicated at this point (as I didn't plan the LDAP transition very well :(). Let's treat the previous patches as a separate branch, that I'll be building on and push it all at once when everything is right. Pavel From pzuna at redhat.com Wed Jun 24 13:51:07 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 24 Jun 2009 15:51:07 +0200 Subject: [Freeipa-devel] [PATCH] Fix minor bugs, typos, etc. discovered by unit tests in plugins. Message-ID: <4A422F4B.9090104@redhat.com> This patch depends on the "LDAP switch" patches blocked because of lacking unit tests, which is kind of a chicken/egg problem. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-minor-bugs-typos-etc.-discovered-by-unit-tests.patch Type: application/mbox Size: 12525 bytes Desc: not available URL: From pzuna at redhat.com Wed Jun 24 13:54:29 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 24 Jun 2009 15:54:29 +0200 Subject: [Freeipa-devel] [PATCH] Add automount plugin. Message-ID: <4A423015.5070207@redhat.com> This plugin will only work after the LDAP switch is completed. I didn't want to do a pre-switch version just to re-write it a few days later. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-automount-plugin.patch Type: application/mbox Size: 9203 bytes Desc: not available URL: From pzuna at redhat.com Wed Jun 24 13:56:57 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 24 Jun 2009 15:56:57 +0200 Subject: [Freeipa-devel] [PATCHES] Add unit tests for new plugins. Message-ID: <4A4230A9.3070405@redhat.com> Patch 0003: Remove unit tests for old plugins. Patch 0004: Add utility functions for plugin unit testing. Patch 0005: Add unit tests for new plugins. This is a re-write of old unit tests to reflect additional functionality of new plugins. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Remove-unit-tests-for-old-plugins.patch Type: application/mbox Size: 63916 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Add-utility-functions-for-plugin-unit-testing.patch Type: application/mbox Size: 1229 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Add-unit-tests-for-new-plugins.patch Type: application/mbox Size: 57832 bytes Desc: not available URL: From jhrozek at redhat.com Wed Jun 24 17:00:10 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 24 Jun 2009 19:00:10 +0200 Subject: [Freeipa-devel] [PATCH] Gettextize the sss_ tools In-Reply-To: <1245437942.11682.21.camel@localhost.localdomain> References: <4A3B98C4.6060209@redhat.com> <1245437942.11682.21.camel@localhost.localdomain> Message-ID: <4A425B9A.4030605@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/19/2009 08:59 PM, Simo Sorce wrote: > Looking at this patch I realize that we used DEBUG() improperly here. > DEBUG() shouldn't be used to return errors, but to aid in debugging. > So we should probably split the DEBUG statements used here in 2. > > 1. A set of PRINT() statements for messages intended to be returned to > users, these messages will be localized, and localization should be part > of the macro itself. Also any time more than 2 parameters are required, > we should use positionals because the position of an expanded parameter > may vary depending on the language. > > 2. A set of DEBUG() statements for messages intended to be seen only > during debugging. These *should not* be translated. > > > Comments ? I agree that we should separate DEBUG and PRINT and I agree with the translation part. Would an inline function like the one in the attached patch be acceptable for you? The problem I see with macros is that we probably would use something like: #define PRINT(fmt, ...) fprintf(stderr, gettext(fmt), ##__VA_ARGS__) while the ## part is a gcc extension (so that the macro is usable even when called only with fmt). Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpCW5oACgkQHsardTLnvCUZBQCgiaBnA8EfM0Dd/cxab7fzTMw0 Ek4AoOwkN0dDueRQI4hLz/wAL3l4FEin =a4OE -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-print_error-inline-function.patch URL: From ssorce at redhat.com Wed Jun 24 17:59:26 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 24 Jun 2009 13:59:26 -0400 Subject: [Freeipa-devel] [PATCH] Gettextize the sss_ tools In-Reply-To: <4A425B9A.4030605@redhat.com> References: <4A3B98C4.6060209@redhat.com> <1245437942.11682.21.camel@localhost.localdomain> <4A425B9A.4030605@redhat.com> Message-ID: <1245866366.5479.26.camel@localhost.localdomain> On Wed, 2009-06-24 at 19:00 +0200, Jakub Hrozek wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 06/19/2009 08:59 PM, Simo Sorce wrote: > > Looking at this patch I realize that we used DEBUG() improperly here. > > DEBUG() shouldn't be used to return errors, but to aid in debugging. > > So we should probably split the DEBUG statements used here in 2. > > > > 1. A set of PRINT() statements for messages intended to be returned to > > users, these messages will be localized, and localization should be part > > of the macro itself. Also any time more than 2 parameters are required, > > we should use positionals because the position of an expanded parameter > > may vary depending on the language. > > > > 2. A set of DEBUG() statements for messages intended to be seen only > > during debugging. These *should not* be translated. > > > > > > Comments ? > > I agree that we should separate DEBUG and PRINT and I agree with the > translation part. > > Would an inline function like the one in the attached patch be > acceptable for you? The problem I see with macros is that we probably > would use something like: > > #define PRINT(fmt, ...) fprintf(stderr, gettext(fmt), ##__VA_ARGS__) > > while the ## part is a gcc extension (so that the macro is usable even > when called only with fmt). I think you can use the same stuff we use for DEBUG and have a print_fn function. That should be more portable if we care about the above being too gcc specific. Simo. -- Simo Sorce * Red Hat, Inc * New York From mnagy at redhat.com Thu Jun 25 06:19:09 2009 From: mnagy at redhat.com (Martin Nagy) Date: Thu, 25 Jun 2009 08:19:09 +0200 Subject: [Freeipa-devel] [PATCH] configure bind+ldap driver In-Reply-To: <1245849700.5479.23.camel@localhost.localdomain> References: <1245849700.5479.23.camel@localhost.localdomain> Message-ID: <20090625081909.459fe8ff@notas> Simo Sorce wrote: > This creates also role/task groups to authorize the ldap driver to > perform DNS updates using its service principal. > Does not support yet installing replicas. I tested this patch and it looks pretty good. I can ack the python part, but I don't feel competent enough to ack delegation.ldif. I'm going to send a follow-up patch shortly that will configure /etc/named.conf so the ldap driver will use SASL authentication when connecting to the ldap server. Martin From mnagy at redhat.com Thu Jun 25 06:54:36 2009 From: mnagy at redhat.com (Martin Nagy) Date: Thu, 25 Jun 2009 08:54:36 +0200 Subject: [Freeipa-devel] [PATCH] Configure BIND LDAP driver to use SASL authentication Message-ID: <20090625085436.36b6b1e2@notas> This patch needs changes introduced by Simo's "configure bind+ldap driver" to use the generated keytab. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Configure-BIND-LDAP-driver-to-use-SASL-authenticatio.patch Type: text/x-patch Size: 2268 bytes Desc: not available URL: From sgallagh at redhat.com Thu Jun 25 15:01:39 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 25 Jun 2009 11:01:39 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Implement _pam_overwrite_n(n, x) for older systems Message-ID: <4A439153.9040707@redhat.com> OSes based on older versions of the PAM development libraries lack the _pam_overwrite_n(n,x) macro. This patch copies the Fedora 11 pam-devel-1.0.91-6 implementation into an SSSD private header. This affects RHEL5 and SUSE10. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Implement-_pam_overwrite_n-n-x-for-older-systems.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From sbose at redhat.com Thu Jun 25 15:18:25 2009 From: sbose at redhat.com (Sumit Bose) Date: Thu, 25 Jun 2009 17:18:25 +0200 Subject: [Freeipa-devel] [PATCH][SSSD] Implement _pam_overwrite_n(n, x) for older systems In-Reply-To: <4A439153.9040707@redhat.com> References: <4A439153.9040707@redhat.com> Message-ID: <4A439541.6040500@redhat.com> Am 25.06.2009 17:01, schrieb Stephen Gallagher: > OSes based on older versions of the PAM development libraries lack > the _pam_overwrite_n(n,x) macro. This patch copies the Fedora 11 > pam-devel-1.0.91-6 implementation into an SSSD private header. > > This affects RHEL5 and SUSE10. > ACK, but please change the Copyright header. bye, Sumit From sgallagh at redhat.com Thu Jun 25 15:21:07 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 25 Jun 2009 11:21:07 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Implement _pam_overwrite_n(n, x) for older systems In-Reply-To: <4A439541.6040500@redhat.com> References: <4A439153.9040707@redhat.com> <4A439541.6040500@redhat.com> Message-ID: <4A4395E3.2040003@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/25/2009 11:18 AM, Sumit Bose wrote: > Am 25.06.2009 17:01, schrieb Stephen Gallagher: >> OSes based on older versions of the PAM development libraries lack >> the _pam_overwrite_n(n,x) macro. This patch copies the Fedora 11 >> pam-devel-1.0.91-6 implementation into an SSSD private header. >> >> This affects RHEL5 and SUSE10. >> > > ACK, but please change the Copyright header. > > bye, > Sumit Fixed copyright header and pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpDldwACgkQeiVVYja6o6OIwgCfVIkl6DG9Csqnb3TZQWN6KxlM rrQAnRv9mVPwHS58PSETpt4Naz77vYhr =FDac -----END PGP SIGNATURE----- From sgallagh at redhat.com Thu Jun 25 19:24:52 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 25 Jun 2009 15:24:52 -0400 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin In-Reply-To: <4A40EF55.2090504@redhat.com> References: <4A2D6F73.7040206@redhat.com> <4A36500D.3030804@redhat.com> <1245106154.14254.62.camel@localhost.localdomain> <4A3B78EE.3090302@redhat.com> <4A40AFC1.9090109@redhat.com> <4A40C23D.3020705@redhat.com> <4A40CFB6.20502@redhat.com> <4A40DA30.8080701@redhat.com> <4A40E1A9.6040403@redhat.com> <4A40EB8C.2070302@redhat.com> <4A40EF55.2090504@redhat.com> Message-ID: <4A43CF04.6030509@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/23/2009 11:05 AM, Stephen Gallagher wrote: > On 06/23/2009 10:49 AM, Sumit Bose wrote: >> fixed krb5pluginpath for different $libdir. > >> bye, >> Sumit > > Ack. I think that's the last of the issues I've seen. > Correction: one more (very minor) issue to address. You're linking the kerberos backend against libsss_crypt.la. There's no need to do this, as it will inherit that from the sssd_be binary. _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpDzwAACgkQeiVVYja6o6OYWwCghw9ZnCitng4gltJovKGgUIuS DIoAn34wjZCwIhmr4aZXw2urao+T1g5U =P2In -----END PGP SIGNATURE----- From sgallagh at redhat.com Thu Jun 25 19:26:32 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 25 Jun 2009 15:26:32 -0400 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin In-Reply-To: <4A43CF04.6030509@redhat.com> References: <4A2D6F73.7040206@redhat.com> <4A36500D.3030804@redhat.com> <1245106154.14254.62.camel@localhost.localdomain> <4A3B78EE.3090302@redhat.com> <4A40AFC1.9090109@redhat.com> <4A40C23D.3020705@redhat.com> <4A40CFB6.20502@redhat.com> <4A40DA30.8080701@redhat.com> <4A40E1A9.6040403@redhat.com> <4A40EB8C.2070302@redhat.com> <4A40EF55.2090504@redhat.com> <4A43CF04.6030509@redhat.com> Message-ID: <4A43CF68.8060609@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/25/2009 03:24 PM, Stephen Gallagher wrote: > On 06/23/2009 11:05 AM, Stephen Gallagher wrote: >> On 06/23/2009 10:49 AM, Sumit Bose wrote: >>> fixed krb5pluginpath for different $libdir. >>> bye, >>> Sumit >> Ack. I think that's the last of the issues I've seen. > > > Correction: one more (very minor) issue to address. You're linking the > kerberos backend against libsss_crypt.la. There's no need to do this, as > it will inherit that from the sssd_be binary. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Sorry, make that two things: Please also create a manpage for sssd-krb5 (similar to sssd-ldap.5) so the available options are spelled out. _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpDz2gACgkQeiVVYja6o6MiPQCfZKQC27L7lH52bYbcBGJWT6P0 ElsAoJ+E3/qgnQpy1rp9JWwbOJ0ljFRP =foir -----END PGP SIGNATURE----- From sbose at redhat.com Fri Jun 26 15:40:27 2009 From: sbose at redhat.com (Sumit Bose) Date: Fri, 26 Jun 2009 17:40:27 +0200 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin In-Reply-To: <4A43CF68.8060609@redhat.com> References: <4A2D6F73.7040206@redhat.com> <4A36500D.3030804@redhat.com> <1245106154.14254.62.camel@localhost.localdomain> <4A3B78EE.3090302@redhat.com> <4A40AFC1.9090109@redhat.com> <4A40C23D.3020705@redhat.com> <4A40CFB6.20502@redhat.com> <4A40DA30.8080701@redhat.com> <4A40E1A9.6040403@redhat.com> <4A40EB8C.2070302@redhat.com> <4A40EF55.2090504@redhat.com> <4A43CF04.6030509@redhat.com> <4A43CF68.8060609@redhat.com> Message-ID: <4A44EBEB.606@redhat.com> Am 25.06.2009 21:26, schrieb Stephen Gallagher: > On 06/25/2009 03:24 PM, Stephen Gallagher wrote: >> On 06/23/2009 11:05 AM, Stephen Gallagher wrote: >>> On 06/23/2009 10:49 AM, Sumit Bose wrote: >>>> fixed krb5pluginpath for different $libdir. >>>> bye, >>>> Sumit >>> Ack. I think that's the last of the issues I've seen. > >> Correction: one more (very minor) issue to address. You're linking the >> kerberos backend against libsss_crypt.la. There's no need to do this, as >> it will inherit that from the sssd_be binary. > >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > Sorry, make that two things: > Please also create a manpage for sssd-krb5 (similar to sssd-ldap.5) so > the available options are spelled out. > I have remove the library and added a short man page. I will extend the man page when more options are added. Can somebody please check the spelling and the general (mis)use of the english/american language? bye, Sumit -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-added-kerberos-locator-plugin.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-added-kerberos-backend-with-tevent_req-event-handlin.patch URL: From sgallagh at redhat.com Fri Jun 26 18:35:23 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 26 Jun 2009 14:35:23 -0400 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin In-Reply-To: <4A44EBEB.606@redhat.com> References: <4A2D6F73.7040206@redhat.com> <4A36500D.3030804@redhat.com> <1245106154.14254.62.camel@localhost.localdomain> <4A3B78EE.3090302@redhat.com> <4A40AFC1.9090109@redhat.com> <4A40C23D.3020705@redhat.com> <4A40CFB6.20502@redhat.com> <4A40DA30.8080701@redhat.com> <4A40E1A9.6040403@redhat.com> <4A40EB8C.2070302@redhat.com> <4A40EF55.2090504@redhat.com> <4A43CF04.6030509@redhat.com> <4A43CF68.8060609@redhat.com> <4A44EBEB.606@redhat.com> Message-ID: <4A4514EB.30905@redhat.com> On 06/26/2009 11:40 AM, Sumit Bose wrote: > Am 25.06.2009 21:26, schrieb Stephen Gallagher: >> On 06/25/2009 03:24 PM, Stephen Gallagher wrote: >>> On 06/23/2009 11:05 AM, Stephen Gallagher wrote: >>>> On 06/23/2009 10:49 AM, Sumit Bose wrote: >>>>> fixed krb5pluginpath for different $libdir. >>>>> bye, >>>>> Sumit >>>> Ack. I think that's the last of the issues I've seen. >>> Correction: one more (very minor) issue to address. You're linking the >>> kerberos backend against libsss_crypt.la. There's no need to do this, as >>> it will inherit that from the sssd_be binary. >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> Sorry, make that two things: >> Please also create a manpage for sssd-krb5 (similar to sssd-ldap.5) so >> the available options are spelled out. >> > > I have remove the library and added a short man page. I will extend the > man page when more options are added. Can somebody please check the > spelling and the general (mis)use of the english/american language? > > bye, > Sumit I have a few suggestions in the attached patch. If you like them, please merge them in. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Grammar-suggestions-for-sssd-krb5.xml.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From kwade at redhat.com Mon Jun 29 08:36:24 2009 From: kwade at redhat.com (Karsten Wade) Date: Mon, 29 Jun 2009 01:36:24 -0700 Subject: [Freeipa-devel] CLA or contribution policy? Message-ID: <20090629083624.GA28739@calliope.phig.org> Recently when I was asking around about the contributor license agreement (CLA) that covers FreeIPA, the Legal man asked, "What does the FreeIPA project want? Do they want a full-blown CLA or would a simpler contribution policy do?" By asking ourselves this question, we have a chance to resolve (be happier) about the current CLA, get it changed to a more useful agreement, or switch entirely to a declarative policy of some kind. On one side, an example of a fairly-loose contribution policy is that of the Linux kernel. I am having a hard time finding a clear, canonical reference, but the book by Jon Corbet, "How To Participate In The Linux Community"[1], lists a few criteria under 'Licensing' in the first chapter. In essence: license must be compatible with GPLv2, no copyright assignments required, only attributable free software is accepted. On the other side, an example of a useful CLA is the Fedora Project's, where FreeIPA's CLA originated. This large project has contributions of all types, at all levels, under many different licenses. One duty this CLA provides is giving a covering license in the case where a contribution's license is not specified. Outside of already licensed packages, this situation is common in Fedora -- people just make edits to the wiki without specifying one license or the other, so it falls under the wiki default license. The CLA has a purpose of helping to govern that situation, aiui. What should FreeIPA's policy be? IANAL, TINLA, thanks, - Karsten [1] http://ldn.linuxfoundation.org/book/1-a-guide-kernel-development-process -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sbose at redhat.com Mon Jun 29 09:37:06 2009 From: sbose at redhat.com (Sumit Bose) Date: Mon, 29 Jun 2009 11:37:06 +0200 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin In-Reply-To: <4A4514EB.30905@redhat.com> References: <4A40C23D.3020705@redhat.com> <4A40CFB6.20502@redhat.com> <4A40DA30.8080701@redhat.com> <4A40E1A9.6040403@redhat.com> <4A40EB8C.2070302@redhat.com> <4A40EF55.2090504@redhat.com> <4A43CF04.6030509@redhat.com> <4A43CF68.8060609@redhat.com> <4A44EBEB.606@redhat.com> <4A4514EB.30905@redhat.com> Message-ID: <20090629093706.GA2969@localhost.localdomain> On Fri, Jun 26, 2009 at 02:35:23PM -0400, Stephen Gallagher wrote: > On 06/26/2009 11:40 AM, Sumit Bose wrote: > > Am 25.06.2009 21:26, schrieb Stephen Gallagher: > >> On 06/25/2009 03:24 PM, Stephen Gallagher wrote: > >>> On 06/23/2009 11:05 AM, Stephen Gallagher wrote: > >>>> On 06/23/2009 10:49 AM, Sumit Bose wrote: > >>>>> fixed krb5pluginpath for different $libdir. > >>>>> bye, > >>>>> Sumit > >>>> Ack. I think that's the last of the issues I've seen. > >>> Correction: one more (very minor) issue to address. You're linking the > >>> kerberos backend against libsss_crypt.la. There's no need to do this, as > >>> it will inherit that from the sssd_be binary. > >>> _______________________________________________ > >>> Freeipa-devel mailing list > >>> Freeipa-devel at redhat.com > >>> https://www.redhat.com/mailman/listinfo/freeipa-devel > >> > >> > >> Sorry, make that two things: > >> Please also create a manpage for sssd-krb5 (similar to sssd-ldap.5) so > >> the available options are spelled out. > >> > > > > I have remove the library and added a short man page. I will extend the > > man page when more options are added. Can somebody please check the > > spelling and the general (mis)use of the english/american language? > > > > bye, > > Sumit > > I have a few suggestions in the attached patch. If you like them, please > merge them in. > Thanks. The following patch contains the suggestions from Stephen. bye, Sumit -------------- next part -------------- >From 6a8f053b5c2147151bd4e8b7a705626475662c89 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 15 Jun 2009 15:06:40 +0200 Subject: [PATCH 1/2] added kerberos locator plugin --- server/Makefile.am | 14 +++ server/conf_macros.m4 | 14 +++- server/configure.ac | 2 + server/external/krb5.m4 | 11 ++ server/krb5_plugin/sssd_krb5_locator_plugin.c | 131 +++++++++++++++++++++++++ server/krb5_plugin/sssd_krb5_locator_plugin.h | 8 ++ sssd.spec.in | 5 +- 7 files changed, 183 insertions(+), 2 deletions(-) create mode 100644 server/external/krb5.m4 create mode 100644 server/krb5_plugin/sssd_krb5_locator_plugin.c create mode 100644 server/krb5_plugin/sssd_krb5_locator_plugin.h diff --git a/server/Makefile.am b/server/Makefile.am index bed9060..b15c230 100644 --- a/server/Makefile.am +++ b/server/Makefile.am @@ -3,6 +3,7 @@ topdir=. sssdlibexecdir = $(libexecdir)/sssd sssdlibdir = $(libdir)/sssd ldblibdir = $(libdir)/ldb +krb5plugindir = @krb5pluginpath@ sssdconfdir = $(sysconfdir)/sssd dbusintrospectdir = $(datarootdir)/sssd/introspect dbuspolicydir = $(sysconfdir)/dbus-1/system.d @@ -80,6 +81,9 @@ sssdlib_LTLIBRARIES = \ ldblib_LTLIBRARIES = \ memberof.la +krb5plugin_LTLIBRARIES = \ + sssd_krb5_locator_plugin.la + noinst_LTLIBRARIES = \ libsss_crypt.la libsss_crypt_la_SOURCES = \ @@ -208,6 +212,7 @@ dist_noinst_HEADERS = \ providers/dp_backend.h \ providers/providers.h \ tools/tools_util.h \ + krb5_plugin/sssd_krb5_locator_plugin.h \ $(infopipe_headers) \ $(polkit_headers) @@ -403,6 +408,15 @@ memberof_la_LDFLAGS = \ -avoid-version \ -module +sssd_krb5_locator_plugin_la_SOURCES = \ + krb5_plugin/sssd_krb5_locator_plugin.c +sssd_krb5_locator_plugin_la_CFLAGS = \ + $(AM_CFLAGS) \ + $(KRB5_CFLAGS) +sssd_krb5_locator_plugin_la_LDFLAGS = \ + -avoid-version \ + -module + ############ # MANPAGES # ############ diff --git a/server/conf_macros.m4 b/server/conf_macros.m4 index 7e230bb..c67b47b 100644 --- a/server/conf_macros.m4 +++ b/server/conf_macros.m4 @@ -132,7 +132,6 @@ AC_DEFUN([WITH_INIT_DIR], AC_SUBST(initdir) ]) - AC_DEFUN([WITH_SHADOW_UTILS_PATH], [ AC_ARG_WITH([shadow-utils-path], [AC_HELP_STRING([--with-shadow-utils-path=PATH], @@ -177,3 +176,16 @@ AC_DEFUN([WITH_XML_CATALOG], AC_SUBST([SGML_CATALOG_FILES]) ]) +AC_DEFUN([WITH_KRB5_PLUGIN_PATH], + [ AC_ARG_WITH([krb5-plugin-path], + [AC_HELP_STRING([--with-krb5-plugin-path=PATH], + [Path to kerberos plugin store [/usr/lib/krb5/plugins/libkrb5]] + ) + ] + ) + krb5pluginpath="${libdir}/krb5/plugins/libkrb5" + if test x"$with_krb5_plugin_path" != x; then + krb5pluginpath=$with_krb5_plugin_path + fi + AC_SUBST(krb5pluginpath) + ]) diff --git a/server/configure.ac b/server/configure.ac index 8803276..facefe2 100644 --- a/server/configure.ac +++ b/server/configure.ac @@ -49,6 +49,7 @@ WITH_INIT_DIR WITH_SHADOW_UTILS_PATH WITH_MANPAGES WITH_XML_CATALOG +WITH_KRB5_PLUGIN_PATH m4_include([external/pkg.m4]) m4_include([external/libpopt.m4]) @@ -59,6 +60,7 @@ m4_include([external/libldb.m4]) m4_include([external/pam.m4]) m4_include([external/ldap.m4]) m4_include([external/libpcre.m4]) +m4_include([external/krb5.m4]) m4_include([util/signal.m4]) PKG_CHECK_MODULES([DBUS],[dbus-1]) diff --git a/server/external/krb5.m4 b/server/external/krb5.m4 new file mode 100644 index 0000000..1ed5064 --- /dev/null +++ b/server/external/krb5.m4 @@ -0,0 +1,11 @@ +AC_SUBST(KRB5_CFLAGS) +AC_SUBST(KRB5_LIBS) +AC_PATH_PROG(KRB5_CONFIG, krb5-config) +AC_MSG_CHECKING(for working krb5-config) +if test -x "$KRB5_CONFIG"; then + KRB5_CFLAGS="`$KRB5_CONFIG --cflags`" + KRB5_LIBS="`$KRB5_CONFIG --libs`" + AC_MSG_RESULT(yes) +else + AC_MSG_ERROR(no. Please install MIT kerberos devel package) +fi diff --git a/server/krb5_plugin/sssd_krb5_locator_plugin.c b/server/krb5_plugin/sssd_krb5_locator_plugin.c new file mode 100644 index 0000000..699cad4 --- /dev/null +++ b/server/krb5_plugin/sssd_krb5_locator_plugin.c @@ -0,0 +1,131 @@ +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "krb5_plugin/sssd_krb5_locator_plugin.h" + +struct sssd_ctx { + char *sssd_realm; + char *sssd_kdc; +}; + +krb5_error_code sssd_krb5_locator_init(krb5_context context, + void **private_data) +{ + struct sssd_ctx *ctx; + char *dummy; + + ctx = calloc(1,sizeof(struct sssd_ctx)); + if (ctx == NULL) return ENOMEM; + + dummy = getenv(SSSD_REALM); + if (dummy == NULL) goto failed; + ctx->sssd_realm = strdup(dummy); + if (ctx->sssd_realm == NULL) goto failed; + + dummy = getenv(SSSD_KDC); + if (dummy == NULL) goto failed; + ctx->sssd_kdc = strdup(dummy); + if (ctx->sssd_kdc == NULL) goto failed; + + *private_data = ctx; + + return 0; +failed: + free(ctx->sssd_realm); + free(ctx->sssd_kdc); + free(ctx); + + private_data = NULL; + + return EINVAL; +} + +void sssd_krb5_locator_close(void *private_data) +{ + struct sssd_ctx *ctx; + + if (private_data == NULL) return; + + ctx = (struct sssd_ctx *) private_data; + free(ctx->sssd_realm); + free(ctx->sssd_kdc); + free(ctx); + + return; +} + +krb5_error_code sssd_krb5_locator_lookup(void *private_data, + enum locate_service_type svc, + const char *realm, + int socktype, + int family, + int (*cbfunc)(void *, int, struct sockaddr *), + void *cbdata) +{ + int ret; + struct sockaddr_in addr; + struct sssd_ctx *ctx; + + if (private_data == NULL) return KRB5_PLUGIN_NO_HANDLE; + ctx = (struct sssd_ctx *) private_data; + +#ifdef KRB5_PLUGIN_DEBUG + fprintf(stderr,"[%s][%s][%s][%d][%d][%d]\n", realm, ctx->sssd_realm, + ctx->sssd_kdc, socktype, + family, svc); +#endif + + switch (svc) { + case locate_service_kdc: + case locate_service_master_kdc: + case locate_service_kadmin: + break; + case locate_service_krb524: + case locate_service_kpasswd: + return KRB5_PLUGIN_NO_HANDLE; + default: + return EINVAL; + } + + switch (family) { + case AF_UNSPEC: + case AF_INET: + break; + default: + return KRB5_PLUGIN_NO_HANDLE; + } + + switch (socktype) { + case SOCK_STREAM: + case SOCK_DGRAM: + break; + default: + return EINVAL; + } + + if (strcmp(realm, ctx->sssd_realm) != 0) + return KRB5_PLUGIN_NO_HANDLE; + + addr.sin_family = AF_INET; + ret = inet_aton(ctx->sssd_kdc, &addr.sin_addr); + if (ret == 0) return EINVAL; + addr.sin_port = htons(88); + + ret = cbfunc(cbdata, socktype, (struct sockaddr *) &addr); + + return 0; +} + +const krb5plugin_service_locate_ftable service_locator = { + 0, /* version */ + sssd_krb5_locator_init, + sssd_krb5_locator_close, + sssd_krb5_locator_lookup, +}; diff --git a/server/krb5_plugin/sssd_krb5_locator_plugin.h b/server/krb5_plugin/sssd_krb5_locator_plugin.h new file mode 100644 index 0000000..ab41689 --- /dev/null +++ b/server/krb5_plugin/sssd_krb5_locator_plugin.h @@ -0,0 +1,8 @@ +#ifndef __SSSD_KRB5_LOCATOR_PLUGIN_H__ +#define __SSSD_KRB5_LOCATOR_PLUGIN_H__ + +#define SSSD_KDC "SSSD_KDC" +#define SSSD_REALM "SSSD_REALM" + +#endif /* __SSSD_KRB5_LOCATOR_PLUGIN_H__ */ + diff --git a/sssd.spec.in b/sssd.spec.in index 2053576..719e6b7 100644 --- a/sssd.spec.in +++ b/sssd.spec.in @@ -42,6 +42,7 @@ BuildRequires: pcre-devel BuildRequires: libxslt BuildRequires: libxml2 BuildRequires: docbook-style-xsl +BuildRequires: krb5-devel %description Provides a set of daemons to manage access to remote directories and @@ -78,7 +79,8 @@ rm -f \ $RPM_BUILD_ROOT/%{_lib}/security/pam_sss.la \ $RPM_BUILD_ROOT/%{_libdir}/ldb/memberof.la \ $RPM_BUILD_ROOT/%{_libdir}/sssd/libsss_ldap.la \ - $RPM_BUILD_ROOT/%{_libdir}/sssd/libsss_proxy.la + $RPM_BUILD_ROOT/%{_libdir}/sssd/libsss_proxy.la \ + $RPM_BUILD_ROOT/%{_libdir}/krb5/plugins/libkrb5/sssd_krb5_locator_plugin.la %clean rm -rf $RPM_BUILD_ROOT @@ -97,6 +99,7 @@ rm -rf $RPM_BUILD_ROOT %{_libexecdir}/%{servicename}/ %{_libdir}/%{name}/ %{_libdir}/ldb/memberof.so +%{_libdir}/krb5/plugins/libkrb5/* %dir %{_sharedstatedir}/sss/ %attr(700,root,root) %dir %{_sharedstatedir}/sss/db %dir %{_sharedstatedir}/sss/pipes -- 1.6.2.5 -------------- next part -------------- >From 5ee778d685d7b4271451dbcf1e450bec2509ffca Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 15 Jun 2009 15:07:39 +0200 Subject: [PATCH 2/2] added kerberos backend with tevent_req event handling --- server/Makefile.am | 17 +- server/man/sssd-krb5.5.xml | 98 ++++++ server/providers/data_provider.h | 2 + server/providers/dp_auth_util.c | 6 + server/providers/krb5/krb5_auth.c | 585 +++++++++++++++++++++++++++++++++ server/providers/krb5/krb5_auth.h | 92 +++++ server/providers/krb5/tgt_req_child.c | 179 ++++++++++ server/responder/pam/pamsrv_cmd.c | 20 +- sss_client/pam_sss.c | 2 +- sssd.spec.in | 1 + 10 files changed, 999 insertions(+), 3 deletions(-) create mode 100644 server/man/sssd-krb5.5.xml create mode 100644 server/providers/krb5/krb5_auth.c create mode 100644 server/providers/krb5/krb5_auth.h create mode 100644 server/providers/krb5/tgt_req_child.c diff --git a/server/Makefile.am b/server/Makefile.am index b15c230..01f3037 100644 --- a/server/Makefile.am +++ b/server/Makefile.am @@ -76,6 +76,7 @@ endif sssdlib_LTLIBRARIES = \ libsss_ldap.la \ + libsss_krb5.la \ libsss_proxy.la ldblib_LTLIBRARIES = \ @@ -211,6 +212,7 @@ dist_noinst_HEADERS = \ providers/dp_interfaces.h \ providers/dp_backend.h \ providers/providers.h \ + providers/krb5/krb5_auth.h \ tools/tools_util.h \ krb5_plugin/sssd_krb5_locator_plugin.h \ $(infopipe_headers) \ @@ -400,6 +402,19 @@ libsss_proxy_la_LDFLAGS = \ -version-info 1:0:0 \ -module +libsss_krb5_la_SOURCES = \ + providers/krb5/krb5_auth.c \ + providers/krb5/tgt_req_child.c +libsss_krb5_la_CFLAGS = \ + $(AM_CFLAGS) \ + $(KRB5_CFLAGS) +libsss_krb5_la_LIBADD = \ + $(PAM_LIBS) \ + $(KRB5_LIBS) +libsss_krb5_la_LDFLAGS = \ + -version-info 1:0:0 \ + -module + memberof_la_SOURCES = \ ldb_modules/memberof.c memberof_la_CFLAGS = \ @@ -429,7 +444,7 @@ XSLTPROC_FLAGS = --catalogs --xinclude --nonet dist_man_MANS = man/sss_useradd.8 man/sss_userdel.8 man/sss_usermod.8 \ man/sss_groupadd.8 man/sss_groupdel.8 man/sss_groupmod.8 \ - man/sssd.8 man/sssd.conf.5 man/sssd-ldap.5 + man/sssd.8 man/sssd.conf.5 man/sssd-ldap.5 man/sssd-krb5.5 SUFFIXES = .1.xml .1 .3.xml .3 .5.xml .5 .8.xml .8 .1.xml.1: diff --git a/server/man/sssd-krb5.5.xml b/server/man/sssd-krb5.5.xml new file mode 100644 index 0000000..a75193a --- /dev/null +++ b/server/man/sssd-krb5.5.xml @@ -0,0 +1,98 @@ + + + +SSSD Manual pages + + + + + sssd-krb5 + 5 + File Formats and Conventions + + + + sssd-krb5 + the configuration file for SSSD + + + + DESCRIPTION + + This manual page describes the configuration of the Kerberos + 5 authentication backend for + + sssd + 8 + . + For a detailed syntax reference, please refer to the FILE FORMAT section of the + + sssd.conf + 5 + manual page + + + + + CONFIGURATION OPTIONS + + If the auth-module krb5 is used in a SSSD domain, the following + options must be used. See the + + sssd.conf + 5 + manual page, section DOMAIN SECTIONS + for details on the configuration of a SSSD domain. + + + krb5KDCIP (string) + + + Specifies the IP address of the Kerberos server. + + + + + + krb5REALM (string) + + + The name of the Kerberos realm. + + + + + + + + + EXAMPLE + + The following example assumes that SSSD is correctly + configured and FOO is one of the domains in the + [domains] section. + + + + [domains/FOO] + auth-module = krb5 + krb5KDCIP = 192.168.1.1 + krb5REALM = EXAMPLE.COM + + + + + + SEE ALSO + + + sssd.conf5 + , + + sssd8 + + + + + diff --git a/server/providers/data_provider.h b/server/providers/data_provider.h index 95a1b37..b747e69 100644 --- a/server/providers/data_provider.h +++ b/server/providers/data_provider.h @@ -117,6 +117,8 @@ struct pam_data { bool offline_auth; int priv; + uid_t pw_uid; + gid_t gr_gid; }; void pam_print_data(int l, struct pam_data *pd); diff --git a/server/providers/dp_auth_util.c b/server/providers/dp_auth_util.c index 279e50b..7219917 100644 --- a/server/providers/dp_auth_util.c +++ b/server/providers/dp_auth_util.c @@ -35,6 +35,8 @@ void pam_print_data(int l, struct pam_data *pd) DEBUG(l, ("newauthtok type: %d\n", pd->newauthtok_type)); DEBUG(l, ("newauthtok size: %d\n", pd->newauthtok_size)); DEBUG(l, ("priv: %d\n", pd->priv)); + DEBUG(l, ("pw_uid: %d\n", pd->pw_uid)); + DEBUG(l, ("gr_gid: %d\n", pd->gr_gid)); } int pam_add_response(struct pam_data *pd, enum response_type type, @@ -83,6 +85,8 @@ bool dp_pack_pam_request(DBusMessage *msg, struct pam_data *pd) &(pd->newauthtok), pd->newauthtok_size, DBUS_TYPE_INT32, &(pd->priv), + DBUS_TYPE_INT32, &(pd->pw_uid), + DBUS_TYPE_INT32, &(pd->gr_gid), DBUS_TYPE_INVALID); return ret; @@ -109,6 +113,8 @@ bool dp_unpack_pam_request(DBusMessage *msg, struct pam_data *pd, DBusError *dbu &(pd->newauthtok), &(pd->newauthtok_size), DBUS_TYPE_INT32, &(pd->priv), + DBUS_TYPE_INT32, &(pd->pw_uid), + DBUS_TYPE_INT32, &(pd->gr_gid), DBUS_TYPE_INVALID); return ret; diff --git a/server/providers/krb5/krb5_auth.c b/server/providers/krb5/krb5_auth.c new file mode 100644 index 0000000..ce26614 --- /dev/null +++ b/server/providers/krb5/krb5_auth.c @@ -0,0 +1,585 @@ +/* + SSSD + + Kerberos 5 Backend Module + + Authors: + Sumit Bose + + Copyright (C) 2009 Red Hat + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . +*/ + + +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "util/util.h" +#include "providers/dp_backend.h" +#include "db/sysdb.h" +#include "../sss_client/sss_cli.h" +#include "krb5_plugin/sssd_krb5_locator_plugin.h" +#include "providers/krb5/krb5_auth.h" + +static void fd_nonblocking(int fd) { + int flags; + + flags = fcntl(fd, F_GETFL, 0); + if (flags == -1) { + DEBUG(1, ("F_GETFL failed [%d][%s].\n", errno, strerror(errno))); + return; + } + + if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) == -1) { + DEBUG(1, ("F_SETFL failed [%d][%s].\n", errno, strerror(errno))); + } + + return; +} + +static int save_cc_file(size_t len, uint8_t *buf) +{ + + return EOK; +} +static void krb5_cleanup(struct krb5_req *kr) +{ + if (kr == NULL) return; + + /* FIXME: is it safe to drop the "!= NULL" checks? */ + if (kr->options != NULL) + krb5_get_init_creds_opt_free(kr->ctx, kr->options); + if (kr->creds != NULL) + krb5_free_cred_contents(kr->ctx, kr->creds); + if (kr->name != NULL) + krb5_free_unparsed_name(kr->ctx, kr->name); + if (kr->princ != NULL) + krb5_free_principal(kr->ctx, kr->princ); + if (kr->cc != NULL) + krb5_cc_close(kr->ctx, kr->cc); + if (kr->ctx != NULL) + krb5_free_context(kr->ctx); + + talloc_free(kr); +} + +static int krb5_setup(struct be_req *req, struct krb5_req **krb5_req) +{ + struct krb5_req *kr = NULL; + struct krb5_ctx *krb5_ctx; + struct pam_data *pd; + krb5_error_code kerr = 0; + char *user_princ_str = NULL; + + pd = talloc_get_type(req->req_data, struct pam_data); + + krb5_ctx = talloc_get_type(req->be_ctx->pvt_auth_data, struct krb5_ctx); + + kr = talloc_zero(req, struct krb5_req); + if (kr == NULL) { + DEBUG(1, ("talloc failed.\n")); + kerr = ENOMEM; + goto failed; + } + + kr->pd = pd; + kr->req = req; + + kerr = krb5_init_context(&kr->ctx); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto failed; + } + +/* TODO: try to read user principal from id backend, use user + realm as a + fallback */ + if (kr->pd->user != NULL && krb5_ctx->realm != NULL) { + user_princ_str = talloc_asprintf(kr, "%s@%s", kr->pd->user, + krb5_ctx->realm); + } + if (user_princ_str == NULL) { + DEBUG(1, ("talloc_asprintf failed.\n")); + kerr = ENOMEM; + goto failed; + } + + kerr = krb5_parse_name(kr->ctx, user_princ_str, &kr->princ); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto failed; + } + + kerr = krb5_unparse_name(kr->ctx, kr->princ, &kr->name); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto failed; + } + + kr->creds = talloc_zero(kr, krb5_creds); + if (kr->creds == NULL) { + DEBUG(1, ("talloc_zero failed.\n")); + kerr = ENOMEM; + goto failed; + } + + kerr = krb5_get_init_creds_opt_alloc(kr->ctx, &kr->options); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto failed; + } + +/* TODO: set options, e.g. + * krb5_get_init_creds_opt_set_tkt_life + * krb5_get_init_creds_opt_set_renew_life + * krb5_get_init_creds_opt_set_forwardable + * krb5_get_init_creds_opt_set_proxiable + * krb5_get_init_creds_opt_set_etype_list + * krb5_get_init_creds_opt_set_address_list + * krb5_get_init_creds_opt_set_preauth_list + * krb5_get_init_creds_opt_set_salt + * krb5_get_init_creds_opt_set_change_password_prompt + * krb5_get_init_creds_opt_set_pa + */ + + *krb5_req = kr; + return EOK; + +failed: + krb5_cleanup(kr); + + return kerr; +} + +/* TODO: remove later + * These functions are available in the latest tevent and are the ones that + * should be used as tevent_req is rightfully opaque there */ +#ifndef tevent_req_data +#define tevent_req_data(req, type) ((type *)req->private_state) +#endif + +#ifndef tevent_req_set_callback +#define tevent_req_set_callback(req, func, data) \ + do { req->async.fn = func; req->async.private_data = data; } while(0) +#endif + +#ifndef tevent_req_callback_data +#define tevent_req_callback_data(req, type) ((type *)req->async.private_data) +#endif + +static void wait_for_child_handler(struct tevent_context *ev, + struct tevent_signal *sige, int signum, + int count, void *__siginfo, void *pvt) +{ + int ret; + int child_status; + siginfo_t *siginfo = (siginfo_t *)__siginfo; + + errno = 0; + do { + ret = waitpid(siginfo->si_pid, &child_status, WNOHANG); + } while (ret == -1 && errno == EINTR); + if (ret == siginfo->si_pid) { + DEBUG(4, ("child status [%d].\n", child_status)); + if (WEXITSTATUS(child_status) != 0) { + DEBUG(1, ("child failed.\n")); + } + } else if (ret == 0) { + DEBUG(1, ("waitpid did not found a child with changed status.\n", ret)); + } else if (ret >= 0 && ret != siginfo->si_pid) { + DEBUG(1, ("waitpid returned wrong child pid [%d], continue waiting.\n", ret)); + } else if (ret == -1 && errno == ECHILD) { + DEBUG(1, ("no child with pid [%d].\n", siginfo->si_pid)); + } else { + DEBUG(1, ("waitpid failed [%s].\n", strerror(errno))); + } + + return; +} + +static int fork_tgt_req_child(struct krb5_req *kr) +{ + int pipefd[2]; + pid_t pid; + int ret; + + ret = pipe(pipefd); + if (ret == -1) { + DEBUG(1, ("pipe failed [%d][%s].\n", errno, strerror(errno))); + return -1; + } + pid = fork(); + + if (pid == 0) { /* child */ + close(pipefd[0]); + tgt_req_child(pipefd[1], kr); + } else if (pid > 0) { /* parent */ + kr->child_pid = pid; + kr->fd = pipefd[0]; + close(pipefd[1]); + + fd_nonblocking(kr->fd); + + } else { /* error */ + DEBUG(1, ("fork failed [%d][%s].\n", errno, strerror(errno))); + return -1; + } + + return EOK; +} + + +struct read_pipe_state { + int fd; + uint8_t *buf; + size_t len; +}; + +static void read_pipe_done(struct tevent_context *ev, struct tevent_fd *fde, + uint16_t flags, void *pvt); + +static struct tevent_req *read_pipe_send(TALLOC_CTX *memctx, + struct tevent_context *ev, + int fd) +{ + struct tevent_req *req; + struct read_pipe_state *state; + struct tevent_fd *fde; + + + req = tevent_req_create(memctx, &state, struct read_pipe_state); + if (req == NULL) return NULL; + + state->fd = fd; + state->buf = talloc_array(state, uint8_t, MAX_CHILD_MSG_SIZE); + if (state->buf == NULL) goto fail; + + fde = tevent_add_fd(ev, state, fd, TEVENT_FD_READ, + read_pipe_done, req); + if (fde == NULL) { + DEBUG(1, ("tevent_add_fd failed.\n")); + goto fail; + } + + return req; + +fail: + talloc_zfree(req); + return NULL; +} + +static void read_pipe_done(struct tevent_context *ev, struct tevent_fd *fde, + uint16_t flags, void *pvt) +{ + ssize_t size; + struct tevent_req *req = talloc_get_type(pvt, struct tevent_req); + struct read_pipe_state *state = tevent_req_data(req, struct read_pipe_state); + + if (flags & TEVENT_FD_WRITE) { + DEBUG(1, ("client_response_handler called with TEVENT_FD_WRITE, this should not happen.\n")); + tevent_req_error(req, EINVAL); + return; + } + + size = read(state->fd, state->buf, talloc_get_size(state->buf)); + if (size == -1) { + if (errno == EAGAIN || errno == EINTR) return; + DEBUG(1, ("read failed [%d][%s].\n", errno, strerror(errno))); + tevent_req_error(req, errno); + return; + } + state->len = size; + + tevent_req_done(req); + return; +} + +static ssize_t read_pipe_recv(struct tevent_req *req, TALLOC_CTX *mem_ctx, + uint8_t **buf, uint64_t *error) { + struct read_pipe_state *state = tevent_req_data(req, + struct read_pipe_state); + enum tevent_req_state tstate; + + if (tevent_req_is_error(req, &tstate, error)) { + return -1; + } + + *buf = talloc_move(mem_ctx, &state->buf); + return state->len; +} + +struct tgt_req_state { + struct krb5_req *kr; + ssize_t len; + uint8_t *buf; +}; + +static void tgt_req_done(struct tevent_req *subreq); + +static struct tevent_req *tgt_req_send(TALLOC_CTX *mem_ctx, struct tevent_context *ev, + struct krb5_req *kr) +{ + int ret; + struct tevent_req *req; + struct tevent_req *subreq; + struct tgt_req_state *state; + + ret = fork_tgt_req_child(kr); + if (ret != EOK) { + DEBUG(1, ("fork_tgt_req_child failed.\n")); + return NULL; + } + + req = tevent_req_create(mem_ctx, &state, struct tgt_req_state); + if (req == NULL) { + return NULL; + } + + state->kr = kr; + + subreq = read_pipe_send(state, ev, kr->fd); + if (tevent_req_nomem(subreq, req)) { + return tevent_req_post(req, ev); + } + tevent_req_set_callback(subreq, tgt_req_done, req); + return req; +} + +static void tgt_req_done(struct tevent_req *subreq) +{ + struct tevent_req *req = tevent_req_callback_data(subreq, + struct tevent_req); + struct tgt_req_state *state = tevent_req_data(req, struct tgt_req_state); + uint64_t error; + + state->len = read_pipe_recv(subreq, state, &state->buf, &error); + talloc_zfree(subreq); + close(state->kr->fd); + if (state->len == -1) { + tevent_req_error(req, error); + return; + } + + tevent_req_done(req); + return; +} + +static ssize_t tgt_req_recv(struct tevent_req *req, TALLOC_CTX *mem_ctx, + uint8_t **buf, uint64_t *error) { + struct tgt_req_state *state = tevent_req_data(req, struct tgt_req_state); + enum tevent_req_state tstate; + + if (tevent_req_is_error(req, &tstate, error)) { + return -1; + } + + *buf = talloc_move(mem_ctx, &state->buf); + return state->len; +} + +static void krb5_pam_handler_done(struct tevent_req *req); + +static void krb5_pam_handler(struct be_req *be_req) +{ + struct krb5_req *kr = NULL; + struct tevent_req *req; + int ret; + struct pam_data *pd; + int pam_status=PAM_SYSTEM_ERR; + + pd = talloc_get_type(be_req->req_data, struct pam_data); + + if (pd->cmd != SSS_PAM_AUTHENTICATE) { + DEBUG(4, ("krb5 does not handles pam task %d.\n", pd->cmd)); + pam_status = PAM_SUCCESS; + goto done; + } + + ret = krb5_setup(be_req, &kr); + if (ret != EOK) { + DEBUG(1, ("krb5_setup failed.\n")); + goto done; + } + + req = tgt_req_send(be_req, be_req->be_ctx->ev, kr); + if (req == NULL) { + DEBUG(1, ("tgt_req_send failed.\n")); + goto done; + } + + tevent_req_set_callback(req, krb5_pam_handler_done, kr); + return; + +done: + krb5_cleanup(kr); + + pd->pam_status = pam_status; + + be_req->fn(be_req, pam_status, NULL); +} + +static void krb5_pam_handler_done(struct tevent_req *req) +{ + struct krb5_req *kr = tevent_req_callback_data(req, struct krb5_req); + struct pam_data *pd = kr->pd; + struct be_req *be_req = kr->req; + struct krb5_ctx *krb5_ctx = talloc_get_type(be_req->be_ctx->pvt_auth_data, + struct krb5_ctx); + struct tgt_req_state *state = tevent_req_data(req, struct tgt_req_state); + int ret; + uint8_t *buf; + ssize_t len; + uint64_t error; + int p; + int32_t *msg_status; + int32_t *msg_type; + int32_t *msg_len; + + pd->pam_status = PAM_SYSTEM_ERR; + krb5_cleanup(kr); + + len = tgt_req_recv(req, state, &buf, &error); + talloc_zfree(req); + if (len == -1) { + DEBUG(1, ("tgt_req request failed\n")); + goto done; + } + + if ((size_t) len < 3*sizeof(int32_t)) { + DEBUG(1, ("message too short.\n")); + goto done; + } + + p=0; + msg_status = ((int32_t *)(buf+p)); + p += sizeof(int32_t); + + msg_type = ((int32_t *)(buf+p)); + p += sizeof(int32_t); + + msg_len = ((int32_t *)(buf+p)); + p += sizeof(int32_t); + + DEBUG(4, ("child response [%d][%d][%d].\n", *msg_status, *msg_type, + *msg_len)); + + if ((p + *msg_len) != len) { + DEBUG(1, ("message format error.\n")); + goto done; + } + + if (msg_type == PAM_ENV_ITEM && krb5_ctx->enable_cc_remover == TRUE) { + ret = save_cc_file(*msg_len, &buf[p]); + if (ret != EOK) { + DEBUG(2, ("save_cc_file failed. cc_remover might not be able to " + "remove this file\n")); + } + } + + ret=pam_add_response(kr->pd, *msg_type, *msg_len, &buf[p]); + if (ret != EOK) { + DEBUG(1, ("pam_add_response failed.\n")); + goto done; + } + + pd->pam_status = *msg_status; + +done: + be_req->fn(be_req, pd->pam_status, NULL); +} + + +struct be_auth_ops krb5_auth_ops = { + .pam_handler = krb5_pam_handler, + .finalize = NULL, +}; + + +int sssm_krb5_auth_init(struct be_ctx *bectx, struct be_auth_ops **ops, + void **pvt_auth_data) +{ + struct krb5_ctx *ctx = NULL; + bool bool_value = FALSE; + char *value = NULL; + int ret; + struct tevent_signal *sige; + + ctx = talloc_zero(bectx, struct krb5_ctx); + if (!ctx) { + DEBUG(1, ("talloc failed.\n")); + return ENOMEM; + } + + ctx->action = INIT_PW; + + ret = confdb_get_bool(bectx->cdb, ctx, bectx->conf_path, + "enableCCRemover", FALSE, &bool_value); + if (ret != EOK) goto fail; + ctx->enable_cc_remover = bool_value; + + ret = confdb_get_string(bectx->cdb, ctx, bectx->conf_path, + "krb5KDCIP", NULL, &value); + if (ret != EOK) goto fail; + if (value == NULL) { + DEBUG(2, ("Missing krb5KDCIP, authentication might fail.\n")); + } else { + ret = setenv(SSSD_KDC, value, 1); + if (ret != EOK) { + DEBUG(2, ("setenv %s failed, authentication might fail.\n", + SSSD_KDC)); + } + } + ctx->kdcip = value; + + ret = confdb_get_string(bectx->cdb, ctx, bectx->conf_path, + "krb5REALM", NULL, &value); + if (ret != EOK) goto fail; + if (value == NULL) { + DEBUG(4, ("Missing krb5REALM authentication might fail.\n")); + } else { + ret = setenv(SSSD_REALM, value, 1); + if (ret != EOK) { + DEBUG(2, ("setenv %s failed, authentication might fail.\n", + SSSD_REALM)); + } + } + ctx->realm = value; + +/* TODO: set options */ + + sige = tevent_add_signal(bectx->ev, ctx, SIGCHLD, SA_SIGINFO, + wait_for_child_handler, NULL); + if (sige == NULL) { + DEBUG(1, ("tevent_add_signal failed.\n")); + ret = ENOMEM; + goto fail; + } + + + *ops = &krb5_auth_ops; + *pvt_auth_data = ctx; + return EOK; + +fail: + talloc_free(ctx); + return ret; +} diff --git a/server/providers/krb5/krb5_auth.h b/server/providers/krb5/krb5_auth.h new file mode 100644 index 0000000..4ae91dd --- /dev/null +++ b/server/providers/krb5/krb5_auth.h @@ -0,0 +1,92 @@ +/* + SSSD + + Kerberos Backend, private header file + + Authors: + Sumit Bose + + Copyright (C) 2009 Red Hat + + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . +*/ + +#ifndef __KRB5_AUTH_H__ +#define __KRB5_AUTH_H__ + +#define MAX_CHILD_MSG_SIZE 255 +#define CCACHE_ENV_NAME "KRB5CCNAME" + +typedef enum { INIT_PW, INIT_KT, RENEW, VALIDATE } action_type; + +struct krb5_ctx { + /* opts taken from kinit */ + /* in seconds */ + krb5_deltat starttime; + krb5_deltat lifetime; + krb5_deltat rlife; + + int forwardable; + int proxiable; + int addresses; + + int not_forwardable; + int not_proxiable; + int no_addresses; + + int verbose; + + char* principal_name; + char* service_name; + char* keytab_name; + char* k5_cache_name; + char* k4_cache_name; + + action_type action; + + int num_pa_opts; + krb5_gic_opt_pa_data *pa_opts; + + char *kdcip; + char *realm; + bool enable_cc_remover; +}; + +struct krb5_req { + krb5_context ctx; + krb5_ccache cc; + krb5_principal princ; + char* name; + krb5_creds *creds; + krb5_get_init_creds_opt *options; + pid_t child_pid; + int fd; + + struct be_req *req; + struct pam_data *pd; + struct krb5_ctx *krb5_ctx; +}; + +static krb5_context krb5_error_ctx; +static const char *__krb5_error_msg; +#define KRB5_DEBUG(level, krb5_error) do { \ + __krb5_error_msg = krb5_get_error_message(krb5_error_ctx, krb5_error); \ + DEBUG(level, ("%d: [%d][%s]\n", __LINE__, krb5_error, __krb5_error_msg)); \ + krb5_free_error_message(krb5_error_ctx, __krb5_error_msg); \ +} while(0); + +void tgt_req_child(int fd, struct krb5_req *kr); + +#endif /* __KRB5_AUTH_H__ */ diff --git a/server/providers/krb5/tgt_req_child.c b/server/providers/krb5/tgt_req_child.c new file mode 100644 index 0000000..edb3d18 --- /dev/null +++ b/server/providers/krb5/tgt_req_child.c @@ -0,0 +1,179 @@ +/* + SSSD + + Kerberos 5 Backend Module -- tgt_req child + + Authors: + Sumit Bose + + Copyright (C) 2009 Red Hat + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . +*/ +#include +#include + +#include + +#include "util/util.h" +#include "providers/dp_backend.h" +#include "providers/krb5/krb5_auth.h" + +static int pack_response_packet(uint8_t *buf, int status, int type, + const char *data) +{ + int len; + int p=0; + + if ((3*sizeof(int32_t) + strlen(data)+1) > MAX_CHILD_MSG_SIZE) { + return -1; + } + + ((int32_t *)(&buf[p]))[0] = status; + p += sizeof(int32_t); + + ((int32_t *)(&buf[p]))[0] = type; + p += sizeof(int32_t); + + len = strlen(data)+1; + ((int32_t *)(&buf[p]))[0] = len; + p += sizeof(int32_t); + + memcpy(&buf[p], data, len); + p += len; + + return p; +} + +void tgt_req_child(int fd, struct krb5_req *kr) +{ + int ret; + krb5_error_code kerr = 0; + char *pass_str = NULL; + uint8_t buf[MAX_CHILD_MSG_SIZE]; + int size = 0; + const char *cc_name; + char *env; + const char *krb5_error_msg; + + ret = setgid(kr->pd->gr_gid); + if (ret == -1) { + DEBUG(1, ("setgid failed [%d][%s].\n", errno, strerror(errno))); + _exit(-1); + } + + ret = setuid(kr->pd->pw_uid); + if (ret == -1) { + DEBUG(1, ("setuid failed [%d][%s].\n", errno, strerror(errno))); + _exit(-1); + } + + ret = setegid(kr->pd->gr_gid); + if (ret == -1) { + DEBUG(1, ("setegid failed [%d][%s].\n", errno, strerror(errno))); + _exit(-1); + } + + ret = seteuid(kr->pd->pw_uid); + if (ret == -1) { + DEBUG(1, ("seteuid failed [%d][%s].\n", errno, strerror(errno))); + _exit(-1); + } + + pass_str = talloc_strndup(kr, (const char *) kr->pd->authtok, + kr->pd->authtok_size); + if (pass_str == NULL) { + DEBUG(1, ("talloc_strndup failed.\n")); + _exit(-1); + } + + kerr = krb5_get_init_creds_password(kr->ctx, kr->creds, kr->princ, + pass_str, NULL, NULL, 0, NULL, + kr->options); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto childfailed; + } + + memset(pass_str, 0, kr->pd->authtok_size); + talloc_free(pass_str); + memset(kr->pd->authtok, 0, kr->pd->authtok_size); + + kerr = krb5_cc_default(kr->ctx, &kr->cc); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto childfailed; + } + + kerr = krb5_cc_initialize(kr->ctx, kr->cc, kr->princ); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto childfailed; + } + + kerr = krb5_cc_store_cred(kr->ctx, kr->cc, kr->creds); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + krb5_cc_destroy(kr->ctx, kr->cc); + goto childfailed; + } + + cc_name = krb5_cc_get_name(kr->ctx, kr->cc); + if (cc_name == NULL) { + DEBUG(1, ("krb5_cc_get_name failed.\n")); + krb5_cc_destroy(kr->ctx, kr->cc); + _exit(-1); + } + + env = talloc_asprintf(kr, "%s=%s",CCACHE_ENV_NAME, cc_name); + if (env == NULL) { + DEBUG(1, ("talloc_asprintf failed.\n")); + krb5_cc_destroy(kr->ctx, kr->cc); + _exit(-1); + } + + size = pack_response_packet(buf, PAM_SUCCESS, PAM_ENV_ITEM, env); + if (size < 0) { + DEBUG(1, ("failed to create response message.\n")); + krb5_cc_destroy(kr->ctx, kr->cc); + _exit(-1); + } + + kerr = 0; + +childfailed: + if (kerr != 0 ) { + krb5_error_msg = krb5_get_error_message(krb5_error_ctx, kerr); + size = pack_response_packet(buf, PAM_SYSTEM_ERR, PAM_USER_INFO, + krb5_error_msg); + if (size < 0) { + DEBUG(1, ("failed to create response message.\n")); + krb5_cc_destroy(kr->ctx, kr->cc); + _exit(-1); + } + krb5_free_error_message(krb5_error_ctx, krb5_error_msg); + } + + ret = write(fd, buf, size); + if (ret == -1) { + DEBUG(1, ("write failed [%d][%s].\n", errno, strerror(errno))); + krb5_cc_destroy(kr->ctx, kr->cc); + _exit(ret); + } + + krb5_cc_close(kr->ctx, kr->cc); + + + _exit(0); +} diff --git a/server/responder/pam/pamsrv_cmd.c b/server/responder/pam/pamsrv_cmd.c index e065490..9b02146 100644 --- a/server/responder/pam/pamsrv_cmd.c +++ b/server/responder/pam/pamsrv_cmd.c @@ -22,6 +22,7 @@ #include #include "util/util.h" +#include "db/sysdb.h" #include "confdb/confdb.h" #include "responder/common/responder_packet.h" #include "responder/common/responder.h" @@ -387,7 +388,6 @@ static int pam_forwarder(struct cli_ctx *cctx, int pam_cmd) size_t blen; int timeout; int ret; - preq = talloc_zero(cctx, struct pam_auth_req); if (!preq) { return ENOMEM; @@ -716,6 +716,24 @@ static void pam_check_user_callback(void *ptr, int status, case 1: /* BINGO */ + preq->pd->pw_uid = + ldb_msg_find_attr_as_int(res->msgs[0], SYSDB_UIDNUM, -1); + if (preq->pd->pw_uid == -1) { + DEBUG(1, ("Failed to find uid for user [%s] in domain [%s].\n", + preq->pd->user, preq->pd->domain)); + preq->pd->pam_status = PAM_SYSTEM_ERR; + pam_reply(preq); + } + + preq->pd->gr_gid = + ldb_msg_find_attr_as_int(res->msgs[0], SYSDB_GIDNUM, -1); + if (preq->pd->gr_gid == -1) { + DEBUG(1, ("Failed to find gid for user [%s] in domain [%s].\n", + preq->pd->user, preq->pd->domain)); + preq->pd->pam_status = PAM_SYSTEM_ERR; + pam_reply(preq); + } + pam_dom_forwarder(preq); return; diff --git a/sss_client/pam_sss.c b/sss_client/pam_sss.c index ccc205c..a10e0ea 100644 --- a/sss_client/pam_sss.c +++ b/sss_client/pam_sss.c @@ -426,7 +426,7 @@ static int eval_response(pam_handle_t *pamh, size_t buflen, uint8_t *buf) break; } logger(pamh, LOG_INFO, "user info: [%s]", &buf[p]); - ret = do_pam_conversation(pamh, PAM_USER_INFO, (char *) &buf[p], + ret = do_pam_conversation(pamh, PAM_TEXT_INFO, (char *) &buf[p], NULL, NULL); if (ret != PAM_SUCCESS) { D(("do_pam_conversation, canot display user info.")); diff --git a/sssd.spec.in b/sssd.spec.in index 719e6b7..1fa847d 100644 --- a/sssd.spec.in +++ b/sssd.spec.in @@ -80,6 +80,7 @@ rm -f \ $RPM_BUILD_ROOT/%{_libdir}/ldb/memberof.la \ $RPM_BUILD_ROOT/%{_libdir}/sssd/libsss_ldap.la \ $RPM_BUILD_ROOT/%{_libdir}/sssd/libsss_proxy.la \ + $RPM_BUILD_ROOT/%{_libdir}/sssd/libsss_krb5.la \ $RPM_BUILD_ROOT/%{_libdir}/krb5/plugins/libkrb5/sssd_krb5_locator_plugin.la %clean -- 1.6.2.5 From sbose at redhat.com Mon Jun 29 09:58:10 2009 From: sbose at redhat.com (Sumit Bose) Date: Mon, 29 Jun 2009 11:58:10 +0200 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin In-Reply-To: <20090629093706.GA2969@localhost.localdomain> References: <4A40CFB6.20502@redhat.com> <4A40DA30.8080701@redhat.com> <4A40E1A9.6040403@redhat.com> <4A40EB8C.2070302@redhat.com> <4A40EF55.2090504@redhat.com> <4A43CF04.6030509@redhat.com> <4A43CF68.8060609@redhat.com> <4A44EBEB.606@redhat.com> <4A4514EB.30905@redhat.com> <20090629093706.GA2969@localhost.localdomain> Message-ID: <20090629095810.GC2969@localhost.localdomain> On Mon, Jun 29, 2009 at 11:37:06AM +0200, Sumit Bose wrote: > On Fri, Jun 26, 2009 at 02:35:23PM -0400, Stephen Gallagher wrote: > > On 06/26/2009 11:40 AM, Sumit Bose wrote: > > > Am 25.06.2009 21:26, schrieb Stephen Gallagher: > > >> On 06/25/2009 03:24 PM, Stephen Gallagher wrote: > > >>> On 06/23/2009 11:05 AM, Stephen Gallagher wrote: > > >>>> On 06/23/2009 10:49 AM, Sumit Bose wrote: > > >>>>> fixed krb5pluginpath for different $libdir. > > >>>>> bye, > > >>>>> Sumit > > >>>> Ack. I think that's the last of the issues I've seen. > > >>> Correction: one more (very minor) issue to address. You're linking the > > >>> kerberos backend against libsss_crypt.la. There's no need to do this, as > > >>> it will inherit that from the sssd_be binary. > > >>> _______________________________________________ > > >>> Freeipa-devel mailing list > > >>> Freeipa-devel at redhat.com > > >>> https://www.redhat.com/mailman/listinfo/freeipa-devel > > >> > > >> > > >> Sorry, make that two things: > > >> Please also create a manpage for sssd-krb5 (similar to sssd-ldap.5) so > > >> the available options are spelled out. > > >> > > > > > > I have remove the library and added a short man page. I will extend the > > > man page when more options are added. Can somebody please check the > > > spelling and the general (mis)use of the english/american language? > > > > > > bye, > > > Sumit > > > > I have a few suggestions in the attached patch. If you like them, please > > merge them in. > > > > Thanks. The following patch contains the suggestions from Stephen. > > bye, > Sumit Sorry, the previous patch contained some hunks from a different patch. Please use the ones attached to this email. bye, Sumit -------------- next part -------------- >From bcd06b3a7a0e4b2080d15ebcd964fd0adde64050 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 15 Jun 2009 15:06:40 +0200 Subject: [PATCH 1/2] added kerberos locator plugin --- server/Makefile.am | 14 +++ server/conf_macros.m4 | 14 +++- server/configure.ac | 2 + server/external/krb5.m4 | 11 ++ server/krb5_plugin/sssd_krb5_locator_plugin.c | 131 +++++++++++++++++++++++++ server/krb5_plugin/sssd_krb5_locator_plugin.h | 8 ++ sssd.spec.in | 5 +- 7 files changed, 183 insertions(+), 2 deletions(-) create mode 100644 server/external/krb5.m4 create mode 100644 server/krb5_plugin/sssd_krb5_locator_plugin.c create mode 100644 server/krb5_plugin/sssd_krb5_locator_plugin.h diff --git a/server/Makefile.am b/server/Makefile.am index bed9060..b15c230 100644 --- a/server/Makefile.am +++ b/server/Makefile.am @@ -3,6 +3,7 @@ topdir=. sssdlibexecdir = $(libexecdir)/sssd sssdlibdir = $(libdir)/sssd ldblibdir = $(libdir)/ldb +krb5plugindir = @krb5pluginpath@ sssdconfdir = $(sysconfdir)/sssd dbusintrospectdir = $(datarootdir)/sssd/introspect dbuspolicydir = $(sysconfdir)/dbus-1/system.d @@ -80,6 +81,9 @@ sssdlib_LTLIBRARIES = \ ldblib_LTLIBRARIES = \ memberof.la +krb5plugin_LTLIBRARIES = \ + sssd_krb5_locator_plugin.la + noinst_LTLIBRARIES = \ libsss_crypt.la libsss_crypt_la_SOURCES = \ @@ -208,6 +212,7 @@ dist_noinst_HEADERS = \ providers/dp_backend.h \ providers/providers.h \ tools/tools_util.h \ + krb5_plugin/sssd_krb5_locator_plugin.h \ $(infopipe_headers) \ $(polkit_headers) @@ -403,6 +408,15 @@ memberof_la_LDFLAGS = \ -avoid-version \ -module +sssd_krb5_locator_plugin_la_SOURCES = \ + krb5_plugin/sssd_krb5_locator_plugin.c +sssd_krb5_locator_plugin_la_CFLAGS = \ + $(AM_CFLAGS) \ + $(KRB5_CFLAGS) +sssd_krb5_locator_plugin_la_LDFLAGS = \ + -avoid-version \ + -module + ############ # MANPAGES # ############ diff --git a/server/conf_macros.m4 b/server/conf_macros.m4 index 7e230bb..c67b47b 100644 --- a/server/conf_macros.m4 +++ b/server/conf_macros.m4 @@ -132,7 +132,6 @@ AC_DEFUN([WITH_INIT_DIR], AC_SUBST(initdir) ]) - AC_DEFUN([WITH_SHADOW_UTILS_PATH], [ AC_ARG_WITH([shadow-utils-path], [AC_HELP_STRING([--with-shadow-utils-path=PATH], @@ -177,3 +176,16 @@ AC_DEFUN([WITH_XML_CATALOG], AC_SUBST([SGML_CATALOG_FILES]) ]) +AC_DEFUN([WITH_KRB5_PLUGIN_PATH], + [ AC_ARG_WITH([krb5-plugin-path], + [AC_HELP_STRING([--with-krb5-plugin-path=PATH], + [Path to kerberos plugin store [/usr/lib/krb5/plugins/libkrb5]] + ) + ] + ) + krb5pluginpath="${libdir}/krb5/plugins/libkrb5" + if test x"$with_krb5_plugin_path" != x; then + krb5pluginpath=$with_krb5_plugin_path + fi + AC_SUBST(krb5pluginpath) + ]) diff --git a/server/configure.ac b/server/configure.ac index 8803276..facefe2 100644 --- a/server/configure.ac +++ b/server/configure.ac @@ -49,6 +49,7 @@ WITH_INIT_DIR WITH_SHADOW_UTILS_PATH WITH_MANPAGES WITH_XML_CATALOG +WITH_KRB5_PLUGIN_PATH m4_include([external/pkg.m4]) m4_include([external/libpopt.m4]) @@ -59,6 +60,7 @@ m4_include([external/libldb.m4]) m4_include([external/pam.m4]) m4_include([external/ldap.m4]) m4_include([external/libpcre.m4]) +m4_include([external/krb5.m4]) m4_include([util/signal.m4]) PKG_CHECK_MODULES([DBUS],[dbus-1]) diff --git a/server/external/krb5.m4 b/server/external/krb5.m4 new file mode 100644 index 0000000..1ed5064 --- /dev/null +++ b/server/external/krb5.m4 @@ -0,0 +1,11 @@ +AC_SUBST(KRB5_CFLAGS) +AC_SUBST(KRB5_LIBS) +AC_PATH_PROG(KRB5_CONFIG, krb5-config) +AC_MSG_CHECKING(for working krb5-config) +if test -x "$KRB5_CONFIG"; then + KRB5_CFLAGS="`$KRB5_CONFIG --cflags`" + KRB5_LIBS="`$KRB5_CONFIG --libs`" + AC_MSG_RESULT(yes) +else + AC_MSG_ERROR(no. Please install MIT kerberos devel package) +fi diff --git a/server/krb5_plugin/sssd_krb5_locator_plugin.c b/server/krb5_plugin/sssd_krb5_locator_plugin.c new file mode 100644 index 0000000..699cad4 --- /dev/null +++ b/server/krb5_plugin/sssd_krb5_locator_plugin.c @@ -0,0 +1,131 @@ +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "krb5_plugin/sssd_krb5_locator_plugin.h" + +struct sssd_ctx { + char *sssd_realm; + char *sssd_kdc; +}; + +krb5_error_code sssd_krb5_locator_init(krb5_context context, + void **private_data) +{ + struct sssd_ctx *ctx; + char *dummy; + + ctx = calloc(1,sizeof(struct sssd_ctx)); + if (ctx == NULL) return ENOMEM; + + dummy = getenv(SSSD_REALM); + if (dummy == NULL) goto failed; + ctx->sssd_realm = strdup(dummy); + if (ctx->sssd_realm == NULL) goto failed; + + dummy = getenv(SSSD_KDC); + if (dummy == NULL) goto failed; + ctx->sssd_kdc = strdup(dummy); + if (ctx->sssd_kdc == NULL) goto failed; + + *private_data = ctx; + + return 0; +failed: + free(ctx->sssd_realm); + free(ctx->sssd_kdc); + free(ctx); + + private_data = NULL; + + return EINVAL; +} + +void sssd_krb5_locator_close(void *private_data) +{ + struct sssd_ctx *ctx; + + if (private_data == NULL) return; + + ctx = (struct sssd_ctx *) private_data; + free(ctx->sssd_realm); + free(ctx->sssd_kdc); + free(ctx); + + return; +} + +krb5_error_code sssd_krb5_locator_lookup(void *private_data, + enum locate_service_type svc, + const char *realm, + int socktype, + int family, + int (*cbfunc)(void *, int, struct sockaddr *), + void *cbdata) +{ + int ret; + struct sockaddr_in addr; + struct sssd_ctx *ctx; + + if (private_data == NULL) return KRB5_PLUGIN_NO_HANDLE; + ctx = (struct sssd_ctx *) private_data; + +#ifdef KRB5_PLUGIN_DEBUG + fprintf(stderr,"[%s][%s][%s][%d][%d][%d]\n", realm, ctx->sssd_realm, + ctx->sssd_kdc, socktype, + family, svc); +#endif + + switch (svc) { + case locate_service_kdc: + case locate_service_master_kdc: + case locate_service_kadmin: + break; + case locate_service_krb524: + case locate_service_kpasswd: + return KRB5_PLUGIN_NO_HANDLE; + default: + return EINVAL; + } + + switch (family) { + case AF_UNSPEC: + case AF_INET: + break; + default: + return KRB5_PLUGIN_NO_HANDLE; + } + + switch (socktype) { + case SOCK_STREAM: + case SOCK_DGRAM: + break; + default: + return EINVAL; + } + + if (strcmp(realm, ctx->sssd_realm) != 0) + return KRB5_PLUGIN_NO_HANDLE; + + addr.sin_family = AF_INET; + ret = inet_aton(ctx->sssd_kdc, &addr.sin_addr); + if (ret == 0) return EINVAL; + addr.sin_port = htons(88); + + ret = cbfunc(cbdata, socktype, (struct sockaddr *) &addr); + + return 0; +} + +const krb5plugin_service_locate_ftable service_locator = { + 0, /* version */ + sssd_krb5_locator_init, + sssd_krb5_locator_close, + sssd_krb5_locator_lookup, +}; diff --git a/server/krb5_plugin/sssd_krb5_locator_plugin.h b/server/krb5_plugin/sssd_krb5_locator_plugin.h new file mode 100644 index 0000000..ab41689 --- /dev/null +++ b/server/krb5_plugin/sssd_krb5_locator_plugin.h @@ -0,0 +1,8 @@ +#ifndef __SSSD_KRB5_LOCATOR_PLUGIN_H__ +#define __SSSD_KRB5_LOCATOR_PLUGIN_H__ + +#define SSSD_KDC "SSSD_KDC" +#define SSSD_REALM "SSSD_REALM" + +#endif /* __SSSD_KRB5_LOCATOR_PLUGIN_H__ */ + diff --git a/sssd.spec.in b/sssd.spec.in index 2053576..719e6b7 100644 --- a/sssd.spec.in +++ b/sssd.spec.in @@ -42,6 +42,7 @@ BuildRequires: pcre-devel BuildRequires: libxslt BuildRequires: libxml2 BuildRequires: docbook-style-xsl +BuildRequires: krb5-devel %description Provides a set of daemons to manage access to remote directories and @@ -78,7 +79,8 @@ rm -f \ $RPM_BUILD_ROOT/%{_lib}/security/pam_sss.la \ $RPM_BUILD_ROOT/%{_libdir}/ldb/memberof.la \ $RPM_BUILD_ROOT/%{_libdir}/sssd/libsss_ldap.la \ - $RPM_BUILD_ROOT/%{_libdir}/sssd/libsss_proxy.la + $RPM_BUILD_ROOT/%{_libdir}/sssd/libsss_proxy.la \ + $RPM_BUILD_ROOT/%{_libdir}/krb5/plugins/libkrb5/sssd_krb5_locator_plugin.la %clean rm -rf $RPM_BUILD_ROOT @@ -97,6 +99,7 @@ rm -rf $RPM_BUILD_ROOT %{_libexecdir}/%{servicename}/ %{_libdir}/%{name}/ %{_libdir}/ldb/memberof.so +%{_libdir}/krb5/plugins/libkrb5/* %dir %{_sharedstatedir}/sss/ %attr(700,root,root) %dir %{_sharedstatedir}/sss/db %dir %{_sharedstatedir}/sss/pipes -- 1.6.2.5 -------------- next part -------------- >From 31554e5e3385cbbf0b9d809dfaf1edd61b2fdbb8 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 15 Jun 2009 15:07:39 +0200 Subject: [PATCH 2/2] added kerberos backend with tevent_req event handling --- server/Makefile.am | 17 +- server/man/sssd-krb5.5.xml | 98 ++++++ server/providers/data_provider.h | 2 + server/providers/dp_auth_util.c | 6 + server/providers/krb5/krb5_auth.c | 567 +++++++++++++++++++++++++++++++++ server/providers/krb5/krb5_auth.h | 91 ++++++ server/providers/krb5/tgt_req_child.c | 179 +++++++++++ server/responder/pam/pamsrv_cmd.c | 20 ++- sss_client/pam_sss.c | 2 +- sssd.spec.in | 1 + 10 files changed, 980 insertions(+), 3 deletions(-) create mode 100644 server/man/sssd-krb5.5.xml create mode 100644 server/providers/krb5/krb5_auth.c create mode 100644 server/providers/krb5/krb5_auth.h create mode 100644 server/providers/krb5/tgt_req_child.c diff --git a/server/Makefile.am b/server/Makefile.am index b15c230..01f3037 100644 --- a/server/Makefile.am +++ b/server/Makefile.am @@ -76,6 +76,7 @@ endif sssdlib_LTLIBRARIES = \ libsss_ldap.la \ + libsss_krb5.la \ libsss_proxy.la ldblib_LTLIBRARIES = \ @@ -211,6 +212,7 @@ dist_noinst_HEADERS = \ providers/dp_interfaces.h \ providers/dp_backend.h \ providers/providers.h \ + providers/krb5/krb5_auth.h \ tools/tools_util.h \ krb5_plugin/sssd_krb5_locator_plugin.h \ $(infopipe_headers) \ @@ -400,6 +402,19 @@ libsss_proxy_la_LDFLAGS = \ -version-info 1:0:0 \ -module +libsss_krb5_la_SOURCES = \ + providers/krb5/krb5_auth.c \ + providers/krb5/tgt_req_child.c +libsss_krb5_la_CFLAGS = \ + $(AM_CFLAGS) \ + $(KRB5_CFLAGS) +libsss_krb5_la_LIBADD = \ + $(PAM_LIBS) \ + $(KRB5_LIBS) +libsss_krb5_la_LDFLAGS = \ + -version-info 1:0:0 \ + -module + memberof_la_SOURCES = \ ldb_modules/memberof.c memberof_la_CFLAGS = \ @@ -429,7 +444,7 @@ XSLTPROC_FLAGS = --catalogs --xinclude --nonet dist_man_MANS = man/sss_useradd.8 man/sss_userdel.8 man/sss_usermod.8 \ man/sss_groupadd.8 man/sss_groupdel.8 man/sss_groupmod.8 \ - man/sssd.8 man/sssd.conf.5 man/sssd-ldap.5 + man/sssd.8 man/sssd.conf.5 man/sssd-ldap.5 man/sssd-krb5.5 SUFFIXES = .1.xml .1 .3.xml .3 .5.xml .5 .8.xml .8 .1.xml.1: diff --git a/server/man/sssd-krb5.5.xml b/server/man/sssd-krb5.5.xml new file mode 100644 index 0000000..a75193a --- /dev/null +++ b/server/man/sssd-krb5.5.xml @@ -0,0 +1,98 @@ + + + +SSSD Manual pages + + + + + sssd-krb5 + 5 + File Formats and Conventions + + + + sssd-krb5 + the configuration file for SSSD + + + + DESCRIPTION + + This manual page describes the configuration of the Kerberos + 5 authentication backend for + + sssd + 8 + . + For a detailed syntax reference, please refer to the FILE FORMAT section of the + + sssd.conf + 5 + manual page + + + + + CONFIGURATION OPTIONS + + If the auth-module krb5 is used in a SSSD domain, the following + options must be used. See the + + sssd.conf + 5 + manual page, section DOMAIN SECTIONS + for details on the configuration of a SSSD domain. + + + krb5KDCIP (string) + + + Specifies the IP address of the Kerberos server. + + + + + + krb5REALM (string) + + + The name of the Kerberos realm. + + + + + + + + + EXAMPLE + + The following example assumes that SSSD is correctly + configured and FOO is one of the domains in the + [domains] section. + + + + [domains/FOO] + auth-module = krb5 + krb5KDCIP = 192.168.1.1 + krb5REALM = EXAMPLE.COM + + + + + + SEE ALSO + + + sssd.conf5 + , + + sssd8 + + + + + diff --git a/server/providers/data_provider.h b/server/providers/data_provider.h index 95a1b37..b747e69 100644 --- a/server/providers/data_provider.h +++ b/server/providers/data_provider.h @@ -117,6 +117,8 @@ struct pam_data { bool offline_auth; int priv; + uid_t pw_uid; + gid_t gr_gid; }; void pam_print_data(int l, struct pam_data *pd); diff --git a/server/providers/dp_auth_util.c b/server/providers/dp_auth_util.c index 279e50b..7219917 100644 --- a/server/providers/dp_auth_util.c +++ b/server/providers/dp_auth_util.c @@ -35,6 +35,8 @@ void pam_print_data(int l, struct pam_data *pd) DEBUG(l, ("newauthtok type: %d\n", pd->newauthtok_type)); DEBUG(l, ("newauthtok size: %d\n", pd->newauthtok_size)); DEBUG(l, ("priv: %d\n", pd->priv)); + DEBUG(l, ("pw_uid: %d\n", pd->pw_uid)); + DEBUG(l, ("gr_gid: %d\n", pd->gr_gid)); } int pam_add_response(struct pam_data *pd, enum response_type type, @@ -83,6 +85,8 @@ bool dp_pack_pam_request(DBusMessage *msg, struct pam_data *pd) &(pd->newauthtok), pd->newauthtok_size, DBUS_TYPE_INT32, &(pd->priv), + DBUS_TYPE_INT32, &(pd->pw_uid), + DBUS_TYPE_INT32, &(pd->gr_gid), DBUS_TYPE_INVALID); return ret; @@ -109,6 +113,8 @@ bool dp_unpack_pam_request(DBusMessage *msg, struct pam_data *pd, DBusError *dbu &(pd->newauthtok), &(pd->newauthtok_size), DBUS_TYPE_INT32, &(pd->priv), + DBUS_TYPE_INT32, &(pd->pw_uid), + DBUS_TYPE_INT32, &(pd->gr_gid), DBUS_TYPE_INVALID); return ret; diff --git a/server/providers/krb5/krb5_auth.c b/server/providers/krb5/krb5_auth.c new file mode 100644 index 0000000..5206bd0 --- /dev/null +++ b/server/providers/krb5/krb5_auth.c @@ -0,0 +1,567 @@ +/* + SSSD + + Kerberos 5 Backend Module + + Authors: + Sumit Bose + + Copyright (C) 2009 Red Hat + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . +*/ + + +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "util/util.h" +#include "providers/dp_backend.h" +#include "db/sysdb.h" +#include "../sss_client/sss_cli.h" +#include "krb5_plugin/sssd_krb5_locator_plugin.h" +#include "providers/krb5/krb5_auth.h" + +static void fd_nonblocking(int fd) { + int flags; + + flags = fcntl(fd, F_GETFL, 0); + if (flags == -1) { + DEBUG(1, ("F_GETFL failed [%d][%s].\n", errno, strerror(errno))); + return; + } + + if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) == -1) { + DEBUG(1, ("F_SETFL failed [%d][%s].\n", errno, strerror(errno))); + } + + return; +} + +static void krb5_cleanup(struct krb5_req *kr) +{ + if (kr == NULL) return; + + /* FIXME: is it safe to drop the "!= NULL" checks? */ + if (kr->options != NULL) + krb5_get_init_creds_opt_free(kr->ctx, kr->options); + if (kr->creds != NULL) + krb5_free_cred_contents(kr->ctx, kr->creds); + if (kr->name != NULL) + krb5_free_unparsed_name(kr->ctx, kr->name); + if (kr->princ != NULL) + krb5_free_principal(kr->ctx, kr->princ); + if (kr->cc != NULL) + krb5_cc_close(kr->ctx, kr->cc); + if (kr->ctx != NULL) + krb5_free_context(kr->ctx); + + talloc_free(kr); +} + +static int krb5_setup(struct be_req *req, struct krb5_req **krb5_req) +{ + struct krb5_req *kr = NULL; + struct krb5_ctx *krb5_ctx; + struct pam_data *pd; + krb5_error_code kerr = 0; + char *user_princ_str = NULL; + + pd = talloc_get_type(req->req_data, struct pam_data); + + krb5_ctx = talloc_get_type(req->be_ctx->pvt_auth_data, struct krb5_ctx); + + kr = talloc_zero(req, struct krb5_req); + if (kr == NULL) { + DEBUG(1, ("talloc failed.\n")); + kerr = ENOMEM; + goto failed; + } + + kr->pd = pd; + kr->req = req; + + kerr = krb5_init_context(&kr->ctx); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto failed; + } + +/* TODO: try to read user principal from id backend, use user + realm as a + fallback */ + if (kr->pd->user != NULL && krb5_ctx->realm != NULL) { + user_princ_str = talloc_asprintf(kr, "%s@%s", kr->pd->user, + krb5_ctx->realm); + } + if (user_princ_str == NULL) { + DEBUG(1, ("talloc_asprintf failed.\n")); + kerr = ENOMEM; + goto failed; + } + + kerr = krb5_parse_name(kr->ctx, user_princ_str, &kr->princ); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto failed; + } + + kerr = krb5_unparse_name(kr->ctx, kr->princ, &kr->name); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto failed; + } + + kr->creds = talloc_zero(kr, krb5_creds); + if (kr->creds == NULL) { + DEBUG(1, ("talloc_zero failed.\n")); + kerr = ENOMEM; + goto failed; + } + + kerr = krb5_get_init_creds_opt_alloc(kr->ctx, &kr->options); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto failed; + } + +/* TODO: set options, e.g. + * krb5_get_init_creds_opt_set_tkt_life + * krb5_get_init_creds_opt_set_renew_life + * krb5_get_init_creds_opt_set_forwardable + * krb5_get_init_creds_opt_set_proxiable + * krb5_get_init_creds_opt_set_etype_list + * krb5_get_init_creds_opt_set_address_list + * krb5_get_init_creds_opt_set_preauth_list + * krb5_get_init_creds_opt_set_salt + * krb5_get_init_creds_opt_set_change_password_prompt + * krb5_get_init_creds_opt_set_pa + */ + + *krb5_req = kr; + return EOK; + +failed: + krb5_cleanup(kr); + + return kerr; +} + +/* TODO: remove later + * These functions are available in the latest tevent and are the ones that + * should be used as tevent_req is rightfully opaque there */ +#ifndef tevent_req_data +#define tevent_req_data(req, type) ((type *)req->private_state) +#endif + +#ifndef tevent_req_set_callback +#define tevent_req_set_callback(req, func, data) \ + do { req->async.fn = func; req->async.private_data = data; } while(0) +#endif + +#ifndef tevent_req_callback_data +#define tevent_req_callback_data(req, type) ((type *)req->async.private_data) +#endif + +static void wait_for_child_handler(struct tevent_context *ev, + struct tevent_signal *sige, int signum, + int count, void *__siginfo, void *pvt) +{ + int ret; + int child_status; + siginfo_t *siginfo = (siginfo_t *)__siginfo; + + errno = 0; + do { + ret = waitpid(siginfo->si_pid, &child_status, WNOHANG); + } while (ret == -1 && errno == EINTR); + if (ret == siginfo->si_pid) { + DEBUG(4, ("child status [%d].\n", child_status)); + if (WEXITSTATUS(child_status) != 0) { + DEBUG(1, ("child failed.\n")); + } + } else if (ret == 0) { + DEBUG(1, ("waitpid did not found a child with changed status.\n", ret)); + } else if (ret >= 0 && ret != siginfo->si_pid) { + DEBUG(1, ("waitpid returned wrong child pid [%d], continue waiting.\n", ret)); + } else if (ret == -1 && errno == ECHILD) { + DEBUG(1, ("no child with pid [%d].\n", siginfo->si_pid)); + } else { + DEBUG(1, ("waitpid failed [%s].\n", strerror(errno))); + } + + return; +} + +static int fork_tgt_req_child(struct krb5_req *kr) +{ + int pipefd[2]; + pid_t pid; + int ret; + + ret = pipe(pipefd); + if (ret == -1) { + DEBUG(1, ("pipe failed [%d][%s].\n", errno, strerror(errno))); + return -1; + } + pid = fork(); + + if (pid == 0) { /* child */ + close(pipefd[0]); + tgt_req_child(pipefd[1], kr); + } else if (pid > 0) { /* parent */ + kr->child_pid = pid; + kr->fd = pipefd[0]; + close(pipefd[1]); + + fd_nonblocking(kr->fd); + + } else { /* error */ + DEBUG(1, ("fork failed [%d][%s].\n", errno, strerror(errno))); + return -1; + } + + return EOK; +} + + +struct read_pipe_state { + int fd; + uint8_t *buf; + size_t len; +}; + +static void read_pipe_done(struct tevent_context *ev, struct tevent_fd *fde, + uint16_t flags, void *pvt); + +static struct tevent_req *read_pipe_send(TALLOC_CTX *memctx, + struct tevent_context *ev, + int fd) +{ + struct tevent_req *req; + struct read_pipe_state *state; + struct tevent_fd *fde; + + + req = tevent_req_create(memctx, &state, struct read_pipe_state); + if (req == NULL) return NULL; + + state->fd = fd; + state->buf = talloc_array(state, uint8_t, MAX_CHILD_MSG_SIZE); + if (state->buf == NULL) goto fail; + + fde = tevent_add_fd(ev, state, fd, TEVENT_FD_READ, + read_pipe_done, req); + if (fde == NULL) { + DEBUG(1, ("tevent_add_fd failed.\n")); + goto fail; + } + + return req; + +fail: + talloc_zfree(req); + return NULL; +} + +static void read_pipe_done(struct tevent_context *ev, struct tevent_fd *fde, + uint16_t flags, void *pvt) +{ + ssize_t size; + struct tevent_req *req = talloc_get_type(pvt, struct tevent_req); + struct read_pipe_state *state = tevent_req_data(req, struct read_pipe_state); + + if (flags & TEVENT_FD_WRITE) { + DEBUG(1, ("client_response_handler called with TEVENT_FD_WRITE, this should not happen.\n")); + tevent_req_error(req, EINVAL); + return; + } + + size = read(state->fd, state->buf, talloc_get_size(state->buf)); + if (size == -1) { + if (errno == EAGAIN || errno == EINTR) return; + DEBUG(1, ("read failed [%d][%s].\n", errno, strerror(errno))); + tevent_req_error(req, errno); + return; + } + state->len = size; + + tevent_req_done(req); + return; +} + +static ssize_t read_pipe_recv(struct tevent_req *req, TALLOC_CTX *mem_ctx, + uint8_t **buf, uint64_t *error) { + struct read_pipe_state *state = tevent_req_data(req, + struct read_pipe_state); + enum tevent_req_state tstate; + + if (tevent_req_is_error(req, &tstate, error)) { + return -1; + } + + *buf = talloc_move(mem_ctx, &state->buf); + return state->len; +} + +struct tgt_req_state { + struct krb5_req *kr; + ssize_t len; + uint8_t *buf; +}; + +static void tgt_req_done(struct tevent_req *subreq); + +static struct tevent_req *tgt_req_send(TALLOC_CTX *mem_ctx, struct tevent_context *ev, + struct krb5_req *kr) +{ + int ret; + struct tevent_req *req; + struct tevent_req *subreq; + struct tgt_req_state *state; + + ret = fork_tgt_req_child(kr); + if (ret != EOK) { + DEBUG(1, ("fork_tgt_req_child failed.\n")); + return NULL; + } + + req = tevent_req_create(mem_ctx, &state, struct tgt_req_state); + if (req == NULL) { + return NULL; + } + + state->kr = kr; + + subreq = read_pipe_send(state, ev, kr->fd); + if (tevent_req_nomem(subreq, req)) { + return tevent_req_post(req, ev); + } + tevent_req_set_callback(subreq, tgt_req_done, req); + return req; +} + +static void tgt_req_done(struct tevent_req *subreq) +{ + struct tevent_req *req = tevent_req_callback_data(subreq, + struct tevent_req); + struct tgt_req_state *state = tevent_req_data(req, struct tgt_req_state); + uint64_t error; + + state->len = read_pipe_recv(subreq, state, &state->buf, &error); + talloc_zfree(subreq); + close(state->kr->fd); + if (state->len == -1) { + tevent_req_error(req, error); + return; + } + + tevent_req_done(req); + return; +} + +static ssize_t tgt_req_recv(struct tevent_req *req, TALLOC_CTX *mem_ctx, + uint8_t **buf, uint64_t *error) { + struct tgt_req_state *state = tevent_req_data(req, struct tgt_req_state); + enum tevent_req_state tstate; + + if (tevent_req_is_error(req, &tstate, error)) { + return -1; + } + + *buf = talloc_move(mem_ctx, &state->buf); + return state->len; +} + +static void krb5_pam_handler_done(struct tevent_req *req); + +static void krb5_pam_handler(struct be_req *be_req) +{ + struct krb5_req *kr = NULL; + struct tevent_req *req; + int ret; + struct pam_data *pd; + int pam_status=PAM_SYSTEM_ERR; + + pd = talloc_get_type(be_req->req_data, struct pam_data); + + if (pd->cmd != SSS_PAM_AUTHENTICATE) { + DEBUG(4, ("krb5 does not handles pam task %d.\n", pd->cmd)); + pam_status = PAM_SUCCESS; + goto done; + } + + ret = krb5_setup(be_req, &kr); + if (ret != EOK) { + DEBUG(1, ("krb5_setup failed.\n")); + goto done; + } + + req = tgt_req_send(be_req, be_req->be_ctx->ev, kr); + if (req == NULL) { + DEBUG(1, ("tgt_req_send failed.\n")); + goto done; + } + + tevent_req_set_callback(req, krb5_pam_handler_done, kr); + return; + +done: + krb5_cleanup(kr); + + pd->pam_status = pam_status; + + be_req->fn(be_req, pam_status, NULL); +} + +static void krb5_pam_handler_done(struct tevent_req *req) +{ + struct krb5_req *kr = tevent_req_callback_data(req, struct krb5_req); + struct pam_data *pd = kr->pd; + struct be_req *be_req = kr->req; + struct krb5_ctx *krb5_ctx = talloc_get_type(be_req->be_ctx->pvt_auth_data, + struct krb5_ctx); + struct tgt_req_state *state = tevent_req_data(req, struct tgt_req_state); + int ret; + uint8_t *buf; + ssize_t len; + uint64_t error; + int p; + int32_t *msg_status; + int32_t *msg_type; + int32_t *msg_len; + + pd->pam_status = PAM_SYSTEM_ERR; + krb5_cleanup(kr); + + len = tgt_req_recv(req, state, &buf, &error); + talloc_zfree(req); + if (len == -1) { + DEBUG(1, ("tgt_req request failed\n")); + goto done; + } + + if ((size_t) len < 3*sizeof(int32_t)) { + DEBUG(1, ("message too short.\n")); + goto done; + } + + p=0; + msg_status = ((int32_t *)(buf+p)); + p += sizeof(int32_t); + + msg_type = ((int32_t *)(buf+p)); + p += sizeof(int32_t); + + msg_len = ((int32_t *)(buf+p)); + p += sizeof(int32_t); + + DEBUG(4, ("child response [%d][%d][%d].\n", *msg_status, *msg_type, + *msg_len)); + + if ((p + *msg_len) != len) { + DEBUG(1, ("message format error.\n")); + goto done; + } + + ret=pam_add_response(kr->pd, *msg_type, *msg_len, &buf[p]); + if (ret != EOK) { + DEBUG(1, ("pam_add_response failed.\n")); + goto done; + } + + pd->pam_status = *msg_status; + +done: + be_req->fn(be_req, pd->pam_status, NULL); +} + + +struct be_auth_ops krb5_auth_ops = { + .pam_handler = krb5_pam_handler, + .finalize = NULL, +}; + + +int sssm_krb5_auth_init(struct be_ctx *bectx, struct be_auth_ops **ops, + void **pvt_auth_data) +{ + struct krb5_ctx *ctx = NULL; + bool bool_value = FALSE; + char *value = NULL; + int ret; + struct tevent_signal *sige; + + ctx = talloc_zero(bectx, struct krb5_ctx); + if (!ctx) { + DEBUG(1, ("talloc failed.\n")); + return ENOMEM; + } + + ctx->action = INIT_PW; + + ret = confdb_get_string(bectx->cdb, ctx, bectx->conf_path, + "krb5KDCIP", NULL, &value); + if (ret != EOK) goto fail; + if (value == NULL) { + DEBUG(2, ("Missing krb5KDCIP, authentication might fail.\n")); + } else { + ret = setenv(SSSD_KDC, value, 1); + if (ret != EOK) { + DEBUG(2, ("setenv %s failed, authentication might fail.\n", + SSSD_KDC)); + } + } + ctx->kdcip = value; + + ret = confdb_get_string(bectx->cdb, ctx, bectx->conf_path, + "krb5REALM", NULL, &value); + if (ret != EOK) goto fail; + if (value == NULL) { + DEBUG(4, ("Missing krb5REALM authentication might fail.\n")); + } else { + ret = setenv(SSSD_REALM, value, 1); + if (ret != EOK) { + DEBUG(2, ("setenv %s failed, authentication might fail.\n", + SSSD_REALM)); + } + } + ctx->realm = value; + +/* TODO: set options */ + + sige = tevent_add_signal(bectx->ev, ctx, SIGCHLD, SA_SIGINFO, + wait_for_child_handler, NULL); + if (sige == NULL) { + DEBUG(1, ("tevent_add_signal failed.\n")); + ret = ENOMEM; + goto fail; + } + + + *ops = &krb5_auth_ops; + *pvt_auth_data = ctx; + return EOK; + +fail: + talloc_free(ctx); + return ret; +} diff --git a/server/providers/krb5/krb5_auth.h b/server/providers/krb5/krb5_auth.h new file mode 100644 index 0000000..d1c5c7c --- /dev/null +++ b/server/providers/krb5/krb5_auth.h @@ -0,0 +1,91 @@ +/* + SSSD + + Kerberos Backend, private header file + + Authors: + Sumit Bose + + Copyright (C) 2009 Red Hat + + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . +*/ + +#ifndef __KRB5_AUTH_H__ +#define __KRB5_AUTH_H__ + +#define MAX_CHILD_MSG_SIZE 255 +#define CCACHE_ENV_NAME "KRB5CCNAME" + +typedef enum { INIT_PW, INIT_KT, RENEW, VALIDATE } action_type; + +struct krb5_ctx { + /* opts taken from kinit */ + /* in seconds */ + krb5_deltat starttime; + krb5_deltat lifetime; + krb5_deltat rlife; + + int forwardable; + int proxiable; + int addresses; + + int not_forwardable; + int not_proxiable; + int no_addresses; + + int verbose; + + char* principal_name; + char* service_name; + char* keytab_name; + char* k5_cache_name; + char* k4_cache_name; + + action_type action; + + int num_pa_opts; + krb5_gic_opt_pa_data *pa_opts; + + char *kdcip; + char *realm; +}; + +struct krb5_req { + krb5_context ctx; + krb5_ccache cc; + krb5_principal princ; + char* name; + krb5_creds *creds; + krb5_get_init_creds_opt *options; + pid_t child_pid; + int fd; + + struct be_req *req; + struct pam_data *pd; + struct krb5_ctx *krb5_ctx; +}; + +static krb5_context krb5_error_ctx; +static const char *__krb5_error_msg; +#define KRB5_DEBUG(level, krb5_error) do { \ + __krb5_error_msg = krb5_get_error_message(krb5_error_ctx, krb5_error); \ + DEBUG(level, ("%d: [%d][%s]\n", __LINE__, krb5_error, __krb5_error_msg)); \ + krb5_free_error_message(krb5_error_ctx, __krb5_error_msg); \ +} while(0); + +void tgt_req_child(int fd, struct krb5_req *kr); + +#endif /* __KRB5_AUTH_H__ */ diff --git a/server/providers/krb5/tgt_req_child.c b/server/providers/krb5/tgt_req_child.c new file mode 100644 index 0000000..edb3d18 --- /dev/null +++ b/server/providers/krb5/tgt_req_child.c @@ -0,0 +1,179 @@ +/* + SSSD + + Kerberos 5 Backend Module -- tgt_req child + + Authors: + Sumit Bose + + Copyright (C) 2009 Red Hat + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . +*/ +#include +#include + +#include + +#include "util/util.h" +#include "providers/dp_backend.h" +#include "providers/krb5/krb5_auth.h" + +static int pack_response_packet(uint8_t *buf, int status, int type, + const char *data) +{ + int len; + int p=0; + + if ((3*sizeof(int32_t) + strlen(data)+1) > MAX_CHILD_MSG_SIZE) { + return -1; + } + + ((int32_t *)(&buf[p]))[0] = status; + p += sizeof(int32_t); + + ((int32_t *)(&buf[p]))[0] = type; + p += sizeof(int32_t); + + len = strlen(data)+1; + ((int32_t *)(&buf[p]))[0] = len; + p += sizeof(int32_t); + + memcpy(&buf[p], data, len); + p += len; + + return p; +} + +void tgt_req_child(int fd, struct krb5_req *kr) +{ + int ret; + krb5_error_code kerr = 0; + char *pass_str = NULL; + uint8_t buf[MAX_CHILD_MSG_SIZE]; + int size = 0; + const char *cc_name; + char *env; + const char *krb5_error_msg; + + ret = setgid(kr->pd->gr_gid); + if (ret == -1) { + DEBUG(1, ("setgid failed [%d][%s].\n", errno, strerror(errno))); + _exit(-1); + } + + ret = setuid(kr->pd->pw_uid); + if (ret == -1) { + DEBUG(1, ("setuid failed [%d][%s].\n", errno, strerror(errno))); + _exit(-1); + } + + ret = setegid(kr->pd->gr_gid); + if (ret == -1) { + DEBUG(1, ("setegid failed [%d][%s].\n", errno, strerror(errno))); + _exit(-1); + } + + ret = seteuid(kr->pd->pw_uid); + if (ret == -1) { + DEBUG(1, ("seteuid failed [%d][%s].\n", errno, strerror(errno))); + _exit(-1); + } + + pass_str = talloc_strndup(kr, (const char *) kr->pd->authtok, + kr->pd->authtok_size); + if (pass_str == NULL) { + DEBUG(1, ("talloc_strndup failed.\n")); + _exit(-1); + } + + kerr = krb5_get_init_creds_password(kr->ctx, kr->creds, kr->princ, + pass_str, NULL, NULL, 0, NULL, + kr->options); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto childfailed; + } + + memset(pass_str, 0, kr->pd->authtok_size); + talloc_free(pass_str); + memset(kr->pd->authtok, 0, kr->pd->authtok_size); + + kerr = krb5_cc_default(kr->ctx, &kr->cc); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto childfailed; + } + + kerr = krb5_cc_initialize(kr->ctx, kr->cc, kr->princ); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto childfailed; + } + + kerr = krb5_cc_store_cred(kr->ctx, kr->cc, kr->creds); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + krb5_cc_destroy(kr->ctx, kr->cc); + goto childfailed; + } + + cc_name = krb5_cc_get_name(kr->ctx, kr->cc); + if (cc_name == NULL) { + DEBUG(1, ("krb5_cc_get_name failed.\n")); + krb5_cc_destroy(kr->ctx, kr->cc); + _exit(-1); + } + + env = talloc_asprintf(kr, "%s=%s",CCACHE_ENV_NAME, cc_name); + if (env == NULL) { + DEBUG(1, ("talloc_asprintf failed.\n")); + krb5_cc_destroy(kr->ctx, kr->cc); + _exit(-1); + } + + size = pack_response_packet(buf, PAM_SUCCESS, PAM_ENV_ITEM, env); + if (size < 0) { + DEBUG(1, ("failed to create response message.\n")); + krb5_cc_destroy(kr->ctx, kr->cc); + _exit(-1); + } + + kerr = 0; + +childfailed: + if (kerr != 0 ) { + krb5_error_msg = krb5_get_error_message(krb5_error_ctx, kerr); + size = pack_response_packet(buf, PAM_SYSTEM_ERR, PAM_USER_INFO, + krb5_error_msg); + if (size < 0) { + DEBUG(1, ("failed to create response message.\n")); + krb5_cc_destroy(kr->ctx, kr->cc); + _exit(-1); + } + krb5_free_error_message(krb5_error_ctx, krb5_error_msg); + } + + ret = write(fd, buf, size); + if (ret == -1) { + DEBUG(1, ("write failed [%d][%s].\n", errno, strerror(errno))); + krb5_cc_destroy(kr->ctx, kr->cc); + _exit(ret); + } + + krb5_cc_close(kr->ctx, kr->cc); + + + _exit(0); +} diff --git a/server/responder/pam/pamsrv_cmd.c b/server/responder/pam/pamsrv_cmd.c index e065490..9b02146 100644 --- a/server/responder/pam/pamsrv_cmd.c +++ b/server/responder/pam/pamsrv_cmd.c @@ -22,6 +22,7 @@ #include #include "util/util.h" +#include "db/sysdb.h" #include "confdb/confdb.h" #include "responder/common/responder_packet.h" #include "responder/common/responder.h" @@ -387,7 +388,6 @@ static int pam_forwarder(struct cli_ctx *cctx, int pam_cmd) size_t blen; int timeout; int ret; - preq = talloc_zero(cctx, struct pam_auth_req); if (!preq) { return ENOMEM; @@ -716,6 +716,24 @@ static void pam_check_user_callback(void *ptr, int status, case 1: /* BINGO */ + preq->pd->pw_uid = + ldb_msg_find_attr_as_int(res->msgs[0], SYSDB_UIDNUM, -1); + if (preq->pd->pw_uid == -1) { + DEBUG(1, ("Failed to find uid for user [%s] in domain [%s].\n", + preq->pd->user, preq->pd->domain)); + preq->pd->pam_status = PAM_SYSTEM_ERR; + pam_reply(preq); + } + + preq->pd->gr_gid = + ldb_msg_find_attr_as_int(res->msgs[0], SYSDB_GIDNUM, -1); + if (preq->pd->gr_gid == -1) { + DEBUG(1, ("Failed to find gid for user [%s] in domain [%s].\n", + preq->pd->user, preq->pd->domain)); + preq->pd->pam_status = PAM_SYSTEM_ERR; + pam_reply(preq); + } + pam_dom_forwarder(preq); return; diff --git a/sss_client/pam_sss.c b/sss_client/pam_sss.c index ccc205c..a10e0ea 100644 --- a/sss_client/pam_sss.c +++ b/sss_client/pam_sss.c @@ -426,7 +426,7 @@ static int eval_response(pam_handle_t *pamh, size_t buflen, uint8_t *buf) break; } logger(pamh, LOG_INFO, "user info: [%s]", &buf[p]); - ret = do_pam_conversation(pamh, PAM_USER_INFO, (char *) &buf[p], + ret = do_pam_conversation(pamh, PAM_TEXT_INFO, (char *) &buf[p], NULL, NULL); if (ret != PAM_SUCCESS) { D(("do_pam_conversation, canot display user info.")); diff --git a/sssd.spec.in b/sssd.spec.in index 719e6b7..1fa847d 100644 --- a/sssd.spec.in +++ b/sssd.spec.in @@ -80,6 +80,7 @@ rm -f \ $RPM_BUILD_ROOT/%{_libdir}/ldb/memberof.la \ $RPM_BUILD_ROOT/%{_libdir}/sssd/libsss_ldap.la \ $RPM_BUILD_ROOT/%{_libdir}/sssd/libsss_proxy.la \ + $RPM_BUILD_ROOT/%{_libdir}/sssd/libsss_krb5.la \ $RPM_BUILD_ROOT/%{_libdir}/krb5/plugins/libkrb5/sssd_krb5_locator_plugin.la %clean -- 1.6.2.5 From jhrozek at redhat.com Mon Jun 29 13:00:44 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 29 Jun 2009 15:00:44 +0200 Subject: [Freeipa-devel] [PATCH] Gettextize the sss_ tools In-Reply-To: <1245866366.5479.26.camel@localhost.localdomain> References: <4A3B98C4.6060209@redhat.com> <1245437942.11682.21.camel@localhost.localdomain> <4A425B9A.4030605@redhat.com> <1245866366.5479.26.camel@localhost.localdomain> Message-ID: <4A48BAFC.4040207@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm sorry for the long delay, I got busy with the c-ares work and forgot to reply back.. > I think you can use the same stuff we use for DEBUG and have a print_fn > function. > That should be more portable if we care about the above being too gcc > specific. Right, do we care, then? I think the variadic macro is by far the most elegant solution by not having a separate body parameter wrapped in its own parenthesis. If we need to be portable outside gcc, I'll send a patch using debug_fn/print_fn. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpIuvwACgkQHsardTLnvCWXbgCgwUhCnL3fLmlbtyAAiwf9z37k XkMAoKJJTGfRmAa+fgFlMQrB7rybYEQh =briv -----END PGP SIGNATURE----- From dpal at redhat.com Mon Jun 29 15:45:25 2009 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 29 Jun 2009 11:45:25 -0400 Subject: [Freeipa-devel] [PATCH] Improvements to collection API Message-ID: <4A48E195.3050508@redhat.com> Collection improvements: 1) In the first implementation the collection elements we always added to the end of the collection. There was no way to insert elements in a specific places in the collection. Now there is. The original implementation of add_xxx_property functions is wrapped around new insert_xxx_property functions. 2) As as pair to the insert functionality there is now an extract functionality also added in this patch. The extraction allows getting specific item from the existing collection and operating with it. 3) Collection.h has a lot of comments describing the meaning and use of different flags. 4) Unit test was updated 5) Valgrind tests were run using unit test. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Adding-INSERT-into-collection-functionality.patch Type: text/x-patch Size: 173081 bytes Desc: not available URL: From dpal at redhat.com Mon Jun 29 16:37:10 2009 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 29 Jun 2009 12:37:10 -0400 Subject: [Freeipa-devel] CLA or contribution policy? In-Reply-To: <20090629083624.GA28739@calliope.phig.org> References: <20090629083624.GA28739@calliope.phig.org> Message-ID: <4A48EDB6.9090209@redhat.com> Karsten Wade wrote: > Recently when I was asking around about the contributor license > agreement (CLA) that covers FreeIPA, the Legal man asked, "What does > the FreeIPA project want? Do they want a full-blown CLA or would a > simpler contribution policy do?" By asking ourselves this question, > we have a chance to resolve (be happier) about the current CLA, get it > changed to a more useful agreement, or switch entirely to a > declarative policy of some kind. > I might be wrong but I do not think anyone looked at the problem this way. Some good guidance on the matter will be helpful. What does freeIPA project wants? Good question. I think the answer lays somewhere along the lines of: * It wants to be sufficiently legally covered * Does not want to create obstacles to contribution * Does not want to affiliate itself with a specific distribution. Any ideas how that can be translated into appropriate CLI or policy? -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mnagy at redhat.com Mon Jun 29 17:04:05 2009 From: mnagy at redhat.com (Martin Nagy) Date: Mon, 29 Jun 2009 19:04:05 +0200 Subject: [Freeipa-devel] [RFC] Integration of c-ares and tevent Message-ID: <20090629190405.4711a5b4@wolverine.englab.brq.redhat.com> Hi, we (me and Jakub) are working on integrating the c-ares [1] asynchronous DNS resolver library with tevent, to be used in SSSD. The result of our work so far is the attached source file that demonstrates how it would be used in SSSD. We would like some comments before we start integrating it directly into SSSD. Thanks. Martin [1] http://c-ares.haxx.se/ -------------- next part -------------- A non-text attachment was scrubbed... Name: resolv.c Type: text/x-csrc Size: 5340 bytes Desc: not available URL: From ssorce at redhat.com Mon Jun 29 17:41:55 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 29 Jun 2009 13:41:55 -0400 Subject: [Freeipa-devel] [RFC] Integration of c-ares and tevent In-Reply-To: <20090629190405.4711a5b4@wolverine.englab.brq.redhat.com> References: <20090629190405.4711a5b4@wolverine.englab.brq.redhat.com> Message-ID: <1246297315.13348.6.camel@localhost.localdomain> On Mon, 2009-06-29 at 19:04 +0200, Martin Nagy wrote: > Hi, > we (me and Jakub) are working on integrating the c-ares [1] asynchronous > DNS resolver library with tevent, to be used in SSSD. The result of our > work so far is the attached source file that demonstrates how it would > be used in SSSD. We would like some comments before we start > integrating it directly into SSSD. The tevent_req interface seem perfect for something like this. I would like to see an interface built using that convention. I am finishing working on a big rewrite of the sysdb and native ldap driver to use tevent_req and it looks really nice. I'll try to post patches as soon as I am done (been working the last 5 days including w/e, mostly boring conversion, but to me the code looks much better). Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Jun 29 18:20:36 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 29 Jun 2009 14:20:36 -0400 Subject: [Freeipa-devel] [PATCH] configure bind+ldap driver In-Reply-To: <1245849700.5479.23.camel@localhost.localdomain> References: <1245849700.5479.23.camel@localhost.localdomain> Message-ID: <4A4905F4.50502@redhat.com> Simo Sorce wrote: > This creates also role/task groups to authorize the ldap driver to > perform DNS updates using its service principal. > Does not support yet installing replicas. > > Simo. > What is the rationale for creating the delegation entries via ldif rather than an update? I seem to recall a chicken-and-egg problem. Can we create just the structural portions via the ldif and leave the taskgroups and rolegroups as updates? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Mon Jun 29 20:06:22 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 29 Jun 2009 16:06:22 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Remove redundand libPath option Message-ID: <4A491EBE.3010708@redhat.com> There is no benefit to having a separate libPath option, as it can be safely constructed from the libName option. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Remove-redundant-libPath-option-from-proxy-provider.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From ssorce at redhat.com Mon Jun 29 20:42:14 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 29 Jun 2009 16:42:14 -0400 Subject: [Freeipa-devel] [PATCH] configure bind+ldap driver In-Reply-To: <4A4905F4.50502@redhat.com> References: <1245849700.5479.23.camel@localhost.localdomain> <4A4905F4.50502@redhat.com> Message-ID: <1246308134.13348.9.camel@localhost.localdomain> On Mon, 2009-06-29 at 14:20 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > This creates also role/task groups to authorize the ldap driver to > > perform DNS updates using its service principal. > > Does not support yet installing replicas. > > > > Simo. > > > > What is the rationale for creating the delegation entries via ldif > rather than an update? I seem to recall a chicken-and-egg problem. > > Can we create just the structural portions via the ldif and leave the > taskgroups and rolegroups as updates? It was the first thing I tried but didn't work. We need the groups to exist before the various *instance(0 classes are run so that group memberships can be added. In the case of bind I need to put the service in the right role/taskgroup, and I was thinking of doing something similar for other cases. Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Mon Jun 29 20:44:57 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 29 Jun 2009 16:44:57 -0400 Subject: [Freeipa-devel] [PATCH] Improvements to collection API In-Reply-To: <4A48E195.3050508@redhat.com> References: <4A48E195.3050508@redhat.com> Message-ID: <4A4927C9.3040204@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/29/2009 11:45 AM, Dmitri Pal wrote: > Collection improvements: > > 1) In the first implementation the collection elements we always added > to the end of the collection. There was no way to insert elements in a > specific places in the collection. > Now there is. The original implementation of add_xxx_property functions > is wrapped around new insert_xxx_property functions. > 2) As as pair to the insert functionality there is now an extract > functionality also added in this patch. The extraction allows getting > specific item from the existing collection and operating with it. > 3) Collection.h has a lot of comments describing the meaning and use of > different flags. > 4) Unit test was updated > 5) Valgrind tests were run using unit test. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Nack. Your PRIME hash function is dangerously limited. You guarantee an overflow on 64-bit systems with strings of 13 characters or more. Worse on 32 bit systems. At minimum, declare phash a uint64_t. Furthermore, in your algorithm, the strings "mystring" and "mystirng" will produce an identical hash. Consider locating a library that provides a safer and less collision-prone hash. (I have no recommendations, perhaps someone else on the list can help.) Beyond that, I'm not going to look too deeply into the internals. Syntactically everything looks fine on a quick scan. It compiles cleanly against the current head and does not break any existing code, so once the above change is made, I'm comfortable with committing it and working out any bugs later on. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpJJ8QACgkQeiVVYja6o6MGWwCeL6huizZqxkVwUrDD38FnO2+o ZzgAn1fH/i1AWplf8vjLx77WqFa5PBVn =zD+E -----END PGP SIGNATURE----- From dpal at redhat.com Mon Jun 29 22:34:07 2009 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 29 Jun 2009 18:34:07 -0400 Subject: [Freeipa-devel] [PATCH] Improvements to collection API In-Reply-To: <4A4927C9.3040204@redhat.com> References: <4A48E195.3050508@redhat.com> <4A4927C9.3040204@redhat.com> Message-ID: <4A49415F.4000804@redhat.com> > > Nack. > > Your PRIME hash function is dangerously limited. You guarantee an > overflow on 64-bit systems with strings of 13 characters or more. Worse > on 32 bit systems. At minimum, declare phash a uint64_t. Furthermore, in > your algorithm, the strings "mystring" and "mystirng" will produce an > identical hash. Consider locating a library that provides a safer and > less collision-prone hash. (I have no recommendations, perhaps someone > else on the list can help.) > > Beyond that, I'm not going to look too deeply into the internals. > Syntactically everything looks fine on a quick scan. It compiles cleanly > against the current head and does not break any existing code, so once > the above change is made, I'm comfortable with committing it and working > out any bugs later on. > This is really funny. The hash function is the exact copy of the key hash function from the dhash.c lines 131 - 132. This function constructs the key for the hash table entries so I assumed that it is sufficient enough. I view this hash as a quick internal aid to searching. If it worked in dhash.c why it would not work for me. The limitation you bring up related to overflow and order of letters is not a worry at the moment. It can be enhanced later in a separate patch. By the way the dhash.c has a bug in this code (line 131). The value of h in the result of the hashing of a string will always be 0 since h is initialized to 0 and then multiplied. If there are no other issues I suggest accepting patch and I will log an enhancement request to improve hashing in collection. _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mathiaz at ubuntu.com Mon Jun 29 23:20:55 2009 From: mathiaz at ubuntu.com (Mathias Gug) Date: Mon, 29 Jun 2009 19:20:55 -0400 Subject: [Freeipa-devel] Ubuntu interests in FreeIPA Message-ID: <20090629232054.GI5965@mathiaz.mathiaz.net> Hi, I'm part of the Ubuntu Server Team. I've been looking at the FreeIPA project for some time now and how it could be integrated in Ubuntu for the next release (Karmic scheduled October 2009). I'd like to get your input on my proposal. Interesting components of FreeIPA that I'd like to get integrated in Ubuntu: * sssd (there is already a work in progress to get debian packages in the next release (karmic)). * the management tools: web UI + cli + XML-RPC backend. * MIT kerberos. Components that I'm looking into replacing: * replace 389 Directory Server with openldap. The main reason being that the 389 Directory server is not available in the Ubuntu archive yet (there is a work in progress to get it included in Debian/Ubuntu) while openldap is already in the archive and the currently recommended directory solution in Ubuntu. My question is how tight are FreeIPA and 389 Directory Server coupled? * different Directory Information Tree (DIT): replace with openldap-dit [1]. [1]: https://launchpad.net/openldap-dit My question is how tight are the management tools and the DIT coupled? * deployment scripts: replace with puppet recipes/manifests. Here is my current proposal for karmic (schedule for October 2009): * package SSSD. * package FreeIPA 1.2.1 management tools. I've got several other questions: * When will the refactoring of the management tools will be completed? * Is there an updated roadmap and timeline? Thanks for your input, -- Mathias Gug Ubuntu Developer http://www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From kwade at redhat.com Tue Jun 30 00:25:07 2009 From: kwade at redhat.com (Karsten Wade) Date: Mon, 29 Jun 2009 17:25:07 -0700 Subject: [Freeipa-devel] CLA or contribution policy? In-Reply-To: <4A48EDB6.9090209@redhat.com> References: <20090629083624.GA28739@calliope.phig.org> <4A48EDB6.9090209@redhat.com> Message-ID: <20090629195019.GF28739@calliope.phig.org> On Mon, Jun 29, 2009 at 12:37:10PM -0400, Dmitri Pal wrote: > Karsten Wade wrote: > > Recently when I was asking around about the contributor license > > agreement (CLA) that covers FreeIPA, the Legal man asked, "What does > > the FreeIPA project want? Do they want a full-blown CLA or would a > > simpler contribution policy do?" By asking ourselves this question, > > we have a chance to resolve (be happier) about the current CLA, get it > > changed to a more useful agreement, or switch entirely to a > > declarative policy of some kind. > > > I might be wrong but I do not think anyone looked at the problem this way. I believe you are right. When FreeIPA was forming, the folks in Legal handling it were new to Red Hat and took a reasonable (I think) approach of re-using the Fedora CLA. > Some good guidance on the matter will be helpful. There have always been some folks who cannot or will not sign/click-agree to a CLA, regardless of how easy it is. Do any of you have stories about the FreeIPA CLA that you can share? Any positive or negative experiences? > What does freeIPA project wants? Good question. > I think the answer lays somewhere along the lines of: > * It wants to be sufficiently legally covered > * Does not want to create obstacles to contribution > * Does not want to affiliate itself with a specific distribution. Just as a place to start gathering and sorting such answers: http://freeipa.org/page/CLA_or_contribution_policy > Any ideas how that can be translated into appropriate CLI or policy? Let's start by listing what we want and do not want, here and then on to that wiki page. To provide more balance, I am going to take a related discussion to the freeipa-users list; anyone interested in participation and such can give some input. I can then use my magic writer powers and come up with a strawman for us to set fire to. Even if our agreed upon language isn't what the lawyers provide, having a few paragraphs that we have consensus on means we are sending a single, clear message to Legal they can work with. - Karsten -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mpcolino at gmail.com Tue Jun 30 08:49:26 2009 From: mpcolino at gmail.com (Miguel P.C.) Date: Tue, 30 Jun 2009 10:49:26 +0200 Subject: [Freeipa-devel] Ubuntu interests in FreeIPA In-Reply-To: <20090629232054.GI5965@mathiaz.mathiaz.net> References: <20090629232054.GI5965@mathiaz.mathiaz.net> Message-ID: > Hi, Hi Mathias! > I'm part of the Ubuntu Server Team. I've been looking at the FreeIPA > project for some time ?now and how it could be integrated in Ubuntu for > the next release (Karmic scheduled October 2009). I'd like to get your > input on my proposal. Tha sounds wonderful. I was working also in the same direction for my Master's Final Project which I'm finishing now (luckily it'll be over during this week). I'll try to add the info I can share from the (really little) experience I have. :-) > Interesting components of FreeIPA that I'd like to get integrated in Ubuntu: > > ?* sssd (there is already a work in progress to get debian packages in > ? the next release (karmic)). SSSD had a problem[1] with "lbd" dependency due to the package prepared for Debian and used in Ubuntu, This must be solved by now but (you helped on it a lot), but as I haven't tested lately, I can't assure it. [1] https://bugs.launchpad.net/debian/+source/samba4/+bug/372405 > ?* the management tools: web UI + cli + XML-RPC backend. If I'm not wrong, most of the web UI belongs to the 389 Directory Server (389DS). The CLI tools seem to me that they are mostly independent and programmed in Pyhton. I can't program in python (yet), I took a look and almost understood how they work so, they must be really clearly and well programmed. Take this with a little grain of salt as I'm not the most experienced person around here. Simo and Stephen can provide a much better and deeper view on this. > ?* MIT kerberos. > > Components that I'm looking into replacing: > > ?* replace 389 Directory Server with openldap. OK. This could be one of the points with a bigger strategic effect on mid and long term. Please consider this step carefully. > ?The main reason being that the 389 Directory server is not available in > ?the Ubuntu archive yet (there is a work in progress to get it included > ?in Debian/Ubuntu) while openldap is already in the archive and the > ?currently recommended directory solution in Ubuntu. Please take into account that 389 has features worth considering when compared to OpenLDAP. I'll name just three: * Multimaster replication * Nice and well tested tools (including WebUI) * Really stable and tested codebase To me it'll be a dream come true having it packaged for Ubuntu/Debian but I still have _a lot_ to learn to be able to do it myself. Pros on OpenLDAP: * It'll make FreeIPA mor "standard" * It'll help adding better support on other LDAP implementations * Shoter TTM for having "FreeIPA Server" in Ubuntu Cons on OpenLDAP: * It'll lower the need for 389DS * Some features available in 389DS will be missing (and when available they won't be so stable) * Adaptation to DIT can be a bit painful (but really healthy!) > ?My question is how tight are FreeIPA and 389 Directory Server coupled? I can't help on this one. Sorry. > ?* different Directory Information Tree (DIT): replace with openldap-dit [1]. > > [1]: https://launchpad.net/openldap-dit > > ?My question is how tight are the management tools and the DIT coupled? Somebody else with deeper knowledge should answer this one. However, to me they looked like really coupled specially when it comes to the "Directives" part of FreeIPA. I'd love to see a standarized DIT that any LDAP server could use to act as the LDAP component of a FreeIPA infrastructure ... hmmm ... > ?* deployment scripts: replace with puppet recipes/manifests. > > Here is my current proposal for karmic (schedule for October 2009): > ?* package SSSD. Already working on it, but not much progress made. [2] [2] https://launchpad.net/~freeipa > ?* package FreeIPA 1.2.1 management tools. Consider it as two parts: client management tools and server management tools. They should be easy to package but they seem to depend on SSSD and 389DS. > I've got several other questions: > ?* When will the refactoring of the management tools will be completed? > ?* Is there an updated roadmap and timeline? Normally I find that info in the usual websites, but from what I read you probably looked for it before. Anyway here they are: [3] https://fedorahosted.org/sssd/ [4] http://freeipa.org [5] http://freeipa.org/page/Roadmap > Thanks for your input, My 0.05 Euro ... (not even two cents) Hope it helps. M* > -- > Mathias Gug > Ubuntu Developer ?http://www.ubuntu.com > From sgallagh at redhat.com Tue Jun 30 12:05:42 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 30 Jun 2009 08:05:42 -0400 Subject: [Freeipa-devel] [PATCH] Improvements to collection API In-Reply-To: <4A49415F.4000804@redhat.com> References: <4A48E195.3050508@redhat.com> <4A4927C9.3040204@redhat.com> <4A49415F.4000804@redhat.com> Message-ID: <4A49FF96.7050907@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/29/2009 06:34 PM, Dmitri Pal wrote: >> Nack. >> >> Your PRIME hash function is dangerously limited. You guarantee an >> overflow on 64-bit systems with strings of 13 characters or more. Worse >> on 32 bit systems. At minimum, declare phash a uint64_t. Furthermore, in >> your algorithm, the strings "mystring" and "mystirng" will produce an >> identical hash. Consider locating a library that provides a safer and >> less collision-prone hash. (I have no recommendations, perhaps someone >> else on the list can help.) >> >> Beyond that, I'm not going to look too deeply into the internals. >> Syntactically everything looks fine on a quick scan. It compiles cleanly >> against the current head and does not break any existing code, so once >> the above change is made, I'm comfortable with committing it and working >> out any bugs later on. >> > This is really funny. > The hash function is the exact copy of the key hash function from the > dhash.c lines 131 - 132. > This function constructs the key for the hash table entries so I assumed > that it is sufficient enough. > I view this hash as a quick internal aid to searching. > If it worked in dhash.c why it would not work for me. > The limitation you bring up related to overflow and order of letters is > not a worry at the moment. > It can be enhanced later in a separate patch. > > By the way the dhash.c has a bug in this code (line 131). > The value of h in the result of the hashing of a string will always be 0 > since h is initialized to 0 and then multiplied. > > If there are no other issues I suggest accepting patch and I will log an > enhancement request to improve hashing in collection. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > I'm re-evaluating my original issue with this, which was the overflow. I realized when thinking about it some more that this really isn't the main issue, because an overflow simply drops the high-order bits. However, there's a more serious problem with the fact that simple transliteration of characters can result in identical hashes. I'd rather see us just use FNV-1a (public domain hash algorithm with excellent dispersion)(1): 64-bit variation of FNV-1a: #define FNV1a_prime 1099511628211 #define FNV1a_base 14695981039346656037 ... item->phash = FNV1a_base; while(property[item->property_len] != 0) { item->phash = item->phash ^ property[item->property_len]; item->phash = hash * FNV1a_prime; item->property_len++; } Also, phash MUST be defined as a uint64_t, not simply as "unsigned", since that's not safely portable. The easiest way to approach this would be simply to pull in the public-domain code available here(2). Among other things, this would handle all of the necessary (1) http://isthe.com/chongo/tech/comp/fnv/#FNV-1 This page gives details on how the "magic numbers" were derived, as well as alternate implementations for different hash sizes (32-bit, 128-bit, 512-bit, etc.) (2) http://isthe.com/chongo/src/fnv/fnv-5.0.1.tar.gz - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpJ/5IACgkQeiVVYja6o6PEyACfXfasV2grJdiaVG7PQgyCo4OM vBwAoK2XXy/tpA/qm6BdSImVR6YWc7kZ =/SKV -----END PGP SIGNATURE----- From sbose at redhat.com Tue Jun 30 12:15:12 2009 From: sbose at redhat.com (Sumit Bose) Date: Tue, 30 Jun 2009 14:15:12 +0200 Subject: [Freeipa-devel] [PATCH][SSSD] Remove redundand libPath option In-Reply-To: <4A491EBE.3010708@redhat.com> References: <4A491EBE.3010708@redhat.com> Message-ID: <20090630121512.GA16678@localhost.localdomain> On Mon, Jun 29, 2009 at 04:06:22PM -0400, Stephen Gallagher wrote: > There is no benefit to having a separate libPath option, as it can be > safely constructed from the libName option. ACK. bye, Sumit From sgallagh at redhat.com Tue Jun 30 12:27:00 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 30 Jun 2009 08:27:00 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Remove redundand libPath option In-Reply-To: <20090630121512.GA16678@localhost.localdomain> References: <4A491EBE.3010708@redhat.com> <20090630121512.GA16678@localhost.localdomain> Message-ID: <4A4A0494.3020801@redhat.com> On 06/30/2009 08:15 AM, Sumit Bose wrote: > On Mon, Jun 29, 2009 at 04:06:22PM -0400, Stephen Gallagher wrote: >> There is no benefit to having a separate libPath option, as it can be >> safely constructed from the libName option. > > ACK. > > bye, > Sumit Actually, I remembered this morning that I didn't update the example sssd.conf. Please see the attached patch. (It probably qualifies under the one-liner rule, but I'd rather just send it out) -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Remove-redundant-libPath-option-from-proxy-provider.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From sbose at redhat.com Tue Jun 30 12:59:58 2009 From: sbose at redhat.com (Sumit Bose) Date: Tue, 30 Jun 2009 14:59:58 +0200 Subject: [Freeipa-devel] [PATCH][SSSD] Remove redundand libPath option In-Reply-To: <4A4A0494.3020801@redhat.com> References: <4A491EBE.3010708@redhat.com> <20090630121512.GA16678@localhost.localdomain> <4A4A0494.3020801@redhat.com> Message-ID: <20090630125958.GB16678@localhost.localdomain> On Tue, Jun 30, 2009 at 08:27:00AM -0400, Stephen Gallagher wrote: > On 06/30/2009 08:15 AM, Sumit Bose wrote: > > On Mon, Jun 29, 2009 at 04:06:22PM -0400, Stephen Gallagher wrote: > >> There is no benefit to having a separate libPath option, as it can be > >> safely constructed from the libName option. > > > > ACK. > > > > bye, > > Sumit > > Actually, I remembered this morning that I didn't update the example > sssd.conf. Please see the attached patch. (It probably qualifies under > the one-liner rule, but I'd rather just send it out) > ACK bye, Sumit From rcritten at redhat.com Tue Jun 30 13:22:41 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 30 Jun 2009 09:22:41 -0400 Subject: [Freeipa-devel] Ubuntu interests in FreeIPA In-Reply-To: <20090629232054.GI5965@mathiaz.mathiaz.net> References: <20090629232054.GI5965@mathiaz.mathiaz.net> Message-ID: <4A4A11A1.2060309@redhat.com> Mathias Gug wrote: > Hi, > > I'm part of the Ubuntu Server Team. I've been looking at the FreeIPA > project for some time now and how it could be integrated in Ubuntu for > the next release (Karmic scheduled October 2009). I'd like to get your > input on my proposal. > > Interesting components of FreeIPA that I'd like to get integrated in Ubuntu: > > * sssd (there is already a work in progress to get debian packages in > the next release (karmic)). > * the management tools: web UI + cli + XML-RPC backend. > * MIT kerberos. > > Components that I'm looking into replacing: > > * replace 389 Directory Server with openldap. > > The main reason being that the 389 Directory server is not available in > the Ubuntu archive yet (there is a work in progress to get it included > in Debian/Ubuntu) while openldap is already in the archive and the > currently recommended directory solution in Ubuntu. > > My question is how tight are FreeIPA and 389 Directory Server coupled? Very tightly coupled. We rely on a number of features that I believe are only available in 389, and have added some of our own that are 389-specific. * Distributed Numeric Assignment (DNA) is used to automatically assign the next uidNumber/gidNumber * Multi-master replication to distribute users and schema. OpenLDAP has some MMR capabilities but as I understand it uses a simpler conflict resolution process. * We wrote a password changing plugin that would need to be refactored/re-written from scratch * Not sure if password policies are handled in the same way * Access control is completely different So within the realm of possibility but would be quite a bit of work. I'd guess that a good bit of the IPA installer would need to be reworked as well. > * different Directory Information Tree (DIT): replace with openldap-dit [1]. > > [1]: https://launchpad.net/openldap-dit > > My question is how tight are the management tools and the DIT coupled? Very tightly coupled. Not something that couldn't be changed but it would really be quite a fork. > > * deployment scripts: replace with puppet recipes/manifests. > > Here is my current proposal for karmic (schedule for October 2009): > * package SSSD. > * package FreeIPA 1.2.1 management tools. > > I've got several other questions: > * When will the refactoring of the management tools will be completed? > * Is there an updated roadmap and timeline? No firm timeline yet but I wouldn't expect to see anything earlier than this Fall/Autumn. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Jun 30 13:30:30 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 30 Jun 2009 09:30:30 -0400 Subject: [Freeipa-devel] Ubuntu interests in FreeIPA In-Reply-To: <20090629232054.GI5965@mathiaz.mathiaz.net> References: <20090629232054.GI5965@mathiaz.mathiaz.net> Message-ID: <1246368630.13348.31.camel@localhost.localdomain> On Mon, 2009-06-29 at 19:20 -0400, Mathias Gug wrote: > Hi, > > I'm part of the Ubuntu Server Team. I've been looking at the FreeIPA > project for some time now and how it could be integrated in Ubuntu for > the next release (Karmic scheduled October 2009). I'd like to get your > input on my proposal. > > Interesting components of FreeIPA that I'd like to get integrated in Ubuntu: > > * sssd (there is already a work in progress to get debian packages in > the next release (karmic)). > * the management tools: web UI + cli + XML-RPC backend. > * MIT kerberos. > > Components that I'm looking into replacing: > > * replace 389 Directory Server with openldap. > > The main reason being that the 389 Directory server is not available in > the Ubuntu archive yet (there is a work in progress to get it included > in Debian/Ubuntu) while openldap is already in the archive and the > currently recommended directory solution in Ubuntu. > > My question is how tight are FreeIPA and 389 Directory Server coupled? Very, we use many features of 389DS and a good amount of plugins not available for openldap. It would require a quite substantial amount of work and testing just to port the slapi plugins. Second, OpenLDAP has experimental object level multimaster replication. 389DS has attribute level multimaster replication and coflict resolution. All the tools to manage replication setup would have to be rewritten. ACIs are slightly different between 389DS and openLDAP, that would require to change part of the installation and management tools. There are probably other issues, that will pop-up once someone attacks the problem. I have no problems in principle on supporting multiple LDAP servers in IPA, but that will require a substantial amount of work. > * different Directory Information Tree (DIT): replace with openldap-dit [1]. > > [1]: https://launchpad.net/openldap-dit First of all I think you may be confusing/conflating DIT and Schema. In 1. the schema is incompatible with the MIT kerberos ldap driver as it uses the heimdal schema. On the pure DIT side I don't see any reason to change FreeIPA DIT. We choose the DIT carefully based on many factors, that is unlikely it is going to change, it would only make things incompatible with no benefit whatsoever. (OpenLDAP can use the FreeIPA DIT w/o any problem). > My question is how tight are the management tools and the DIT coupled? > > * deployment scripts: replace with puppet recipes/manifests. Our installation scripts are python scripts delivered with the package, I see no reason to deliver them via puppet. > Here is my current proposal for karmic (schedule for October 2009): > * package SSSD. > * package FreeIPA 1.2.1 management tools. The management tools are bonded to schema, DIT, plugins, once you get them running, you have the whole shebang anyway. > I've got several other questions: > * When will the refactoring of the management tools will be completed? I'll let Rob make an estimate here. > * Is there an updated roadmap and timeline? Not yet. Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Tue Jun 30 14:16:11 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 30 Jun 2009 10:16:11 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Remove redundand libPath option In-Reply-To: <20090630125958.GB16678@localhost.localdomain> References: <4A491EBE.3010708@redhat.com> <20090630121512.GA16678@localhost.localdomain> <4A4A0494.3020801@redhat.com> <20090630125958.GB16678@localhost.localdomain> Message-ID: <4A4A1E2B.8020104@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/30/2009 08:59 AM, Sumit Bose wrote: > On Tue, Jun 30, 2009 at 08:27:00AM -0400, Stephen Gallagher wrote: >> On 06/30/2009 08:15 AM, Sumit Bose wrote: >>> On Mon, Jun 29, 2009 at 04:06:22PM -0400, Stephen Gallagher wrote: >>>> There is no benefit to having a separate libPath option, as it can be >>>> safely constructed from the libName option. >>> ACK. >>> >>> bye, >>> Sumit >> Actually, I remembered this morning that I didn't update the example >> sssd.conf. Please see the attached patch. (It probably qualifies under >> the one-liner rule, but I'd rather just send it out) >> > > ACK > > bye, > Sumit Pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpKHh4ACgkQeiVVYja6o6PRvwCdGRlqkAd12zx8O+PApZCMkQWJ xPkAoJpYYothxU/DPcRk44DhU7me0H61 =m8dc -----END PGP SIGNATURE----- From sgallagh at redhat.com Tue Jun 30 14:17:40 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 30 Jun 2009 10:17:40 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Add missing file to make dist Message-ID: <4A4A1E84.7000702@redhat.com> When I added sss_pam_macros.h, I forgot to add it to Makefile.am. "make dist" wasn't picking it up, so it wasn't included in "make dist-gzip" when creating a tarball. Pushed under one-liner rule. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Add-pam_sss_macros.h-to-make-dist.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From dpal at redhat.com Tue Jun 30 14:44:12 2009 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 30 Jun 2009 10:44:12 -0400 Subject: [Freeipa-devel] CLA or contribution policy? In-Reply-To: <20090629195019.GF28739@calliope.phig.org> References: <20090629083624.GA28739@calliope.phig.org> <4A48EDB6.9090209@redhat.com> <20090629195019.GF28739@calliope.phig.org> Message-ID: <4A4A24BC.6090307@redhat.com> Karsten Wade wrote: > On Mon, Jun 29, 2009 at 12:37:10PM -0400, Dmitri Pal wrote: > >> Karsten Wade wrote: >> >>> Recently when I was asking around about the contributor license >>> agreement (CLA) that covers FreeIPA, the Legal man asked, "What does >>> the FreeIPA project want? Do they want a full-blown CLA or would a >>> simpler contribution policy do?" By asking ourselves this question, >>> we have a chance to resolve (be happier) about the current CLA, get it >>> changed to a more useful agreement, or switch entirely to a >>> declarative policy of some kind. >>> >>> >> I might be wrong but I do not think anyone looked at the problem this way. >> > > I believe you are right. When FreeIPA was forming, the folks in Legal > handling it were new to Red Hat and took a reasonable (I think) > approach of re-using the Fedora CLA. > > >> Some good guidance on the matter will be helpful. >> > > There have always been some folks who cannot or will not > sign/click-agree to a CLA, regardless of how easy it is. > > Do any of you have stories about the FreeIPA CLA that you can share? > Any positive or negative experiences? > > I think there was a case when a person was not interested in contributing due to the need to sign CLA. And I think there have been couple people who signed CLA and added to the project by providing valuable information and guidelines that are now published on the wiki. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Tue Jun 30 14:47:16 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 30 Jun 2009 10:47:16 -0400 Subject: [Freeipa-devel] CLA or contribution policy? In-Reply-To: <20090629195019.GF28739@calliope.phig.org> References: <20090629083624.GA28739@calliope.phig.org> <4A48EDB6.9090209@redhat.com> <20090629195019.GF28739@calliope.phig.org> Message-ID: <1246373236.25726.6.camel@localhost.localdomain> On Mon, 2009-06-29 at 17:25 -0700, Karsten Wade wrote: > On Mon, Jun 29, 2009 at 12:37:10PM -0400, Dmitri Pal wrote: > > Karsten Wade wrote: > > > Recently when I was asking around about the contributor license > > > agreement (CLA) that covers FreeIPA, the Legal man asked, "What does > > > the FreeIPA project want? Do they want a full-blown CLA or would a > > > simpler contribution policy do?" By asking ourselves this question, > > > we have a chance to resolve (be happier) about the current CLA, get it > > > changed to a more useful agreement, or switch entirely to a > > > declarative policy of some kind. > > > > > I might be wrong but I do not think anyone looked at the problem this way. > > I believe you are right. When FreeIPA was forming, the folks in Legal > handling it were new to Red Hat and took a reasonable (I think) > approach of re-using the Fedora CLA. > > > Some good guidance on the matter will be helpful. > > There have always been some folks who cannot or will not > sign/click-agree to a CLA, regardless of how easy it is. > > Do any of you have stories about the FreeIPA CLA that you can share? > Any positive or negative experiences? We had one not so positive experience. With one of the first contributor it took substantial pain and time to get his employer to allow him to sign away rights with the CLA. The employer had no problem with him contributing code to free software projects under the GPL or other licenses though. The problem with CLA is that it may require a substantial investment of time both for the developer and the company he is employed with, that may scare off contributors that are not willing to suffer that pain. > > What does freeIPA project wants? Good question. > > I think the answer lays somewhere along the lines of: > > * It wants to be sufficiently legally covered > > * Does not want to create obstacles to contribution > > * Does not want to affiliate itself with a specific distribution. > > Just as a place to start gathering and sorting such answers: > > http://freeipa.org/page/CLA_or_contribution_policy > > > Any ideas how that can be translated into appropriate CLI or policy? > > Let's start by listing what we want and do not want, here and then on > to that wiki page. To provide more balance, I am going to take a > related discussion to the freeipa-users list; anyone interested in > participation and such can give some input. I can then use my magic > writer powers and come up with a strawman for us to set fire to. > > Even if our agreed upon language isn't what the lawyers provide, > having a few paragraphs that we have consensus on means we are sending > a single, clear message to Legal they can work with. Thanks, this will be very useful. Simo. -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Tue Jun 30 17:08:47 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 30 Jun 2009 19:08:47 +0200 Subject: [Freeipa-devel] [PATCH] Gettextize the sss_ tools In-Reply-To: <4A48BAFC.4040207@redhat.com> References: <4A3B98C4.6060209@redhat.com> <1245437942.11682.21.camel@localhost.localdomain> <4A425B9A.4030605@redhat.com> <1245866366.5479.26.camel@localhost.localdomain> <4A48BAFC.4040207@redhat.com> Message-ID: <4A4A469F.6050009@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/29/2009 03:00 PM, Jakub Hrozek wrote: > Right, do we care, then? > > I think the variadic macro is by far the most elegant solution by not > having a separate body parameter wrapped in its own parenthesis. The same expressed with code is attached. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpKRp8ACgkQHsardTLnvCUKKwCg2Y2ORgd0Wz96Id/8LE11hw9V m5sAoMUV8soyQ3raUNjDLGDLX6cpIzrC =rfIw -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-PRINT-and-ERROR-macros.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-Gettextize-the-sss_-tools.patch URL: From dpal at redhat.com Tue Jun 30 18:28:42 2009 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 30 Jun 2009 14:28:42 -0400 Subject: [Freeipa-devel] [PATCH] Improvements to collection API In-Reply-To: <4A49FF96.7050907@redhat.com> References: <4A48E195.3050508@redhat.com> <4A4927C9.3040204@redhat.com> <4A49415F.4000804@redhat.com> <4A49FF96.7050907@redhat.com> Message-ID: <4A4A595A.6030300@redhat.com> Stephen Gallagher wrote: > On 06/29/2009 06:34 PM, Dmitri Pal wrote: > >> Nack. > >> > >> Your PRIME hash function is dangerously limited. You guarantee an > >> overflow on 64-bit systems with strings of 13 characters or more. Worse > >> on 32 bit systems. At minimum, declare phash a uint64_t. > Furthermore, in > >> your algorithm, the strings "mystring" and "mystirng" will produce an > >> identical hash. Consider locating a library that provides a safer and > >> less collision-prone hash. (I have no recommendations, perhaps someone > >> else on the list can help.) > >> > >> Beyond that, I'm not going to look too deeply into the internals. > >> Syntactically everything looks fine on a quick scan. It compiles > cleanly > >> against the current head and does not break any existing code, so once > >> the above change is made, I'm comfortable with committing it and > working > >> out any bugs later on. > >> The updated patch with more advanced hash is attached. _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Adding-INSERT-into-collection-functionality.patch Type: text/x-patch Size: 174434 bytes Desc: not available URL: From sgallagh at redhat.com Tue Jun 30 18:36:54 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 30 Jun 2009 14:36:54 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Eliminate segfault on first start-up Message-ID: <4A4A5B46.7080904@redhat.com> There was a typo in the confdb setup portion of the monitor_process_init that was attempting to use the wrong cdb object to initialize. This patch also adds some missing talloc_free() calls on error. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Eliminate-segfault-on-first-start-up.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From ssorce at redhat.com Tue Jun 30 18:43:04 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 30 Jun 2009 14:43:04 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Eliminate segfault on first start-up In-Reply-To: <4A4A5B46.7080904@redhat.com> References: <4A4A5B46.7080904@redhat.com> Message-ID: <1246387384.25726.7.camel@localhost.localdomain> On Tue, 2009-06-30 at 14:36 -0400, Stephen Gallagher wrote: > > There was a typo in the confdb setup portion of the > monitor_process_init that was attempting to use the wrong cdb > object to initialize. > > This patch also adds some missing talloc_free() calls on error. ack, commit asap, broken otherwise :) Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Jun 30 18:53:43 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 30 Jun 2009 14:53:43 -0400 Subject: [Freeipa-devel] [PATCHES][SSSD] Config monitoring patches In-Reply-To: <4A421B00.8060907@redhat.com> References: <4A421B00.8060907@redhat.com> Message-ID: <1246388023.25726.10.camel@localhost.localdomain> On Wed, 2009-06-24 at 08:24 -0400, Stephen Gallagher wrote: > + /* First, remove the old watch descriptor */ > + ret = inotify_rm_watch(file_ctx->fd, file_ctx->wd); > + if (ret < 0) { > + err = errno; > + DEBUG(0, ("Could not remove watch descriptor [%s]", > + strerror(err))); > + } > + > + file_ctx->wd = inotify_add_watch(file_ctx->fd, > file_ctx->filename, > + IN_MODIFY); > + if (file_ctx->wd < 0) { > + err = errno; > + DEBUG(0, ("Could not add inotify watch for file [%s]. > Error [%d:%s]\n", > + file_ctx->filename, err, strerror(err))); > + close(file_ctx->fd); > + kill(getpid(), SIGTERM); > + return; > + } > } Have to nack this. As discussed on IRC the remove is unnecessary But the problem is that here you give whatever editor (or human) just 1 second to replace the file. Please allow more time maybe with a progressive delay scheme (wait 1,2,4,8,16 seconds) after X retries (I guess waiting for 30secs or so is fine) then give up and kill the daemon. Haven't checked the rest yet, will do a review of other parts once this is fixed, unless you want me to review some spcific bits before you fix this issue. Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Tue Jun 30 19:20:05 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 30 Jun 2009 15:20:05 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Eliminate segfault on first start-up In-Reply-To: <1246387384.25726.7.camel@localhost.localdomain> References: <4A4A5B46.7080904@redhat.com> <1246387384.25726.7.camel@localhost.localdomain> Message-ID: <4A4A6565.50103@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/30/2009 02:43 PM, Simo Sorce wrote: > On Tue, 2009-06-30 at 14:36 -0400, Stephen Gallagher wrote: >> There was a typo in the confdb setup portion of the >> monitor_process_init that was attempting to use the wrong cdb >> object to initialize. >> >> This patch also adds some missing talloc_free() calls on error. > > ack, commit asap, broken otherwise :) > > Simo. > Pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpKZV8ACgkQeiVVYja6o6PYYACfY4xqoCTr+OoYK2pP8lCW0qIZ SD8An3RiP3cshwgbaFeSb/+gn71UCHlE =3VBW -----END PGP SIGNATURE----- From rcritten at redhat.com Tue Jun 30 20:08:44 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 30 Jun 2009 16:08:44 -0400 Subject: [Freeipa-devel] [PATCH] Fix ipa-client configure on Fedora 11 Message-ID: <4A4A70CC.6060906@redhat.com> This fixes an m4 issue on Fedora 11 in ipa-client. LT wasn't being initialized so only a partial code bit was being added to configure causing it to fail. I tested this on F-11 and F-9. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-configure-with-newer-auto-and-libtool-on-Fedora.patch Type: application/mbox Size: 737 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Jun 30 20:38:13 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 30 Jun 2009 16:38:13 -0400 Subject: [Freeipa-devel] [PATCH] fix httplib issues on Fedora 11 Message-ID: <4A4A77B5.9000803@redhat.com> Fedora 11 switched to Python 2.6 which has a very different httplib implementation. We override some functions to work with nsslib. This forward ports some code from Python 2.5 so the same code should work on 2.4 - 2.6. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-a-local-implementation-of-httplib.SSLFile-and-ht.patch Type: application/mbox Size: 8222 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Jun 30 21:10:20 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 30 Jun 2009 17:10:20 -0400 Subject: [Freeipa-devel] [PATCH] Fix ipa-client configure on Fedora 11 In-Reply-To: <4A4A70CC.6060906@redhat.com> References: <4A4A70CC.6060906@redhat.com> Message-ID: <1246396220.25726.11.camel@localhost.localdomain> On Tue, 2009-06-30 at 16:08 -0400, Rob Crittenden wrote: > This fixes an m4 issue on Fedora 11 in ipa-client. LT wasn't being > initialized so only a partial code bit was being added to configure > causing it to fail. > > I tested this on F-11 and F-9. > ack -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Jun 30 21:11:55 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 30 Jun 2009 17:11:55 -0400 Subject: [Freeipa-devel] [PATCH] fix httplib issues on Fedora 11 In-Reply-To: <4A4A77B5.9000803@redhat.com> References: <4A4A77B5.9000803@redhat.com> Message-ID: <1246396315.25726.12.camel@localhost.localdomain> On Tue, 2009-06-30 at 16:38 -0400, Rob Crittenden wrote: > Fedora 11 switched to Python 2.6 which has a very different httplib > implementation. We override some functions to work with nsslib. This > forward ports some code from Python 2.5 so the same code should work > on > 2.4 - 2.6. meh this is so hackish :) ack -- Simo Sorce * Red Hat, Inc * New York