From mnagy at redhat.com Wed Jul 1 04:15:49 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 1 Jul 2009 06:15:49 +0200 Subject: [Freeipa-devel] Failed replica installation (v2) Message-ID: <20090701061549.6adeb8c9@notas> I'm trying to install a replica, but the installation script fails when trying to restart the 389 server: 2009-07-01 04:11:59,777 INFO [01/Jul/2009:04:11:49 -0400] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8179 - Peer's Certificate issuer is not recognized.) [01/Jul/2009:04:11:49 -0400] - SSL failure: None of the cipher are valid Is this somehow my fault or is this a bug? Thanks Martin From mnagy at redhat.com Wed Jul 1 06:30:44 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 1 Jul 2009 08:30:44 +0200 Subject: [Freeipa-devel] [RFC] Integration of c-ares and tevent In-Reply-To: <1246297315.13348.6.camel@localhost.localdomain> References: <20090629190405.4711a5b4@wolverine.englab.brq.redhat.com> <1246297315.13348.6.camel@localhost.localdomain> Message-ID: <20090701083044.13efc9c8@notas> Simo Sorce wrote: > 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). I just spent couple of hours trying to grasp the tevent_req interface and then trying to use it with resolv.c. Unfortunately, I hit many problems and I think we should just stay with the first version. One thing I really hate is that you create a tevent_req inside a function, return it, and only then will the caller set the callback. This might be all well and good for our code, but ares can call its callback immediately and that's a problem. It could be solved by using tevent_req_post(), but after ares calls the callback you give it and before it returns, it will destroy the hostent struct, so you have to copy the whole thing. And, another problem is that you don't even know if the user did set the callback or not, so the tevent_req_post() will cause the callback to be called two times, argh! I tried to resolve this by using a "default callback" to be used if ares calls it immediately. User would then overwrite it. But I hit some other problems and I'm really sick of it at this moment, so I just quit for now. So, I'm in favor of using the old way. I can try some more if you want, but IMHO it's a waste of time. The pros of using tevent_req is a unified interface, which really is a good thing, but not necessary easy to do if it's not your code that has to call the callback. On the other hand, I can see a big advantage of our current approach. Basically, almost every function you use takes a different callback type. This at least provides some type safety during compile time. Tevent has some checks through talloc, sure, but only during the runtime. It also saves you from having a ton of structs (you could use unions in one struct, but this could be dangerous if you're accessing the wrong union member). So in the summary, yeah, tevent_req is nice but IMHO not very suitable for this particular task. Does anyone have any comments on this? Sorry for the long rant. Martin From rcritten at redhat.com Wed Jul 1 12:33:36 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 01 Jul 2009 08:33:36 -0400 Subject: [Freeipa-devel] Failed replica installation (v2) In-Reply-To: <20090701061549.6adeb8c9@notas> References: <20090701061549.6adeb8c9@notas> Message-ID: <4A4B57A0.7030608@redhat.com> Martin Nagy wrote: > I'm trying to install a replica, but the installation script fails when > trying to restart the 389 server: > > 2009-07-01 04:11:59,777 INFO [01/Jul/2009:04:11:49 -0400] - SSL alert: > CERT_VerifyCertificateNow: verify certificate failed for cert > Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable > Runtime error -8179 - Peer's Certificate issuer is not recognized.) > [01/Jul/2009:04:11:49 -0400] - SSL failure: None of the cipher are valid > > Is this somehow my fault or is this a bug? That would be a bug. It would seem that the CA is not being imported into DS either because it wasn't put into the replica file or some other bug. 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 Jul 1 12:52:37 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 01 Jul 2009 08:52:37 -0400 Subject: [Freeipa-devel] [PATCH] fix httplib issues on Fedora 11 In-Reply-To: <1246396315.25726.12.camel@localhost.localdomain> References: <4A4A77B5.9000803@redhat.com> <1246396315.25726.12.camel@localhost.localdomain> Message-ID: <4A4B5C15.7080503@redhat.com> Simo Sorce wrote: > 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 > Yeah, I'll work on a more long-term fix but this at least lets it work on F-11. 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 Jul 1 12:52:46 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 01 Jul 2009 08:52:46 -0400 Subject: [Freeipa-devel] [PATCH] Fix ipa-client configure on Fedora 11 In-Reply-To: <1246396220.25726.11.camel@localhost.localdomain> References: <4A4A70CC.6060906@redhat.com> <1246396220.25726.11.camel@localhost.localdomain> Message-ID: <4A4B5C1E.9070401@redhat.com> Simo Sorce wrote: > 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 > 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 mnagy at redhat.com Wed Jul 1 13:08:27 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 1 Jul 2009 15:08:27 +0200 Subject: [Freeipa-devel] Failed replica installation (v2) In-Reply-To: <4A4B57A0.7030608@redhat.com> References: <20090701061549.6adeb8c9@notas> <4A4B57A0.7030608@redhat.com> Message-ID: <20090701150827.6c30ae1d@wolverine.englab.brq.redhat.com> On Wed, 01 Jul 2009 08:33:36 -0400, Rob Crittenden wrote: > Martin Nagy wrote: > > I'm trying to install a replica, but the installation script fails > > when trying to restart the 389 server: > > > > 2009-07-01 04:11:59,777 INFO [01/Jul/2009:04:11:49 -0400] - SSL > > alert: CERT_VerifyCertificateNow: verify certificate failed for cert > > Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape > > Portable Runtime error -8179 - Peer's Certificate issuer is not > > recognized.) [01/Jul/2009:04:11:49 -0400] - SSL failure: None of > > the cipher are valid > > > > Is this somehow my fault or is this a bug? > > That would be a bug. It would seem that the CA is not being imported > into DS either because it wasn't put into the replica file or some > other bug. Submitted as bug# 509111. Is there a workaround? BTW, I can see a ca.crt inside the replica info file. Martin From sgallagh at redhat.com Wed Jul 1 13:12:48 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 01 Jul 2009 09:12:48 -0400 Subject: [Freeipa-devel] [PATCH] Improvements to collection API In-Reply-To: <4A4A595A.6030300@redhat.com> References: <4A48E195.3050508@redhat.com> <4A4927C9.3040204@redhat.com> <4A49415F.4000804@redhat.com> <4A49FF96.7050907@redhat.com> <4A4A595A.6030300@redhat.com> Message-ID: <4A4B60D0.8020305@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/30/2009 02:28 PM, Dmitri Pal wrote: > 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 > > > > These changes look good to me. 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/ iEYEARECAAYFAkpLYMoACgkQeiVVYja6o6OCWwCcDyvoYq2IWB4byB68se12OlNO b+4AniKJiD7nkGqOwlLLAsw1ldcu28PR =Thrd -----END PGP SIGNATURE----- From sgallagh at redhat.com Wed Jul 1 13:18:38 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 01 Jul 2009 09:18:38 -0400 Subject: [Freeipa-devel] [PATCH] Improvements to collection API In-Reply-To: <4A4B60D0.8020305@redhat.com> References: <4A48E195.3050508@redhat.com> <4A4927C9.3040204@redhat.com> <4A49415F.4000804@redhat.com> <4A49FF96.7050907@redhat.com> <4A4A595A.6030300@redhat.com> <4A4B60D0.8020305@redhat.com> Message-ID: <4A4B622E.5090206@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/01/2009 09:12 AM, Stephen Gallagher wrote: > On 06/30/2009 02:28 PM, Dmitri Pal wrote: >> 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 > > > > > > These changes look good to me. > Ack. > Pushed to master. _______________________________________________ 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/ iEYEARECAAYFAkpLYh4ACgkQeiVVYja6o6MNjACfXBVunb6UTPriokNjrVFTrOrb QPQAn2LLsZH1MzzbZdm8hzqmXuHueNl4 =C18b -----END PGP SIGNATURE----- From rcritten at redhat.com Wed Jul 1 13:27:00 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 01 Jul 2009 09:27:00 -0400 Subject: [Freeipa-devel] Failed replica installation (v2) In-Reply-To: <20090701150827.6c30ae1d@wolverine.englab.brq.redhat.com> References: <20090701061549.6adeb8c9@notas> <4A4B57A0.7030608@redhat.com> <20090701150827.6c30ae1d@wolverine.englab.brq.redhat.com> Message-ID: <4A4B6424.9010702@redhat.com> Martin Nagy wrote: > On Wed, 01 Jul 2009 08:33:36 -0400, Rob Crittenden > wrote: > >> Martin Nagy wrote: >>> I'm trying to install a replica, but the installation script fails >>> when trying to restart the 389 server: >>> >>> 2009-07-01 04:11:59,777 INFO [01/Jul/2009:04:11:49 -0400] - SSL >>> alert: CERT_VerifyCertificateNow: verify certificate failed for cert >>> Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape >>> Portable Runtime error -8179 - Peer's Certificate issuer is not >>> recognized.) [01/Jul/2009:04:11:49 -0400] - SSL failure: None of >>> the cipher are valid >>> >>> Is this somehow my fault or is this a bug? >> That would be a bug. It would seem that the CA is not being imported >> into DS either because it wasn't put into the replica file or some >> other bug. > > Submitted as bug# 509111. Is there a workaround? BTW, I can > see a ca.crt inside the replica info file. > > Martin I'm firing up a second F-11 VM now to give replication a test. It worked the last time I tried a few weeks ago so I don't know if this is another F-11 idiosyncrasy or a generic bug. 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 Jul 1 14:10:33 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 01 Jul 2009 10:10:33 -0400 Subject: [Freeipa-devel] Failed replica installation (v2) In-Reply-To: <4A4B6424.9010702@redhat.com> References: <20090701061549.6adeb8c9@notas> <4A4B57A0.7030608@redhat.com> <20090701150827.6c30ae1d@wolverine.englab.brq.redhat.com> <4A4B6424.9010702@redhat.com> Message-ID: <4A4B6E59.80702@redhat.com> Rob Crittenden wrote: > Martin Nagy wrote: >> On Wed, 01 Jul 2009 08:33:36 -0400, Rob Crittenden >> wrote: >> >>> Martin Nagy wrote: >>>> I'm trying to install a replica, but the installation script fails >>>> when trying to restart the 389 server: >>>> >>>> 2009-07-01 04:11:59,777 INFO [01/Jul/2009:04:11:49 -0400] - SSL >>>> alert: CERT_VerifyCertificateNow: verify certificate failed for cert >>>> Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape >>>> Portable Runtime error -8179 - Peer's Certificate issuer is not >>>> recognized.) [01/Jul/2009:04:11:49 -0400] - SSL failure: None of >>>> the cipher are valid >>>> >>>> Is this somehow my fault or is this a bug? >>> That would be a bug. It would seem that the CA is not being imported >>> into DS either because it wasn't put into the replica file or some >>> other bug. >> >> Submitted as bug# 509111. Is there a workaround? BTW, I can >> see a ca.crt inside the replica info file. >> >> Martin > > I'm firing up a second F-11 VM now to give replication a test. It worked > the last time I tried a few weeks ago so I don't know if this is another > F-11 idiosyncrasy or a generic bug. > > rob The NSS tool certutil used to list the entire cert chain with the -O option. Now it only lists those certs in the chain that are trusted. We used this to determine what CA's to trust when importing from a PKCS#12 file. I've filed a bug on this. A short-term workaround is to modify ipaserver/install/certs.py in find_root_cert() to always return "CA certificate". This will only work with our self-signed CA. I was able to stand up a replica with this change. 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 Jul 1 17:09:03 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 01 Jul 2009 13:09:03 -0400 Subject: [Freeipa-devel] [RFC] Integration of c-ares and tevent In-Reply-To: <20090701083044.13efc9c8@notas> References: <20090629190405.4711a5b4@wolverine.englab.brq.redhat.com> <1246297315.13348.6.camel@localhost.localdomain> <20090701083044.13efc9c8@notas> Message-ID: <1246468143.25726.31.camel@localhost.localdomain> On Wed, 2009-07-01 at 08:30 +0200, Martin Nagy wrote: > So in the summary, yeah, tevent_req is nice but IMHO not very suitable > for this particular task. Does anyone have any comments on this? Nope, except that I do not agree with the conclusion :-) Sorry if I don't have time to comment more atm. Simo. -- Simo Sorce * Red Hat, Inc * New York From d.Thomas at colostate.edu Wed Jul 1 18:07:26 2009 From: d.Thomas at colostate.edu (Thomas,Dave) Date: Wed, 1 Jul 2009 12:07:26 -0600 Subject: [Freeipa-devel] Failed replica installation (v2) In-Reply-To: <4A4B6E59.80702@redhat.com> References: <20090701061549.6adeb8c9@notas> <4A4B57A0.7030608@redhat.com> <20090701150827.6c30ae1d@wolverine.englab.brq.redhat.com> <4A4B6424.9010702@redhat.com>,<4A4B6E59.80702@redhat.com> Message-ID: <67A4901921307B49AC55A96647DBDBDD10A6FABFFC@EVS4.ColoState.EDU> This fixed my problem with v1.2.1 as well. Thanks. Dave ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Wednesday, July 01, 2009 8:10 AM To: Martin Nagy Cc: freeipa-devel at redhat.com Subject: Re: [Freeipa-devel] Failed replica installation (v2) Rob Crittenden wrote: > Martin Nagy wrote: >> On Wed, 01 Jul 2009 08:33:36 -0400, Rob Crittenden >> wrote: >> >>> Martin Nagy wrote: >>>> I'm trying to install a replica, but the installation script fails >>>> when trying to restart the 389 server: >>>> >>>> 2009-07-01 04:11:59,777 INFO [01/Jul/2009:04:11:49 -0400] - SSL >>>> alert: CERT_VerifyCertificateNow: verify certificate failed for cert >>>> Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape >>>> Portable Runtime error -8179 - Peer's Certificate issuer is not >>>> recognized.) [01/Jul/2009:04:11:49 -0400] - SSL failure: None of >>>> the cipher are valid >>>> >>>> Is this somehow my fault or is this a bug? >>> That would be a bug. It would seem that the CA is not being imported >>> into DS either because it wasn't put into the replica file or some >>> other bug. >> >> Submitted as bug# 509111. Is there a workaround? BTW, I can >> see a ca.crt inside the replica info file. >> >> Martin > > I'm firing up a second F-11 VM now to give replication a test. It worked > the last time I tried a few weeks ago so I don't know if this is another > F-11 idiosyncrasy or a generic bug. > > rob The NSS tool certutil used to list the entire cert chain with the -O option. Now it only lists those certs in the chain that are trusted. We used this to determine what CA's to trust when importing from a PKCS#12 file. I've filed a bug on this. A short-term workaround is to modify ipaserver/install/certs.py in find_root_cert() to always return "CA certificate". This will only work with our self-signed CA. I was able to stand up a replica with this change. rob From mnagy at redhat.com Wed Jul 1 19:39:59 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 1 Jul 2009 21:39:59 +0200 Subject: [Freeipa-devel] [RFC] Integration of c-ares and tevent In-Reply-To: <1246468143.25726.31.camel@localhost.localdomain> References: <20090629190405.4711a5b4@wolverine.englab.brq.redhat.com> <1246297315.13348.6.camel@localhost.localdomain> <20090701083044.13efc9c8@notas> <1246468143.25726.31.camel@localhost.localdomain> Message-ID: <20090701213959.1f4c132e@wolverine.englab.brq.redhat.com> On Wed, 01 Jul 2009 13:09:03 -0400, Simo Sorce wrote: > On Wed, 2009-07-01 at 08:30 +0200, Martin Nagy wrote: > > So in the summary, yeah, tevent_req is nice but IMHO not very > > suitable for this particular task. Does anyone have any comments on > > this? > > Nope, except that I do not agree with the conclusion :-) > Sorry if I don't have time to comment more atm. > > Simo. OK, so I wrapped it into yet another wrapper. I don't like it, but after applying the _send and _recv convention (as discussed on IRC), I really like the result. New version attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: resolv_new.c Type: text/x-csrc Size: 8571 bytes Desc: not available URL: From rcritten at redhat.com Wed Jul 1 19:52:55 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 01 Jul 2009 15:52:55 -0400 Subject: [Freeipa-devel] [PATCH] Fix SELinux compilation on Fedora 11 Message-ID: <4A4BBE97.9010907@redhat.com> Fedora 11 replaced a SELinux macro which was causing the build to fail. Dan Walsh provided a patch to fix it and this patch integrates it into the tree. I've added a conditional so that the same policy file should build against even old SELinux policies (I tested on Fedora 9 and 11). I've included patches for both the master and ipa-1-2 branches. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: selinux-121.patch Type: application/mbox Size: 2845 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: selinux-master.patch Type: application/mbox Size: 2810 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 Jul 1 21:33:59 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 01 Jul 2009 17:33:59 -0400 Subject: [Freeipa-devel] [PATCH] Formatting patch for the collection unit test Message-ID: <4A4BD647.2060802@redhat.com> No logical changes. Just formatting changes to comply with the style guide and enhance readability. I was planning to do it for a while per Simo's comment when he accepted the core of the collection code but indicated that the unit test should be cleaned later. Later has come. -- 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-FORMATTING-minor-cleanup-of-the-unit-test.patch Type: text/x-patch Size: 45724 bytes Desc: not available URL: From dpal at redhat.com Wed Jul 1 22:25:25 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 01 Jul 2009 18:25:25 -0400 Subject: [Freeipa-devel] [PATCH] Stack and Queue APIs using collection Message-ID: <4A4BE255.6020700@redhat.com> Patch adds two convenience interfaces that allow using collection as a queue or as a stack. -- 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-Queue-and-stack-APIs-using-collection.patch Type: text/x-patch Size: 36891 bytes Desc: not available URL: From kwade at redhat.com Thu Jul 2 00:41:17 2009 From: kwade at redhat.com (Karsten Wade) Date: Wed, 1 Jul 2009 17:41:17 -0700 Subject: [Freeipa-devel] Ubuntu interests in FreeIPA In-Reply-To: <1246368630.13348.31.camel@localhost.localdomain> References: <20090629232054.GI5965@mathiaz.mathiaz.net> <1246368630.13348.31.camel@localhost.localdomain> Message-ID: <20090702004117.GL6469@calliope.phig.org> On Tue, Jun 30, 2009 at 09:30:30AM -0400, Simo Sorce wrote: > On Mon, 2009-06-29 at 19:20 -0400, Mathias Gug wrote: > > > > 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. Mathias: With your better connection to the Ubuntu packaging community, do you think there is someone out there already who might want to package 389DS?[1] You might find an unexpected collaborator. From the replies so far, it sounds far more complicated to wed FreeIPA to OpenLDAP than it is to get all of 389DS and SSSD in to Debian. (Do I have that pathway right? Or does Ubuntu maintain a separate source package repo from Debian with additional packages?) cheers - Karsten [1] AIUI, one of the explicit reasons for rebranding to 389DS was to stop people thinking it is just for Fedora-the-Linux-distro. I'm sure there are interested people out there who want to help get 389DS in to Debian/Ubuntu. -- 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 Thu Jul 2 08:14:50 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 02 Jul 2009 10:14:50 +0200 Subject: [Freeipa-devel] [PATCH] Remove outstanding 2's from plugins. Message-ID: <4A4C6C7A.1030706@redhat.com> There were still some references to plugins2 after the backend switch. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Remove-outstanding-2-s-from-plugins.patch Type: application/mbox Size: 3093 bytes Desc: not available URL: From pzuna at redhat.com Thu Jul 2 08:17:13 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 02 Jul 2009 10:17:13 +0200 Subject: [Freeipa-devel] [PATCH] Fix bug: when deleting hosts, their services were deleted incorrectly Message-ID: <4A4C6D09.3060207@redhat.com> Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-bug-when-deleting-hosts-their-services-where-d.patch Type: application/mbox Size: 1508 bytes Desc: not available URL: From sgallagh at redhat.com Thu Jul 2 11:38:18 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 02 Jul 2009 07:38:18 -0400 Subject: [Freeipa-devel] [PATCH] Formatting patch for the collection unit test In-Reply-To: <4A4BD647.2060802@redhat.com> References: <4A4BD647.2060802@redhat.com> Message-ID: <4A4C9C2A.1020409@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/01/2009 05:33 PM, Dmitri Pal wrote: > No logical changes. > Just formatting changes to comply with the style guide and enhance > readability. > > I was planning to do it for a while per Simo's comment when he accepted > the core of the collection code but > indicated that the unit test should be cleaned later. > Later has come. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Ack. There are no functional changes, it applies and compiles cleanly. - -- 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/ iEYEARECAAYFAkpMnCUACgkQeiVVYja6o6P8fwCdEwtXF6+/ZgHi9XX4jGIiQV/v O0MAoJJfYvsxWQv9+wK0jxfzPX9d/28c =i4Eb -----END PGP SIGNATURE----- From sgallagh at redhat.com Thu Jul 2 12:06:00 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 02 Jul 2009 08:06:00 -0400 Subject: [Freeipa-devel] [PATCH] Stack and Queue APIs using collection In-Reply-To: <4A4BE255.6020700@redhat.com> References: <4A4BE255.6020700@redhat.com> Message-ID: <4A4CA2A8.60407@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/01/2009 06:25 PM, Dmitri Pal wrote: > Patch adds two convenience interfaces that allow using collection as a > queue or as a stack. > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I will ack this and commit it but I'm going to fix two things: 1) Formatting bug: every "return error;" line in collection_queue.c and collection_stack.c is prepended by a tab instead of four spaces. There's also one in queue test before "unsigned count;" 2) Trace messages are wrong for enqueue_any_property. I've also opened https://fedorahosted.org/sssd/ticket/69 (tangentially related). The collection API has the potential for namespace collision with programs attempting to import it, so we should clear that up. This patch made me aware of it, but it's true of the pre-existing code, so it'll be better to fix it all at once. - -- 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/ iEYEARECAAYFAkpMoqIACgkQeiVVYja6o6O+0wCeLq31v9Oz8Wo2SfSGfWkmAPyg 2vkAnjejD7xNyS5M+vg/+9UDQKHpANZj =ERYP -----END PGP SIGNATURE----- From sgallagh at redhat.com Thu Jul 2 12:17:43 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 02 Jul 2009 08:17:43 -0400 Subject: [Freeipa-devel] [PATCH] Formatting patch for the collection unit test In-Reply-To: <4A4C9C2A.1020409@redhat.com> References: <4A4BD647.2060802@redhat.com> <4A4C9C2A.1020409@redhat.com> Message-ID: <4A4CA567.6050503@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/02/2009 07:38 AM, Stephen Gallagher wrote: > On 07/01/2009 05:33 PM, Dmitri Pal wrote: >> No logical changes. >> Just formatting changes to comply with the style guide and enhance >> readability. > >> I was planning to do it for a while per Simo's comment when he accepted >> the core of the collection code but >> indicated that the unit test should be cleaned later. >> Later has come. > > > > >> ------------------------------------------------------------------------ > >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Ack. There are no functional changes, it applies and compiles cleanly. > Pushed to master. _______________________________________________ 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/ iEYEARECAAYFAkpMpWcACgkQeiVVYja6o6Me8QCeKbGrH1wAjvcILJl8zxixiWdB 0qUAoIhw4A5zWFvhorOcBgET6EJf7zuU =W0vU -----END PGP SIGNATURE----- From sgallagh at redhat.com Thu Jul 2 12:17:49 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 02 Jul 2009 08:17:49 -0400 Subject: [Freeipa-devel] [PATCH] Stack and Queue APIs using collection In-Reply-To: <4A4CA2A8.60407@redhat.com> References: <4A4BE255.6020700@redhat.com> <4A4CA2A8.60407@redhat.com> Message-ID: <4A4CA56D.1010304@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/02/2009 08:06 AM, Stephen Gallagher wrote: > On 07/01/2009 06:25 PM, Dmitri Pal wrote: >> Patch adds two convenience interfaces that allow using collection as a >> queue or as a stack. > > > > > >> ------------------------------------------------------------------------ > >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > I will ack this and commit it but I'm going to fix two things: > > 1) Formatting bug: every "return error;" line in collection_queue.c and > collection_stack.c is prepended by a tab instead of four spaces. There's > also one in queue test before "unsigned count;" > > 2) Trace messages are wrong for enqueue_any_property. > > I've also opened https://fedorahosted.org/sssd/ticket/69 (tangentially > related). The collection API has the potential for namespace collision > with programs attempting to import it, so we should clear that up. This > patch made me aware of it, but it's true of the pre-existing code, so > it'll be better to fix it all at once. Pushed to master. _______________________________________________ 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/ iEYEARECAAYFAkpMpW0ACgkQeiVVYja6o6MkpQCcDZZtTH5y0riySjF3YKhLkaUT 6z0AnjowpcpZqMsYMSmgUcBohdk7ZncO =hjkr -----END PGP SIGNATURE----- From sgallagh at redhat.com Thu Jul 2 13:01:09 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 02 Jul 2009 09:01:09 -0400 Subject: [Freeipa-devel] [PATCH] check pending_return after dbus_connection_send_with_reply In-Reply-To: <4A421FFF.9030408@redhat.com> 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> <4A421FFF.9030408@redhat.com> Message-ID: <4A4CAF95.4000400@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/24/2009 08:45 AM, Stephen Gallagher wrote: > 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) > Pushed to master. _______________________________________________ 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/ iEYEARECAAYFAkpMr5AACgkQeiVVYja6o6OFOQCfY/EaPWZNtYUCvE5ajN9WSIwB 5lIAnjUpeeVKzq2sQHh46iNjEmSgELwx =snAE -----END PGP SIGNATURE----- From sgallagh at redhat.com Thu Jul 2 13:01:39 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 02 Jul 2009 09:01:39 -0400 Subject: [Freeipa-devel] [PATCH] added kerberos backend and kdc locator plugin In-Reply-To: <20090629095810.GC2969@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> <20090629095810.GC2969@localhost.localdomain> Message-ID: <4A4CAFB3.5060108@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/29/2009 05:58 AM, Sumit Bose wrote: > 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 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Ack 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/ iEYEARECAAYFAkpMr7IACgkQeiVVYja6o6MRRACfdIRRpO1qSyJGyWUrDC9fBfXE tSkAniROxypTrqmjzQ3edOfwR4y6rSiX =2IHg -----END PGP SIGNATURE----- From sgallagh at redhat.com Thu Jul 2 13:02:06 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 02 Jul 2009 09:02:06 -0400 Subject: [Freeipa-devel] [PATCH] let .gitignore only filter autogenerated m4 files In-Reply-To: <4A3A275E.6000202@redhat.com> References: <4A3A06E6.9060602@redhat.com> <4A3A275E.6000202@redhat.com> Message-ID: <4A4CAFCE.9050309@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/18/2009 07:39 AM, Stephen Gallagher wrote: > 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 > Pushed to master. _______________________________________________ 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/ iEYEARECAAYFAkpMr84ACgkQeiVVYja6o6PTxwCaA36ma42oW+BBsi7NSovf0vWh UK0AoJLUb1j/bSsSswaQAvdI+hjdxSVG =6j53 -----END PGP SIGNATURE----- From rcritten at redhat.com Thu Jul 2 13:07:40 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Jul 2009 09:07:40 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix bug: when deleting hosts, their services were deleted incorrectly In-Reply-To: <4A4C6D09.3060207@redhat.com> References: <4A4C6D09.3060207@redhat.com> Message-ID: <4A4CB11C.2020208@redhat.com> Pavel Zuna wrote: > > Pavel I gather this is to handle the case where the incoming hostname could be not fully qualified? Should we have a normalizer to always make the hostname lower-case? 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 Thu Jul 2 13:14:02 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 02 Jul 2009 15:14:02 +0200 Subject: [Freeipa-devel] Re: [PATCH] Fix bug: when deleting hosts, their services were deleted incorrectly In-Reply-To: <4A4CB11C.2020208@redhat.com> References: <4A4C6D09.3060207@redhat.com> <4A4CB11C.2020208@redhat.com> Message-ID: <4A4CB29A.7080807@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> >> Pavel > > I gather this is to handle the case where the incoming hostname could be > not fully qualified? > > Should we have a normalizer to always make the hostname lower-case? > > rob No, the problem was that services for the host being deleted were searched for incorrectly - even services for other hosts can be returned if the service name contains the hostname. I just added check so it doesn't happen. The normalizer is already there, I just didn't notice. The line: hostname = hostname.lower() is redundant. Pavel From rcritten at redhat.com Thu Jul 2 13:15:56 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Jul 2009 09:15:56 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix bug: when deleting hosts, their services were deleted incorrectly In-Reply-To: <4A4CB29A.7080807@redhat.com> References: <4A4C6D09.3060207@redhat.com> <4A4CB11C.2020208@redhat.com> <4A4CB29A.7080807@redhat.com> Message-ID: <4A4CB30C.4010206@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> >>> Pavel >> >> I gather this is to handle the case where the incoming hostname could >> be not fully qualified? >> >> Should we have a normalizer to always make the hostname lower-case? >> >> rob > No, the problem was that services for the host being deleted were > searched for incorrectly - even services for other hosts can be returned > if the service name contains the hostname. I just added check so it > doesn't happen. Ah, nice catch. If you had a host named ldap bad things woudl happen :-) > The normalizer is already there, I just didn't notice. The line: > > hostname = hostname.lower() > > is redundant. > > Pavel Ok, ack. 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 Thu Jul 2 13:26:14 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 02 Jul 2009 15:26:14 +0200 Subject: [Freeipa-devel] [PATCH] Make basegroup-{add, del}-member print failed members with error decriptions. Message-ID: <4A4CB576.7070400@redhat.com> If a member being added/removed isn't found or fails for some reason, I catch the exception and print: name_of_meber: ERROR: exception_message before the command output. I wonder if this shouldn't go to stderr... Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-basegroup-add-del-member-print-failed-member.patch Type: application/mbox Size: 18479 bytes Desc: not available URL: From pzuna at redhat.com Thu Jul 2 13:29:09 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 02 Jul 2009 15:29:09 +0200 Subject: [Freeipa-devel] [PATCH] Fix bug: number of found entries was reported incorrectly in some plugins. Message-ID: <4A4CB625.6040800@redhat.com> Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-bug-number-of-found-entries-was-reported-incorr.patch Type: application/mbox Size: 3072 bytes Desc: not available URL: From dpal at redhat.com Thu Jul 2 13:44:24 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 02 Jul 2009 09:44:24 -0400 Subject: [Freeipa-devel] [PATCH] Stack and Queue APIs using collection In-Reply-To: <4A4CA2A8.60407@redhat.com> References: <4A4BE255.6020700@redhat.com> <4A4CA2A8.60407@redhat.com> Message-ID: <4A4CB9B8.1060809@redhat.com> Stephen Gallagher wrote: > On 07/01/2009 06:25 PM, Dmitri Pal wrote: > > Patch adds two convenience interfaces that allow using collection as a > > queue or as a stack. > > > > > > > ------------------------------------------------------------------------ > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > I will ack this and commit it but I'm going to fix two things: > > 1) Formatting bug: every "return error;" line in collection_queue.c and > collection_stack.c is prepended by a tab instead of four spaces. There's > also one in queue test before "unsigned count;" > Weird. This is bug in the editor. I will try not to forget to check for that. > 2) Trace messages are wrong for enqueue_any_property. > Thanks. > I've also opened https://fedorahosted.org/sssd/ticket/69 (tangentially > related). The collection API has the potential for namespace collision > with programs attempting to import it, so we should clear that up. This > patch made me aware of it, but it's true of the pre-existing code, so > it'll be better to fix it all at once. I understand the motivation. Is it really the best practice? I am concerned that it will be a big effort. I already have about 5 dozen functions. Some of them have collection in the name, some do not. Blindly adding "col" or some other prefix does not seem to be the right approach. It would require a global rethinking of the naming. So far I used the following terminology: property - a key value pair item - property in a internal representation of the collection (think turned into an object) collection - set of items and other collections So names are constructed from these terms and actions (sometimes with preposition and type): insert_str_property modify_bool_item create_collection If we follow the proposal in the ticket we would have: col_create_collection - looks a bit strange to me. Is it Ok with everybody? Suggestions welcome. _______________________________________________ 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 jdennis at redhat.com Thu Jul 2 13:53:27 2009 From: jdennis at redhat.com (John Dennis) Date: Thu, 02 Jul 2009 09:53:27 -0400 Subject: [Freeipa-devel] [PATCH] Stack and Queue APIs using collection In-Reply-To: <4A4CB9B8.1060809@redhat.com> References: <4A4BE255.6020700@redhat.com> <4A4CA2A8.60407@redhat.com> <4A4CB9B8.1060809@redhat.com> Message-ID: <4A4CBBD7.3070005@redhat.com> >> I've also opened https://fedorahosted.org/sssd/ticket/69 (tangentially >> related). The collection API has the potential for namespace collision >> with programs attempting to import it, so we should clear that up. This >> patch made me aware of it, but it's true of the pre-existing code, so >> it'll be better to fix it all at once. > I understand the motivation. Is it really the best practice? yes, it is common to use short prefix for all symbols in languages which do not support namespaces (e.g. C) in order to create a pseudo namespace, and yes it's good practice. > property - a key value pair > item - property in a internal representation of the collection (think > turned into an object) > collection - set of items and other collections > So names are constructed from these terms and actions (sometimes with > preposition and type): > insert_str_property > modify_bool_item > create_collection > If we follow the proposal in the ticket we would have: > col_create_collection - looks a bit strange to me. Is it Ok with everybody? O.K. with me. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Thu Jul 2 14:03:14 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 02 Jul 2009 10:03:14 -0400 Subject: [Freeipa-devel] [PATCH] Stack and Queue APIs using collection In-Reply-To: <4A4CBBD7.3070005@redhat.com> References: <4A4BE255.6020700@redhat.com> <4A4CA2A8.60407@redhat.com> <4A4CB9B8.1060809@redhat.com> <4A4CBBD7.3070005@redhat.com> Message-ID: <4A4CBE22.2040103@redhat.com> John Dennis wrote: >>> I've also opened https://fedorahosted.org/sssd/ticket/69 (tangentially >>> related). The collection API has the potential for namespace collision >>> with programs attempting to import it, so we should clear that up. This >>> patch made me aware of it, but it's true of the pre-existing code, so >>> it'll be better to fix it all at once. > >> I understand the motivation. Is it really the best practice? > > yes, it is common to use short prefix for all symbols in languages > which do not support namespaces (e.g. C) in order to create a pseudo > namespace, and yes it's good practice. > >> property - a key value pair >> item - property in a internal representation of the collection (think >> turned into an object) >> collection - set of items and other collections > >> So names are constructed from these terms and actions (sometimes with >> preposition and type): >> insert_str_property >> modify_bool_item >> create_collection > >> If we follow the proposal in the ticket we would have: >> col_create_collection - looks a bit strange to me. Is it Ok with >> everybody? > > O.K. with me. > Ok massive patch is coming today then. Line up for review. :-) -- 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 Jul 2 14:44:26 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 02 Jul 2009 10:44:26 -0400 Subject: [Freeipa-devel] [PATCH] New deletion unit test Message-ID: <4A4CC7CA.3040000@redhat.com> and minor addition to unit test to address ticket 64. https://fedorahosted.org/sssd/ticket/64 -- 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-New-deletion-unit-test.patch Type: text/x-patch Size: 2877 bytes Desc: not available URL: From pzuna at redhat.com Thu Jul 2 15:02:37 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 02 Jul 2009 17:02:37 +0200 Subject: [Freeipa-devel] [PATCH] Fix unit tests to handle new group-{add, del}-member semantics. Message-ID: <4A4CCC0D.4030805@redhat.com> Fixes unit tests to handle the changes made by a previous patch I posted today. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-unit-tests-to-handle-new-group-add-del-member.patch Type: application/mbox Size: 10671 bytes Desc: not available URL: From dpal at redhat.com Thu Jul 2 15:04:16 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 02 Jul 2009 11:04:16 -0400 Subject: [Freeipa-devel] [PATCH] New deletion unit test In-Reply-To: <4A4CC7CA.3040000@redhat.com> References: <4A4CC7CA.3040000@redhat.com> Message-ID: <4A4CCC70.90904@redhat.com> Dmitri Pal wrote: > and minor addition to unit test to address ticket 64. > https://fedorahosted.org/sssd/ticket/64 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hope this one does not have tabs. -- 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-New-deletion-unit-test.patch Type: text/x-patch Size: 2907 bytes Desc: not available URL: From sgallagh at redhat.com Thu Jul 2 15:35:57 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 02 Jul 2009 11:35:57 -0400 Subject: [Freeipa-devel] [PATCH] New deletion unit test In-Reply-To: <4A4CCC70.90904@redhat.com> References: <4A4CC7CA.3040000@redhat.com> <4A4CCC70.90904@redhat.com> Message-ID: <4A4CD3DD.7040309@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/02/2009 11:04 AM, Dmitri Pal wrote: > Dmitri Pal wrote: >> and minor addition to unit test to address ticket 64. >> https://fedorahosted.org/sssd/ticket/64 >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Hope this one does not have tabs. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Ack 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/ iEYEARECAAYFAkpM09cACgkQeiVVYja6o6PQHQCfR3z28TqSMST9XbAzRpBSRD4M BEQAnjQJz5J1+03Eg2UoWLNGwYF7/mc6 =PrEL -----END PGP SIGNATURE----- From rcritten at redhat.com Thu Jul 2 17:42:01 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Jul 2009 13:42:01 -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: <4A4CF169.8000006@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 ack and 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 Thu Jul 2 17:42:04 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Jul 2009 13:42:04 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix Encoder.decode test. In-Reply-To: <4A37B25E.3040005@redhat.com> References: <4A37B25E.3040005@redhat.com> Message-ID: <4A4CF16C.1010305@redhat.com> Pavel Zuna wrote: > Patch 0001: Fix Encoder.decode test. > > Pavel ack and 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 Thu Jul 2 17:42:08 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Jul 2009 13:42:08 -0400 Subject: [Freeipa-devel] Re: [PATCH] Rename *-create/*-delete commands to *-add/*-del respectively. In-Reply-To: <4A37B2A5.9070906@redhat.com> References: <4A37B2A5.9070906@redhat.com> Message-ID: <4A4CF170.1010500@redhat.com> Pavel Zuna wrote: > Patch 0002: Rename *-create/*-delete commands to *-add/*-del respectively. > > Pavel ack and 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 Thu Jul 2 17:42:11 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Jul 2009 13:42:11 -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: <4A4CF173.7080701@redhat.com> Pavel Z?na wrote: > Patch 0001: Fix bug in basegroup and passwd plugins (incorrect use of > find_entry_attr). > > Pavel ack and 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 Thu Jul 2 17:42:17 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Jul 2009 13:42:17 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix minor bugs, typos, etc. discovered by unit tests in plugins. In-Reply-To: <4A422F4B.9090104@redhat.com> References: <4A422F4B.9090104@redhat.com> Message-ID: <4A4CF179.1030709@redhat.com> Pavel Zuna wrote: > This patch depends on the "LDAP switch" patches blocked because of > lacking unit tests, which is kind of a chicken/egg problem. > > Pavel ack and 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 Thu Jul 2 17:42:23 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Jul 2009 13:42:23 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Add unit tests for new plugins. In-Reply-To: <4A4230A9.3070405@redhat.com> References: <4A4230A9.3070405@redhat.com> Message-ID: <4A4CF17F.3000107@redhat.com> Pavel Zuna wrote: > 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 ack x3 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 Thu Jul 2 17:42:27 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Jul 2009 13:42:27 -0400 Subject: [Freeipa-devel] Re: [PATCH] Remove outstanding 2's from plugins. In-Reply-To: <4A4C6C7A.1030706@redhat.com> References: <4A4C6C7A.1030706@redhat.com> Message-ID: <4A4CF183.8040308@redhat.com> Pavel Zuna wrote: > There were still some references to plugins2 after the backend switch. > > Pavel ack and 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 Thu Jul 2 17:42:33 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Jul 2009 13:42:33 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix bug: when deleting hosts, their services were deleted incorrectly In-Reply-To: <4A4CB29A.7080807@redhat.com> References: <4A4C6D09.3060207@redhat.com> <4A4CB11C.2020208@redhat.com> <4A4CB29A.7080807@redhat.com> Message-ID: <4A4CF189.1040704@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> >>> Pavel >> >> I gather this is to handle the case where the incoming hostname could >> be not fully qualified? >> >> Should we have a normalizer to always make the hostname lower-case? >> >> rob > No, the problem was that services for the host being deleted were > searched for incorrectly - even services for other hosts can be returned > if the service name contains the hostname. I just added check so it > doesn't happen. > > The normalizer is already there, I just didn't notice. The line: > > hostname = hostname.lower() > > is redundant. > > Pavel Ok, doing a massive push of patches, we'll address this later. ack and 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 Thu Jul 2 17:42:36 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Jul 2009 13:42:36 -0400 Subject: [Freeipa-devel] Re: [PATCH] Make basegroup-{add, del}-member print failed members with error decriptions. In-Reply-To: <4A4CB576.7070400@redhat.com> References: <4A4CB576.7070400@redhat.com> Message-ID: <4A4CF18C.5070509@redhat.com> Pavel Zuna wrote: > If a member being added/removed isn't found or fails for some reason, I > catch the exception and print: > > name_of_meber: ERROR: exception_message > > before the command output. > > I wonder if this shouldn't go to stderr... > > 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 Thu Jul 2 17:42:39 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Jul 2009 13:42:39 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix bug: number of found entries was reported incorrectly in some plugins. In-Reply-To: <4A4CB625.6040800@redhat.com> References: <4A4CB625.6040800@redhat.com> Message-ID: <4A4CF18F.7060308@redhat.com> Pavel Zuna wrote: > > Pavel ack and 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 Thu Jul 2 17:42:42 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Jul 2009 13:42:42 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix unit tests to handle new group-{add, del}-member semantics. In-Reply-To: <4A4CCC0D.4030805@redhat.com> References: <4A4CCC0D.4030805@redhat.com> Message-ID: <4A4CF192.7030209@redhat.com> Pavel Zuna wrote: > Fixes unit tests to handle the changes made by a previous patch I posted > today. > > Pavel ack and 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 Thu Jul 2 17:50:17 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Jul 2009 13:50:17 -0400 Subject: [Freeipa-devel] NOTICE: new backend pushed Message-ID: <4A4CF359.30700@redhat.com> I just pushed about 20 patches that officially switches to Pavel's new LDAP backend. This removes the object-based LDAP model we used in v1 and had ported to v2. This significantly improves our automated search filter writing so we should be able to do lots of new and clever things and make the *-find commands much smarter. It also adds a slew more base classes for us to subclass from, making plugin programming even simpler. The old model still exists in the tree because it is used by the installer, ipa-ldap-updater and the replication utilities. Those will be migrated over to something new over time. It passes all of our unit tests and I ran through a bunch of other manual tests so I think in general it is pretty solid. One major change from the user perspective is that the data coming out will be both more verbose and more consistent (gotta love inheritance). Otherwise it should work more or less the same as the old plugin. The one different is the automount commands have been renamed but we'll argue that point next week :-) I'm so convinced this is solid that I'm pushing it out the day before a 3-day holiday weekend in the U.S. How is that for confidence. Kudos to Pavel for the good 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 jhrozek at redhat.com Thu Jul 2 17:55:27 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 02 Jul 2009 19:55:27 +0200 Subject: [Freeipa-devel] [PATCH] Gettextize the sss_ tools In-Reply-To: <4A4A469F.6050009@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> <4A4A469F.6050009@redhat.com> Message-ID: <4A4CF48F.3070104@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/30/2009 07:08 PM, Jakub Hrozek wrote: > 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 We had a discussion with Stephen off-list on this. New patches are attached - this time, most of the DEBUG messages is left there to provide debugging information, only using debug_level 1 instead of 0. On critical errors, the gettextized ERROR() macro is used to provide (potentionally localized) information to the user with less technical details. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpM9I8ACgkQHsardTLnvCWwCgCg5O7+5lgxKL4XYx7L25gjnVnI Et0An1Wlio1Ni/tqrNSCNrr3/MdHRAuH =ES9f -----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 rcritten at redhat.com Thu Jul 2 18:02:13 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Jul 2009 14:02:13 -0400 Subject: [Freeipa-devel] [PATCH] 234 passwd plugin unit test Message-ID: <4A4CF625.8030007@redhat.com> Add a simple unit test for the password plugin. Doesn't exercise it too much but at least we'll run it. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-234-passwd.patch Type: application/mbox Size: 2852 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 Thu Jul 2 18:17:06 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 02 Jul 2009 14:17:06 -0400 Subject: [Freeipa-devel] [PATCH] Gettextize the sss_ tools In-Reply-To: <4A4CF48F.3070104@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> <4A4A469F.6050009@redhat.com> <4A4CF48F.3070104@redhat.com> Message-ID: <4A4CF9A2.6080307@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/02/2009 01:55 PM, Jakub Hrozek wrote: > On 06/30/2009 07:08 PM, Jakub Hrozek wrote: >> 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 > > We had a discussion with Stephen off-list on this. New patches are > attached - this time, most of the DEBUG messages is left there to > provide debugging information, only using debug_level 1 instead of 0. > On critical errors, the gettextized ERROR() macro is used to provide > (potentionally localized) information to the user with less technical > details. > > Jakub Ack and pushed to master. - ------------------------------------------------------------------------ _______________________________________________ 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/ iEYEARECAAYFAkpM+ZwACgkQeiVVYja6o6MBMACgrKFu1O35j2MePkeYwT0CLORk ZIkAn0dvkSzkLnuYCAyCS1YwpMhXXeM1 =0MGg -----END PGP SIGNATURE----- From ssorce at redhat.com Thu Jul 2 18:41:03 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 02 Jul 2009 14:41:03 -0400 Subject: [Freeipa-devel] NOTICE: new backend pushed In-Reply-To: <4A4CF359.30700@redhat.com> References: <4A4CF359.30700@redhat.com> Message-ID: <1246560063.25726.44.camel@localhost.localdomain> On Thu, 2009-07-02 at 13:50 -0400, Rob Crittenden wrote: > I just pushed about 20 patches that officially switches to Pavel's new > LDAP backend. This removes the object-based LDAP model we used in v1 and > had ported to v2. > > This significantly improves our automated search filter writing so we > should be able to do lots of new and clever things and make the *-find > commands much smarter. > > It also adds a slew more base classes for us to subclass from, making > plugin programming even simpler. > > The old model still exists in the tree because it is used by the > installer, ipa-ldap-updater and the replication utilities. Those will be > migrated over to something new over time. > > It passes all of our unit tests and I ran through a bunch of other > manual tests so I think in general it is pretty solid. > > One major change from the user perspective is that the data coming out > will be both more verbose and more consistent (gotta love inheritance). > Otherwise it should work more or less the same as the old plugin. The > one different is the automount commands have been renamed but we'll > argue that point next week :-) > > I'm so convinced this is solid that I'm pushing it out the day before a > 3-day holiday weekend in the U.S. How is that for confidence. > > Kudos to Pavel for the good work. Yeah kudos to Pavel and the superconfident Rob :-) Very good work guys. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Thu Jul 2 20:13:43 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 02 Jul 2009 16:13:43 -0400 Subject: [Freeipa-devel] [PATCH] Adding prefix "col_" to collection functions Message-ID: <4A4D14F7.8060800@redhat.com> $subj -- 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-Changing-function-names-for-collection-API.patch Type: text/x-patch Size: 436754 bytes Desc: not available URL: From sgallagh at redhat.com Thu Jul 2 20:30:27 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 02 Jul 2009 16:30:27 -0400 Subject: [Freeipa-devel] [PATCH] Adding prefix "col_" to collection functions In-Reply-To: <4A4D14F7.8060800@redhat.com> References: <4A4D14F7.8060800@redhat.com> Message-ID: <4A4D18E3.4010006@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/02/2009 04:13 PM, Dmitri Pal wrote: > $subj > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Nack. You forgot to update server/confdb/confdb_setup.c This would break the build. Other than that, I think it looks sound. - -- 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/ iEYEARECAAYFAkpNGNwACgkQeiVVYja6o6PzmQCfVw89o6tarGbJbFw5LRv+cVTR icUAn361b62FcZ1ClJiPcBM3TRFOVtDB =UemN -----END PGP SIGNATURE----- From ssorce at redhat.com Thu Jul 2 23:21:51 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 02 Jul 2009 19:21:51 -0400 Subject: [Freeipa-devel] [PATCH 0/3] sssd: Rework sysdb to use tevent_req async style Message-ID: <1246576911.25726.71.camel@localhost.localdomain> Hello all, While working on the native ldap driver I found it increasingly cumbersome to use the current sysdb transactional code and callbacks. After some major thinking I decided it would be useful to convert sysdb to use the tevent_req async style. This style uses a few conventions that make async programming a lot easier in my opinion. What follows are three patches: 1. Prep code renames sysdb_req to sysdb_handle to better reflect what this structure actually is and avoid confusion with tevent_req 2. Convert all sysdb code to use tevent_req async style 3. Convert the proxy backend They can be applied one at a time and all should keep working. I've tested all operations with all 3 applied together and everything seem working. I have not yet converted the responder and the sysdb_getXXyyy calls (except for minor internal adjustments), not sure if it is worth changing that interface yet. I may convert the backends interfaae to use directly a tevent_req style later, but preferred to go in steps. I might propose such a patch together with the ldap driver. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Jul 2 23:21:56 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 02 Jul 2009 19:21:56 -0400 Subject: [Freeipa-devel] [PATCH 1/3] sssd: sysdb_req -> sysdb_handle Message-ID: <1246576916.25726.72.camel@localhost.localdomain> Just prep work, a huge rename of one variable. Separating this patch should avoid cluttering the next one which is already huge. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Rename-sysdb_req-to-sysdb_handle.patch Type: text/x-patch Size: 97210 bytes Desc: not available URL: From ssorce at redhat.com Thu Jul 2 23:21:59 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 02 Jul 2009 19:21:59 -0400 Subject: [Freeipa-devel] [PATCH 2/3] sssd: convert sysdb Message-ID: <1246576919.25726.73.camel@localhost.localdomain> This is the huge conversion patch. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Rework-transaction-code-to-use-tevent_req.patch Type: text/x-patch Size: 343648 bytes Desc: not available URL: From ssorce at redhat.com Thu Jul 2 23:22:01 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 02 Jul 2009 19:22:01 -0400 Subject: [Freeipa-devel] [PATCH 3/3] sssd: convert proxy Message-ID: <1246576921.25726.74.camel@localhost.localdomain> Based on the previous patch this one converts also the proxy backend. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Convert-proxy-internals-to-tevent_req-style.patch Type: text/x-patch Size: 97335 bytes Desc: not available URL: From dpal at redhat.com Thu Jul 2 23:44:45 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 02 Jul 2009 19:44:45 -0400 Subject: [Freeipa-devel] [PATCH] Adding wrappers to free data in INI API Message-ID: <4A4D466D.1010003@redhat.com> $subj -- 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-wrappers-to-free-data-in-INI-API.patch Type: text/x-patch Size: 19209 bytes Desc: not available URL: From sgallagh at redhat.com Fri Jul 3 00:03:03 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 02 Jul 2009 20:03:03 -0400 Subject: [Freeipa-devel] [PATCH] Adding wrappers to free data in INI API In-Reply-To: <4A4D466D.1010003@redhat.com> References: <4A4D466D.1010003@redhat.com> Message-ID: <4A4D4AB7.2000106@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/02/2009 07:44 PM, Dmitri Pal wrote: > $subj > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Ack 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/ iEYEARECAAYFAkpNSrMACgkQeiVVYja6o6Ne2gCcCJ6fGVueuAwzsXTt4ivJT2mV klEAn2Pf21zJ1ooEtUpRXtUiRxVFAY4J =CgvP -----END PGP SIGNATURE----- From sgallagh at redhat.com Fri Jul 3 00:03:36 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 02 Jul 2009 20:03:36 -0400 Subject: [Freeipa-devel] [PATCH] Adding prefix "col_" to collection functions In-Reply-To: <4A4D18E3.4010006@redhat.com> References: <4A4D14F7.8060800@redhat.com> <4A4D18E3.4010006@redhat.com> Message-ID: <4A4D4AD8.200@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/02/2009 04:30 PM, Stephen Gallagher wrote: > On 07/02/2009 04:13 PM, Dmitri Pal wrote: >> $subj > > > >> ------------------------------------------------------------------------ > >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Nack. You forgot to update server/confdb/confdb_setup.c > This would break the build. > > Other than that, I think it looks sound. > Ack and pushed to master alongside the INI API wrapper which addressed my previous concern. _______________________________________________ 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/ iEYEARECAAYFAkpNStgACgkQeiVVYja6o6PDDgCghKVDO0E9YK3Oit8sLe3kAo7v i5AAmwebv1lWV0g/f3k8UMe1Y9EhseL0 =Cdsx -----END PGP SIGNATURE----- From sbose at redhat.com Fri Jul 3 12:54:10 2009 From: sbose at redhat.com (Sumit Bose) Date: Fri, 3 Jul 2009 14:54:10 +0200 Subject: [Freeipa-devel] [PATCH 0/3] sssd: Rework sysdb to use tevent_req async style In-Reply-To: <1246576911.25726.71.camel@localhost.localdomain> References: <1246576911.25726.71.camel@localhost.localdomain> Message-ID: <20090703125410.GA13363@localhost.localdomain> On Thu, Jul 02, 2009 at 07:21:51PM -0400, Simo Sorce wrote: > Hello all, > > While working on the native ldap driver I found it increasingly > cumbersome to use the current sysdb transactional code and callbacks. > > After some major thinking I decided it would be useful to convert sysdb > to use the tevent_req async style. > > This style uses a few conventions that make async programming a lot > easier in my opinion. > > What follows are three patches: > 1. Prep code renames sysdb_req to sysdb_handle to better reflect what > this structure actually is and avoid confusion with tevent_req > 2. Convert all sysdb code to use tevent_req async style > 3. Convert the proxy backend > > They can be applied one at a time and all should keep working. > I've tested all operations with all 3 applied together and everything > seem working. > I have tested them together and have not found any issues. Therefore ACK ACK ACK > I have not yet converted the responder and the sysdb_getXXyyy calls > (except for minor internal adjustments), not sure if it is worth > changing that interface yet. > I think it would make sense to have only one interface. Shall I take the pam responder? > I may convert the backends interfaae to use directly a tevent_req style > later, but preferred to go in steps. I might propose such a patch > together with the ldap driver. > +1 This will underline that the backends have to be asynchronous and have to/should use tevent to achieve this. Thanks for the redesign. I'm looking forward to the new LDAP backend. bye, Sumit > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From jhrozek at redhat.com Fri Jul 3 13:47:35 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 03 Jul 2009 15:47:35 +0200 Subject: [Freeipa-devel] [PATCH] Check for root before initializing the tools Message-ID: <4A4E0BF7.8040200@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Check for root before initializing the tools Also move setting locale to separate function to be called before anything else to make sure the "Not root" message would be localized. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpOC/YACgkQHsardTLnvCV9SQCguL0rOoZb6XRW+oE9X6bFmmwD jBMAnAnux1T96bjCkLX3Hue6XHILWb3H =CvXD -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Check-for-root-before-initializing.patch URL: From ssorce at redhat.com Fri Jul 3 15:17:42 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 03 Jul 2009 11:17:42 -0400 Subject: [Freeipa-devel] [PATCH 0/3] sssd: Rework sysdb to use tevent_req async style In-Reply-To: <20090703125410.GA13363@localhost.localdomain> References: <1246576911.25726.71.camel@localhost.localdomain> <20090703125410.GA13363@localhost.localdomain> Message-ID: <1246634262.6317.2.camel@localhost.localdomain> On Fri, 2009-07-03 at 14:54 +0200, Sumit Bose wrote: > > I have tested them together and have not found any issues. Therefore > > ACK > ACK > ACK Ok, pushed to master. > > I have not yet converted the responder and the sysdb_getXXyyy calls > > (except for minor internal adjustments), not sure if it is worth > > changing that interface yet. > > > > I think it would make sense to have only one interface. Shall I take > the > pam responder? Do you have in mind any change beyond just how you fetch information about users ? > > I may convert the backends interfaae to use directly a tevent_req > style > > later, but preferred to go in steps. I might propose such a patch > > together with the ldap driver. > > > > +1 > This will underline that the backends have to be asynchronous and have > to/should use tevent to achieve this. This is the idea. > Thanks for the redesign. I'm looking forward to the new LDAP backend. Yeah working on that :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Fri Jul 3 15:21:48 2009 From: sbose at redhat.com (Sumit Bose) Date: Fri, 3 Jul 2009 17:21:48 +0200 Subject: [Freeipa-devel] [PATCH] Check for root before initializing the tools In-Reply-To: <4A4E0BF7.8040200@redhat.com> References: <4A4E0BF7.8040200@redhat.com> Message-ID: <20090703152148.GB13363@localhost.localdomain> On Fri, Jul 03, 2009 at 03:47:35PM +0200, Jakub Hrozek wrote: > > +int set_locale(void) > +{ > + char *c; > + > + c = setlocale(LC_ALL, ""); > + if (c == NULL) { > + return EIO; > + } > + > + errno = 0; > + c = bindtextdomain(PACKAGE, LOCALEDIR); > + if (c == NULL) { > + return errno; > + } > + > + errno = 0; > + textdomain(PACKAGE); please add 'c = ' > + if (c == NULL) { > + return errno; > + } > + > + return EOK; > +} > + From ssorce at redhat.com Fri Jul 3 16:48:22 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 03 Jul 2009 12:48:22 -0400 Subject: [Freeipa-devel] [PATCH] cleanups Message-ID: <1246639702.6317.10.camel@localhost.localdomain> To all, I have done janitorial work to fix lots and lots of warnings (mainly in common/collection) in the following 2 patches. We have only 1 warning left in collection (I will need to discuss this one with Dmitri next week). Please, before submitting a patch do a complete build from scratch using the following command: make CFLAGS="-Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings" LIBTOOLFLAGS=--silent --quiet If you see any output but "Making all in " then you have a bug to fix before sending the patch in for review. cheers, Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Clean-up-warnings-in-common.patch Type: text/x-patch Size: 46291 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Cleanup-warnings-in-client-and-server-code.patch Type: text/x-patch Size: 2452 bytes Desc: not available URL: From jhrozek at redhat.com Sat Jul 4 17:21:22 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sat, 04 Jul 2009 19:21:22 +0200 Subject: [Freeipa-devel] [PATCH] Check for root before initializing the tools In-Reply-To: <20090703152148.GB13363@localhost.localdomain> References: <4A4E0BF7.8040200@redhat.com> <20090703152148.GB13363@localhost.localdomain> Message-ID: <4A4F8F92.8050607@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/03/2009 05:21 PM, Sumit Bose wrote: > please add 'c = ' Correct, thank you. New patch attached. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpPj4QACgkQHsardTLnvCU/MwCgkY2l2G2rEw8zuveKg5ux70lh cVwAoKUFZAi8i+kRoBztHgNmWBjYLRsM =hoFw -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Check-for-root-before-initializing.patch URL: From sbose at redhat.com Mon Jul 6 08:36:14 2009 From: sbose at redhat.com (Sumit Bose) Date: Mon, 6 Jul 2009 10:36:14 +0200 Subject: [Freeipa-devel] [PATCH] cleanups In-Reply-To: <1246639702.6317.10.camel@localhost.localdomain> References: <1246639702.6317.10.camel@localhost.localdomain> Message-ID: <20090706083614.GC13363@localhost.localdomain> On Fri, Jul 03, 2009 at 12:48:22PM -0400, Simo Sorce wrote: > To all, > I have done janitorial work to fix lots and lots of warnings (mainly in > common/collection) in the following 2 patches. > > We have only 1 warning left in collection (I will need to discuss this > one with Dmitri next week). > > Please, > before submitting a patch do a complete build from scratch using the > following command: > > make CFLAGS="-Wall -Wshadow -Wstrict-prototypes -Wpointer-arith > -Wcast-qual -Wcast-align -Wwrite-strings" LIBTOOLFLAGS=--silent --quiet > > If you see any output but "Making all in " then you have a > bug to fix before sending the patch in for review. > ACK But I have two more questions: - I still get 'collection.c:72: warning: initialization discards qualifiers from pointer target type' because dummy_item is initialized with "" which is const. While looking at col_delete_collection I think it might be possible that a free is called on that "". Shouldn't we use a strdup'ed "" to initialize dummy_item to be on the safe side? - some people recommend to replace code like: if (item->property != NULL) free(item->property); by free(item->property); (see http://post-office.corp.redhat.com/archives/tech-list/2009-May/msg00659.html) Shall we try to meet this recommendation and change this? (Yes, I know I have done this in pam_sss.c, too. :-) bye, Sumit From ssorce at redhat.com Mon Jul 6 12:14:45 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 06 Jul 2009 08:14:45 -0400 Subject: [Freeipa-devel] [PATCH] cleanups In-Reply-To: <20090706083614.GC13363@localhost.localdomain> References: <1246639702.6317.10.camel@localhost.localdomain> <20090706083614.GC13363@localhost.localdomain> Message-ID: <1246882485.6317.31.camel@localhost.localdomain> On Mon, 2009-07-06 at 10:36 +0200, Sumit Bose wrote: > On Fri, Jul 03, 2009 at 12:48:22PM -0400, Simo Sorce wrote: > > To all, > > I have done janitorial work to fix lots and lots of warnings (mainly in > > common/collection) in the following 2 patches. > > > > We have only 1 warning left in collection (I will need to discuss this > > one with Dmitri next week). > > > > Please, > > before submitting a patch do a complete build from scratch using the > > following command: > > > > make CFLAGS="-Wall -Wshadow -Wstrict-prototypes -Wpointer-arith > > -Wcast-qual -Wcast-align -Wwrite-strings" LIBTOOLFLAGS=--silent --quiet > > > > If you see any output but "Making all in " then you have a > > bug to fix before sending the patch in for review. > > > > ACK > > But I have two more questions: > > - I still get 'collection.c:72: warning: initialization discards > qualifiers from pointer target type' because dummy_item is initialized > with "" which is const. While looking at col_delete_collection I think > it might be possible that a free is called on that "". Shouldn't we > use a strdup'ed "" to initialize dummy_item to be on the safe side? Yes, this is exactly the thing I said I need to talk Dmitri about. > - some people recommend to replace code like: > if (item->property != NULL) free(item->property); > by > free(item->property); > (see > http://post-office.corp.redhat.com/archives/tech-list/2009-May/msg00659.html) > > Shall we try to meet this recommendation and change this? (Yes, I know > I have done this in pam_sss.c, too. :-) Yes, absolutely, it makes not sense to check for NULL, free(NULL) is just a noop, worth not wasting checking about it. Simo. -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Mon Jul 6 12:31:19 2009 From: sbose at redhat.com (Sumit Bose) Date: Mon, 6 Jul 2009 14:31:19 +0200 Subject: [Freeipa-devel] [PATCH] Check for root before initializing the tools In-Reply-To: <4A4F8F92.8050607@redhat.com> References: <4A4E0BF7.8040200@redhat.com> <20090703152148.GB13363@localhost.localdomain> <4A4F8F92.8050607@redhat.com> Message-ID: <20090706123119.GD13363@localhost.localdomain> On Sat, Jul 04, 2009 at 07:21:22PM +0200, Jakub Hrozek wrote: > > On 07/03/2009 05:21 PM, Sumit Bose wrote: > > please add 'c = ' > > Correct, thank you. New patch attached. > > Jakub ACK I would like to rise the question how we should handle patches which will affect *.pot and *po files like this one. Should - the author of the patch provided the changes to *.pot and *.po files together with the patch - the *.pot and *.po files in the repository be only updated when a new release is created? Does anyone know which way the Fedora translation team would prefer? bye, Sumit From dpal at redhat.com Mon Jul 6 12:42:59 2009 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 06 Jul 2009 08:42:59 -0400 Subject: [Freeipa-devel] [PATCH] cleanups In-Reply-To: <1246639702.6317.10.camel@localhost.localdomain> References: <1246639702.6317.10.camel@localhost.localdomain> Message-ID: <4A51F153.1090707@redhat.com> Simo Sorce wrote: > To all, > I have done janitorial work to fix lots and lots of warnings (mainly in > common/collection) in the following 2 patches. > > Thank you. But why they do not show up automatically in the normal build? I trust whatever Steven has setup as the default build and I do not see any warnings otherwise I would have addressed them. > We have only 1 warning left in collection (I will need to discuss this > one with Dmitri next week). > > I am just used to checking free(). In old times it was dangerous to free without checking. I do not know how porting to other platforms would go down the road. It might be that we would have to use other compiler on other platforms and it might not be as smart. Also I suspect that smart compiler probably optimizes the code so the duplicate checking is removed. It is a bit of defensive programming. If you think it is not worth checking nowadays I will stop doing it. > Please, > before submitting a patch do a complete build from scratch using the > following command: > > make CFLAGS="-Wall -Wshadow -Wstrict-prototypes -Wpointer-arith > -Wcast-qual -Wcast-align -Wwrite-strings" LIBTOOLFLAGS=--silent --quiet > > This should be baked into the configure so it can be easily turned off and on (if not be on by default). > If you see any output but "Making all in " then you have a > bug to fix before sending the patch in for review. > > cheers, > Simo. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Mon Jul 6 13:27:22 2009 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 06 Jul 2009 09:27:22 -0400 Subject: [Freeipa-devel] [PATCH] cleanups In-Reply-To: <1246882485.6317.31.camel@localhost.localdomain> References: <1246639702.6317.10.camel@localhost.localdomain> <20090706083614.GC13363@localhost.localdomain> <1246882485.6317.31.camel@localhost.localdomain> Message-ID: <4A51FBBA.8070200@redhat.com> Simo Sorce wrote: > On Mon, 2009-07-06 at 10:36 +0200, Sumit Bose wrote: > >> On Fri, Jul 03, 2009 at 12:48:22PM -0400, Simo Sorce wrote: >> >>> To all, >>> I have done janitorial work to fix lots and lots of warnings (mainly in >>> common/collection) in the following 2 patches. >>> >>> We have only 1 warning left in collection (I will need to discuss this >>> one with Dmitri next week). >>> >>> Please, >>> before submitting a patch do a complete build from scratch using the >>> following command: >>> >>> make CFLAGS="-Wall -Wshadow -Wstrict-prototypes -Wpointer-arith >>> -Wcast-qual -Wcast-align -Wwrite-strings" LIBTOOLFLAGS=--silent --quiet >>> >>> If you see any output but "Making all in " then you have a >>> bug to fix before sending the patch in for review. >>> >>> >> ACK >> >> But I have two more questions: >> >> - I still get 'collection.c:72: warning: initialization discards >> qualifiers from pointer target type' because dummy_item is initialized >> with "" which is const. While looking at col_delete_collection I think >> it might be possible that a free is called on that "". Shouldn't we >> use a strdup'ed "" to initialize dummy_item to be on the safe side? >> > > Yes, this is exactly the thing I said I need to talk Dmitri about. > > Free is never called on this. It is a special item that is not a part of a collection. It is a marker indicating the end of the collection. It is returned to the caller only if he requests it. And even in this case the custom callback is executed with this item so the pointer to the struct is never even available to the caller to be freed. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rmeggins at redhat.com Mon Jul 6 15:03:56 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 06 Jul 2009 09:03:56 -0600 Subject: [Freeipa-devel] [PATCH] cleanups In-Reply-To: <4A51F153.1090707@redhat.com> References: <1246639702.6317.10.camel@localhost.localdomain> <4A51F153.1090707@redhat.com> Message-ID: <4A52125C.6000900@redhat.com> Dmitri Pal wrote: > Simo Sorce wrote: > >> To all, >> I have done janitorial work to fix lots and lots of warnings (mainly in >> common/collection) in the following 2 patches. >> >> >> > Thank you. But why they do not show up automatically in the normal build? > I trust whatever Steven has setup as the default build and I do not see > any warnings otherwise I would have addressed them. > CFLAGS to do warnings, etc. are traditionally passed in by the build system. For example, these are the flags used when you use rpmbuild on most of our platforms: rpm --eval '%{optflags}' -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic You'll notice the -Wall there - that causes many warnings to be printed. > >> We have only 1 warning left in collection (I will need to discuss this >> one with Dmitri next week). >> >> >> > I am just used to checking free(). In old times it was dangerous to free > without checking. > I do not know how porting to other platforms would go down the road. > It might be that we would have to use other compiler on other platforms > and it might not be as smart. > Also I suspect that smart compiler probably optimizes the code so the > duplicate checking is removed. > It is a bit of defensive programming. If you think it is not worth > checking nowadays I will stop doing it. > There was a discussion about this a while ago on tech-list, and also in the mozilla newsgroups. It has been at least 10 years since checking for NULL before free was recommended. It is not needed anymore on any platform. > > >> Please, >> before submitting a patch do a complete build from scratch using the >> following command: >> >> make CFLAGS="-Wall -Wshadow -Wstrict-prototypes -Wpointer-arith >> -Wcast-qual -Wcast-align -Wwrite-strings" LIBTOOLFLAGS=--silent --quiet >> >> >> > This should be baked into the configure so it can be easily turned off > and on (if not be on by default). > It's tricky to do that portably. > > > >> If you see any output but "Making all in " then you have a >> bug to fix before sending the patch in for review. >> >> cheers, >> Simo. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 ssorce at redhat.com Mon Jul 6 15:42:53 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 06 Jul 2009 11:42:53 -0400 Subject: [Freeipa-devel] [PATCH] cleanups In-Reply-To: <20090706083614.GC13363@localhost.localdomain> References: <1246639702.6317.10.camel@localhost.localdomain> <20090706083614.GC13363@localhost.localdomain> Message-ID: <1246894973.6317.36.camel@localhost.localdomain> On Mon, 2009-07-06 at 10:36 +0200, Sumit Bose wrote: > > ACK > pushed both Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Mon Jul 6 16:18:11 2009 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 06 Jul 2009 12:18:11 -0400 Subject: [Freeipa-devel] [PATCH] Fixing build issues Message-ID: <4A5223C3.4050202@redhat.com> There is a missing macro in the replace's configure.ac. -- 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-Fixing-build-issues.patch Type: text/x-patch Size: 686 bytes Desc: not available URL: From ssorce at redhat.com Mon Jul 6 17:03:07 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 06 Jul 2009 13:03:07 -0400 Subject: [Freeipa-devel] [PATCH] Check for root before initializing the tools In-Reply-To: <20090706123119.GD13363@localhost.localdomain> References: <4A4E0BF7.8040200@redhat.com> <20090703152148.GB13363@localhost.localdomain> <4A4F8F92.8050607@redhat.com> <20090706123119.GD13363@localhost.localdomain> Message-ID: <1246899787.6317.113.camel@localhost.localdomain> On Mon, 2009-07-06 at 14:31 +0200, Sumit Bose wrote: > On Sat, Jul 04, 2009 at 07:21:22PM +0200, Jakub Hrozek wrote: > > > > On 07/03/2009 05:21 PM, Sumit Bose wrote: > > > please add 'c = ' > > > > Correct, thank you. New patch attached. > > > > Jakub > > ACK pushed > I would like to rise the question how we should handle patches which > will affect *.pot and *po files like this one. Should > > - the author of the patch provided the changes to *.pot and *.po files > together with the patch > - the *.pot and *.po files in the repository be only updated when a new > release is created? We always need to insure the latter, although I personally prefer the former I think we decided that it is not required. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Mon Jul 6 17:30:50 2009 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 06 Jul 2009 13:30:50 -0400 Subject: [Freeipa-devel] [PATCH] COLLECTION Removing static placeholder structure. Message-ID: <4A5234CA.5010108@redhat.com> There was a static global structure used in iteration and in traversing the collection. It has been removed and replaced with a better solution. Ticket #77. https://fedorahosted.org/sssd/ticket/77 -- 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 Mon Jul 6 17:42:59 2009 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 06 Jul 2009 13:42:59 -0400 Subject: [Freeipa-devel] [PATCH] COLLECTION Removing static placeholder structure. In-Reply-To: <4A5234CA.5010108@redhat.com> References: <4A5234CA.5010108@redhat.com> Message-ID: <4A5237A3.4040006@redhat.com> Dmitri Pal wrote: > There was a static global structure used in iteration and in > traversing the collection. It has been removed and replaced with > a better solution. > > Ticket #77. https://fedorahosted.org/sssd/ticket/77 > > Oops. The patch is attached :-) -- 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-COLLECTION-Removing-static-placeholder-structure.patch Type: text/x-patch Size: 3391 bytes Desc: not available URL: From ssorce at redhat.com Mon Jul 6 18:06:39 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 06 Jul 2009 14:06:39 -0400 Subject: [Freeipa-devel] [PATCH] Fixing build issues In-Reply-To: <4A5223C3.4050202@redhat.com> References: <4A5223C3.4050202@redhat.com> Message-ID: <1246903599.6317.115.camel@localhost.localdomain> On Mon, 2009-07-06 at 12:18 -0400, Dmitri Pal wrote: > There is a missing macro in the replace's configure.ac. ack and pushed. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Jul 6 18:07:22 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 06 Jul 2009 14:07:22 -0400 Subject: [Freeipa-devel] [PATCH] COLLECTION Removing static placeholder structure. In-Reply-To: <4A5237A3.4040006@redhat.com> References: <4A5234CA.5010108@redhat.com> <4A5237A3.4040006@redhat.com> Message-ID: <1246903642.6317.116.camel@localhost.localdomain> On Mon, 2009-07-06 at 13:42 -0400, Dmitri Pal wrote: > > There was a static global structure used in iteration and in > > traversing the collection. It has been removed and replaced with > > a better solution. > > > > Ticket #77. https://fedorahosted.org/sssd/ticket/77 > > > > > Oops. The patch is attached :-) > Ack and pushed. Thanks for fixing this Dmitri, it removed our last warning (hurrah!) and a potential real bug. Simo. -- Simo Sorce * Red Hat, Inc * New York From jderose at redhat.com Tue Jul 7 04:56:31 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 06 Jul 2009 22:56:31 -0600 Subject: [Freeipa-devel] Encoding of Kerberos principal Message-ID: <1246942591.6198.5.camel@jgd-flap> Don, Is it safe to assume that the principal is UTF-8 encoded (as far as the MIT Kerberos library is concerned)? Cheers, Jason From jderose at redhat.com Tue Jul 7 07:07:10 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 07 Jul 2009 07:07:10 +0000 Subject: [Freeipa-devel] [PATCH] jderose 011 Fleshed out krb plugin and added example of scripting against Python API Message-ID: <1246950430.6198.55.camel@jgd-flap> This patch adds the first example of scripting against the IPA Python API in doc/examples/python-api.py. It also finally fleshes out the ipalib.plugins.kerberos.krb plugin. It wraps the krbV bindings and does correct Unicode encoding/decoding. More work will be coming shortly with some exception handling cleanup and porting code to use Backend.krb instead of krbV, but this is a start. I'm still trying to decide on a good solution for implementing the connection creation in a generic and plugable way (to replace the hard-coded Executioner.create_context() method). The difficulty is 1) we need it to be plugable, we want to be able to add new backends that authenticate using their own mechanisms, while at the same time 2) we only want to expose connections (but not credentials of any kind) on request.context, and to make things worse, we 3) want to lazily create connections whenever possible. I took a couple of stabs at the above, but didn't like any of them, so for now doc/examples/python-api.py just uses a similar hard-coded connection setup to what Executioner.create_context() uses, specifically it does this: if api.env.in_server: api.Backend.ldap2.connect( ccache=api.Backend.krb.default_ccname() ) else: api.Backend.xmlclient.connect() This will be replaced eventually with some common method, but this works for now. One last thing: to be consisted with the Kerberos library (right?) and SASL, I think we should consistently use `ccname` to mean the path of the file containing the credential cache. We use `ccache` a lot instead, which can also be confused with the krbV.CCache object. What does everyone think about this? Cheers, Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-011-krb-plugin-plus-api-example.patch Type: text/x-patch Size: 5103 bytes Desc: not available URL: From mnagy at redhat.com Tue Jul 7 08:44:44 2009 From: mnagy at redhat.com (Martin Nagy) Date: Tue, 7 Jul 2009 10:44:44 +0200 Subject: [Freeipa-devel] [PATCH] cleanups In-Reply-To: <4A51F153.1090707@redhat.com> References: <1246639702.6317.10.camel@localhost.localdomain> <4A51F153.1090707@redhat.com> Message-ID: <20090707104444.24bfc6ed@wolverine.englab.brq.redhat.com> On Mon, 06 Jul 2009 08:42:59 -0400, Dmitri Pal wrote: > I am just used to checking free(). In old times it was dangerous to > free without checking. > I do not know how porting to other platforms would go down the road. > It might be that we would have to use other compiler on other > platforms and it might not be as smart. If we ever find ourselves in the need to use a platform as old as that, we can always do something like this: #define free(x) do { if ((x) != NULL) free(x); } while (0) > Also I suspect that smart compiler probably optimizes the code so the > duplicate checking is removed. Hm.. Nope. Although I would expect as much. But this really isn't the issue. A test like that is really not a performance concern. It's more about having the code pretty. Martin From pzuna at redhat.com Tue Jul 7 09:05:37 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 07 Jul 2009 11:05:37 +0200 Subject: [Freeipa-devel] [PATCH] Fix bug in ldap2.modify_password and make adding/removing members slightly more efficient. Message-ID: <4A530FE1.2050200@redhat.com> - python-ldap method was called incorrectly in ldap2.modify_password - when adding/removing entries, we can retrieve the member attribute only instead of the whole entry Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-bug-in-ldap2.modify_password-and-make-adding-rem.patch Type: application/mbox Size: 1838 bytes Desc: not available URL: From pzuna at redhat.com Tue Jul 7 09:07:01 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 07 Jul 2009 11:07:01 +0200 Subject: [Freeipa-devel] [PATCH] 234 passwd plugin unit test In-Reply-To: <4A4CF625.8030007@redhat.com> References: <4A4CF625.8030007@redhat.com> Message-ID: <4A531035.4080101@redhat.com> Rob Crittenden wrote: > Add a simple unit test for the password plugin. Doesn't exercise it too > much but at least we'll run it. > > rob > There's a bug in ldap2 that you reported before and I didn't fix it yet (posted a patch a few minutes ago on freeipa-devel), but after applying it, it works fine, so: ack. Pavel From dodavis at redhat.com Tue Jul 7 14:08:37 2009 From: dodavis at redhat.com (Don Davis) Date: Tue, 07 Jul 2009 10:08:37 -0400 Subject: [Freeipa-devel] Re: Encoding of Kerberos principal In-Reply-To: <1246942591.6198.5.camel@jgd-flap> References: <1246942591.6198.5.camel@jgd-flap> Message-ID: <4A5356E5.2080706@redhat.com> > > Is it safe to assume that the principal is UTF-8 encoded > (as far as the MIT Kerberos library is concerned)? > hi, jason -- the short answer is "no;" in general, principal names are claimed to be encoding-agnostic, meaning that they're not null-terminated, and the code is supposed to ignore the bytes' internal structure; a principal-name is just void*+length, more-or-less. the long answer is complex, and i can't represent it faithfully. there are places in the code that know about ucs2le (a predecessor to utf-16), and there are Windows- specific places in the code that know about utf-16 strings per se. also, kerberos handles internationalization of passwords, principal-names, and realm-names all differently. it's pretty much what you'd expect for legacy code that predates the internationalization effort. if, as i expect, you have a more-detailed version of your question, i'll try to help. - don - From rcritten at redhat.com Wed Jul 8 02:58:00 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 07 Jul 2009 22:58:00 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix bug in ldap2.modify_password and make adding/removing members slightly more efficient. In-Reply-To: <4A530FE1.2050200@redhat.com> References: <4A530FE1.2050200@redhat.com> Message-ID: <4A540B38.7040301@redhat.com> Pavel Zuna wrote: > - python-ldap method was called incorrectly in ldap2.modify_password > - when adding/removing entries, we can retrieve the member attribute > only instead of the whole entry > > Pavel ack and 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 Jul 8 02:58:06 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 07 Jul 2009 22:58:06 -0400 Subject: [Freeipa-devel] [PATCH] 234 passwd plugin unit test In-Reply-To: <4A531035.4080101@redhat.com> References: <4A4CF625.8030007@redhat.com> <4A531035.4080101@redhat.com> Message-ID: <4A540B3E.1020303@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Add a simple unit test for the password plugin. Doesn't exercise it >> too much but at least we'll run it. >> >> rob >> > > There's a bug in ldap2 that you reported before and I didn't fix it yet > (posted a patch a few minutes ago on freeipa-devel), but after applying > it, it works fine, so: > > 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 Wed Jul 8 03:00:30 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 07 Jul 2009 23:00:30 -0400 Subject: [Freeipa-devel] [PATCH] Add LDAP class variable for SSL Message-ID: <4A540BCE.9060702@redhat.com> Older versions of python-ldap will assert if you call ldap.get_option() on an option that hasn't been set yet. This was causing the server to crash on Fedora 9 and older with any request. I added a _ssl boolean class variable which gets set to True if either a CA is set or a cert is provided for authentication. I've already pushed this out to master because it was causing the server to not work at all. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-235-ldap.patch Type: application/mbox Size: 1682 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 Wed Jul 8 09:09:20 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Wed, 08 Jul 2009 09:09:20 +0000 Subject: [Freeipa-devel] Re: Encoding of Kerberos principal In-Reply-To: <4A5356E5.2080706@redhat.com> References: <1246942591.6198.5.camel@jgd-flap> <4A5356E5.2080706@redhat.com> Message-ID: <1247044160.8404.59.camel@jgd-flap> On Tue, 2009-07-07 at 10:08 -0400, Don Davis wrote: > > > > Is it safe to assume that the principal is UTF-8 encoded > > (as far as the MIT Kerberos library is concerned)? > > > > hi, jason -- > > the short answer is "no;" in general, principal names > are claimed to be encoding-agnostic, meaning that they're > not null-terminated, and the code is supposed to ignore the > bytes' internal structure; a principal-name is just void*+length, > more-or-less. Well, as far as the principal and realm, I'm only using it two ways: 1. Client-side I extract the principal/realm from the default credential cache of the user running the process. 2. Client or server side, I get the default realm (which just comes from /etc/krb5.conf, AFAIK). I don't know if the Kerberos standard even allows non-ascii characters in the realm, so I think the only gotcha is with the user-name portion of the principal. Anyway, in the above situations, can I expect any consistency? Does the Kerberos server negotiate the character encoding with the client? Like what happens if I have non-ascii characters in my user-name and and authenticating from a Windows box to a Linux authentication server? > the long answer is complex, and i can't represent it > faithfully. there are places in the code that know about > ucs2le (a predecessor to utf-16), and there are Windows- > specific places in the code that know about utf-16 strings > per se. also, kerberos handles internationalization of > passwords, principal-names, and realm-names all > differently. it's pretty much what you'd expect for > legacy code that predates the internationalization effort. Was the above specific enough? I don't know if I know Kerberos well enough to ask the right questions, but I'm also (at the moment) only concerned with very limited aspects of the libkrb5 API (which I'm using via the python-krbV bindings). Thanks for your help! > if, as i expect, you have a more-detailed version of > your question, i'll try to help. > > - don > > > > > > - From sbose at redhat.com Wed Jul 8 11:08:34 2009 From: sbose at redhat.com (Sumit Bose) Date: Wed, 8 Jul 2009 13:08:34 +0200 Subject: [Freeipa-devel] [PATCH] fixed a double talloc_free error Message-ID: <20090708110834.GE13363@localhost.localdomain> Hi, this patch fixes a double talloc_free error in the sss tools. The sysdb_transaction_commit_recv call free the handle already. bye, Sumit -------------- next part -------------- >From 2bdaf1c7316eeb5c9fc68f0ff6cd0e7487730f6e Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 8 Jul 2009 13:02:44 +0200 Subject: [PATCH] fixed a double talloc_free error --- server/tools/sss_groupadd.c | 2 -- server/tools/sss_groupdel.c | 2 -- server/tools/sss_groupmod.c | 2 -- server/tools/sss_useradd.c | 2 -- server/tools/sss_userdel.c | 2 -- server/tools/sss_usermod.c | 2 -- 6 files changed, 0 insertions(+), 12 deletions(-) diff --git a/server/tools/sss_groupadd.c b/server/tools/sss_groupadd.c index 7050567..40df8c9 100644 --- a/server/tools/sss_groupadd.c +++ b/server/tools/sss_groupadd.c @@ -65,8 +65,6 @@ static void add_group_req_done(struct tevent_req *req) data->error = sysdb_transaction_commit_recv(req); data->done = true; - - talloc_zfree(data->handle); } static void add_group_terminate(struct group_add_ctx *data, int error) diff --git a/server/tools/sss_groupdel.c b/server/tools/sss_groupdel.c index 50ed112..7b65b7d 100644 --- a/server/tools/sss_groupdel.c +++ b/server/tools/sss_groupdel.c @@ -64,8 +64,6 @@ static void groupdel_req_done(struct tevent_req *req) data->error = sysdb_transaction_commit_recv(req); data->done = true; - - talloc_zfree(data->handle); } /* sysdb callback */ diff --git a/server/tools/sss_groupmod.c b/server/tools/sss_groupmod.c index 30f8e54..9f6a974 100644 --- a/server/tools/sss_groupmod.c +++ b/server/tools/sss_groupmod.c @@ -70,8 +70,6 @@ static void mod_group_req_done(struct tevent_req *req) data->error = sysdb_transaction_commit_recv(req); data->done = true; - - talloc_zfree(data->handle); } static void mod_group_done(struct group_mod_ctx *data, int error) diff --git a/server/tools/sss_useradd.c b/server/tools/sss_useradd.c index e78e11c..f9482aa 100644 --- a/server/tools/sss_useradd.c +++ b/server/tools/sss_useradd.c @@ -196,8 +196,6 @@ static void add_user_req_done(struct tevent_req *req) data->error = sysdb_transaction_commit_recv(req); data->done = true; - - talloc_zfree(data->handle); } static void add_user_terminate(struct user_add_ctx *data, int error) diff --git a/server/tools/sss_userdel.c b/server/tools/sss_userdel.c index 857057f..5e400fc 100644 --- a/server/tools/sss_userdel.c +++ b/server/tools/sss_userdel.c @@ -63,8 +63,6 @@ static void userdel_req_done(struct tevent_req *req) data->error = sysdb_transaction_commit_recv(req); data->done = true; - - talloc_zfree(data->handle); } /* sysdb callback */ diff --git a/server/tools/sss_usermod.c b/server/tools/sss_usermod.c index 1b1478a..05df133 100644 --- a/server/tools/sss_usermod.c +++ b/server/tools/sss_usermod.c @@ -107,8 +107,6 @@ static void mod_user_req_done(struct tevent_req *req) data->error = sysdb_transaction_commit_recv(req); data->done = true; - - talloc_zfree(data->handle); } static void mod_user_done(struct user_mod_ctx *data, int error) -- 1.6.2.5 From ssorce at redhat.com Wed Jul 8 12:27:05 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 08 Jul 2009 08:27:05 -0400 Subject: [Freeipa-devel] [PATCH] fixed a double talloc_free error In-Reply-To: <20090708110834.GE13363@localhost.localdomain> References: <20090708110834.GE13363@localhost.localdomain> Message-ID: <1247056025.6317.148.camel@localhost.localdomain> On Wed, 2009-07-08 at 13:08 +0200, Sumit Bose wrote: > > this patch fixes a double talloc_free error in the sss tools. The > sysdb_transaction_commit_recv call free the handle already. > ahh my fault! I saw I made the same error elsewhere when converting and forgot to check if all places were fixed :/ Thanks for catching this! ack! Simo. -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Wed Jul 8 12:38:12 2009 From: sbose at redhat.com (Sumit Bose) Date: Wed, 8 Jul 2009 14:38:12 +0200 Subject: [Freeipa-devel] [PATCH] fixed some typos which prevented password caching Message-ID: <20090708123812.GF13363@localhost.localdomain> Hi, with this patch offline authentication with the proxy backend should work again. bye, Sumit -------------- next part -------------- >From 1da1354949710e64dc1058c26a39787e12c38fe7 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 8 Jul 2009 14:34:06 +0200 Subject: [PATCH] fixed some typos which prevented password caching --- server/providers/proxy.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/server/providers/proxy.c b/server/providers/proxy.c index 048f31f..58d52d5 100644 --- a/server/providers/proxy.c +++ b/server/providers/proxy.c @@ -268,6 +268,8 @@ static void proxy_pam_handler(struct be_req *req) { return proxy_reply(req, EOK, NULL); } tevent_req_set_callback(treq, proxy_pam_handler_cache_done, req); + + return; } proxy_reply(req, EOK, NULL); @@ -385,8 +387,8 @@ static struct tevent_req *cache_password_send(TALLOC_CTX *mem_ctx, talloc_set_destructor((TALLOC_CTX *)state->passwd, password_destructor); - req = sysdb_transaction_send(state, state->ev, sysdb); - if (!req) { + subreq = sysdb_transaction_send(state, state->ev, sysdb); + if (!subreq) { ret = ENOMEM; goto fail; } @@ -408,7 +410,7 @@ static void cache_password_process(struct tevent_req *subreq) struct cache_pw_state); int ret; - ret = sysdb_transaction_recv(req, state, &state->handle); + ret = sysdb_transaction_recv(subreq, state, &state->handle); if (ret) { tevent_req_error(req, ret); return; -- 1.6.2.5 From dodavis at redhat.com Wed Jul 8 14:35:50 2009 From: dodavis at redhat.com (Don Davis) Date: Wed, 08 Jul 2009 10:35:50 -0400 Subject: [Freeipa-devel] Re: Encoding of Kerberos principal In-Reply-To: <1247044160.8404.59.camel@jgd-flap> References: <1246942591.6198.5.camel@jgd-flap> <4A5356E5.2080706@redhat.com> <1247044160.8404.59.camel@jgd-flap> Message-ID: <4A54AEC6.2000005@redhat.com> On 07/08/2009 05:09 AM, Jason Gerard DeRose wrote: > On Tue, 2009-07-07 at 10:08 -0400, Don Davis wrote: >>> > Is it safe to assume that the principal is UTF-8 encoded >>> > (as far as the MIT Kerberos library is concerned)? >>> >>> the short answer is "no;" in general, principal names >>> are claimed to be encoding-agnostic, meaning that they're >>> not null-terminated, and the code is supposed to ignore the >>> bytes' internal structure; a principal-name is just void*+length, >>> more-or-less. > > Well, as far as the principal and realm, I'm only using it two ways: > > 1. Client-side I extract the principal/realm from the default credential > cache of the user running the process. > > 2. Client or server side, I get the default realm (which just comes > from /etc/krb5.conf, AFAIK). > > I don't know if the Kerberos standard even allows non-ascii characters > in the realm, so I think the only gotcha is with the user-name portion > of the principal. > > Anyway, in the above situations, can I expect any consistency? Does the > Kerberos server negotiate the character encoding with the client? Like > what happens if I have non-ascii characters in my user-name and and > authenticating from a Windows box to a Linux authentication server? hi, jason -- i think you're doing as well as you can, but you can't expect perfect consistency. the krb protocol does _not_ negotiate a character-set. the krb spec says, on p.52: "In practice, many implementations treat [name strings] as if they were 8-bit strings of whichever character set the implementation defaults to, without regard to correct usage of character-set designation escape sequences. The default character set is often determined by the current user's operating system-dependent locale. At least one major implementation places unescaped UTF-8 encoded Unicode characters in the [name strings]. This failure to adhere to the ... specifications results in interoperability issueswhen conflicting character encodings are utilized by the Kerberos clients, services, and KDC..." -- http://www.ietf.org/rfc/rfc4120.txt in other words, if a customer's hosts all use the same locale, they might get OK results when AD & MIT try to talk to each other about names. from my reading, i expect krb implementations are most likely to screw up on names and passwords that contain a mixture of characters from different languages (like using a greek letter as part of an english or german name). this weird-but-legal usage is where the above-mentioned "escape sequences" kick in, and krb implementations vary in how well they deal with such mixed-language names. unfortunately, the kerberos spec relies heavily on the ASN.1 spec, which was & is screwed-up on the subject of i8n, just as ASN.1 is screwed up in other ways. if you need a more-precise/standard answer, i'd suggest you read: * pp.52-54 of rfc4120: http://www.ietf.org/rfc/rfc4120.txt * skim the wikipedia description of iso-2022, which is the legacy i8n mechanism, predating unicode & utf8, that krb implementations are supposed to support correctly: http://en.wikipedia.org/wiki/ISO/IEC_2022 * skim iso-8859 (iso latin), too. this is the modern standard for most of the commercially-important alphabetic languages (but not asia), and it's arguably what you wish krb would support well: http://en.wikipedia.org/wiki/ISO/IEC_8859 for interoperability, there's no substitute for testing. further, i think we need to decide early which foreign character-sets we can put off worrying about, based on which languages our paying customers use. the prioritized list i've used elsewhere is: Europe > Japan > Korea > China > Russia > India > Middle East, but redhat's customer-base is probably different. - don - -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Wed Jul 8 14:39:59 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 08 Jul 2009 10:39:59 -0400 Subject: [Freeipa-devel] [PATCH] fixed some typos which prevented password caching In-Reply-To: <20090708123812.GF13363@localhost.localdomain> References: <20090708123812.GF13363@localhost.localdomain> Message-ID: <1247063999.6317.151.camel@localhost.localdomain> On Wed, 2009-07-08 at 14:38 +0200, Sumit Bose wrote: > > with this patch offline authentication with the proxy backend should > work again. If you keep squashing all my bugs, there will be none left for me :-) ack Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Jul 8 14:48:21 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 08 Jul 2009 10:48:21 -0400 Subject: [Freeipa-devel] Re: Encoding of Kerberos principal In-Reply-To: <4A54AEC6.2000005@redhat.com> References: <1246942591.6198.5.camel@jgd-flap> <4A5356E5.2080706@redhat.com> <1247044160.8404.59.camel@jgd-flap> <4A54AEC6.2000005@redhat.com> Message-ID: <1247064501.6317.156.camel@localhost.localdomain> On Wed, 2009-07-08 at 10:35 -0400, Don Davis wrote: > > unfortunately, the kerberos spec relies heavily on the ASN.1 spec, > which was & is screwed-up on the subject of i8n, just as ASN.1 is > screwed up in other ways. if you need a more-precise/standard > answer, > i'd suggest you read: > * pp.52-54 of rfc4120: http://www.ietf.org/rfc/rfc4120.txt > * skim the wikipedia description of iso-2022, which is the > legacy i8n mechanism, predating unicode & utf8, that krb > implementations are supposed to support correctly: > http://en.wikipedia.org/wiki/ISO/IEC_2022 > * skim iso-8859 (iso latin), too. this is the modern standard > for most of the commercially-important alphabetic languages > (but not asia), and it's arguably what you wish krb would > support well: http://en.wikipedia.org/wiki/ISO/IEC_8859 > > for interoperability, there's no substitute for testing. further, > i think we need to decide early which foreign character-sets we > can put off worrying about, based on which languages our paying > customers use. the prioritized list i've used elsewhere is: > Europe > Japan > Korea > China > Russia > India > Middle East, > but redhat's customer-base is probably different. I think the best course of action, at the moment, is to consider using only utf-8 when we generate something and treat as blobs names coming from outside the framework (with getters that tentatively try to return a Unicode string). Using anything but utf-8 is doomed to fail in spectacular ways. If during testing we will find some other consistent pattern we will try to find a fix for the specific case assuming it is detectable or will recommend the user to fix whatever is using absurd encodings. Simo. -- Simo Sorce * Red Hat, Inc * New York From dodavis at redhat.com Wed Jul 8 15:13:42 2009 From: dodavis at redhat.com (Don Davis) Date: Wed, 08 Jul 2009 11:13:42 -0400 Subject: [Freeipa-devel] Re: Encoding of Kerberos principal In-Reply-To: <1247064501.6317.156.camel@localhost.localdomain> References: <1246942591.6198.5.camel@jgd-flap> <4A5356E5.2080706@redhat.com> <1247044160.8404.59.camel@jgd-flap> <4A54AEC6.2000005@redhat.com> <1247064501.6317.156.camel@localhost.localdomain> Message-ID: <4A54B7A6.4040808@redhat.com> On 07/08/2009 10:48 AM, Simo Sorce wrote: > I think the best course of action, at the moment, is to consider using > only utf-8 when we generate something and treat as blobs names coming > from outside the framework (with getters that tentatively try to return > a Unicode string). > > Using anything but utf-8 is doomed to fail in spectacular ways. hi, simo -- p.53 of thr krb spec (rfc4120) says accepting utf-8 is sorta ok, but if the kdc _generates_ anything that's not ascii per se, then interoperability will fail. further, i expect even handling utf-8 as a blob will break down at times, when we're trying to convert between AD-style names, NT-style names, and MIT-style names. - don - From pzuna at redhat.com Wed Jul 8 15:17:41 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 08 Jul 2009 17:17:41 +0200 Subject: [Freeipa-devel] [PATCH] Import explode_dn from ldap.functions for backward compatibility with older version of python-ldap. Fix bug in add_entry_to_group. Message-ID: <4A54B895.6040306@redhat.com> Fixes to blocker bugs when using older version of python-ldap: - explode_dn was moved to ldap.dn in version 2.3.0, but is still available for backward compatibility in ldap.functions (I haven't tested it personally with an older version of python-ldap, but it works with the current and should with older according to documentation.) - get_entry was called with incorrect arguments in ldap2.add_entry_to_group Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Import-explode_dn-from-ldap.functions-for-backward-c.patch Type: application/mbox Size: 1663 bytes Desc: not available URL: From ssorce at redhat.com Wed Jul 8 15:53:40 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 08 Jul 2009 11:53:40 -0400 Subject: [Freeipa-devel] Re: Encoding of Kerberos principal In-Reply-To: <4A54B7A6.4040808@redhat.com> References: <1246942591.6198.5.camel@jgd-flap> <4A5356E5.2080706@redhat.com> <1247044160.8404.59.camel@jgd-flap> <4A54AEC6.2000005@redhat.com> <1247064501.6317.156.camel@localhost.localdomain> <4A54B7A6.4040808@redhat.com> Message-ID: <1247068420.6317.159.camel@localhost.localdomain> On Wed, 2009-07-08 at 11:13 -0400, Don Davis wrote: > On 07/08/2009 10:48 AM, Simo Sorce wrote: > > I think the best course of action, at the moment, is to consider using > > only utf-8 when we generate something and treat as blobs names coming > > from outside the framework (with getters that tentatively try to return > > a Unicode string). > > > > Using anything but utf-8 is doomed to fail in spectacular ways. > hi, simo -- > > p.53 of thr krb spec (rfc4120) says accepting utf-8 is sorta ok, > but if the kdc _generates_ anything that's not ascii per se, then > interoperability will fail. further, i expect even handling utf-8 > as a blob will break down at times, when we're trying to convert > between AD-style names, NT-style names, and MIT-style names. Yes, it's a mess, I made just a generic statement on what we should do by default. Any special case need to be coded tested and coded as exceptions. That's why I said: generate as utf-8, read as a blob, it is just the classic meme "be strict on what you send, be liberal on what you get." Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Jul 8 16:16:09 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 08 Jul 2009 12:16:09 -0400 Subject: [Freeipa-devel] Re: [PATCH] Import explode_dn from ldap.functions for backward compatibility with older version of python-ldap. Fix bug in add_entry_to_group. In-Reply-To: <4A54B895.6040306@redhat.com> References: <4A54B895.6040306@redhat.com> Message-ID: <4A54C649.5050902@redhat.com> Pavel Zuna wrote: > Fixes to blocker bugs when using older version of python-ldap: > > - explode_dn was moved to ldap.dn in version 2.3.0, but is still > available for backward compatibility in ldap.functions (I haven't tested > it personally with an older version of python-ldap, but it works with > the current and should with older according to documentation.) > > - get_entry was called with incorrect arguments in ldap2.add_entry_to_group > > 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 sbose at redhat.com Wed Jul 8 18:58:34 2009 From: sbose at redhat.com (Sumit Bose) Date: Wed, 8 Jul 2009 20:58:34 +0200 Subject: [Freeipa-devel] [PATCH] fix return code of krb5 child to indicate that the kdc is unavailable Message-ID: <20090708185834.GG13363@localhost.localdomain> Hi, this patch let the kerberos child process indicate that the KDC is not available, i.e. the client is offline. This is necessary to tell sssd to use the cached passwords, if available. I will send a patch which will actually store the passwords, when the needed sysdb calls are available. bye, Sumit -------------- next part -------------- >From e56ea0f7c694ad496d53ce205b28a1c8d766337a Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 8 Jul 2009 20:09:56 +0200 Subject: [PATCH] fix return code of krb5 child to indicate that the kdc is unavailable --- server/providers/krb5/tgt_req_child.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/server/providers/krb5/tgt_req_child.c b/server/providers/krb5/tgt_req_child.c index edb3d18..af9f52f 100644 --- a/server/providers/krb5/tgt_req_child.c +++ b/server/providers/krb5/tgt_req_child.c @@ -66,6 +66,7 @@ void tgt_req_child(int fd, struct krb5_req *kr) const char *cc_name; char *env; const char *krb5_error_msg; + int pam_status = PAM_SYSTEM_ERR; ret = setgid(kr->pd->gr_gid); if (ret == -1) { @@ -103,6 +104,9 @@ void tgt_req_child(int fd, struct krb5_req *kr) kr->options); if (kerr != 0) { KRB5_DEBUG(1, kerr); + if (kerr == KRB5_KDC_UNREACH) { + pam_status = PAM_AUTHINFO_UNAVAIL; + } goto childfailed; } @@ -155,7 +159,7 @@ void tgt_req_child(int fd, struct krb5_req *kr) 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, + size = pack_response_packet(buf, pam_status, PAM_USER_INFO, krb5_error_msg); if (size < 0) { DEBUG(1, ("failed to create response message.\n")); -- 1.6.2.5 From ssorce at redhat.com Wed Jul 8 23:41:44 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 08 Jul 2009 19:41:44 -0400 Subject: [Freeipa-devel] [PATCHES(6)] SSSD: Native ldap driver Message-ID: <1247096504.6317.176.camel@localhost.localdomain> This set of patches implement a native ldap driver backend. It is the first basic core of a working driver. It still have a few TODOs and FIXMEs in it, and there are still features that need to be implemented. But it is stable enough and big enough to be useful. I've done basic testing through development, and most stuff should work. Patches: 0001 - add some cleanup code to remove .X files 0002 - expose some useful sysdb functions previously declared static 0003 - add a set of async helpers for the ldap driver 0004 - convert ldap auth to use the async helpers 0005 - unify password caching between proxy and ldap 0006 - implement the identity part of the ldap driver notes: - Sumit you may want to look at 0005 and then unify the krb password caching. - during the implementation of the initgr call I noticed that it would be useful if some of the search function in sysdb could autostart an operation, I implemented this for some functions, might make sense to extend it to others. - there is a definition for an ipa-v1 schema but no implementation yet, it will require 2 other ways to handle initgr depending on whether the ASQ control is available or not. I think the code is good enough to be pushed and will help align the team (esp. Sumit waiting on some of this stuff) so although not perfect it here for review. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-dumb-way-to-clean-up-.X-files.patch Type: text/x-patch Size: 1084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Expose-sysdb-function-to-parse-sysdb_attrs.patch Type: text/x-patch Size: 1523 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-async-helper-functions.patch Type: text/x-patch Size: 73169 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Use-async-helpers-for-ldap-auth-module.patch Type: text/x-patch Size: 41990 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Unify-password-caching-ops-in-sysdb.patch Type: text/x-patch Size: 25353 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Implement-the-ldap-identity-module.patch Type: text/x-patch Size: 93787 bytes Desc: not available URL: From ssorce at redhat.com Wed Jul 8 23:42:02 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 08 Jul 2009 19:42:02 -0400 Subject: [Freeipa-devel] [PATCH] fixed a double talloc_free error In-Reply-To: <1247056025.6317.148.camel@localhost.localdomain> References: <20090708110834.GE13363@localhost.localdomain> <1247056025.6317.148.camel@localhost.localdomain> Message-ID: <1247096522.6317.177.camel@localhost.localdomain> On Wed, 2009-07-08 at 08:27 -0400, Simo Sorce wrote: > On Wed, 2009-07-08 at 13:08 +0200, Sumit Bose wrote: > > > > this patch fixes a double talloc_free error in the sss tools. The > > sysdb_transaction_commit_recv call free the handle already. > > > ahh my fault! > I saw I made the same error elsewhere when converting and forgot to > check if all places were fixed :/ > Thanks for catching this! > > ack! pushed -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Jul 8 23:42:17 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 08 Jul 2009 19:42:17 -0400 Subject: [Freeipa-devel] [PATCH] fixed some typos which prevented password caching In-Reply-To: <1247063999.6317.151.camel@localhost.localdomain> References: <20090708123812.GF13363@localhost.localdomain> <1247063999.6317.151.camel@localhost.localdomain> Message-ID: <1247096537.6317.178.camel@localhost.localdomain> On Wed, 2009-07-08 at 10:39 -0400, Simo Sorce wrote: > On Wed, 2009-07-08 at 14:38 +0200, Sumit Bose wrote: > > > > with this patch offline authentication with the proxy backend should > > work again. > > If you keep squashing all my bugs, there will be none left for me :-) > > ack pushed -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Jul 8 23:42:29 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 08 Jul 2009 19:42:29 -0400 Subject: [Freeipa-devel] [PATCH] fix return code of krb5 child to indicate that the kdc is unavailable In-Reply-To: <20090708185834.GG13363@localhost.localdomain> References: <20090708185834.GG13363@localhost.localdomain> Message-ID: <1247096549.6317.179.camel@localhost.localdomain> On Wed, 2009-07-08 at 20:58 +0200, Sumit Bose wrote: > Hi, > > this patch let the kerberos child process indicate that the KDC is not > available, i.e. the client is offline. This is necessary to tell sssd to > use the cached passwords, if available. I will send a patch which will > actually store the passwords, when the needed sysdb calls are available. ack and pushed -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Thu Jul 9 10:38:18 2009 From: sbose at redhat.com (Sumit Bose) Date: Thu, 9 Jul 2009 12:38:18 +0200 Subject: [Freeipa-devel] [PATCHES(6)] SSSD: Native ldap driver In-Reply-To: <1247096504.6317.176.camel@localhost.localdomain> References: <1247096504.6317.176.camel@localhost.localdomain> Message-ID: <20090709103817.GI13363@localhost.localdomain> On Wed, Jul 08, 2009 at 07:41:44PM -0400, Simo Sorce wrote: > This set of patches implement a native ldap driver backend. > > It is the first basic core of a working driver. It still have a few > TODOs and FIXMEs in it, and there are still features that need to be > implemented. > > But it is stable enough and big enough to be useful. > I've done basic testing through development, and most stuff should work. > > Patches: > 0001 - add some cleanup code to remove .X files > 0002 - expose some useful sysdb functions previously declared static > 0003 - add a set of async helpers for the ldap driver > 0004 - convert ldap auth to use the async helpers > 0005 - unify password caching between proxy and ldap > 0006 - implement the identity part of the ldap driver > > notes: > - Sumit you may want to look at 0005 and then unify the krb password > caching. > - during the implementation of the initgr call I noticed that it would > be useful if some of the search function in sysdb could autostart an > operation, I implemented this for some functions, might make sense to > extend it to others. > - there is a definition for an ipa-v1 schema but no implementation yet, > it will require 2 other ways to handle initgr depending on whether the > ASQ control is available or not. > > > I think the code is good enough to be pushed and will help align the > team (esp. Sumit waiting on some of this stuff) so although not perfect > it here for review. > > Simo. ACK with the following patch applied. Talloc might be smart enough to make the talloc_zfree not needed, but I think it looks clearer this way. Great work, btw. bye, Sumit -------------- next part -------------- >From 7e2ecfb8b6632ae90537e02c897cbd7278323794 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Thu, 9 Jul 2009 12:33:51 +0200 Subject: [PATCH] fixed typos and a potential memory leak --- server/db/sysdb_ops.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/server/db/sysdb_ops.c b/server/db/sysdb_ops.c index efcc5d1..ad4a63e 100644 --- a/server/db/sysdb_ops.c +++ b/server/db/sysdb_ops.c @@ -3098,7 +3098,7 @@ struct tevent_req *sysdb_cache_password_send(TALLOC_CTX *mem_ctx, char *salt; int ret; - req = tevent_req_create(mem_ctx, &state, struct sysdb_op_state); + req = tevent_req_create(mem_ctx, &state, struct sysdb_cache_pw_state); if (!req) return NULL; state->ev = ev; @@ -3170,7 +3170,8 @@ static void sysdb_cache_password_trans(struct tevent_req *subreq) struct sysdb_cache_pw_state); int ret; - ret = sysdb_transaction_recv(req, state, &state->handle); + ret = sysdb_transaction_recv(subreq, state, &state->handle); + talloc_zfree(subreq); if (ret) { tevent_req_error(req, ret); return; -- 1.6.2.5 From ssorce at redhat.com Thu Jul 9 13:03:32 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 09 Jul 2009 09:03:32 -0400 Subject: [Freeipa-devel] [PATCHES(6)] SSSD: Native ldap driver In-Reply-To: <20090709103817.GI13363@localhost.localdomain> References: <1247096504.6317.176.camel@localhost.localdomain> <20090709103817.GI13363@localhost.localdomain> Message-ID: <1247144612.6317.182.camel@localhost.localdomain> On Thu, 2009-07-09 at 12:38 +0200, Sumit Bose wrote: > On Wed, Jul 08, 2009 at 07:41:44PM -0400, Simo Sorce wrote: > > This set of patches implement a native ldap driver backend. > > > > It is the first basic core of a working driver. It still have a few > > TODOs and FIXMEs in it, and there are still features that need to be > > implemented. > > > > But it is stable enough and big enough to be useful. > > I've done basic testing through development, and most stuff should work. > > > > Patches: > > 0001 - add some cleanup code to remove .X files > > 0002 - expose some useful sysdb functions previously declared static > > 0003 - add a set of async helpers for the ldap driver > > 0004 - convert ldap auth to use the async helpers > > 0005 - unify password caching between proxy and ldap > > 0006 - implement the identity part of the ldap driver > > > > notes: > > - Sumit you may want to look at 0005 and then unify the krb password > > caching. > > - during the implementation of the initgr call I noticed that it would > > be useful if some of the search function in sysdb could autostart an > > operation, I implemented this for some functions, might make sense to > > extend it to others. > > - there is a definition for an ipa-v1 schema but no implementation yet, > > it will require 2 other ways to handle initgr depending on whether the > > ASQ control is available or not. > > > > > > I think the code is good enough to be pushed and will help align the > > team (esp. Sumit waiting on some of this stuff) so although not perfect > > it here for review. > > > > Simo. > > ACK with the following patch applied. Talloc might be smart enough to > make the talloc_zfree not needed, but I think it looks clearer this way. Yes, talloc is indeed smart enough, the reson why we call talloc_zfree() in these case is 2 fold: 1) avoid piling up memory. All emmory will be freed when the breq will be freed anyway, cause it is all hanging on from there, but it doesn't make sense to carry around potentially high quantities of memory we do not need anymore. 2) catch with a nice segfault invalid use of subreq in the following code, as subreq is not to be used except to get results. So the patch is very welcome, thanks! > Great work, btw. Thank you, pushing the code now! Simo. -- Simo Sorce * Red Hat, Inc * New York From pzuna at redhat.com Thu Jul 9 17:10:20 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 09 Jul 2009 19:10:20 +0200 Subject: [Freeipa-devel] [PATCH] Change command names from *group-del-member to *group-remove-member. Message-ID: <4A56247C.7060300@redhat.com> This patch changes names of commands used to remove members from groups to match the pattern used by old plugins. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Change-command-names-from-group-del-member-to-grou.patch Type: application/mbox Size: 5703 bytes Desc: not available URL: From sbose at redhat.com Thu Jul 9 17:21:35 2009 From: sbose at redhat.com (Sumit Bose) Date: Thu, 9 Jul 2009 19:21:35 +0200 Subject: [Freeipa-devel] [PATCH] add a short explanation about the used debug levels Message-ID: <20090709172135.GB29325@localhost.localdomain> Hi, this patch adds a short description of the debuglevels used by sssd. I have used a doxygen style comment to make it easy to have some nice api-doc some time in the future. bye, Sumit -------------- next part -------------- >From d40c42e44c1774553a04b80538eeb485899479f0 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Thu, 9 Jul 2009 19:17:45 +0200 Subject: [PATCH] add a short explanation about the used debug levels --- server/util/util.h | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/server/util/util.h b/server/util/util.h index 77bafce..fac3ea5 100644 --- a/server/util/util.h +++ b/server/util/util.h @@ -21,6 +21,20 @@ void debug_fn(const char *format, ...); {"debug-level", 'd', POPT_ARG_INT, &debug_level, 0, \ "Debug level", NULL}, +/** \def DEBUG(level, body) + \brief macro to generate debug messages + + \param level the debug level, please respect the following guidelines: + - 1 is for critical errors users may find it difficult to understand but + are still quite clear + - 2-4 is for stuff developers are interested in in general, but + shouldn't fill the screen with useless low level verbose stuff + - 5-6 is for errors you may want to track, but only if you explicitly + looking for additional clues + - 7-10 is for informational stuff + + \param body the debug message you want to send, should end with \n +*/ #define DEBUG(level, body) do { \ if (level <= debug_level) { \ debug_fn("[%s] [%s] (%d): ", \ -- 1.6.2.5 From ssorce at redhat.com Thu Jul 9 18:16:50 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 09 Jul 2009 14:16:50 -0400 Subject: [Freeipa-devel] [PATCH] Add LDAP class variable for SSL In-Reply-To: <4A540BCE.9060702@redhat.com> References: <4A540BCE.9060702@redhat.com> Message-ID: <1247163410.6317.191.camel@localhost.localdomain> On Tue, 2009-07-07 at 23:00 -0400, Rob Crittenden wrote: > Older versions of python-ldap will assert if you call ldap.get_option() > on an option that hasn't been set yet. This was causing the server to > crash on Fedora 9 and older with any request. > > I added a _ssl boolean class variable which gets set to True if either a > CA is set or a cert is provided for authentication. > > I've already pushed this out to master because it was causing the server > to not work at all. ack -- Simo Sorce * Red Hat, Inc * New York From jderose at redhat.com Thu Jul 9 19:26:01 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Thu, 09 Jul 2009 13:26:01 -0600 Subject: [Freeipa-devel] [PATCH] Change command names from *group-del-member to *group-remove-member. In-Reply-To: <4A56247C.7060300@redhat.com> References: <4A56247C.7060300@redhat.com> Message-ID: <1247167561.13833.0.camel@jgd-flap> On Thu, 2009-07-09 at 19:10 +0200, Pavel Zuna wrote: > This patch changes names of commands used to remove members from groups to match > the pattern used by old plugins. > > Pavel ack, pushed to master. From dpal at redhat.com Thu Jul 9 22:34:58 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 09 Jul 2009 18:34:58 -0400 Subject: [Freeipa-devel] [PATCH] COLLECTION Adding flat traversal & copy Message-ID: <4A567092.9050908@redhat.com> COLLECTION Adding flat traversal & copy The collection is hierarchical. The flattening of the collection was not implemented before both for traversal and copying. This patch introduces functionality to traverse or iterate through collection as flat set and also copy collection into another flattening it and automatically resolving conflicts. Also improved traceability and fixed memory leak in unbind iterator code. Sorry it grew a bit due to me adding extensive unit tests for different cases (and fixing things as I uncovered them). 1) Checked for tabs 2) Ran UT in valgrind 3) Checked for warnings in special build using Simo's scripts -- 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-COLLECTION-Adding-flat-traversal-copy.patch Type: text/x-patch Size: 46962 bytes Desc: not available URL: From jderose at redhat.com Thu Jul 9 23:49:56 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Thu, 09 Jul 2009 17:49:56 -0600 Subject: [Freeipa-devel] Web SSO and securely storing the ccache Message-ID: <1247183396.13833.142.camel@jgd-flap> This is my proposal for how to implement the web-SSO that has been discussed a few times. Some background --------------- We want a single URL (say /login) to be protected with modauthkerb. When a user successfully authenticates at the /login page, they're given a session cookie and their credential cache is kept in session storage on the server. When a user visits a URL other than /login, we check to see if they have a valid session cookie: if they don't, they get redirected to /login; if they do, their ccache is retrieved and we use it to authenticate to LDAP on the user's behalf. This will improve the performance quite a bit as the modauthkerb negotiation is pretty slow. We can also use this to provide SSO authentication to other webapps on the same server (although we shouldn't retrieve the ccache and make it available to just any webapp, only to ones that actually need it). IPA uses the user's forwarded TGT to authenticate to LDAP, so minimizing exposure of the ccache is very important (otherwise if Apache is compromised, it could potentially authenticate to arbitrary services on behalf of the signed-in users). Proposal for securely storing the ccache ---------------------------------------- Once we start storing the ccache in the session, it becomes much more difficult to minimize exposure of the ccache, but I believe I have a workable solution: When the user authenticates at /login, we create a random 256-bit session_key, which we send to the client as a cookie. We then store the ccache in a two column session table, like this: primary_key encrypted_ccache =================== =========================== sha256(session_key) aes256(session_key, ccache) The session_key is needed to decrypt the encrypted_ccache, and only the client (browser) has the session_key, which it sends along with each request (as a cookie in the request header). When a request is received, the server creates the primary_key by doing a sha256 hash of the session_key, with which it retrieves the correct encrypted_ccache from the session table. Then the encrypted_ccache is decrypted using the session_key. Lastly, the clear-text ccache is written to a temporary file (like in a tmpfs or in /dev/shm) just long enough to do the LDAP bind, after which the clear-text ccache is deleted. We need to write the ccache to a file so we can bind to LDAP. We currently bind doing something like this (in Python): conn = ldap.initialize(...) os.environ['KRB5CCNAME'] = ccache conn.sasl_interactive_bind_s('', _sasl_auth) Us Red Hatters haven't found another way to do this, but if anyone else has a better idea, we'd love to hear it (we'd love to avoid the KRB5CCNAME environment variable hack). Anyway, I believe this is a reasonable way to protect the stored ccache's from Apache while still allowing Apache to access (briefly) the ccache of the user whose request it's currently processing. Questions? Comments? Flame easy, I'm almost on vacation! ;) Cheers, Jason From jdennis at redhat.com Fri Jul 10 00:32:51 2009 From: jdennis at redhat.com (John Dennis) Date: Thu, 09 Jul 2009 20:32:51 -0400 Subject: [Freeipa-devel] Web SSO and securely storing the ccache In-Reply-To: <1247183396.13833.142.camel@jgd-flap> References: <1247183396.13833.142.camel@jgd-flap> Message-ID: <4A568C33.5080809@redhat.com> I think the dirsec folks should review this too, perhaps you might want to cc them as well. What purpose is the sha56 hash of the session key serving? It appears to be only used for look-up purposes, if that's the case why not just lookup based on the session key? You didn't state if this scheme would be restricted to only SSL/TLS sessions, if not then ... The session key is visible in the HTML headers, correct? Doesn't that mean all one would need to do is sniff the session key to masquerade as a legitimate user and automatically be authenticated as them? (Because you'll look up the cached credentials under that session key and present them without validating there is an uncompromised association between the original user, the TGT, the ccache, and the currently presented session cookie). In which case the scheme is essentially equivalent to using clear text passwords with the exception the credentials will eventually expire. Otherwise if the session is SSL/TLS encrypted then the primary exposure is reduced to brute force attacks on the session key which is probably a minimal risk given it's a 256 bit key which is valid only during the window the TGT is valid. You will have to be careful that there is no collision or reuse of the session key within a specified time interval (greater than the ticket duration). -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jderose at redhat.com Fri Jul 10 01:23:21 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Fri, 10 Jul 2009 01:23:21 +0000 Subject: [Freeipa-devel] Web SSO and securely storing the ccache In-Reply-To: <4A568C33.5080809@redhat.com> References: <1247183396.13833.142.camel@jgd-flap> <4A568C33.5080809@redhat.com> Message-ID: <1247189001.13833.185.camel@jgd-flap> On Thu, 2009-07-09 at 20:32 -0400, John Dennis wrote: > I think the dirsec folks should review this too, perhaps you might want > to cc them as well. > > What purpose is the sha56 hash of the session key serving? It appears to > be only used for look-up purposes, if that's the case why not just > lookup based on the session key? The session_key is what's used to encrypt the ccache, so we don't want to store it on the server at all (certainly not in the same table as the ccache). Doing a one-way-hash of the session_key is a simple way to preserve the association with the session_key without storing the session_key in the session table. > You didn't state if this scheme would be restricted to only SSL/TLS > sessions, if not then ... The IPA web UI and XML-RPC are only accessibly via SSL (right, Rob?). Obviously the scheme I presented can't be used over clear HTTP. > The session key is visible in the HTML headers, correct? Doesn't that > mean all one would need to do is sniff the session key to masquerade as > a legitimate user and automatically be authenticated as them? (Because > you'll look up the cached credentials under that session key and present > them without validating there is an uncompromised association between > the original user, the TGT, the ccache, and the currently presented > session cookie). In which case the scheme is essentially equivalent to > using clear text passwords with the exception the credentials will > eventually expire. Again, if the HTTP traffic is in the clear, this scheme wont work. We can also keep the session lifetime fairly short (say 15 minutes). Unless I'm missing something, if our goal is to avoid doing the modauthkerb negotiation at each request, we will have to use some kind of cookie-based scheme (or add session information to URLs dynamically, but that doesn't offer any security advantage over cookies). Simo, am I on track here? Details aside, your idea was some kind of cookie-based session after the user hits /login, correct? > Otherwise if the session is SSL/TLS encrypted then the primary exposure > is reduced to brute force attacks on the session key which is probably a > minimal risk given it's a 256 bit key which is valid only during the > window the TGT is valid. You will have to be careful that there is no > collision or reuse of the session key within a specified time interval > (greater than the ticket duration). Well, with a 256-bit random key (from /dev/urandom) I think we can just assume there wont be collisions in our lifetimes. ;) From sbose at redhat.com Fri Jul 10 09:37:26 2009 From: sbose at redhat.com (Sumit Bose) Date: Fri, 10 Jul 2009 11:37:26 +0200 Subject: [Freeipa-devel] [PATCH] fixed the default value for tls_reqcert Message-ID: <20090710093726.GE29325@localhost.localdomain> Hi, this patch sets the default value of tls_reqcert to a value that is allowed :). bye, Sumit -------------- next part -------------- >From 36a9f4707d800af6dc8dddbe9722556c97637a1e Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Fri, 10 Jul 2009 11:34:49 +0200 Subject: [PATCH] fixed the default value for tls_reqcert --- server/providers/ldap/sdap.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/server/providers/ldap/sdap.c b/server/providers/ldap/sdap.c index ddba0ba..9c957ff 100644 --- a/server/providers/ldap/sdap.c +++ b/server/providers/ldap/sdap.c @@ -32,7 +32,7 @@ struct sdap_gen_opts default_basic_opts[] = { { "defaultAuthtok", NULL, NULL }, { "network_timeout", "5", NULL }, { "opt_timeout", "5", NULL }, - { "tls_reqcert", "always", NULL }, + { "tls_reqcert", "hard", NULL }, { "userSearchBase", "dc=example,dc=com", NULL }, { "userSearchScope", "sub", NULL }, { "userSearchFilter", NULL, NULL }, -- 1.6.2.5 From pzuna at redhat.com Fri Jul 10 10:26:44 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 10 Jul 2009 12:26:44 +0200 Subject: [Freeipa-devel] [PATCH] Make object classes of automatically created entries lowercase. Message-ID: <4A571764.30502@redhat.com> This makes entries created upon installation more consistent with entries created by plugins. It's a cosmetic thing, not that useful. Well, it might makes things a little easier for scripts/tests that want to parse command output... Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-object-classes-of-automatically-created-entries.patch Type: application/mbox Size: 2998 bytes Desc: not available URL: From sbose at redhat.com Fri Jul 10 10:31:16 2009 From: sbose at redhat.com (Sumit Bose) Date: Fri, 10 Jul 2009 12:31:16 +0200 Subject: [Freeipa-devel] [PATCH] COLLECTION Adding flat traversal & copy In-Reply-To: <4A567092.9050908@redhat.com> References: <4A567092.9050908@redhat.com> Message-ID: <20090710103116.GF29325@localhost.localdomain> On Thu, Jul 09, 2009 at 06:34:58PM -0400, Dmitri Pal wrote: > COLLECTION Adding flat traversal & copy > > The collection is hierarchical. The flattening > of the collection was not implemented before > both for traversal and copying. This patch > introduces functionality to traverse or > iterate through collection as flat set > and also copy collection into another flattening > it and automatically resolving conflicts. > Also improved traceability and fixed memory leak > in unbind iterator code. > > Sorry it grew a bit due to me adding extensive unit tests for different > cases (and fixing things as I uncovered them). > 1) Checked for tabs > 2) Ran UT in valgrind > 3) Checked for warnings in special build using Simo's scripts > > Hi Dmitri, the patch applies and compiles well. There are a couple of '--' on unsigned values in this patch. I have not checked if this is always save. Maybe it makes sense to add some decrement macro which checks for 0 before doing -- ? While tracking some signed/unsigned comparisons (-Wextra will show them) I have found an issue in col_insert_item_into_current. If collection == NULL and collection->type != COL_TYPE_COLLECTION, collection will be NULL the first time it is accessed. The attached patch will solve this. Concerning signed/unsigned comparisons. What do you think about setting the idx/index arguements of: - col_insert_item_into_current - col_extract_item_from_current - col_extract_item - col_insert_item and the level of col_iterate_up to unsigned to make it clear the unsigned values are expected? bye, Sumit -------------- next part -------------- >From 7d39704baab85118c16ebad22641a38e086440e9 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Fri, 10 Jul 2009 12:14:32 +0200 Subject: [PATCH] fix for a potential segfault --- common/collection/collection.c | 27 ++++++++++++--------------- 1 files changed, 12 insertions(+), 15 deletions(-) diff --git a/common/collection/collection.c b/common/collection/collection.c index b4a2c8d..a2ba328 100644 --- a/common/collection/collection.c +++ b/common/collection/collection.c @@ -346,24 +346,21 @@ int col_insert_item_into_current(struct collection_item *collection, return EINVAL; } + /* We can add items only to collections */ + if (collection->type != COL_TYPE_COLLECTION) { + TRACE_ERROR_STRING("Attempt to add item to non collection.",""); + TRACE_ERROR_STRING("Collection name:", collection->property); + TRACE_ERROR_NUMBER("Collection type:", collection->type); + return EINVAL; + } + if (collection == NULL) { TRACE_INFO_STRING("col_insert_item_into_current", "Collection accepting is NULL"); - if (item->type == COL_TYPE_COLLECTION) { - /* This is a special case of self creation */ - TRACE_INFO_STRING("col_insert_item_into_current", - "Adding header item to new collection."); - collection = item; - } - } - else { - /* We can add items only to collections */ - if (collection->type != COL_TYPE_COLLECTION) { - TRACE_ERROR_STRING("Attempt to add item to non collection.",""); - TRACE_ERROR_STRING("Collection name:", collection->property); - TRACE_ERROR_NUMBER("Collection type:", collection->type); - return EINVAL; - } + /* This is a special case of self creation */ + TRACE_INFO_STRING("col_insert_item_into_current", + "Adding header item to new collection."); + collection = item; } /* After processing flags we can process disposition */ -- 1.6.2.5 From sbose at redhat.com Fri Jul 10 11:25:01 2009 From: sbose at redhat.com (Sumit Bose) Date: Fri, 10 Jul 2009 13:25:01 +0200 Subject: [Freeipa-devel] [PATCH] let krb5 backend safe valid credentials for offline authentication Message-ID: <20090710112501.GG29325@localhost.localdomain> Hi, with this patch the kerberos backend can safe valid credential to enable offline authentication. bye, Sumit -------------- next part -------------- >From d240a9d7b8b3fe3ec627e8276f269e126e2e3e56 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Fri, 10 Jul 2009 09:18:06 +0200 Subject: [PATCH] let krb5 backend safe valid credentials for offline authentication --- server/providers/krb5/krb5_auth.c | 43 +++++++++++++++++++++++++++++++++++++ 1 files changed, 43 insertions(+), 0 deletions(-) diff --git a/server/providers/krb5/krb5_auth.c b/server/providers/krb5/krb5_auth.c index 0420955..2cbdc99 100644 --- a/server/providers/krb5/krb5_auth.c +++ b/server/providers/krb5/krb5_auth.c @@ -392,6 +392,7 @@ static ssize_t tgt_req_recv(struct tevent_req *req, TALLOC_CTX *mem_ctx, } static void krb5_pam_handler_done(struct tevent_req *req); +static void krb5_pam_handler_cache_done(struct tevent_req *treq); static void krb5_pam_handler(struct be_req *be_req) { @@ -446,6 +447,8 @@ static void krb5_pam_handler_done(struct tevent_req *req) int32_t *msg_status; int32_t *msg_type; int32_t *msg_len; + struct tevent_req *subreq = NULL; + char *password = NULL; pd->pam_status = PAM_SYSTEM_ERR; krb5_cleanup(kr); @@ -488,10 +491,50 @@ static void krb5_pam_handler_done(struct tevent_req *req) pd->pam_status = *msg_status; + if (pd->pam_status == PAM_SUCCESS && + be_req->be_ctx->domain->cache_credentials == TRUE) { + password = talloc_size(be_req, pd->authtok_size + 1); + if (password == NULL) { + DEBUG(0, ("talloc_size failed, offline auth may not work.\n")); + goto done; + } + memcpy(password, pd->authtok, pd->authtok_size); + password[pd->authtok_size] = '\0'; + talloc_set_destructor((TALLOC_CTX *)password, password_destructor); + + subreq = sysdb_cache_password_send(be_req, be_req->be_ctx->ev, + be_req->be_ctx->sysdb, NULL, + be_req->be_ctx->domain, pd->user, + password); + if (subreq == NULL) { + DEBUG(2, ("cache_password_send failed, offline auth may not work.\n")); + goto done; + } + tevent_req_set_callback(subreq, krb5_pam_handler_cache_done, be_req); + + return; + } done: be_req->fn(be_req, pd->pam_status, NULL); } +static void krb5_pam_handler_cache_done(struct tevent_req *subreq) +{ + struct be_req *be_req = tevent_req_callback_data(subreq, struct be_req); + int ret; + + /* password caching failures are not fatal errors */ + ret = sysdb_cache_password_recv(subreq); + talloc_zfree(subreq); + + /* so we just log it any return */ + if (ret) { + DEBUG(2, ("Failed to cache password (%d)[%s]!?\n", + ret, strerror(ret))); + } + + be_req->fn(be_req, PAM_SUCCESS, NULL); +} struct be_auth_ops krb5_auth_ops = { .pam_handler = krb5_pam_handler, -- 1.6.2.5 From rcritten at redhat.com Fri Jul 10 12:59:09 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 Jul 2009 08:59:09 -0400 Subject: [Freeipa-devel] [PATCH] Make object classes of automatically created entries lowercase. In-Reply-To: <4A571764.30502@redhat.com> References: <4A571764.30502@redhat.com> Message-ID: <4A573B1D.20106@redhat.com> Pavel Zuna wrote: > This makes entries created upon installation more consistent with > entries created by plugins. It's a cosmetic thing, not that useful. > Well, it might makes things a little easier for scripts/tests that want > to parse command output... > > Pavel > I'm ok with this but want to point out that it won't affect existing entries at all. 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 ssorce at redhat.com Fri Jul 10 13:01:13 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 10 Jul 2009 09:01:13 -0400 Subject: [Freeipa-devel] Web SSO and securely storing the ccache In-Reply-To: <1247189001.13833.185.camel@jgd-flap> References: <1247183396.13833.142.camel@jgd-flap> <4A568C33.5080809@redhat.com> <1247189001.13833.185.camel@jgd-flap> Message-ID: <1247230873.6317.205.camel@localhost.localdomain> On Fri, 2009-07-10 at 01:23 +0000, Jason Gerard DeRose wrote: > > Simo, am I on track here? Details aside, your idea was some kind of > cookie-based session after the user hits /login, correct? Yes, and what you propose makes sense to me. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Jul 10 13:09:38 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 Jul 2009 09:09:38 -0400 Subject: [Freeipa-devel] Web SSO and securely storing the ccache In-Reply-To: <1247183396.13833.142.camel@jgd-flap> References: <1247183396.13833.142.camel@jgd-flap> Message-ID: <4A573D92.9040102@redhat.com> Jason Gerard DeRose wrote: > This is my proposal for how to implement the web-SSO that has been > discussed a few times. > > > Some background > --------------- > > We want a single URL (say /login) to be protected with modauthkerb. > When a user successfully authenticates at the /login page, they're given > a session cookie and their credential cache is kept in session storage > on the server. When a user visits a URL other than /login, we check to > see if they have a valid session cookie: if they don't, they get > redirected to /login; if they do, their ccache is retrieved and we use > it to authenticate to LDAP on the user's behalf. This will improve the > performance quite a bit as the modauthkerb negotiation is pretty slow. > We can also use this to provide SSO authentication to other webapps on > the same server (although we shouldn't retrieve the ccache and make it > available to just any webapp, only to ones that actually need it). > > IPA uses the user's forwarded TGT to authenticate to LDAP, so minimizing > exposure of the ccache is very important (otherwise if Apache is > compromised, it could potentially authenticate to arbitrary services on > behalf of the signed-in users). > > > Proposal for securely storing the ccache > ---------------------------------------- > > Once we start storing the ccache in the session, it becomes much more > difficult to minimize exposure of the ccache, but I believe I have a > workable solution: > > When the user authenticates at /login, we create a random 256-bit > session_key, which we send to the client as a cookie. We then store the > ccache in a two column session table, like this: > > primary_key encrypted_ccache > =================== =========================== > sha256(session_key) aes256(session_key, ccache) > > The session_key is needed to decrypt the encrypted_ccache, and only the > client (browser) has the session_key, which it sends along with each > request (as a cookie in the request header). When a request is > received, the server creates the primary_key by doing a sha256 hash of > the session_key, with which it retrieves the correct encrypted_ccache > from the session table. Then the encrypted_ccache is decrypted using > the session_key. Lastly, the clear-text ccache is written to a > temporary file (like in a tmpfs or in /dev/shm) just long enough to do > the LDAP bind, after which the clear-text ccache is deleted. > > We need to write the ccache to a file so we can bind to LDAP. We > currently bind doing something like this (in Python): > > conn = ldap.initialize(...) > os.environ['KRB5CCNAME'] = ccache > conn.sasl_interactive_bind_s('', _sasl_auth) > > Us Red Hatters haven't found another way to do this, but if anyone else > has a better idea, we'd love to hear it (we'd love to avoid the > KRB5CCNAME environment variable hack). > > Anyway, I believe this is a reasonable way to protect the stored > ccache's from Apache while still allowing Apache to access (briefly) the > ccache of the user whose request it's currently processing. > > > Questions? Comments? Flame easy, I'm almost on vacation! ;) > > Cheers, > Jason > How do we want to handle an expired TGT? If my ticket expires in 5 minutes I can still log into the UI. I go grab a cup of coffee and a danish and come back 10 minutes later and start to work again. The first LDAP operation will fail because the ticket is expired. Should we alert the user and redirect them, redirect to /login and see if we can somehow automatically re-try the operation or some other option? Or should the entry point where we test the existence of the ccache look inside somehow to verify that the ticket is still valid within some threshold? I'm assuming that python-krbV will let us do that. 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 Jul 10 13:40:23 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 Jul 2009 09:40:23 -0400 Subject: [Freeipa-devel] [PATCH] configure bind+ldap driver In-Reply-To: <1246308134.13348.9.camel@localhost.localdomain> References: <1245849700.5479.23.camel@localhost.localdomain> <4A4905F4.50502@redhat.com> <1246308134.13348.9.camel@localhost.localdomain> Message-ID: <4A5744C7.50606@redhat.com> Simo Sorce wrote: > 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. > Ok, ack. 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 Jul 10 13:43:11 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 10 Jul 2009 09:43:11 -0400 Subject: [Freeipa-devel] [PATCH] configure bind+ldap driver In-Reply-To: <4A5744C7.50606@redhat.com> References: <1245849700.5479.23.camel@localhost.localdomain> <4A4905F4.50502@redhat.com> <1246308134.13348.9.camel@localhost.localdomain> <4A5744C7.50606@redhat.com> Message-ID: <1247233391.6317.206.camel@localhost.localdomain> On Fri, 2009-07-10 at 09:40 -0400, Rob Crittenden wrote: > > Ok, ack. pushed -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Jul 10 13:47:20 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 10 Jul 2009 09:47:20 -0400 Subject: [Freeipa-devel] Web SSO and securely storing the ccache In-Reply-To: <4A573D92.9040102@redhat.com> References: <1247183396.13833.142.camel@jgd-flap> <4A573D92.9040102@redhat.com> Message-ID: <1247233640.6317.210.camel@localhost.localdomain> On Fri, 2009-07-10 at 09:09 -0400, Rob Crittenden wrote: > > How do we want to handle an expired TGT? Uhmm very good point. > If my ticket expires in 5 minutes I can still log into the UI. I go > grab > a cup of coffee and a danish and come back 10 minutes later and start > to > work again. > > The first LDAP operation will fail because the ticket is expired. > Should > we alert the user and redirect them, redirect to /login and see if we > can somehow automatically re-try the operation or some other option? Yes I think we should redirect them to the /login page. This page in turn will do one the following 2: a) warn the user that his kerberos ticket is expired. We may go as far as giving advice on how to renew the ticket, although it would be nice if this page could be customizable so that admins can point users at their internal guides/resources/helpdesk/whatever b) warn the user but also ask username/password (if configured to allow aksing for user/pass, not the default). > Or should the entry point where we test the existence of the ccache > look > inside somehow to verify that the ticket is still valid within some > threshold? I'm assuming that python-krbV will let us do that. I think we can do both if it is not too much trouble, but the former is certainly more important IMO. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Jul 10 13:52:29 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 10 Jul 2009 09:52:29 -0400 Subject: [Freeipa-devel] [PATCH] add a short explanation about the used debug levels In-Reply-To: <20090709172135.GB29325@localhost.localdomain> References: <20090709172135.GB29325@localhost.localdomain> Message-ID: <1247233949.6317.211.camel@localhost.localdomain> On Thu, 2009-07-09 at 19:21 +0200, Sumit Bose wrote: > this patch adds a short description of the debuglevels used by sssd. I > have used a doxygen style comment to make it easy to have some nice > api-doc some time in the future. ack and pushed Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Jul 10 13:52:46 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 10 Jul 2009 09:52:46 -0400 Subject: [Freeipa-devel] [PATCH] fixed the default value for tls_reqcert In-Reply-To: <20090710093726.GE29325@localhost.localdomain> References: <20090710093726.GE29325@localhost.localdomain> Message-ID: <1247233966.6317.212.camel@localhost.localdomain> On Fri, 2009-07-10 at 11:37 +0200, Sumit Bose wrote: > this patch sets the default value of tls_reqcert to a value that is > allowed :). Ack and pushed Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Jul 10 13:53:14 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 10 Jul 2009 09:53:14 -0400 Subject: [Freeipa-devel] [PATCH] let krb5 backend safe valid credentials for offline authentication In-Reply-To: <20090710112501.GG29325@localhost.localdomain> References: <20090710112501.GG29325@localhost.localdomain> Message-ID: <1247233994.6317.213.camel@localhost.localdomain> On Fri, 2009-07-10 at 13:25 +0200, Sumit Bose wrote: > > with this patch the kerberos backend can safe valid credential to > enable > offline authentication. ack and pushed Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Jul 10 13:56:06 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 10 Jul 2009 09:56:06 -0400 Subject: [Freeipa-devel] [PATCH] Configure BIND LDAP driver to use SASL authentication In-Reply-To: <20090625085436.36b6b1e2@notas> References: <20090625085436.36b6b1e2@notas> Message-ID: <1247234166.6317.214.camel@localhost.localdomain> On Thu, 2009-06-25 at 08:54 +0200, Martin Nagy wrote: > This patch needs changes introduced by Simo's "configure bind+ldap > driver" to use the generated keytab. Ack and pushed Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Jul 10 13:59:30 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 10 Jul 2009 09:59:30 -0400 Subject: [Freeipa-devel] [PATCH] 229 set shell return value In-Reply-To: <4A368E73.3080104@redhat.com> References: <4A368E73.3080104@redhat.com> Message-ID: <1247234370.6317.215.camel@localhost.localdomain> On Mon, 2009-06-15 at 14:09 -0400, Rob Crittenden wrote: > 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". Ack. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Jul 10 14:05:12 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 10 Jul 2009 10:05:12 -0400 Subject: [Freeipa-devel] [PATCH] require password only once from a pipe In-Reply-To: <4A1C56B7.9080305@redhat.com> References: <4A1C56B7.9080305@redhat.com> Message-ID: <1247234712.6317.216.camel@localhost.localdomain> On Tue, 2009-05-26 at 16:53 -0400, Rob Crittenden wrote: > When reading the password in from a pipe require that it be provided > only once. > > This will let people do: > > % echo "secret123" | ipa user-add --first=Joe --last=Robinson jrobinson > > or > > % echo "secret123" | ipa passwd jrobinson ack -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Jul 10 14:06:51 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 10 Jul 2009 10:06:51 -0400 Subject: [Freeipa-devel] [PATCH] 227 virtual operations In-Reply-To: <4A2422BC.7080601@redhat.com> References: <4A2422BC.7080601@redhat.com> Message-ID: <1247234811.6317.217.camel@localhost.localdomain> On Mon, 2009-06-01 at 14:49 -0400, Rob Crittenden wrote: > 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. ack -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Jul 10 14:08:13 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 10 Jul 2009 10:08:13 -0400 Subject: [Freeipa-devel] [PATCH] 231 Add one-character option to cli In-Reply-To: <4A3008BE.7050204@redhat.com> References: <4A3008BE.7050204@redhat.com> Message-ID: <1247234893.6317.218.camel@localhost.localdomain> On Wed, 2009-06-10 at 15:25 -0400, Rob Crittenden wrote: > 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. ack -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Jul 10 14:10:32 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 10 Jul 2009 10:10:32 -0400 Subject: [Freeipa-devel] [PATCH] 228 add function to prompt for entry after multiple results in -find In-Reply-To: <4A2E9F9D.2020108@redhat.com> References: <4A2D859A.1040600@redhat.com> <1244565555.6533.11.camel@jgd-dsk> <4A2E9A5F.4050709@redhat.com> <4A2E9F9D.2020108@redhat.com> Message-ID: <1247235032.6317.219.camel@localhost.localdomain> On Tue, 2009-06-09 at 13:45 -0400, Rob Crittenden wrote: > 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. ack -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Jul 10 14:32:59 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 10 Jul 2009 10:32:59 -0400 Subject: [Freeipa-devel] [PATCH] COLLECTION Adding flat traversal & copy In-Reply-To: <20090710103116.GF29325@localhost.localdomain> References: <4A567092.9050908@redhat.com> <20090710103116.GF29325@localhost.localdomain> Message-ID: <4A57511B.1090204@redhat.com> Sumit Bose wrote: > On Thu, Jul 09, 2009 at 06:34:58PM -0400, Dmitri Pal wrote: > >> COLLECTION Adding flat traversal & copy >> >> The collection is hierarchical. The flattening >> of the collection was not implemented before >> both for traversal and copying. This patch >> introduces functionality to traverse or >> iterate through collection as flat set >> and also copy collection into another flattening >> it and automatically resolving conflicts. >> Also improved traceability and fixed memory leak >> in unbind iterator code. >> >> Sorry it grew a bit due to me adding extensive unit tests for different >> cases (and fixing things as I uncovered them). >> 1) Checked for tabs >> 2) Ran UT in valgrind >> 3) Checked for warnings in special build using Simo's scripts >> >> >> > Hi Dmitri, > > the patch applies and compiles well. > > There are a couple of '--' on unsigned values in this patch. I have not > checked if this is always save. Maybe it makes sense to add some > decrement macro which checks for 0 before doing -- ? > These unsigned values are the size of the internal stack or depth level. They need to always be positive this is why they are unsigned. I do not want obfuscate the error by preventing them to go below 0. If it goes the program will crash and we will see the problem. If we add the check we most likely hide the problem if there is a coding error. > While tracking some signed/unsigned comparisons (-Wextra will show them) > I have found an issue in col_insert_item_into_current. If > collection == NULL and collection->type != COL_TYPE_COLLECTION, > collection will be NULL the first time it is accessed. The attached > patch will solve this. > > I see the issue, thanks for pointing it to me but I do not like the patch. Your patch will crash if collection is NULL in the first place since it will check collection->type before checking the collection itself. This issue however is not related to the patch I sent. Should I fix it in this patch or include in the next one? I would prefer next one since I have other things to do in collection today. > Concerning signed/unsigned comparisons. What do you think about setting > the idx/index arguements of: > - col_insert_item_into_current > - col_extract_item_from_current > - col_extract_item > - col_insert_item > > In future the index might be negative to indicate special value so I would prefer leaving it as int. > and the level of col_iterate_up to unsigned to make it clear the > unsigned values are expected? > I see the problem. This function needs to be fixed. Again, should it be done in this patch or a separate one? > bye, > Sumit > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From nkinder at redhat.com Fri Jul 10 15:10:01 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 10 Jul 2009 08:10:01 -0700 Subject: [Freeipa-devel] [PATCH] 230 enable VLV anonymous browsing In-Reply-To: <4A2FBCE9.6080606@redhat.com> References: <4A2FBCE9.6080606@redhat.com> Message-ID: <4A5759C9.1000403@redhat.com> On 06/10/2009 07:02 AM, Rob Crittenden wrote: > Enable anonyomus VLV browsing so that automount on Solaris will work. ack > > 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 dpal at redhat.com Fri Jul 10 15:48:26 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 10 Jul 2009 11:48:26 -0400 Subject: [Freeipa-devel] [PATCH] COLLECTION patches resending In-Reply-To: <4A57511B.1090204@redhat.com> References: <4A567092.9050908@redhat.com> <20090710103116.GF29325@localhost.localdomain> <4A57511B.1090204@redhat.com> Message-ID: <4A5762CA.4060606@redhat.com> Dmitri Pal wrote: > Sumit Bose wrote: > >> On Thu, Jul 09, 2009 at 06:34:58PM -0400, Dmitri Pal wrote: >> >> >>> COLLECTION Adding flat traversal & copy >>> >>> The collection is hierarchical. The flattening >>> of the collection was not implemented before >>> both for traversal and copying. This patch >>> introduces functionality to traverse or >>> iterate through collection as flat set >>> and also copy collection into another flattening >>> it and automatically resolving conflicts. >>> Also improved traceability and fixed memory leak >>> in unbind iterator code. >>> >>> Sorry it grew a bit due to me adding extensive unit tests for different >>> cases (and fixing things as I uncovered them). >>> 1) Checked for tabs >>> 2) Ran UT in valgrind >>> 3) Checked for warnings in special build using Simo's scripts >>> >>> >>> >>> >> Hi Dmitri, >> >> the patch applies and compiles well. >> >> There are a couple of '--' on unsigned values in this patch. I have not >> checked if this is always save. Maybe it makes sense to add some >> decrement macro which checks for 0 before doing -- ? >> >> > These unsigned values are the size of the internal stack or depth level. > They need to always be positive this is why they are unsigned. > I do not want obfuscate the error by preventing them to go below 0. > If it goes the program will crash and we will see the problem. > If we add the check we most likely hide the problem if there is a coding > error. > > >> While tracking some signed/unsigned comparisons (-Wextra will show them) >> I have found an issue in col_insert_item_into_current. If >> collection == NULL and collection->type != COL_TYPE_COLLECTION, >> collection will be NULL the first time it is accessed. The attached >> patch will solve this. >> >> >> > I see the issue, thanks for pointing it to me but I do not like the patch. > Your patch will crash if collection is NULL in the first place since it > will check collection->type before checking the collection itself. > This issue however is not related to the patch I sent. Should I fix it > in this patch or include in the next one? > I would prefer next one since I have other things to do in collection > today. > > > >> Concerning signed/unsigned comparisons. What do you think about setting >> the idx/index arguements of: >> - col_insert_item_into_current >> - col_extract_item_from_current >> - col_extract_item >> - col_insert_item >> >> >> > In future the index might be negative to indicate special value so I > would prefer leaving it as int. > > >> and the level of col_iterate_up to unsigned to make it clear the >> unsigned values are expected? >> >> Original patch COLLECTION Adding flat traversal & copy The collection is hierarchical. The flattening of the collection was not implemented before both for traversal and copying. This patch introduces functionality to traverse or iterate through collection as flat set and also copy collection into another flattening it and automatically resolving conflicts. Also improved traceability and fixed memory leak in unbind iterator code. Correcting patch to address issues mentioned above. COLLECTION Fixed: iterator_up and insert_into_current During a review of the previous patch the two issues were found: a) The col_iterator_up function was not implemented properly so it got reworked. New implementation changes the way error condition is handled. Comments were updated accordingly. b) There was a missing check for validity of the argument in the col_insert_into_current function. Check was added. c) Unit test modified to reflect the change in functionality. -- 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: 0002-COLLECTION-Fixed-iterator_up-and-insert_into_curren.patch Type: text/x-patch Size: 7626 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-COLLECTION-Adding-flat-traversal-copy.patch Type: text/x-patch Size: 46962 bytes Desc: not available URL: From jderose at redhat.com Fri Jul 10 17:24:41 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Fri, 10 Jul 2009 11:24:41 -0600 Subject: [Freeipa-devel] Web SSO and securely storing the ccache In-Reply-To: <1247230873.6317.205.camel@localhost.localdomain> References: <1247183396.13833.142.camel@jgd-flap> <4A568C33.5080809@redhat.com> <1247189001.13833.185.camel@jgd-flap> <1247230873.6317.205.camel@localhost.localdomain> Message-ID: <1247246681.13833.186.camel@jgd-flap> On Fri, 2009-07-10 at 09:01 -0400, Simo Sorce wrote: > On Fri, 2009-07-10 at 01:23 +0000, Jason Gerard DeRose wrote: > > > > Simo, am I on track here? Details aside, your idea was some kind of > > cookie-based session after the user hits /login, correct? > > Yes, and what you propose makes sense to me. Okay, good. I didn't know if I was on the wrong track. ;) > Simo. > From rmeggins at redhat.com Fri Jul 10 17:59:57 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 10 Jul 2009 11:59:57 -0600 Subject: [Freeipa-devel] Web SSO and securely storing the ccache In-Reply-To: <1247183396.13833.142.camel@jgd-flap> References: <1247183396.13833.142.camel@jgd-flap> Message-ID: <4A57819D.3020402@redhat.com> Jason Gerard DeRose wrote: > This is my proposal for how to implement the web-SSO that has been > discussed a few times. > > > Some background > --------------- > > We want a single URL (say /login) to be protected with modauthkerb. > When a user successfully authenticates at the /login page, they're given > a session cookie and their credential cache is kept in session storage > on the server. When a user visits a URL other than /login, we check to > see if they have a valid session cookie: if they don't, they get > redirected to /login; if they do, their ccache is retrieved and we use > it to authenticate to LDAP on the user's behalf. This will improve the > performance quite a bit as the modauthkerb negotiation is pretty slow. > We can also use this to provide SSO authentication to other webapps on > the same server (although we shouldn't retrieve the ccache and make it > available to just any webapp, only to ones that actually need it). > > IPA uses the user's forwarded TGT to authenticate to LDAP, so minimizing > exposure of the ccache is very important (otherwise if Apache is > compromised, it could potentially authenticate to arbitrary services on > behalf of the signed-in users). > > > Proposal for securely storing the ccache > ---------------------------------------- > > Once we start storing the ccache in the session, it becomes much more > difficult to minimize exposure of the ccache, but I believe I have a > workable solution: > > When the user authenticates at /login, we create a random 256-bit > session_key, which we send to the client as a cookie. We then store the > ccache in a two column session table, like this: > > primary_key encrypted_ccache > =================== =========================== > sha256(session_key) aes256(session_key, ccache) > > The session_key is needed to decrypt the encrypted_ccache, and only the > client (browser) has the session_key, which it sends along with each > request (as a cookie in the request header). When a request is > received, the server creates the primary_key by doing a sha256 hash of > the session_key, with which it retrieves the correct encrypted_ccache > from the session table. Then the encrypted_ccache is decrypted using > the session_key. Lastly, the clear-text ccache is written to a > temporary file (like in a tmpfs or in /dev/shm) just long enough to do > the LDAP bind, after which the clear-text ccache is deleted. > > We need to write the ccache to a file so we can bind to LDAP. We > currently bind doing something like this (in Python): > > conn = ldap.initialize(...) > os.environ['KRB5CCNAME'] = ccache > conn.sasl_interactive_bind_s('', _sasl_auth) > > Us Red Hatters haven't found another way to do this, but if anyone else > has a better idea, we'd love to hear it (we'd love to avoid the > KRB5CCNAME environment variable hack). > > Anyway, I believe this is a reasonable way to protect the stored > ccache's from Apache while still allowing Apache to access (briefly) the > ccache of the user whose request it's currently processing. > > > Questions? Comments? Flame easy, I'm almost on vacation! ;) > Have you investigated other Web SSO frameworks? I'd just like to make sure we review the current state of the art, and not reinvent the wheel. I don't know too much about it, but I do know there are things like PubCookie out there http://www.pubcookie.org/ > Cheers, > Jason > > > > > > _______________________________________________ > 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 rcritten at redhat.com Fri Jul 10 20:25:32 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 Jul 2009 16:25:32 -0400 Subject: [Freeipa-devel] [PATCH] 236 Have RPC catch HTTP errors Message-ID: <4A57A3BC.5000403@redhat.com> Catch and handle HTTP error conditions in the command-line. I ran into this when I would get a valid ticket, then blow away the IPA instance and create a new one but try to use the ipa command before re-running kinit. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-236-rpc.patch Type: application/mbox Size: 1091 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 Fri Jul 10 20:27:27 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 Jul 2009 16:27:27 -0400 Subject: [Freeipa-devel] [PATCH] 237 Enable replication with a dogtag CA Message-ID: <4A57A42F.5050808@redhat.com> This patch enables one to create replicas when using dogtag as the CA. This just sort of gets things to the point of working, a lot of work is left to be done to handle errors better and to better identify the type of IPA system being used (self-signed NSS CA, dogtag CA or external CA that provides PKCS#12 files to IPA). I've only tested this with a single replica so far. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-237-dogtag.patch Type: application/mbox Size: 35861 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 Fri Jul 10 20:45:06 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 Jul 2009 16:45:06 -0400 Subject: [Freeipa-devel] [PATCH] 227 virtual operations In-Reply-To: <1247234811.6317.217.camel@localhost.localdomain> References: <4A2422BC.7080601@redhat.com> <1247234811.6317.217.camel@localhost.localdomain> Message-ID: <4A57A852.9040707@redhat.com> Simo Sorce wrote: > On Mon, 2009-06-01 at 14:49 -0400, Rob Crittenden wrote: >> 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. > > 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 Jul 10 20:45:09 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 Jul 2009 16:45:09 -0400 Subject: [Freeipa-devel] [PATCH] 228 add function to prompt for entry after multiple results in -find In-Reply-To: <1247235032.6317.219.camel@localhost.localdomain> References: <4A2D859A.1040600@redhat.com> <1244565555.6533.11.camel@jgd-dsk> <4A2E9A5F.4050709@redhat.com> <4A2E9F9D.2020108@redhat.com> <1247235032.6317.219.camel@localhost.localdomain> Message-ID: <4A57A855.9050302@redhat.com> Simo Sorce wrote: > On Tue, 2009-06-09 at 13:45 -0400, Rob Crittenden wrote: >> 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. > > 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 Jul 10 20:45:14 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 Jul 2009 16:45:14 -0400 Subject: [Freeipa-devel] [PATCH] 229 set shell return value In-Reply-To: <1247234370.6317.215.camel@localhost.localdomain> References: <4A368E73.3080104@redhat.com> <1247234370.6317.215.camel@localhost.localdomain> Message-ID: <4A57A85A.20502@redhat.com> Simo Sorce wrote: > On Mon, 2009-06-15 at 14:09 -0400, Rob Crittenden wrote: >> 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". > > 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 Jul 10 20:46:12 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 Jul 2009 16:46:12 -0400 Subject: [Freeipa-devel] [PATCH] 230 enable VLV anonymous browsing In-Reply-To: <4A5759C9.1000403@redhat.com> References: <4A2FBCE9.6080606@redhat.com> <4A5759C9.1000403@redhat.com> Message-ID: <4A57A894.2050708@redhat.com> Nathan Kinder wrote: > On 06/10/2009 07:02 AM, Rob Crittenden wrote: >> Enable anonyomus VLV browsing so that automount on Solaris will work. > 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 Jul 10 20:46:48 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 Jul 2009 16:46:48 -0400 Subject: [Freeipa-devel] [PATCH] 231 Add one-character option to cli In-Reply-To: <1247234893.6317.218.camel@localhost.localdomain> References: <4A3008BE.7050204@redhat.com> <1247234893.6317.218.camel@localhost.localdomain> Message-ID: <4A57A8B8.3040209@redhat.com> Simo Sorce wrote: > On Wed, 2009-06-10 at 15:25 -0400, Rob Crittenden wrote: >> 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. > > 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 Jul 10 20:47:49 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 Jul 2009 16:47:49 -0400 Subject: [Freeipa-devel] [PATCH] require password only once from a pipe In-Reply-To: <1247234712.6317.216.camel@localhost.localdomain> References: <4A1C56B7.9080305@redhat.com> <1247234712.6317.216.camel@localhost.localdomain> Message-ID: <4A57A8F5.20503@redhat.com> Simo Sorce wrote: > On Tue, 2009-05-26 at 16:53 -0400, Rob Crittenden wrote: >> When reading the password in from a pipe require that it be provided >> only once. >> >> This will let people do: >> >> % echo "secret123" | ipa user-add --first=Joe --last=Robinson jrobinson >> >> or >> >> % echo "secret123" | ipa passwd jrobinson > > 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 sbose at redhat.com Fri Jul 10 21:15:51 2009 From: sbose at redhat.com (Sumit Bose) Date: Fri, 10 Jul 2009 23:15:51 +0200 Subject: [Freeipa-devel] Re: [PATCH] COLLECTION patches resending In-Reply-To: <4A5762CA.4060606@redhat.com> References: <4A567092.9050908@redhat.com> <20090710103116.GF29325@localhost.localdomain> <4A57511B.1090204@redhat.com> <4A5762CA.4060606@redhat.com> Message-ID: <20090710211551.GB22416@localhost.localdomain> On Fri, Jul 10, 2009 at 11:48:26AM -0400, Dmitri Pal wrote: > Dmitri Pal wrote: > > Sumit Bose wrote: > > > >> On Thu, Jul 09, 2009 at 06:34:58PM -0400, Dmitri Pal wrote: > >> > >> > >>> COLLECTION Adding flat traversal & copy > >>> > >>> The collection is hierarchical. The flattening > >>> of the collection was not implemented before > >>> both for traversal and copying. This patch > >>> introduces functionality to traverse or > >>> iterate through collection as flat set > >>> and also copy collection into another flattening > >>> it and automatically resolving conflicts. > >>> Also improved traceability and fixed memory leak > >>> in unbind iterator code. > >>> > >>> Sorry it grew a bit due to me adding extensive unit tests for different > >>> cases (and fixing things as I uncovered them). > >>> 1) Checked for tabs > >>> 2) Ran UT in valgrind > >>> 3) Checked for warnings in special build using Simo's scripts > >>> > >>> > >>> > >>> > >> Hi Dmitri, > >> > >> the patch applies and compiles well. > >> > >> There are a couple of '--' on unsigned values in this patch. I have not > >> checked if this is always save. Maybe it makes sense to add some > >> decrement macro which checks for 0 before doing -- ? > >> > >> > > These unsigned values are the size of the internal stack or depth level. > > They need to always be positive this is why they are unsigned. > > I do not want obfuscate the error by preventing them to go below 0. > > If it goes the program will crash and we will see the problem. Are you sure that the program will crash or maybe just override some random memory? If you use a macro you can call abort() if the value is 0 and the program will definitely exit. > > If we add the check we most likely hide the problem if there is a coding > > error. > > > > > >> While tracking some signed/unsigned comparisons (-Wextra will show them) > >> I have found an issue in col_insert_item_into_current. If > >> collection == NULL and collection->type != COL_TYPE_COLLECTION, > >> collection will be NULL the first time it is accessed. The attached > >> patch will solve this. > >> > >> > >> > > I see the issue, thanks for pointing it to me but I do not like the patch. > > Your patch will crash if collection is NULL in the first place since it > > will check collection->type before checking the collection itself. ah, yeah, sorry, I shoot myself into the foot. > > This issue however is not related to the patch I sent. Should I fix it > > in this patch or include in the next one? > > I would prefer next one since I have other things to do in collection > > today. > > Yes, it is completely unrelated and worth a separate patch > > > > > >> Concerning signed/unsigned comparisons. What do you think about setting > >> the idx/index arguements of: > >> - col_insert_item_into_current > >> - col_extract_item_from_current > >> - col_extract_item > >> - col_insert_item > >> > >> > >> > > In future the index might be negative to indicate special value so I > > would prefer leaving it as int. > > > > > >> and the level of col_iterate_up to unsigned to make it clear the > >> unsigned values are expected? > >> > >> > Original patch > > COLLECTION Adding flat traversal & copy > > The collection is hierarchical. The flattening > of the collection was not implemented before > both for traversal and copying. This patch > introduces functionality to traverse or > iterate through collection as flat set > and also copy collection into another flattening > it and automatically resolving conflicts. > Also improved traceability and fixed memory leak > in unbind iterator code. > > Correcting patch to address issues mentioned above. > > COLLECTION Fixed: iterator_up and insert_into_current > > During a review of the previous patch the two issues > were found: > a) The col_iterator_up function was not implemented properly > so it got reworked. New implementation changes > the way error condition is handled. Comments were updated accordingly. > b) There was a missing check for validity of the argument in > the col_insert_into_current function. Check was added. > c) Unit test modified to reflect the change in functionality. > These patches make sense to me, but I have to admit that I'm not too familiar with the collection code. I ACK these two patches, but it would be nice if Simo or Stephen can have a closer look on them before pushing them. bye, Sumit From dpal at redhat.com Fri Jul 10 21:29:06 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 10 Jul 2009 17:29:06 -0400 Subject: [Freeipa-devel] Re: [PATCH] COLLECTION patches resending In-Reply-To: <20090710211551.GB22416@localhost.localdomain> References: <4A567092.9050908@redhat.com> <20090710103116.GF29325@localhost.localdomain> <4A57511B.1090204@redhat.com> <4A5762CA.4060606@redhat.com> <20090710211551.GB22416@localhost.localdomain> Message-ID: <4A57B2A2.8070703@redhat.com> >>> These unsigned values are the size of the internal stack or depth level. >>> They need to always be positive this is why they are unsigned. >>> I do not want obfuscate the error by preventing them to go below 0. >>> If it goes the program will crash and we will see the problem. >>> > > Are you sure that the program will crash or maybe just override some > random memory? If you use a macro you can call abort() if the value is > 0 and the program will definitely exit. > > It will become MAX unsigned. Since the variable is used as an index to the array it will point to some unrelated memory and program will get memory violation. But the place where it was a problem is in the function that i fixed with the second patch. Thanks for reviewing! Dmitri From ssorce at redhat.com Sat Jul 11 15:10:47 2009 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 11 Jul 2009 11:10:47 -0400 Subject: [Freeipa-devel] [PATCH] 236 Have RPC catch HTTP errors In-Reply-To: <4A57A3BC.5000403@redhat.com> References: <4A57A3BC.5000403@redhat.com> Message-ID: <1247325047.6317.226.camel@localhost.localdomain> On Fri, 2009-07-10 at 16:25 -0400, Rob Crittenden wrote: > Catch and handle HTTP error conditions in the command-line. > > I ran into this when I would get a valid ticket, then blow away the IPA > instance and create a new one but try to use the ipa command before > re-running kinit. ack -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Sat Jul 11 15:13:09 2009 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 11 Jul 2009 11:13:09 -0400 Subject: [Freeipa-devel] [PATCH] 237 Enable replication with a dogtag CA In-Reply-To: <4A57A42F.5050808@redhat.com> References: <4A57A42F.5050808@redhat.com> Message-ID: <1247325189.6317.227.camel@localhost.localdomain> On Fri, 2009-07-10 at 16:27 -0400, Rob Crittenden wrote: > This patch enables one to create replicas when using dogtag as the CA. > > This just sort of gets things to the point of working, a lot of work > is > left to be done to handle errors better and to better identify the > type > of IPA system being used (self-signed NSS CA, dogtag CA or external > CA > that provides PKCS#12 files to IPA). > > I've only tested this with a single replica so far. ack -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Sat Jul 11 15:13:38 2009 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 11 Jul 2009 11:13:38 -0400 Subject: [Freeipa-devel] [PATCH] Fix SELinux compilation on Fedora 11 In-Reply-To: <4A4BBE97.9010907@redhat.com> References: <4A4BBE97.9010907@redhat.com> Message-ID: <1247325218.6317.228.camel@localhost.localdomain> On Wed, 2009-07-01 at 15:52 -0400, Rob Crittenden wrote: > Fedora 11 replaced a SELinux macro which was causing the build to fail. > Dan Walsh provided a patch to fix it and this patch integrates it into > the tree. I've added a conditional so that the same policy file should > build against even old SELinux policies (I tested on Fedora 9 and 11). > > I've included patches for both the master and ipa-1-2 branches. ack -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Mon Jul 13 11:33:22 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 13 Jul 2009 07:33:22 -0400 Subject: [Freeipa-devel] [PATCH] Check for root before initializing the tools In-Reply-To: <1246899787.6317.113.camel@localhost.localdomain> References: <4A4E0BF7.8040200@redhat.com> <20090703152148.GB13363@localhost.localdomain> <4A4F8F92.8050607@redhat.com> <20090706123119.GD13363@localhost.localdomain> <1246899787.6317.113.camel@localhost.localdomain> Message-ID: <4A5B1B82.90001@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/06/2009 01:03 PM, Simo Sorce wrote: > On Mon, 2009-07-06 at 14:31 +0200, Sumit Bose wrote: >> On Sat, Jul 04, 2009 at 07:21:22PM +0200, Jakub Hrozek wrote: >>> On 07/03/2009 05:21 PM, Sumit Bose wrote: >>>> please add 'c = ' >>> Correct, thank you. New patch attached. >>> >>> Jakub >> ACK > > pushed > >> I would like to rise the question how we should handle patches which >> will affect *.pot and *po files like this one. Should >> >> - the author of the patch provided the changes to *.pot and *.po files >> together with the patch >> - the *.pot and *.po files in the repository be only updated when a new >> release is created? > > We always need to insure the latter, although I personally prefer the > former I think we decided that it is not required. > > Simo. > In the ReleaseProcess wiki page that I put together and no one seemed to read, I addressed this. Updating the *.po[t] files will be part of the release process during the "Prepare the sources" step. https://fedorahosted.org/sssd/wiki/ReleaseProcess I think this makes the most sense as it dictates a way to ensure that all releases are up-to-date with the translations. - -- 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/ iEYEARECAAYFAkpbG3oACgkQeiVVYja6o6OlewCgqzw6w4N0TZJkGdp5mjtFeT4+ IWgAoJi8eyeIHlNQyiTx5f05VhDeTfPZ =pp1q -----END PGP SIGNATURE----- From sgallagh at redhat.com Mon Jul 13 12:10:24 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 13 Jul 2009 08:10:24 -0400 Subject: [Freeipa-devel] Re: [PATCH] COLLECTION patches resending In-Reply-To: <4A57B2A2.8070703@redhat.com> References: <4A567092.9050908@redhat.com> <20090710103116.GF29325@localhost.localdomain> <4A57511B.1090204@redhat.com> <4A5762CA.4060606@redhat.com> <20090710211551.GB22416@localhost.localdomain> <4A57B2A2.8070703@redhat.com> Message-ID: <4A5B2430.9000502@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/10/2009 05:29 PM, Dmitri Pal wrote: >>>> These unsigned values are the size of the internal stack or depth level. >>>> They need to always be positive this is why they are unsigned. >>>> I do not want obfuscate the error by preventing them to go below 0. >>>> If it goes the program will crash and we will see the problem. >>>> >> Are you sure that the program will crash or maybe just override some >> random memory? If you use a macro you can call abort() if the value is >> 0 and the program will definitely exit. >> >> > It will become MAX unsigned. Since the variable is used as an index to > the array it will point to some unrelated memory and program will get > memory violation. You cannot and MUST NOT rely on a "memory violation", since it's possible for you to be working on a machine with copious amounts of memory, where max unsigned might still be addressable (see PAE kernels for examples of this). Sumit is correct, you need to do this with a macro that calls abort() if a program attempts to decrement the stack counter when it's already zero. > But the place where it was a problem is in the function that i fixed > with the second patch. > > Thanks for reviewing! > > Dmitri > > > > _______________________________________________ > 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/ iEYEARECAAYFAkpbJCgACgkQeiVVYja6o6N/bQCdFu5t07PwSEptxQc1RrupSy8y 6c4An1XnlKYtoQ2W6tGRnkM+/59gmxC0 =fGLZ -----END PGP SIGNATURE----- From sbose at redhat.com Mon Jul 13 12:28:07 2009 From: sbose at redhat.com (Sumit Bose) Date: Mon, 13 Jul 2009 14:28:07 +0200 Subject: [Freeipa-devel] [PATCH] Check for root before initializing the tools In-Reply-To: <4A5B1B82.90001@redhat.com> References: <4A4E0BF7.8040200@redhat.com> <20090703152148.GB13363@localhost.localdomain> <4A4F8F92.8050607@redhat.com> <20090706123119.GD13363@localhost.localdomain> <1246899787.6317.113.camel@localhost.localdomain> <4A5B1B82.90001@redhat.com> Message-ID: <20090713122807.GC22416@localhost.localdomain> On Mon, Jul 13, 2009 at 07:33:22AM -0400, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/06/2009 01:03 PM, Simo Sorce wrote: > > On Mon, 2009-07-06 at 14:31 +0200, Sumit Bose wrote: > >> On Sat, Jul 04, 2009 at 07:21:22PM +0200, Jakub Hrozek wrote: > >>> On 07/03/2009 05:21 PM, Sumit Bose wrote: > >>>> please add 'c = ' > >>> Correct, thank you. New patch attached. > >>> > >>> Jakub > >> ACK > > > > pushed > > > >> I would like to rise the question how we should handle patches which > >> will affect *.pot and *po files like this one. Should > >> > >> - the author of the patch provided the changes to *.pot and *.po files > >> together with the patch > >> - the *.pot and *.po files in the repository be only updated when a new > >> release is created? > > > > We always need to insure the latter, although I personally prefer the > > former I think we decided that it is not required. > > > > Simo. > > > > In the ReleaseProcess wiki page that I put together and no one seemed to > read, I addressed this. Updating the *.po[t] files will be part of the > release process during the "Prepare the sources" step. > > https://fedorahosted.org/sssd/wiki/ReleaseProcess > > I think this makes the most sense as it dictates a way to ensure that > all releases are up-to-date with the translations. > I have read the page, but I have asked, because I wondered how the people who will translate the messages are working. I would expect that they/their tool will check out the *.pot and *.po files from the sssd repository, add their translations and commit the new *.po files back some way or the other. If we want to have up-to-date translations with a release and not only current *.pot and *.po files the translators need to have them before the release is tagged. If the translators will check out the whole tree, update the *.pot and *.po files on their own and send all modified *.pot and *.po files back then we only need to check that everything is valid at release time. bye, Sumit From sgallagh at redhat.com Mon Jul 13 12:33:37 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 13 Jul 2009 08:33:37 -0400 Subject: [Freeipa-devel] SSSD Translation Process Message-ID: <4A5B29A1.4060806@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/13/2009 08:28 AM, Sumit Bose wrote: > On Mon, Jul 13, 2009 at 07:33:22AM -0400, Stephen Gallagher wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 07/06/2009 01:03 PM, Simo Sorce wrote: >>> On Mon, 2009-07-06 at 14:31 +0200, Sumit Bose wrote: >>>> On Sat, Jul 04, 2009 at 07:21:22PM +0200, Jakub Hrozek wrote: >>>>> On 07/03/2009 05:21 PM, Sumit Bose wrote: >>>>>> please add 'c = ' >>>>> Correct, thank you. New patch attached. >>>>> >>>>> Jakub >>>> ACK >>> pushed >>> >>>> I would like to rise the question how we should handle patches which >>>> will affect *.pot and *po files like this one. Should >>>> >>>> - the author of the patch provided the changes to *.pot and *.po files >>>> together with the patch >>>> - the *.pot and *.po files in the repository be only updated when a new >>>> release is created? >>> We always need to insure the latter, although I personally prefer the >>> former I think we decided that it is not required. >>> >>> Simo. >>> >> In the ReleaseProcess wiki page that I put together and no one seemed to >> read, I addressed this. Updating the *.po[t] files will be part of the >> release process during the "Prepare the sources" step. >> >> https://fedorahosted.org/sssd/wiki/ReleaseProcess >> >> I think this makes the most sense as it dictates a way to ensure that >> all releases are up-to-date with the translations. >> > > I have read the page, but I have asked, because I wondered how the > people who will translate the messages are working. I would expect that > they/their tool will check out the *.pot and *.po files from the sssd > repository, add their translations and commit the new *.po files back > some way or the other. If we want to have up-to-date translations with a > release and not only current *.pot and *.po files the translators need > to have them before the release is tagged. > > If the translators will check out the whole tree, update the *.pot and > *.po files on their own and send all modified *.pot and *.po files back > then we only need to check that everything is valid at release time. > > bye, > Sumit > Hmm, that's a good point. We should probably create a separate process document for translators. I think what you said has merit. The process for translators should be something like: Check out the latest sources. Run 'make dist' to ensure that the translatable strings and locations are up-to-date. Do your translations. Submit for code review. Before check-in, make sure to rebase to the latest code and run 'make dist' again. Then the release engineer is only responsible for being concerned with line-number changes. - -- 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/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpbKZ0ACgkQeiVVYja6o6PrnwCeLtoQVbMArkiA+y763/mbbkBV zfUAn3WwY6SyAQn4KZA4CkQRxP3MDSXY =Y138 -----END PGP SIGNATURE----- From dpal at redhat.com Mon Jul 13 12:35:14 2009 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 13 Jul 2009 08:35:14 -0400 Subject: [Freeipa-devel] Re: [PATCH] COLLECTION patches resending In-Reply-To: <4A5B2430.9000502@redhat.com> References: <4A567092.9050908@redhat.com> <20090710103116.GF29325@localhost.localdomain> <4A57511B.1090204@redhat.com> <4A5762CA.4060606@redhat.com> <20090710211551.GB22416@localhost.localdomain> <4A57B2A2.8070703@redhat.com> <4A5B2430.9000502@redhat.com> Message-ID: <4A5B2A02.3000908@redhat.com> Stephen Gallagher wrote: > On 07/10/2009 05:29 PM, Dmitri Pal wrote: > >>>> These unsigned values are the size of the internal stack or depth > level. > >>>> They need to always be positive this is why they are unsigned. > >>>> I do not want obfuscate the error by preventing them to go below 0. > >>>> If it goes the program will crash and we will see the problem. > >>>> > >> Are you sure that the program will crash or maybe just override some > >> random memory? If you use a macro you can call abort() if the value is > >> 0 and the program will definitely exit. > >> > >> > > It will become MAX unsigned. Since the variable is used as an index to > > the array it will point to some unrelated memory and program will get > > memory violation. > > You cannot and MUST NOT rely on a "memory violation", since it's > possible for you to be working on a machine with copious amounts of > memory, where max unsigned might still be addressable (see PAE kernels > for examples of this). Sumit is correct, you need to do this with a > macro that calls abort() if a program attempts to decrement the stack > counter when it's already zero. > I do not agree with your argument and I do not like the abort(). IMO it is a theoretical discussion anyways. We are talking about bad things happening if there is a bug. The whole point is not to hide it if it is there. But the bigger point is not to have a bug. The latest patch addresses all the issues with "--". If you look at the code closely you will see that: 1) In walk_items the depth is incremented at the entry to the function and decremented at exit - no check is needed there. 2) In the iterator the check happens at the top of the loop and at the beginning the stack_size is set to 1. 3) The only problem was in the iterate_up function that is now reworked with the second patch. Please review and ack/nack. Thanks Dmitri From sgallagh at redhat.com Mon Jul 13 13:16:02 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 13 Jul 2009 09:16:02 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Build all SSSD components with warnings enabled Message-ID: <4A5B3392.3010805@redhat.com> Previously, only the SSSD server components were being built with compile-time warnings enabled. This patch will ensure that all components in common and sss_client are also built the same way. This is being done in response to a set of comments in the thread: https://www.redhat.com/archives/freeipa-devel/2009-July/msg00067.html -- 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-Build-all-SSSD-components-with-warnings-enabled.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 jdennis at redhat.com Mon Jul 13 15:37:52 2009 From: jdennis at redhat.com (John Dennis) Date: Mon, 13 Jul 2009 11:37:52 -0400 Subject: [Freeipa-devel] SSSD Translation Process In-Reply-To: <4A5B29A1.4060806@redhat.com> References: <4A5B29A1.4060806@redhat.com> Message-ID: <4A5B54D0.5090501@redhat.com> On 07/13/2009 08:33 AM, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/13/2009 08:28 AM, Sumit Bose wrote: >> On Mon, Jul 13, 2009 at 07:33:22AM -0400, Stephen Gallagher wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 07/06/2009 01:03 PM, Simo Sorce wrote: >>>> On Mon, 2009-07-06 at 14:31 +0200, Sumit Bose wrote: >>>>> On Sat, Jul 04, 2009 at 07:21:22PM +0200, Jakub Hrozek wrote: >>>>>> On 07/03/2009 05:21 PM, Sumit Bose wrote: >>>>>>> please add 'c = ' >>>>>> Correct, thank you. New patch attached. >>>>>> >>>>>> Jakub >>>>> ACK >>>> pushed >>>> >>>>> I would like to rise the question how we should handle patches which >>>>> will affect *.pot and *po files like this one. Should >>>>> >>>>> - the author of the patch provided the changes to *.pot and *.po files >>>>> together with the patch >>>>> - the *.pot and *.po files in the repository be only updated when a new >>>>> release is created? >>>> We always need to insure the latter, although I personally prefer the >>>> former I think we decided that it is not required. >>>> >>>> Simo. >>>> >>> In the ReleaseProcess wiki page that I put together and no one seemed to >>> read, I addressed this. Updating the *.po[t] files will be part of the >>> release process during the "Prepare the sources" step. >>> >>> https://fedorahosted.org/sssd/wiki/ReleaseProcess >>> >>> I think this makes the most sense as it dictates a way to ensure that >>> all releases are up-to-date with the translations. >>> >> I have read the page, but I have asked, because I wondered how the >> people who will translate the messages are working. I would expect that >> they/their tool will check out the *.pot and *.po files from the sssd >> repository, add their translations and commit the new *.po files back >> some way or the other. If we want to have up-to-date translations with a >> release and not only current *.pot and *.po files the translators need >> to have them before the release is tagged. >> >> If the translators will check out the whole tree, update the *.pot and >> *.po files on their own and send all modified *.pot and *.po files back >> then we only need to check that everything is valid at release time. >> >> bye, >> Sumit >> > > Hmm, that's a good point. We should probably create a separate process > document for translators. I think what you said has merit. The process > for translators should be something like: > > Check out the latest sources. Run 'make dist' to ensure that the > translatable strings and locations are up-to-date. Do your translations. > Submit for code review. Before check-in, make sure to rebase to the > latest code and run 'make dist' again. > > Then the release engineer is only responsible for being concerned with > line-number changes. The Fedora localization project (https://fedoraproject.org/wiki/L10N) has specific procedures for how translators interact with the SCM of the project they are providing translations for. My suggestion would be to depend on the Fedora translators and to follow their procedures. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sbose at redhat.com Mon Jul 13 16:12:24 2009 From: sbose at redhat.com (Sumit Bose) Date: Mon, 13 Jul 2009 18:12:24 +0200 Subject: [Freeipa-devel] [PATCH][SSSD] Build all SSSD components with warnings enabled In-Reply-To: <4A5B3392.3010805@redhat.com> References: <4A5B3392.3010805@redhat.com> Message-ID: <20090713161224.GD22416@localhost.localdomain> On Mon, Jul 13, 2009 at 09:16:02AM -0400, Stephen Gallagher wrote: > Previously, only the SSSD server components were being built with > compile-time warnings enabled. This patch will ensure that all > components in common and sss_client are also built the same way. > > This is being done in response to a set of comments in the thread: > https://www.redhat.com/archives/freeipa-devel/2009-July/msg00067.html > ACK bye, Sumit From sgallagh at redhat.com Mon Jul 13 16:14:30 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 13 Jul 2009 12:14:30 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Build all SSSD components with warnings enabled In-Reply-To: <20090713161224.GD22416@localhost.localdomain> References: <4A5B3392.3010805@redhat.com> <20090713161224.GD22416@localhost.localdomain> Message-ID: <4A5B5D66.5040507@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/13/2009 12:12 PM, Sumit Bose wrote: > On Mon, Jul 13, 2009 at 09:16:02AM -0400, Stephen Gallagher wrote: >> Previously, only the SSSD server components were being built with >> compile-time warnings enabled. This patch will ensure that all >> components in common and sss_client are also built the same way. >> >> This is being done in response to a set of comments in the thread: >> https://www.redhat.com/archives/freeipa-devel/2009-July/msg00067.html >> > > 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/ iEYEARECAAYFAkpbXV8ACgkQeiVVYja6o6PYrQCfbsKcpqNFLu/lVC8fNWKU07Se LugAniIlCDv1sockr+siiO5hMbYOhZh2 =1PvX -----END PGP SIGNATURE----- From sgallagh at redhat.com Mon Jul 13 19:00:03 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 13 Jul 2009 15:00:03 -0400 Subject: [Freeipa-devel] [SSSD] First draft of a bug lifecycle process Message-ID: <4A5B8433.6090308@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In order to make it easier to maintain the SSSD bug tracker, I've created a page on the SSSD wiki to describe the process for opening a bug, fixing a bug, and resolving a bug. The sections on opening a bug should be of interest to anyone working with SSSD, the latter sections only to the engineers involved. Questions and suggestions are most welcome. I intend to create a main "Contributors" page for the SSSD and link this from there, once we're agreed on its content. I will be doing something similar for the translation process once that is decided on. https://fedorahosted.org/sssd/wiki/BugLifecycle - -- 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/ iEYEARECAAYFAkpbhCoACgkQeiVVYja6o6OvfgCfRivrI39lgz/qieSoHNVac/V3 t3YAniID4qQ89vACPi4cPNpQqhVrM6hc =7u2d -----END PGP SIGNATURE----- From kwade at redhat.com Mon Jul 13 21:15:27 2009 From: kwade at redhat.com (Karsten Wade) Date: Mon, 13 Jul 2009 14:15:27 -0700 Subject: [Freeipa-devel] SSSD Translation Process In-Reply-To: <4A5B54D0.5090501@redhat.com> References: <4A5B29A1.4060806@redhat.com> <4A5B54D0.5090501@redhat.com> Message-ID: <20090713211527.GQ29035@calliope.phig.org> On Mon, Jul 13, 2009 at 11:37:52AM -0400, John Dennis wrote: > The Fedora localization project (https://fedoraproject.org/wiki/L10N) > has specific procedures for how translators interact with the SCM of the > project they are providing translations for. My suggestion would be to > depend on the Fedora translators and to follow their procedures. So, let's talk about L10n. Fortunately, the means and methods are much similar to what Red Hat has done all along. A key piece is Transifex, which is a (web) service that sits between your SCM and a translation community. Fedora's instance is here: https://translate.fedoraproject.org/ In general, the translators work against the schedule set by the developers, such as the Fedora Linux or GNOME release schedules. This includes many individual software packages that also release with Fedora, such as the system-config-* set of tools. Those developers release to the same drumbeat as Fedora overall, so can coordinate in unison with translators. In my experience, what translators do to a schedule is insert additional milestone activites. In particular, string freeze that is really frozen and not slushy. For example, in Fedora Docs we've preferred to be late with our freeze than to risk breaking it later. Steve, you said in IRC this morning that you'd like to coordinate the FreeIPA side. How about if we meet on #fedora-l10n and bend the ears of a few people there (diegobz, glezoz, vpv, et al)? Turn my loose assurances in to actual process, etc. We can hit their mailing list and set a specific time, if it helps; folks there are in many timezones (South America, Greece India, Australia, etc.) Alternately, if you want to join fedora-trans-list, we can discuss async. cheers - 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 ssorce at redhat.com Mon Jul 13 22:11:29 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 13 Jul 2009 18:11:29 -0400 Subject: [Freeipa-devel] [PATCHES] tools and debug tidyups Message-ID: <1247523089.29458.14.camel@localhost.localdomain> Fixes and tidyups to tools and debugging of memberof. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Start-rationalizing-user-tools-a-bit.patch Type: text/x-patch Size: 60671 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Instrument-memberof-for-debugging.patch Type: text/x-patch Size: 13028 bytes Desc: not available URL: From dpal at redhat.com Mon Jul 13 23:41:23 2009 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 13 Jul 2009 19:41:23 -0400 Subject: [Freeipa-devel] [PATCH] First part of the ELAPI interface Message-ID: <4A5BC623.1030604@redhat.com> This is just a part of the interface, a beginning. Most likely some of the functions will be altered but it is a starting point. For example in future there will be a way to override some of the parts of the default template using the application configuration file. I just need to start somewhere. More to come during the week. -- 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 Mon Jul 13 23:42:26 2009 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 13 Jul 2009 19:42:26 -0400 Subject: [Freeipa-devel] [PATCH] First part of the ELAPI interface (resend) In-Reply-To: <4A5BC623.1030604@redhat.com> References: <4A5BC623.1030604@redhat.com> Message-ID: <4A5BC662.1070302@redhat.com> Dmitri Pal wrote: > This is just a part of the interface, > a beginning. Most likely some of the functions > will be altered but it is a starting point. > For example in future there will be > a way to override some of the parts of the > default template using the application configuration file. > > > I just need to start somewhere. More to come during the week. > > Forgot the attachment... -- 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-ELAPI-First-part-of-the-interface.patch Type: text/x-patch Size: 65304 bytes Desc: not available URL: From sgallagh at redhat.com Tue Jul 14 10:11:27 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 14 Jul 2009 06:11:27 -0400 Subject: [Freeipa-devel] SSSD Translation Process In-Reply-To: <20090713211527.GQ29035@calliope.phig.org> References: <4A5B29A1.4060806@redhat.com> <4A5B54D0.5090501@redhat.com> <20090713211527.GQ29035@calliope.phig.org> Message-ID: <4A5C59CF.6070809@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/13/2009 05:15 PM, Karsten Wade wrote: > On Mon, Jul 13, 2009 at 11:37:52AM -0400, John Dennis wrote: > >> The Fedora localization project (https://fedoraproject.org/wiki/L10N) >> has specific procedures for how translators interact with the SCM of the >> project they are providing translations for. My suggestion would be to >> depend on the Fedora translators and to follow their procedures. > > So, let's talk about L10n. > > Fortunately, the means and methods are much similar to what Red Hat > has done all along. A key piece is Transifex, which is a (web) > service that sits between your SCM and a translation community. > Fedora's instance is here: > > https://translate.fedoraproject.org/ > > In general, the translators work against the schedule set by the > developers, such as the Fedora Linux or GNOME release schedules. This > includes many individual software packages that also release with > Fedora, such as the system-config-* set of tools. Those developers > release to the same drumbeat as Fedora overall, so can coordinate in > unison with translators. > > In my experience, what translators do to a schedule is insert > additional milestone activites. In particular, string freeze that is > really frozen and not slushy. For example, in Fedora Docs we've > preferred to be late with our freeze than to risk breaking it later. > > Steve, you said in IRC this morning that you'd like to coordinate the > FreeIPA side. How about if we meet on #fedora-l10n and bend the ears > of a few people there (diegobz, glezoz, vpv, et al)? Turn my loose > assurances in to actual process, etc. We can hit their mailing list > and set a specific time, if it helps; folks there are in many > timezones (South America, Greece India, Australia, etc.) Alternately, > if you want to join fedora-trans-list, we can discuss async. > Sure, in terms of a rough estimate, how about we hit up #fedora-l10n sometime between 1p.m. and 4p.m. EDT (1500-1800 UTC) today (July 14th)? We can hammer out some of the details and then we'll post back to this list (and a wiki page) about our plans. > cheers - Karsten > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/ iEYEARECAAYFAkpcWc4ACgkQeiVVYja6o6NSxwCfVDGAW9WyBAm0AMwbEkBuiETn aHIAn0CFbnrZ84CeS8eSR321i5VMcMQv =SoBr -----END PGP SIGNATURE----- From sgallagh at redhat.com Tue Jul 14 10:38:23 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 14 Jul 2009 06:38:23 -0400 Subject: [Freeipa-devel] [PATCHES] tools and debug tidyups In-Reply-To: <1247523089.29458.14.camel@localhost.localdomain> References: <1247523089.29458.14.camel@localhost.localdomain> Message-ID: <4A5C601F.1030701@redhat.com> On 07/13/2009 06:11 PM, Simo Sorce wrote: > Fixes and tidyups to tools and debugging of memberof. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Nack. I applied your patch and attempted to run 'sss_useradd tempuser' as root. The program segfaulted with the attached core file. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: core.4612.gz Type: application/x-gzip Size: 199859 bytes Desc: not available 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 Jul 14 10:41:08 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 14 Jul 2009 06:41:08 -0400 Subject: [Freeipa-devel] [PATCHES] tools and debug tidyups In-Reply-To: <4A5C601F.1030701@redhat.com> References: <1247523089.29458.14.camel@localhost.localdomain> <4A5C601F.1030701@redhat.com> Message-ID: <4A5C60C4.3050607@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/14/2009 06:38 AM, Stephen Gallagher wrote: > On 07/13/2009 06:11 PM, Simo Sorce wrote: >> Fixes and tidyups to tools and debugging of memberof. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Nack. I applied your patch and attempted to run 'sss_useradd tempuser' > as root. The program segfaulted with the attached core file. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I realized I should add some more information, since that core file was generated with a different binary than the one you will be using. Here's the backtrace and some print commands that show that the problem is that we're attempting to dereference state->base while it is null. Core was generated by `sss_useradd tempuser'. Program terminated with signal 11, Segmentation fault. #0 0x000000000040bc01 in sysdb_get_new_id_verify (subreq=0x0) at ../../server/db/sysdb_ops.c:1451 1451 msg->dn = state->base->dn; Missing separate debuginfos, use: debuginfo-install sssd-0.4.1-2.fc11.x86_64 (gdb) bt #0 0x000000000040bc01 in sysdb_get_new_id_verify (subreq=0x0) at ../../server/db/sysdb_ops.c:1451 #1 0x0000000000409237 in sldb_request_callback (ldbreq=0xa1d300, ldbreply=0xa08e10) at ../../server/db/sysdb_ops.c:158 #2 0x00007f7a2198601f in ?? () from /usr/lib64/libldb.so.0 #3 0x0000003dcf202f35 in tevent_common_loop_timer_delay () from /usr/lib64/libtevent.so.0 #4 0x0000003dcf20458b in ?? () from /usr/lib64/libtevent.so.0 #5 0x000000000040591b in main (argc=2, argv=0x7fffa13f6998) at ../../server/tools/sss_useradd.c:512 (gdb) print msg $1 = (struct ldb_message *) 0xa0a910 (gdb) print *msg $2 = {dn = 0x0, num_elements = 0, elements = 0x0} (gdb) print state $3 = (struct sysdb_get_new_id_state *) 0xa07ba0 (gdb) print state->base $4 = (struct ldb_message *) 0x0 - -- 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/ iEYEARECAAYFAkpcYMQACgkQeiVVYja6o6Mx/QCgmqvLnS0Bv0qV5gIbaZTdk+AN vjEAnj4iQwomtzequ0tO32QhB06A9Krz =TJ4A -----END PGP SIGNATURE----- From sbose at redhat.com Tue Jul 14 12:45:47 2009 From: sbose at redhat.com (Sumit Bose) Date: Tue, 14 Jul 2009 14:45:47 +0200 Subject: [Freeipa-devel] [PATCH] First part of the ELAPI interface (resend) In-Reply-To: <4A5BC662.1070302@redhat.com> References: <4A5BC623.1030604@redhat.com> <4A5BC662.1070302@redhat.com> Message-ID: <20090714124547.GE22416@localhost.localdomain> On Mon, Jul 13, 2009 at 07:42:26PM -0400, Dmitri Pal wrote: > Dmitri Pal wrote: > > This is just a part of the interface, > > a beginning. Most likely some of the functions > > will be altered but it is a starting point. > > For example in future there will be > > a way to override some of the parts of the > > default template using the application configuration file. > > > > > > I just need to start somewhere. More to come during the week. > > > > > Forgot the attachment... > Just a few general comments for a start. - I think you have to add the m4 subdirectory to the repository, too. autoreconf does not create it automatically - please change configure.ac and Makefile.am according to Stephen's recent patch to include all thew usual -W* flags to AM_CFLAGS - I get a "'COL_ADD_MODE_FLAT' undeclared" bye, Sumit From ssorce at redhat.com Tue Jul 14 13:02:37 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 14 Jul 2009 09:02:37 -0400 Subject: [Freeipa-devel] [PATCHES] tools and debug tidyups In-Reply-To: <4A5C60C4.3050607@redhat.com> References: <1247523089.29458.14.camel@localhost.localdomain> <4A5C601F.1030701@redhat.com> <4A5C60C4.3050607@redhat.com> Message-ID: <1247576557.29458.27.camel@localhost.localdomain> On Tue, 2009-07-14 at 06:41 -0400, Stephen Gallagher wrote: > I realized I should add some more information, since that core file was > generated with a different binary than the one you will be using. Here's > the backtrace and some print commands that show that the problem is that > we're attempting to dereference state->base while it is null. This is a bug in sysdb, not in my patch, I'll address this bug separately (strange it didn't happen to me, and I tested sss_useradd quite a lot ...) Please ack/nack the patch on its own merit. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Jul 14 13:11:23 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 14 Jul 2009 09:11:23 -0400 Subject: [Freeipa-devel] [PATCH] First part of the ELAPI interface (resend) In-Reply-To: <4A5BC662.1070302@redhat.com> References: <4A5BC623.1030604@redhat.com> <4A5BC662.1070302@redhat.com> Message-ID: <1247577083.29458.30.camel@localhost.localdomain> On Mon, 2009-07-13 at 19:42 -0400, Dmitri Pal wrote: > Dmitri Pal wrote: > > This is just a part of the interface, > > a beginning. Most likely some of the functions > > will be altered but it is a starting point. > > For example in future there will be > > a way to override some of the parts of the > > default template using the application configuration file. > > > > > > I just need to start somewhere. More to come during the week. Haven't read everything, but I saw a couple of things that are not ok. 1. the public header requires the private header, this is a nack. 2. Never, ever typedef to a pointer. typedef struct foo foo_t is ok if really necessary typedef struct foo * foo_t is an instant-nack Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Jul 14 13:48:26 2009 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 14 Jul 2009 09:48:26 -0400 Subject: [Freeipa-devel] [PATCH] First part of the ELAPI interface (resend) In-Reply-To: <20090714124547.GE22416@localhost.localdomain> References: <4A5BC623.1030604@redhat.com> <4A5BC662.1070302@redhat.com> <20090714124547.GE22416@localhost.localdomain> Message-ID: <4A5C8CAA.8000100@redhat.com> Sumit Bose wrote: > On Mon, Jul 13, 2009 at 07:42:26PM -0400, Dmitri Pal wrote: > >> Dmitri Pal wrote: >> >>> This is just a part of the interface, >>> a beginning. Most likely some of the functions >>> will be altered but it is a starting point. >>> For example in future there will be >>> a way to override some of the parts of the >>> default template using the application configuration file. >>> >>> >>> I just need to start somewhere. More to come during the week. >>> >>> >>> >> Forgot the attachment... >> >> > > Just a few general comments for a start. > - I think you have to add the m4 subdirectory to the repository, too. > autoreconf does not create it automatically > I noticed that too but thought it is a problem with my configuration. Steven is that the case? > - please change configure.ac and Makefile.am according to Stephen's > recent patch to include all thew usual -W* flags to AM_CFLAGS > I can do it in a separate patch on top of this one. No need to jam things together. But I will take a look. > - I get a "'COL_ADD_MODE_FLAT' undeclared" > It is declared in one of the two previous patches I submitted. They have not been pushed yet. You need all three for things to work. On relies on another. Thanks for taking a look. > bye, > Sumit > -- 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 Tue Jul 14 15:02:38 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 14 Jul 2009 11:02:38 -0400 Subject: [Freeipa-devel] [PATCH] First part of the ELAPI interface (resend) In-Reply-To: <4A5C8CAA.8000100@redhat.com> References: <4A5BC623.1030604@redhat.com> <4A5BC662.1070302@redhat.com> <20090714124547.GE22416@localhost.localdomain> <4A5C8CAA.8000100@redhat.com> Message-ID: <4A5C9E0E.8040109@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/14/2009 09:48 AM, Dmitri Pal wrote: > Sumit Bose wrote: >> On Mon, Jul 13, 2009 at 07:42:26PM -0400, Dmitri Pal wrote: >> >>> Dmitri Pal wrote: >>> >>>> This is just a part of the interface, >>>> a beginning. Most likely some of the functions >>>> will be altered but it is a starting point. >>>> For example in future there will be >>>> a way to override some of the parts of the >>>> default template using the application configuration file. >>>> >>>> >>>> I just need to start somewhere. More to come during the week. >>>> >>>> >>>> >>> Forgot the attachment... >>> >>> >> Just a few general comments for a start. >> - I think you have to add the m4 subdirectory to the repository, too. >> autoreconf does not create it automatically >> > I noticed that too but thought it is a problem with my configuration. > Steven is that the case? Yes, the m4 directory needs to be present. The way I've done this in the past is to add a m4/.dir zero-length file to the repository. I don't know how to make git add an empty directory otherwise. > >> - please change configure.ac and Makefile.am according to Stephen's >> recent patch to include all thew usual -W* flags to AM_CFLAGS >> > I can do it in a separate patch on top of this one. > No need to jam things together. But I will take a look. Since you're going back and modifying this patch anyway, please include this. > >> - I get a "'COL_ADD_MODE_FLAT' undeclared" >> > It is declared in one of the two previous patches I submitted. > They have not been pushed yet. You need all three for things to work. > On relies on another. > > Thanks for taking a look. > >> 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/ iEYEARECAAYFAkpcngoACgkQeiVVYja6o6NPxQCfT1K/m87oFiUcMnK/wxeKomJi YjYAn2RoBilBFEN3+6GXROfLFECWQSYE =b1t3 -----END PGP SIGNATURE----- From kwade at redhat.com Tue Jul 14 15:42:22 2009 From: kwade at redhat.com (Karsten Wade) Date: Tue, 14 Jul 2009 08:42:22 -0700 Subject: [Freeipa-devel] SSSD Translation Process In-Reply-To: <4A5C59CF.6070809@redhat.com> References: <4A5B29A1.4060806@redhat.com> <4A5B54D0.5090501@redhat.com> <20090713211527.GQ29035@calliope.phig.org> <4A5C59CF.6070809@redhat.com> Message-ID: <20090714154222.GC29199@calliope.phig.org> On Tue, Jul 14, 2009 at 06:11:27AM -0400, Stephen Gallagher wrote: > > Sure, in terms of a rough estimate, how about we hit up #fedora-l10n > sometime between 1p.m. and 4p.m. EDT (1500-1800 UTC) today (July 14th)? OK, I sent some word and there will definitely be helpful folks around during that window. - 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 dpal at redhat.com Tue Jul 14 15:55:09 2009 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 14 Jul 2009 11:55:09 -0400 Subject: [Freeipa-devel] [PATCH] First part of the ELAPI interface (resend) In-Reply-To: <1247577083.29458.30.camel@localhost.localdomain> References: <4A5BC623.1030604@redhat.com> <4A5BC662.1070302@redhat.com> <1247577083.29458.30.camel@localhost.localdomain> Message-ID: <4A5CAA5D.7070701@redhat.com> Simo Sorce wrote: > On Mon, 2009-07-13 at 19:42 -0400, Dmitri Pal wrote: > >> Dmitri Pal wrote: >> >>> This is just a part of the interface, >>> a beginning. Most likely some of the functions >>> will be altered but it is a starting point. >>> For example in future there will be >>> a way to override some of the parts of the >>> default template using the application configuration file. >>> >>> >>> I just need to start somewhere. More to come during the week. >>> > > Haven't read everything, but I saw a couple of things that are not ok. > 1. the public header requires the private header, this is a nack. > 2. Never, ever typedef to a pointer. > > typedef struct foo foo_t is ok if really necessary > typedef struct foo * foo_t is an instant-nack > > Simo. > > > We had a phone conversation and decided that we will not try to hide the "struct collection_item *" behind typedefs at all. I will amend the patch accordingly. -- 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 Tue Jul 14 17:46:51 2009 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 14 Jul 2009 13:46:51 -0400 Subject: [Freeipa-devel] [PATCH] First part of the ELAPI interface (resend 2) In-Reply-To: <4A5CAA5D.7070701@redhat.com> References: <4A5BC623.1030604@redhat.com> <4A5BC662.1070302@redhat.com> <1247577083.29458.30.camel@localhost.localdomain> <4A5CAA5D.7070701@redhat.com> Message-ID: <4A5CC48B.3060708@redhat.com> Dmitri Pal wrote: > Simo Sorce wrote: > >> On Mon, 2009-07-13 at 19:42 -0400, Dmitri Pal wrote: >> >> >>> Dmitri Pal wrote: >>> >>> >>>> This is just a part of the interface, >>>> a beginning. Most likely some of the functions >>>> will be altered but it is a starting point. >>>> For example in future there will be >>>> a way to override some of the parts of the >>>> default template using the application configuration file. >>>> >>>> >>>> I just need to start somewhere. More to come during the week. >>>> >>>> >> Haven't read everything, but I saw a couple of things that are not ok. >> 1. the public header requires the private header, this is a nack. >> 2. Never, ever typedef to a pointer. >> >> typedef struct foo foo_t is ok if really necessary >> typedef struct foo * foo_t is an instant-nack >> >> Simo. >> >> >> >> > We had a phone conversation and decided that we will not try to hide the > "struct collection_item *" behind typedefs at all. > I will amend the patch accordingly. > > * Removed the obfuscation of data types based on discussion with Simo. * Changed header file inclusion - private header is private. * Changed compilation flags * Added m4 directory following Steven's method. Patch works only on top of previous two patches. -- 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-ELAPI-First-part-of-the-interface.patch Type: text/x-patch Size: 62820 bytes Desc: not available URL: From jdennis at redhat.com Tue Jul 14 18:02:46 2009 From: jdennis at redhat.com (John Dennis) Date: Tue, 14 Jul 2009 14:02:46 -0400 Subject: [Freeipa-devel] [PATCH] add path_utils to common Message-ID: <4A5CC846.5040701@redhat.com> This is the first of several patches to add code to repository for the audit log watching code. I needed a variety of file system path manipulation functions which either weren't in standard libraries or didn't work as needed. Since this is general utility code it was broken out from the rest of the log watch code to permit reuse. The code has been heavily beat upon and sails through valgrind without any errors. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-add-path_utils-filesystem-path-manipulation-utility.patch Type: text/x-patch Size: 30697 bytes Desc: not available URL: From sgallagh at redhat.com Tue Jul 14 19:25:25 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 14 Jul 2009 15:25:25 -0400 Subject: [Freeipa-devel] [PATCH] add path_utils to common In-Reply-To: <4A5CC846.5040701@redhat.com> References: <4A5CC846.5040701@redhat.com> Message-ID: <4A5CDBA5.6000206@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/14/2009 02:02 PM, John Dennis wrote: > This is the first of several patches to add code to repository for the > audit log watching code. I needed a variety of file system path > manipulation functions which either weren't in standard libraries or > didn't work as needed. Since this is general utility code it was broken > out from the rest of the log watch code to permit reuse. The code has > been heavily beat upon and sails through valgrind without any errors. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Nack. path_utils_error_string(): PATH_UTILS_ERROR_NOT_FULLY_NORALAIZED should probably be PATH_UTILS_ERROR_NOT_FULLY_NORMALIZED. Also, there should be capitalization of "path" in the string there. Furthermore, should path_utils_error_string() be localized? I'm not saying in this patch, but it looks like a good candidate. get_basename(): It would be wise to put in a check that base_name_size < PATH_MAX or you could get truncation. In that case, I'd think you might want to have this function return either NULL or better yet an error code. get_dirname(): You need to check for ERANGE after getcwd(). It's possible that you're getting a path back from a foreign filesystem that supports longer paths than PATH_MAX. get_directory_and_base_name(): Same concerns as get_dirname() and get_basename(). Also, is this function useful? (I realize it's one fewer copy to tmp_path than calling get_basename and get_dirname, but it seems like a bit of code waste) path_concat(): if (dst >= dst_end) should be if (dst > dst_end). You've already accounted for the null terminator when defining dst_end. make_path_absolute(): Same concerns as path_concat(). Finally, you have a ton of tabs and trailing spaces hanging around. - -- 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/ iEYEARECAAYFAkpc258ACgkQeiVVYja6o6O8DwCcC4R/zSve2n44TLbHNK/UV3NK VpwAn3EChXubCKGSpKU8+4qzJLGd6R/J =UCyx -----END PGP SIGNATURE----- From mnagy at redhat.com Tue Jul 14 21:23:38 2009 From: mnagy at redhat.com (Martin Nagy) Date: Tue, 14 Jul 2009 23:23:38 +0200 Subject: [Freeipa-devel] [PATCH] Use uppercase boolean values in dns.ldif Message-ID: <20090714232338.39e176b0@notas> The newest 389 server implements syntax checking and causes problems if the boolean attribute is set to "True". The correct value should be "TRUE". Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-uppercase-boolean-values-in-dns.ldif.patch Type: text/x-patch Size: 917 bytes Desc: not available URL: From nkinder at redhat.com Tue Jul 14 22:02:38 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 14 Jul 2009 15:02:38 -0700 Subject: [Freeipa-devel] [PATCH] Use uppercase boolean values in dns.ldif In-Reply-To: <20090714232338.39e176b0@notas> References: <20090714232338.39e176b0@notas> Message-ID: <4A5D007E.9040106@redhat.com> On 07/14/2009 02:23 PM, Martin Nagy wrote: > The newest 389 server implements syntax checking and causes problems if > the boolean attribute is set to "True". The correct value should be > "TRUE". > ack. > Martin > ------------------------------------------------------------------------ > > _______________________________________________ > 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 jdennis at redhat.com Tue Jul 14 22:48:53 2009 From: jdennis at redhat.com (John Dennis) Date: Tue, 14 Jul 2009 18:48:53 -0400 Subject: [Freeipa-devel] [PATCH] add path_utils to common In-Reply-To: <4A5CDBA5.6000206@redhat.com> References: <4A5CC846.5040701@redhat.com> <4A5CDBA5.6000206@redhat.com> Message-ID: <4A5D0B55.3000507@redhat.com> On 07/14/2009 03:25 PM, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/14/2009 02:02 PM, John Dennis wrote: >> This is the first of several patches to add code to repository for the >> audit log watching code. I needed a variety of file system path >> manipulation functions which either weren't in standard libraries or >> didn't work as needed. Since this is general utility code it was broken >> out from the rest of the log watch code to permit reuse. The code has >> been heavily beat upon and sails through valgrind without any errors. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Nack. New patch attached which addresses the issues Stephen raised. Thank you Stephen for your careful reading. > > path_utils_error_string(): > PATH_UTILS_ERROR_NOT_FULLY_NORALAIZED should probably be > PATH_UTILS_ERROR_NOT_FULLY_NORMALIZED. Also, there should be > capitalization of "path" in the string there. > > Furthermore, should path_utils_error_string() be localized? I'm not > saying in this patch, but it looks like a good candidate. easy, done. > get_basename(): > It would be wise to put in a check that base_name_size< PATH_MAX or you > could get truncation. In that case, I'd think you might want to have > this function return either NULL or better yet an error code. I put in a slightly different check which I think is more robust. Truncation can also occur if the size of the passed in buffer is too small. The check is to see if strncpy exhausted the available buffer space, which will be true if the last byte in the buffer is not zero. This check has been added in numerous places. > get_dirname(): > You need to check for ERANGE after getcwd(). It's possible that you're > getting a path back from a foreign filesystem that supports longer paths > than PATH_MAX. done > get_directory_and_base_name(): > Same concerns as get_dirname() and get_basename(). Also, is this > function useful? (I realize it's one fewer copy to tmp_path than calling > get_basename and get_dirname, but it seems like a bit of code waste) The reason for this extra function is because I discovered it was very common to want both the basename and the directory, so the frequency of use justified the optimization. > path_concat(): > if (dst>= dst_end) should be if (dst> dst_end). You've already > accounted for the null terminator when defining dst_end. > > make_path_absolute(): > Same concerns as path_concat(). good catch, done. > Finally, you have a ton of tabs and trailing spaces hanging around. silly me, I thought I had taken care of that but I guess not, it's done now. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-add-path_utils-filesystem-path-manipulation-utility.patch Type: text/x-patch Size: 33690 bytes Desc: not available URL: From kwade at redhat.com Wed Jul 15 04:46:01 2009 From: kwade at redhat.com (Karsten Wade) Date: Tue, 14 Jul 2009 21:46:01 -0700 Subject: [Freeipa-devel] contribution policy draft Message-ID: <20090715044601.GB29035@calliope.phig.org> Here's my simple thinking: 1. We get this to say what we *mean* it to say: http://freeipa.org/page/User:Quaid/Contribution_policy_(draft) 2. We pass that back to Red Hat Legal, saying, "These are the policies we want contributions to be under; it doesn't need to be a CLA. Can you help us word this so it is a sufficient replacement for the CLA." Here is the page where I've gathered requirements so far; the policy draft is transcluded, too. I wrote the policy draft from my experience with Fedora Project policy and borrowing liberally from the ideas in the Wikipedia Terms of Use[1]. http://freeipa.org/page/User:Quaid/Contribution_policy_(draft) What is missing? What is sufficient for you, as contributors, to know your work is covered for being free and open forevermore? Thanks - Karsten [1] http://wikimediafoundation.org/wiki/Terms_of_Use -- 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 mnagy at redhat.com Wed Jul 15 05:36:03 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 15 Jul 2009 07:36:03 +0200 Subject: [Freeipa-devel] [PATCH] Use uppercase boolean values in dns.ldif In-Reply-To: <4A5D007E.9040106@redhat.com> References: <20090714232338.39e176b0@notas> <4A5D007E.9040106@redhat.com> Message-ID: <20090715073603.2dd2ce70@wolverine.englab.brq.redhat.com> On Tue, 14 Jul 2009 15:02:38 -0700, Nathan Kinder wrote: > On 07/14/2009 02:23 PM, Martin Nagy wrote: > > The newest 389 server implements syntax checking and causes > > problems if the boolean attribute is set to "True". The correct > > value should be "TRUE". > > > ack. Pushed to master. From sgallagh at redhat.com Wed Jul 15 10:31:31 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 15 Jul 2009 06:31:31 -0400 Subject: [Freeipa-devel] contribution policy draft In-Reply-To: <20090715044601.GB29035@calliope.phig.org> References: <20090715044601.GB29035@calliope.phig.org> Message-ID: <4A5DB003.3030404@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/15/2009 12:46 AM, Karsten Wade wrote: > Here's my simple thinking: > > 1. We get this to say what we *mean* it to say: > > http://freeipa.org/page/User:Quaid/Contribution_policy_(draft) > > 2. We pass that back to Red Hat Legal, saying, "These are the policies > we want contributions to be under; it doesn't need to be a CLA. Can > you help us word this so it is a sufficient replacement for the > CLA." > > Here is the page where I've gathered requirements so far; the policy > draft is transcluded, too. I wrote the policy draft from my > experience with Fedora Project policy and borrowing liberally from the > ideas in the Wikipedia Terms of Use[1]. > > http://freeipa.org/page/User:Quaid/Contribution_policy_(draft) > > What is missing? > > What is sufficient for you, as contributors, to know your work is > covered for being free and open forevermore? > > Thanks - Karsten > > [1] http://wikimediafoundation.org/wiki/Terms_of_Use > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Karsten, I'd also like to put together something similar for the SSSD contribution page (not currently existing in any useful form). The SSSD has some different licensing requirements, however. While all portions of the server should be GPL (version debatable), we have several shared libraries that need to be LGPL, and we also have a nebulous set of plugins that are loaded by server-processes*. These last present a somewhat troublesome legal question. We need to figure out how to license contributions so that end-users are allowed to create back-end plugins that may or may not be open-source (for example, a company might decide to produce a closed-source backend to the SSSD to support their one-time password device). We need to ensure that this is possible within the license. * For clarification, in the SSSD service model, we have business logic performed in several "data provider" backend services. These are separate, small processes that handle some basic setup (such as hooking into the main Data Provider process) and then loads a plugin shared object that must expose certain functions that handle all of the business logic for a particular authentication or authorization feature. My concern is that neither the GPL nor the LGPL would be acceptable for the data provider backend services, because the plugins would have to be considered derivative works (which is not acceptable for some potential users). - -- 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/ iEYEARECAAYFAkpdr/YACgkQeiVVYja6o6MNzwCeP/ETwn0iyyFi7q8peMWp15wj 3iwAn0SBdXTMzbN+51+JEOfYvFryFYt7 =7q5h -----END PGP SIGNATURE----- From jhrozek at redhat.com Wed Jul 15 10:48:02 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 15 Jul 2009 12:48:02 +0200 Subject: [Freeipa-devel] [PATCH] Fix saving new nextID Message-ID: <4A5DB3E2.4000009@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The attached patch fixes the problem when sss_ tools segfaulted when there was no nextID for a given domain. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpds+IACgkQHsardTLnvCWq3QCfX8xvsshpsd4Gsh4nZncvpzw0 Yy4AoJmlkMUOjA2gyEyGaTm0Ki4Urd9k =LfeM -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Fix-saving-new-nextID.patch URL: From sgallagh at redhat.com Wed Jul 15 11:10:52 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 15 Jul 2009 07:10:52 -0400 Subject: [Freeipa-devel] [PATCH] add path_utils to common In-Reply-To: <4A5D0B55.3000507@redhat.com> References: <4A5CC846.5040701@redhat.com> <4A5CDBA5.6000206@redhat.com> <4A5D0B55.3000507@redhat.com> Message-ID: <4A5DB93C.3040304@redhat.com> On 07/14/2009 06:48 PM, John Dennis wrote: > On 07/14/2009 03:25 PM, Stephen Gallagher wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 07/14/2009 02:02 PM, John Dennis wrote: >>> This is the first of several patches to add code to repository for the >>> audit log watching code. I needed a variety of file system path >>> manipulation functions which either weren't in standard libraries or >>> didn't work as needed. Since this is general utility code it was broken >>> out from the rest of the log watch code to permit reuse. The code has >>> been heavily beat upon and sails through valgrind without any errors. >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Nack. > > New patch attached which addresses the issues Stephen raised. Thank you > Stephen for your careful reading. > >> >> path_utils_error_string(): >> PATH_UTILS_ERROR_NOT_FULLY_NORALAIZED should probably be >> PATH_UTILS_ERROR_NOT_FULLY_NORMALIZED. Also, there should be >> capitalization of "path" in the string there. >> >> Furthermore, should path_utils_error_string() be localized? I'm not >> saying in this patch, but it looks like a good candidate. > > easy, done. > >> get_basename(): >> It would be wise to put in a check that base_name_size< PATH_MAX or you >> could get truncation. In that case, I'd think you might want to have >> this function return either NULL or better yet an error code. > > I put in a slightly different check which I think is more robust. > Truncation can also occur if the size of the passed in buffer is too > small. The check is to see if strncpy exhausted the available buffer > space, which will be true if the last byte in the buffer is not zero. > This check has been added in numerous places. > >> get_dirname(): >> You need to check for ERANGE after getcwd(). It's possible that you're >> getting a path back from a foreign filesystem that supports longer paths >> than PATH_MAX. > > done > >> get_directory_and_base_name(): >> Same concerns as get_dirname() and get_basename(). Also, is this >> function useful? (I realize it's one fewer copy to tmp_path than calling >> get_basename and get_dirname, but it seems like a bit of code waste) > > The reason for this extra function is because I discovered it was very > common to want both the basename and the directory, so the frequency of > use justified the optimization. > >> path_concat(): >> if (dst>= dst_end) should be if (dst> dst_end). You've already >> accounted for the null terminator when defining dst_end. >> >> make_path_absolute(): >> Same concerns as path_concat(). > > good catch, done. > >> Finally, you have a ton of tabs and trailing spaces hanging around. > > silly me, I thought I had taken care of that but I guess not, it's done > now. > Sorry, I found a couple remaining minor issues. You were creating a path_utils.pc file directly, instead of a path_utils.pc.in that gets its install path data from configure. The minor typo I mentioned in my previous review was unchanged. I am attaching a patch to this email that corrects these issues (as they are so minor that I figured I'd save you the trouble). Please review them yourself, and if you approve of them as-is, I will squash it into your patch and push 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-Fix-path_utils.pc.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 Jul 15 12:08:55 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 15 Jul 2009 08:08:55 -0400 Subject: [Freeipa-devel] [PATCH] Fix saving new nextID In-Reply-To: <4A5DB3E2.4000009@redhat.com> References: <4A5DB3E2.4000009@redhat.com> Message-ID: <1247659735.29458.57.camel@localhost.localdomain> On Wed, 2009-07-15 at 12:48 +0200, Jakub Hrozek wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The attached patch fixes the problem when sss_ tools segfaulted when > there was no nextID for a given domain. > Nack, we already have the value in state->base_dn, this look like it was just a typo state->base->dn instead of state->base_dn Simo. -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Wed Jul 15 12:15:53 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 15 Jul 2009 14:15:53 +0200 Subject: [Freeipa-devel] [PATCH] Fix saving new nextID In-Reply-To: <1247659735.29458.57.camel@localhost.localdomain> References: <4A5DB3E2.4000009@redhat.com> <1247659735.29458.57.camel@localhost.localdomain> Message-ID: <4A5DC879.6040904@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/15/2009 02:08 PM, Simo Sorce wrote: > Nack, we already have the value in state->base_dn, this look like it was > just a typo state->base->dn instead of state->base_dn > > Simo. > True, new patch that just fixes the typo is attached. Thanks, Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpdyHkACgkQHsardTLnvCXrdQCfbPIPWo8erTASxpUk0s0dCGSn I3EAn0lD4IK0pRdgpDWwVwD1Hxp/7EF6 =wlCs -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Fix-saving-new-nextID.patch URL: From jdennis at redhat.com Wed Jul 15 12:38:55 2009 From: jdennis at redhat.com (John Dennis) Date: Wed, 15 Jul 2009 08:38:55 -0400 Subject: [Freeipa-devel] [PATCH] add path_utils to common In-Reply-To: <4A5DB93C.3040304@redhat.com> References: <4A5CC846.5040701@redhat.com> <4A5CDBA5.6000206@redhat.com> <4A5D0B55.3000507@redhat.com> <4A5DB93C.3040304@redhat.com> Message-ID: <4A5DCDDF.6020603@redhat.com> On 07/15/2009 07:10 AM, Stephen Gallagher wrote: > I am attaching a patch to this email that corrects these issues (as they > are so minor that I figured I'd save you the trouble). Please review > them yourself, and if you approve of them as-is, I will squash it into > your patch and push it. Thank you Stephen, looks good, please squash and push. Thanks. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sbose at redhat.com Wed Jul 15 12:53:00 2009 From: sbose at redhat.com (Sumit Bose) Date: Wed, 15 Jul 2009 14:53:00 +0200 Subject: [Freeipa-devel] [PATCH] add infrastructure to handle new backend targets Message-ID: <20090715125300.GD3219@localhost.localdomain> Hi, this patch adds the handling of the new backend targets access (a.k.a. authorization) and chpass to the data provider infrastructure. I have changed the way the current id and auth targets are handled to avoid multiple loading of a single backend and to avoid massive code duplication. This patch touches the backends only where necessary. This means that the sssd can be complied successfully and id and auth are working as expected (at least in my test :-). The access target is set to a default permit target. I will provide a patch for the backends if this patch and the new scheme of handling the backends and their targets is accepted. bye, Sumit -------------- next part -------------- >From 6892cd8ce82d966327bf9e1f66955a88ab6968e9 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 14 Jul 2009 21:12:30 +0200 Subject: [PATCH] add infrastructure to handle new backend targets --- server/providers/data_provider_be.c | 278 +++++++++++++++++++++-------------- server/providers/dp_backend.h | 49 ++++-- server/providers/krb5/krb5_auth.c | 9 +- server/providers/ldap/ldap_auth.c | 9 +- server/providers/ldap/ldap_id.c | 10 +- server/providers/proxy.c | 23 ++-- 6 files changed, 228 insertions(+), 150 deletions(-) diff --git a/server/providers/data_provider_be.c b/server/providers/data_provider_be.c index 6cd86e8..24254d1 100644 --- a/server/providers/data_provider_be.c +++ b/server/providers/data_provider_be.c @@ -71,6 +71,17 @@ struct sbus_method be_methods[] = { { NULL, NULL } }; +static struct bet_data bet_data[] = { + {BET_NULL, NULL, NULL}, + {BET_ID, "provider", "sssm_%s_init"}, + {BET_AUTH, "auth-module", "sssm_%s_auth_init"}, + {BET_ACCESS, "access-module", "sssm_%s_access_init"}, + {BET_CHPASS, "chpass-module", "sssm_%s_chpass_init"}, + {BET_MAX, NULL, NULL} +}; + + + static int service_identity(DBusMessage *message, struct sbus_conn_ctx *sconn) { dbus_uint16_t version = DATA_PROVIDER_VERSION; @@ -303,7 +314,7 @@ static int be_check_online(DBusMessage *message, struct sbus_conn_ctx *sconn) be_req->req_data = req; - ret = be_file_request(ctx, ctx->id_ops->check_online, be_req); + ret = be_file_request(ctx, ctx->bet_info[BET_ID].bet_ops->check_online, be_req); if (ret != EOK) { online = MOD_OFFLINE; err_maj = DP_ERR_FATAL; @@ -480,7 +491,7 @@ static int be_get_account_info(DBusMessage *message, struct sbus_conn_ctx *sconn be_req->req_data = req; - ret = be_file_request(ctx, ctx->id_ops->get_account_info, be_req); + ret = be_file_request(ctx, ctx->bet_info[BET_ID].bet_ops->handler, be_req); if (ret != EOK) { err_maj = DP_ERR_FATAL; err_min = ret; @@ -548,6 +559,7 @@ static int be_pam_handler(DBusMessage *message, struct sbus_conn_ctx *sconn) struct pam_data *pd = NULL; struct be_req *be_req = NULL; uint32_t pam_status = PAM_SYSTEM_ERR; + enum bet_type target = BET_NULL; user_data = sbus_conn_get_private_data(sconn); if (!user_data) return EINVAL; @@ -561,10 +573,6 @@ static int be_pam_handler(DBusMessage *message, struct sbus_conn_ctx *sconn) return ENOMEM; } - /* return an error if no auth backend is configured */ - if (!ctx->auth_ops) - goto done; - pd = talloc_zero(ctx, struct pam_data); if (!pd) return ENOMEM; @@ -580,6 +588,29 @@ static int be_pam_handler(DBusMessage *message, struct sbus_conn_ctx *sconn) DEBUG(4, ("Got request with the following data\n")); DEBUG_PAM_DATA(4, pd); + switch (pd->cmd) { + case SSS_PAM_AUTHENTICATE: + target = BET_AUTH; + break; + case SSS_PAM_ACCT_MGMT: + target = BET_ACCESS; + break; + case SSS_PAM_CHAUTHTOK: + target = BET_CHPASS; + break; + default: + DEBUG(7, ("Unsupported PAM command [%d].\n", pd->cmd)); + pam_status = PAM_SUCCESS; + ret = EOK; + goto done; + } + + /* return an error if corresponding backend target is configured */ + if (!ctx->bet_info[target].bet_ops) { + DEBUG(7, ("Undefined backend target.\n")); + goto done; + } + be_req = talloc_zero(ctx, struct be_req); if (!be_req) goto done; @@ -589,7 +620,7 @@ static int be_pam_handler(DBusMessage *message, struct sbus_conn_ctx *sconn) be_req->pvt = reply; be_req->req_data = pd; - ret = be_file_request(ctx, ctx->auth_ops->pam_handler, be_req); + ret = be_file_request(ctx, ctx->bet_info[target].bet_ops->handler, be_req); if (ret != EOK) goto done; @@ -769,9 +800,9 @@ static void be_id_shutdown(struct be_req *req, int status, const char *errstr) shutdown_req->be_ctx = ctx; shutdown_req->fn = be_id_shutdown; - shutdown_req->pvt = ctx->pvt_id_data; + shutdown_req->pvt = ctx->bet_info[BET_ID].pvt_bet_data; - ret = be_file_request(ctx, ctx->id_ops->finalize, shutdown_req); + ret = be_file_request(ctx, ctx->bet_info[BET_ID].bet_ops->finalize, shutdown_req); if (ret == EOK) return; @@ -793,9 +824,9 @@ static int be_finalize(struct be_ctx *ctx) shutdown_req->be_ctx = ctx; shutdown_req->fn = be_id_shutdown; - shutdown_req->pvt = ctx->pvt_auth_data; + shutdown_req->pvt = ctx->bet_info[BET_AUTH].pvt_bet_data; - ret = be_file_request(ctx, ctx->auth_ops->finalize, shutdown_req); + ret = be_file_request(ctx, ctx->bet_info[BET_AUTH].bet_ops->finalize, shutdown_req); if (ret == EOK) return EOK; fail: @@ -804,80 +835,51 @@ fail: return ret; } -static int load_id_backend(struct be_ctx *ctx) +static void be_target_access_permit(struct be_req *be_req) { - TALLOC_CTX *tmp_ctx; - char *path; - void *handle; - char *mod_init_fn_name; - be_id_init_fn_t mod_init_fn; - int ret; - - tmp_ctx = talloc_new(ctx); - if (!tmp_ctx) { - return ENOMEM; - } + struct pam_data *pd = talloc_get_type(be_req->req_data, struct pam_data); + DEBUG(9, ("be_target_access_permit called, returning PAM_SUCCESS.\n")); - path = talloc_asprintf(tmp_ctx, "%s/libsss_%s.so", - DATA_PROVIDER_PLUGINS_PATH, ctx->name); - if (!path) { - ret = ENOMEM; - goto done; - } - - handle = dlopen(path, RTLD_NOW); - if (!handle) { - DEBUG(0, ("Unable to load %s module with path (%s), error: %s\n", - ctx->name, path, dlerror())); - ret = ELIBACC; - goto done; - } - - mod_init_fn_name = talloc_asprintf(tmp_ctx, "sssm_%s_init", ctx->name); - if (!mod_init_fn_name) { - ret = ENOMEM; - goto done; - } - - mod_init_fn = (be_id_init_fn_t)dlsym(handle, mod_init_fn_name); - if (!mod_init_fn) { - DEBUG(0, ("Unable to load init fn from module %s, error: %s\n", - ctx->name, dlerror())); - ret = ELIBBAD; - goto done; - } - - ret = mod_init_fn(ctx, &ctx->id_ops, &ctx->pvt_id_data); - if (ret != EOK) { - DEBUG(0, ("Error (%d) in module (%s) initialization!\n", - ret, ctx->name)); - goto done; - } - - ret = EOK; - -done: - talloc_free(tmp_ctx); - return ret; + pd->pam_status = PAM_SUCCESS; + be_req->fn(be_req, PAM_SUCCESS, NULL); } -static int load_auth_backend(struct be_ctx *ctx) +static struct bet_ops be_target_access_permit_ops = { + .check_online = NULL, + .handler = be_target_access_permit, + .finalize = NULL +}; + +static int load_backend_module(struct be_ctx *ctx, + enum bet_type bet_type, + struct bet_ops **be_ops, + void **be_pvt_data) { TALLOC_CTX *tmp_ctx; - char *mod_name; - char *path; + int ret = EINVAL; + bool already_loaded = false; + int lb=0; + char *mod_name = NULL; + char *path = NULL; void *handle; - char *mod_init_fn_name; - be_auth_init_fn_t mod_init_fn; - int ret; + char *mod_init_fn_name = NULL; + bet_init_fn_t mod_init_fn = NULL; + + if (bet_type <= BET_NULL || bet_type >= BET_MAX || + bet_type != bet_data[bet_type].bet_type) { + DEBUG(2, ("invalid bet_type or bet_data corrupted.\n")); + return EINVAL; + } tmp_ctx = talloc_new(ctx); if (!tmp_ctx) { + DEBUG(7, ("talloc_new failed.\n")); return ENOMEM; } ret = confdb_get_string(ctx->cdb, tmp_ctx, ctx->conf_path, - "auth-module", NULL, &mod_name); + bet_data[bet_type].option_name, NULL, + &mod_name); if (ret != EOK) { ret = EFAULT; goto done; @@ -887,39 +889,65 @@ static int load_auth_backend(struct be_ctx *ctx) goto done; } - path = talloc_asprintf(tmp_ctx, "%s/libsss_%s.so", - DATA_PROVIDER_PLUGINS_PATH, mod_name); - if (!path) { + mod_init_fn_name = talloc_asprintf(tmp_ctx, + bet_data[bet_type].mod_init_fn_name_fmt, + mod_name); + if (mod_init_fn_name == NULL) { + DEBUG(7, ("talloc_asprintf failed\n")); ret = ENOMEM; goto done; } - handle = dlopen(path, RTLD_NOW); - if (!handle) { - DEBUG(0, ("Unable to load %s module with path (%s), error: %s\n", - mod_name, path, dlerror())); - ret = ELIBACC; - goto done; + + lb = 0; + while(ctx->loaded_be[lb].be_name != NULL) { + if (strncmp(ctx->loaded_be[lb].be_name, mod_name, + strlen(mod_name)) == 0) { + DEBUG(7, ("Backend [%s] already loaded.\n", mod_name)); + already_loaded = true; + break; + } + + ++lb; + if (lb >= BET_MAX) { + DEBUG(2, ("Backend context corrupted.\n")); + return EINVAL; + } } - mod_init_fn_name = talloc_asprintf(tmp_ctx, "sssm_%s_auth_init", mod_name); - if (!mod_init_fn_name) { - ret = ENOMEM; - goto done; + if (!already_loaded) { + path = talloc_asprintf(tmp_ctx, "%s/libsss_%s.so", + DATA_PROVIDER_PLUGINS_PATH, mod_name); + if (!path) { + return ENOMEM; + } + + DEBUG(7, ("Loading backend [%s] with path [%s].\n", mod_name, path)); + handle = dlopen(path, RTLD_NOW); + if (!handle) { + DEBUG(0, ("Unable to load %s module with path (%s), error: %s\n", + mod_name, path, dlerror())); + ret = ELIBACC; + goto done; + } + + ctx->loaded_be[lb].be_name = talloc_strdup(ctx, mod_name); + ctx->loaded_be[lb].handle = handle; } - mod_init_fn = (be_auth_init_fn_t)dlsym(handle, mod_init_fn_name); - if (!mod_init_fn) { - DEBUG(0, ("Unable to load init fn from module %s, error: %s\n", - mod_name, dlerror())); + mod_init_fn = (bet_init_fn_t)dlsym(ctx->loaded_be[lb].handle, + mod_init_fn_name); + if (mod_init_fn == NULL) { + DEBUG(0, ("Unable to load init fn %s from module %s, error: %s\n", + mod_init_fn_name, mod_name, dlerror())); ret = ELIBBAD; goto done; } - ret = mod_init_fn(ctx, &ctx->auth_ops, &ctx->pvt_auth_data); + ret = mod_init_fn(ctx, be_ops, be_pvt_data); if (ret != EOK) { - DEBUG(0, ("Error (%d) in module (%s) initialization!\n", - ret, mod_name)); + DEBUG(0, ("Error (%d) in module (%s) initialization (%s)!\n", + ret, mod_name, mod_init_fn_name)); goto done; } @@ -978,13 +1006,17 @@ int be_process_init(TALLOC_CTX *mem_ctx, return ret; } - ret = load_id_backend(ctx); + ret = load_backend_module(ctx, BET_ID, + &ctx->bet_info[BET_ID].bet_ops, + &ctx->bet_info[BET_ID].pvt_bet_data); if (ret != EOK) { DEBUG(0, ("fatal error initializing data providers\n")); return ret; } - ret = load_auth_backend(ctx); + ret = load_backend_module(ctx, BET_AUTH, + &ctx->bet_info[BET_AUTH].bet_ops, + &ctx->bet_info[BET_AUTH].pvt_bet_data); if (ret != EOK) { if (ret != ENOENT) { DEBUG(0, ("fatal error initializing data providers\n")); @@ -994,6 +1026,32 @@ int be_process_init(TALLOC_CTX *mem_ctx, be_domain)); } + ret = load_backend_module(ctx, BET_ACCESS, + &ctx->bet_info[BET_ACCESS].bet_ops, + &ctx->bet_info[BET_ACCESS].pvt_bet_data); + if (ret != EOK) { + if (ret != ENOENT) { + DEBUG(0, ("fatal error initializing data providers\n")); + return ret; + } + DEBUG(1, ("No access control module provided for [%s] " + "using be_target_access_permit!!\n", be_domain)); + ctx->bet_info[BET_ACCESS].bet_ops = &be_target_access_permit_ops; + ctx->bet_info[BET_ACCESS].pvt_bet_data = NULL; + } + + ret = load_backend_module(ctx, BET_CHPASS, + &ctx->bet_info[BET_CHPASS].bet_ops, + &ctx->bet_info[BET_CHPASS].pvt_bet_data); + if (ret != EOK) { + if (ret != ENOENT) { + DEBUG(0, ("fatal error initializing data providers\n")); + return ret; + } + DEBUG(1, ("No change password module provided for [%s] !!\n", + be_domain)); + } + return EOK; } @@ -1008,28 +1066,28 @@ int main(int argc, const char *argv[]) struct main_context *main_ctx; int ret; - struct poptOption long_options[] = { - POPT_AUTOHELP + struct poptOption long_options[] = { + POPT_AUTOHELP SSSD_MAIN_OPTS {"provider", 0, POPT_ARG_STRING, &be_name, 0, "Information Provider", NULL }, {"domain", 0, POPT_ARG_STRING, &be_domain, 0, "Domain of the information provider", NULL }, - { NULL } - }; - - pc = poptGetContext(argv[0], argc, argv, long_options, 0); - while((opt = poptGetNextOpt(pc)) != -1) { - switch(opt) { - default: - fprintf(stderr, "\nInvalid option %s: %s\n\n", - poptBadOption(pc, 0), poptStrerror(opt)); - poptPrintUsage(pc, stderr, 0); - return 1; - } - } - - poptFreeContext(pc); + POPT_TABLEEND + }; + + pc = poptGetContext(argv[0], argc, argv, long_options, 0); + while((opt = poptGetNextOpt(pc)) != -1) { + switch(opt) { + default: + fprintf(stderr, "\nInvalid option %s: %s\n\n", + poptBadOption(pc, 0), poptStrerror(opt)); + poptPrintUsage(pc, stderr, 0); + return 1; + } + } + + poptFreeContext(pc); /* set up things like debug , signals, daemonization, etc... */ srv_name = talloc_asprintf(NULL, "sssd[be[%s]]", be_name); diff --git a/server/providers/dp_backend.h b/server/providers/dp_backend.h index 27f79eb..66bc871 100644 --- a/server/providers/dp_backend.h +++ b/server/providers/dp_backend.h @@ -26,16 +26,41 @@ #include "db/sysdb.h" struct be_ctx; -struct be_id_ops; -struct be_auth_ops; +struct bet_ops; struct be_req; -typedef int (*be_id_init_fn_t)(TALLOC_CTX *, struct be_id_ops **, void **); -typedef int (*be_auth_init_fn_t)(TALLOC_CTX *, struct be_auth_ops **, void **); +typedef int (*bet_init_fn_t)(TALLOC_CTX *, struct bet_ops **, void **); typedef void (*be_shutdown_fn)(void *); typedef void (*be_req_fn_t)(struct be_req *); typedef void (*be_async_callback_t)(struct be_req *, int, const char *); +enum bet_type { + BET_NULL = 0, + BET_ID, + BET_AUTH, + BET_ACCESS, + BET_CHPASS, + BET_MAX +}; + +struct bet_data { + enum bet_type bet_type; + const char *option_name; + const char *mod_init_fn_name_fmt; +}; + +struct loaded_be { + char *be_name; + void *handle; +}; + +struct bet_info { + enum bet_type bet_type; + struct bet_ops *bet_ops; + void *pvt_bet_data; +}; + + struct be_ctx { struct tevent_context *ev; struct confdb_ctx *cdb; @@ -47,21 +72,13 @@ struct be_ctx { const char *identity; const char *conf_path; - struct be_id_ops *id_ops; - void *pvt_id_data; - - struct be_auth_ops *auth_ops; - void *pvt_auth_data; + struct loaded_be loaded_be[BET_MAX]; + struct bet_info bet_info[BET_MAX]; }; -struct be_id_ops { +struct bet_ops { be_req_fn_t check_online; - be_req_fn_t get_account_info; - be_req_fn_t finalize; -}; - -struct be_auth_ops { - be_req_fn_t pam_handler; + be_req_fn_t handler; be_req_fn_t finalize; }; diff --git a/server/providers/krb5/krb5_auth.c b/server/providers/krb5/krb5_auth.c index 2cbdc99..c2bf83f 100644 --- a/server/providers/krb5/krb5_auth.c +++ b/server/providers/krb5/krb5_auth.c @@ -88,7 +88,7 @@ static int krb5_setup(struct be_req *req, struct krb5_req **krb5_req) pd = talloc_get_type(req->req_data, struct pam_data); - krb5_ctx = talloc_get_type(req->be_ctx->pvt_auth_data, struct krb5_ctx); + krb5_ctx = talloc_get_type(req->be_ctx->bet_info[BET_AUTH].pvt_bet_data, struct krb5_ctx); kr = talloc_zero(req, struct krb5_req); if (kr == NULL) { @@ -536,13 +536,14 @@ static void krb5_pam_handler_cache_done(struct tevent_req *subreq) be_req->fn(be_req, PAM_SUCCESS, NULL); } -struct be_auth_ops krb5_auth_ops = { - .pam_handler = krb5_pam_handler, +struct bet_ops krb5_auth_ops = { + .check_online = NULL, + .handler = krb5_pam_handler, .finalize = NULL, }; -int sssm_krb5_auth_init(struct be_ctx *bectx, struct be_auth_ops **ops, +int sssm_krb5_auth_init(struct be_ctx *bectx, struct bet_ops **ops, void **pvt_auth_data) { struct krb5_ctx *ctx = NULL; diff --git a/server/providers/ldap/ldap_auth.c b/server/providers/ldap/ldap_auth.c index e363385..cfbff98 100644 --- a/server/providers/ldap/ldap_auth.c +++ b/server/providers/ldap/ldap_auth.c @@ -322,7 +322,7 @@ static void sdap_pam_auth_send(struct be_req *breq) struct tevent_req *subreq; struct pam_data *pd; - ctx = talloc_get_type(breq->be_ctx->pvt_auth_data, struct sdap_auth_ctx); + ctx = talloc_get_type(breq->be_ctx->bet_info[BET_AUTH].pvt_bet_data, struct sdap_auth_ctx); pd = talloc_get_type(breq->req_data, struct pam_data); pd->pam_status = PAM_SYSTEM_ERR; @@ -447,13 +447,14 @@ static void sdap_shutdown(struct be_req *req) req->fn(req, EOK, NULL); } -struct be_auth_ops sdap_auth_ops = { - .pam_handler = sdap_pam_auth_send, +struct bet_ops sdap_auth_ops = { + .check_online = NULL, + .handler = sdap_pam_auth_send, .finalize = sdap_shutdown }; int sssm_ldap_auth_init(struct be_ctx *bectx, - struct be_auth_ops **ops, + struct bet_ops **ops, void **pvt_data) { int ldap_opt_x_tls_require_cert; diff --git a/server/providers/ldap/ldap_id.c b/server/providers/ldap/ldap_id.c index 1218027..83d009e 100644 --- a/server/providers/ldap/ldap_id.c +++ b/server/providers/ldap/ldap_id.c @@ -61,7 +61,7 @@ static void sdap_check_online(struct be_req *req) struct be_online_req *oreq; struct sdap_id_ctx *ctx; - ctx = talloc_get_type(req->be_ctx->pvt_id_data, struct sdap_id_ctx); + ctx = talloc_get_type(req->be_ctx->bet_info[BET_ID].pvt_bet_data, struct sdap_id_ctx); oreq = talloc_get_type(req->req_data, struct be_online_req); if (is_offline(ctx)) { @@ -674,7 +674,7 @@ static void sdap_get_account_info(struct be_req *breq) const char *err = "Unknown Error"; int ret = EOK; - ctx = talloc_get_type(breq->be_ctx->pvt_id_data, struct sdap_id_ctx); + ctx = talloc_get_type(breq->be_ctx->bet_info[BET_ID].pvt_bet_data, struct sdap_id_ctx); if (is_offline(ctx)) { return sdap_req_done(breq, EAGAIN, "Offline"); @@ -753,14 +753,14 @@ static void sdap_shutdown(struct be_req *req) sdap_req_done(req, EOK, NULL); } -struct be_id_ops sdap_id_ops = { +struct bet_ops sdap_id_ops = { .check_online = sdap_check_online, - .get_account_info = sdap_get_account_info, + .handler = sdap_get_account_info, .finalize = sdap_shutdown }; int sssm_ldap_init(struct be_ctx *bectx, - struct be_id_ops **ops, + struct bet_ops **ops, void **pvt_data) { int ldap_opt_x_tls_require_cert; diff --git a/server/providers/proxy.c b/server/providers/proxy.c index 2336094..aa5b1c9 100644 --- a/server/providers/proxy.c +++ b/server/providers/proxy.c @@ -87,7 +87,7 @@ static void go_offline(struct be_ctx *be_ctx) struct timeval timeout; int ret; - ctx = talloc_get_type(be_ctx->pvt_id_data, struct proxy_ctx); + ctx = talloc_get_type(be_ctx->bet_info[BET_ID].pvt_bet_data, struct proxy_ctx); ret = gettimeofday(&timeout, NULL); if (ret == -1) { @@ -109,7 +109,7 @@ static bool is_offline(struct be_ctx *be_ctx) { struct proxy_ctx *ctx; - ctx = talloc_get_type(be_ctx->pvt_id_data, struct proxy_ctx); + ctx = talloc_get_type(be_ctx->bet_info[BET_ID].pvt_bet_data, struct proxy_ctx); return ctx->offline; } @@ -171,7 +171,7 @@ static void proxy_pam_handler(struct be_req *req) { struct proxy_auth_ctx *ctx;; bool cache_auth_data = false; - ctx = talloc_get_type(req->be_ctx->pvt_auth_data, struct proxy_auth_ctx); + ctx = talloc_get_type(req->be_ctx->bet_info[BET_AUTH].pvt_bet_data, struct proxy_auth_ctx); pd = talloc_get_type(req->req_data, struct pam_data); conv.conv=proxy_internal_conv; @@ -1892,7 +1892,7 @@ static void proxy_get_account_info(struct be_req *breq) gid_t gid; ar = talloc_get_type(breq->req_data, struct be_acct_req); - ctx = talloc_get_type(breq->be_ctx->pvt_id_data, struct proxy_ctx); + ctx = talloc_get_type(breq->be_ctx->bet_info[BET_ID].pvt_bet_data, struct proxy_ctx); ev = breq->be_ctx->ev; sysdb = breq->be_ctx->sysdb; domain = breq->be_ctx->domain; @@ -2053,18 +2053,19 @@ static void proxy_shutdown(struct be_req *req) static void proxy_auth_shutdown(struct be_req *req) { - talloc_free(req->be_ctx->pvt_auth_data); + talloc_free(req->be_ctx->bet_info[BET_AUTH].pvt_bet_data); req->fn(req, EOK, NULL); } -struct be_id_ops proxy_id_ops = { +struct bet_ops proxy_id_ops = { .check_online = proxy_check_online, - .get_account_info = proxy_get_account_info, + .handler = proxy_get_account_info, .finalize = proxy_shutdown }; -struct be_auth_ops proxy_auth_ops = { - .pam_handler = proxy_pam_handler, +struct bet_ops proxy_auth_ops = { + .check_online = proxy_check_online, + .handler = proxy_pam_handler, .finalize = proxy_auth_shutdown }; @@ -2083,7 +2084,7 @@ static void *proxy_dlsym(void *handle, const char *functemp, char *libname) } int sssm_proxy_init(struct be_ctx *bectx, - struct be_id_ops **ops, void **pvt_data) + struct bet_ops **ops, void **pvt_data) { struct proxy_ctx *ctx; char *libname; @@ -2209,7 +2210,7 @@ done: } int sssm_proxy_auth_init(struct be_ctx *bectx, - struct be_auth_ops **ops, void **pvt_data) + struct bet_ops **ops, void **pvt_data) { struct proxy_auth_ctx *ctx; int ret; -- 1.6.2.5 From sgallagh at redhat.com Wed Jul 15 12:57:34 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 15 Jul 2009 08:57:34 -0400 Subject: [Freeipa-devel] [PATCH] add path_utils to common In-Reply-To: <4A5DCDDF.6020603@redhat.com> References: <4A5CC846.5040701@redhat.com> <4A5CDBA5.6000206@redhat.com> <4A5D0B55.3000507@redhat.com> <4A5DB93C.3040304@redhat.com> <4A5DCDDF.6020603@redhat.com> Message-ID: <4A5DD23E.6010909@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/15/2009 08:38 AM, John Dennis wrote: > On 07/15/2009 07:10 AM, Stephen Gallagher wrote: >> I am attaching a patch to this email that corrects these issues (as they >> are so minor that I figured I'd save you the trouble). Please review >> them yourself, and if you approve of them as-is, I will squash it into >> your patch and push it. > > Thank you Stephen, looks good, please squash and push. Thanks. Ack 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/ iEYEARECAAYFAkpd0jcACgkQeiVVYja6o6OoWwCfVF5ioEG31ndYB5b40ySkGPrD bK8AmgLKhHyrk+Z2LImW4OL3byr03vfr =9mJU -----END PGP SIGNATURE----- From rcritten at redhat.com Wed Jul 15 13:00:19 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 15 Jul 2009 09:00:19 -0400 Subject: [Freeipa-devel] [PATCH] 236 Have RPC catch HTTP errors In-Reply-To: <1247325047.6317.226.camel@localhost.localdomain> References: <4A57A3BC.5000403@redhat.com> <1247325047.6317.226.camel@localhost.localdomain> Message-ID: <4A5DD2E3.8010209@redhat.com> Simo Sorce wrote: > On Fri, 2009-07-10 at 16:25 -0400, Rob Crittenden wrote: >> Catch and handle HTTP error conditions in the command-line. >> >> I ran into this when I would get a valid ticket, then blow away the IPA >> instance and create a new one but try to use the ipa command before >> re-running kinit. > > 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 Jul 15 13:00:25 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 15 Jul 2009 09:00:25 -0400 Subject: [Freeipa-devel] [PATCH] 237 Enable replication with a dogtag CA In-Reply-To: <1247325189.6317.227.camel@localhost.localdomain> References: <4A57A42F.5050808@redhat.com> <1247325189.6317.227.camel@localhost.localdomain> Message-ID: <4A5DD2E9.10100@redhat.com> Simo Sorce wrote: > On Fri, 2009-07-10 at 16:27 -0400, Rob Crittenden wrote: >> This patch enables one to create replicas when using dogtag as the CA. >> >> This just sort of gets things to the point of working, a lot of work >> is >> left to be done to handle errors better and to better identify the >> type >> of IPA system being used (self-signed NSS CA, dogtag CA or external >> CA >> that provides PKCS#12 files to IPA). >> >> I've only tested this with a single replica so far. > > 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 mnagy at redhat.com Wed Jul 15 13:21:04 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 15 Jul 2009 15:21:04 +0200 Subject: [Freeipa-devel] [PATCH] Set of patches to enable DNS work in replica Message-ID: <20090715152104.38042d30@wolverine.englab.brq.redhat.com> Patches are attached. Now we also provide an option --setup-dns to ipa-replica-install that will set up BIND, but will only create the zone if it didn't exist before. One patch also introduces reverse zone, which we didn't have before. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-setup-dns-option.-It-will-replace-setup-bind.patch Type: text/x-patch Size: 4097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-a-reverse-zone-with-server-s-PTR-record.patch Type: text/x-patch Size: 4293 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Make-setup-dns-work-on-replica-installation.patch Type: text/x-patch Size: 7599 bytes Desc: not available URL: From rcritten at redhat.com Wed Jul 15 13:39:28 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 15 Jul 2009 09:39:28 -0400 Subject: [Freeipa-devel] [PATCH] Set of patches to enable DNS work in replica In-Reply-To: <20090715152104.38042d30@wolverine.englab.brq.redhat.com> References: <20090715152104.38042d30@wolverine.englab.brq.redhat.com> Message-ID: <4A5DDC10.8080405@redhat.com> Martin Nagy wrote: > Patches are attached. Now we also provide an option --setup-dns to > ipa-replica-install that will set up BIND, but will only create the zone > if it didn't exist before. One patch also introduces reverse zone, > which we didn't have before. > > Martin > A couple of questions. So when installing a replica a bind instance isn't required? In other words, you could have a mixed environment where some IPA servers do DNS and others don't? Looks like the reverse_host and reverse_subnet code you are adding to bindinstance.py won't work on IPv6. Does --setup-bind do anything at all now? 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 jdennis at redhat.com Wed Jul 15 13:44:46 2009 From: jdennis at redhat.com (John Dennis) Date: Wed, 15 Jul 2009 09:44:46 -0400 Subject: [Freeipa-devel] timestamps Message-ID: <4A5DDD4E.6080506@redhat.com> Dmitri and I were discussing the storage of timestamps yesterday. My understanding of best practice (after much investigation) is to store timestamps in UTC paired with the current zoneinfo (important clarification, *not* the local offset, rather the *zoneinfo* [1]). This is the only unambiguous way be able to convert to/from local time in the past, now, and in the future. It also has the nice property of preserving the timestamp in a normalized form (UTC) which can be compared to other timestamps and/or presented in another zone (in the past, now, or in the future). However one problem I encountered as I tried to implement this was I could not find a standard library which returned the current zoneinfo. glibc and other posix libraries provide offsets and/or the TZ value (which really just an offset in wolf's clothing). I have a very clear understanding of how to retrieve the zoneinfo in a Linux environment. In fact I found a number of examples of code which had their own private function to query the zoneinfo. The downside to this is it is OS specific (but it's not too terrible to tweak it to a particular OS). So I have a few questions: * Jakob, in the policy engine when you wrote the code which deals with time evaluation how did you handle the zone issue? * Have others needed to deal with timestamps and if so what has been your methodology? * Is anyone aware of a library which can retrieve the zoneinfo in a portable manner? [1] If you're wondering why offsets are evil and why zoneinfo was invented it's because timezones are notoriously fluid, they are the result of political decisions and vary in unpredictable ways (in both the geographic domain and the time domain). The only unambiguous way to know what a proper offset is to know a geographic location at a specific moment in history, hence the introduction of the zoneinfo database which allows one to query the offset based on location and moment in time. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mnagy at redhat.com Wed Jul 15 13:56:33 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 15 Jul 2009 15:56:33 +0200 Subject: [Freeipa-devel] [PATCH] Set of patches to enable DNS work in replica In-Reply-To: <4A5DDC10.8080405@redhat.com> References: <20090715152104.38042d30@wolverine.englab.brq.redhat.com> <4A5DDC10.8080405@redhat.com> Message-ID: <20090715155633.6396c925@wolverine.englab.brq.redhat.com> On Wed, 15 Jul 2009 09:39:28 -0400, Rob Crittenden wrote: > Martin Nagy wrote: > > Patches are attached. Now we also provide an option --setup-dns to > > ipa-replica-install that will set up BIND, but will only create the > > zone if it didn't exist before. One patch also introduces reverse > > zone, which we didn't have before. > > > > Martin > > > > A couple of questions. > > So when installing a replica a bind instance isn't required? In other > words, you could have a mixed environment where some IPA servers do > DNS and others don't? Yes, you can. This is deliberate. > Looks like the reverse_host and reverse_subnet code you are adding to > bindinstance.py won't work on IPv6. Uhm, no, good point. I'll try to figure something out. > Does --setup-bind do anything at all now? No, good catch. I wanted to leave it there so QE can transit peacefully. I'll change dest from 'setup_bind' to 'setup_dns' so the effect of both options is the same. Martin From dpal at redhat.com Wed Jul 15 15:07:01 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 15 Jul 2009 11:07:01 -0400 Subject: [Freeipa-devel] timestamps In-Reply-To: <4A5DDD4E.6080506@redhat.com> References: <4A5DDD4E.6080506@redhat.com> Message-ID: <4A5DF095.8030308@redhat.com> John Dennis wrote: > Dmitri and I were discussing the storage of timestamps yesterday. My > understanding of best practice (after much investigation) is to store > timestamps in UTC paired with the current zoneinfo (important > clarification, *not* the local offset, rather the *zoneinfo* [1]). > This is the only unambiguous way be able to convert to/from local time > in the past, now, and in the future. It also has the nice property of > preserving the timestamp in a normalized form (UTC) which can be > compared to other timestamps and/or presented in another zone (in the > past, now, or in the future). > > However one problem I encountered as I tried to implement this was I > could not find a standard library which returned the current zoneinfo. > glibc and other posix libraries provide offsets and/or the TZ value > (which really just an offset in wolf's clothing). I have a very clear > understanding of how to retrieve the zoneinfo in a Linux environment. > In fact I found a number of examples of code which had their own > private function to query the zoneinfo. The downside to this is it is > OS specific (but it's not too terrible to tweak it to a particular OS). > > So I have a few questions: > > * Jakob, in the policy engine when you wrote the code which deals with > time evaluation how did you handle the zone issue? > > * Have others needed to deal with timestamps and if so what has been > your methodology? > > * Is anyone aware of a library which can retrieve the zoneinfo in a > portable manner? > > [1] If you're wondering why offsets are evil and why zoneinfo was > invented it's because timezones are notoriously fluid, they are the > result of political decisions and vary in unpredictable ways (in both > the geographic domain and the time domain). The only unambiguous way > to know what a proper offset is to know a geographic location at a > specific moment in history, hence the introduction of the zoneinfo > database which allows one to query the offset based on location and > moment in time. > Yes we talked about this with John the other day and John broght to my attention the issues related to time. I promised to think about it more. After some more thinking and discussions on IRC with Simo, here are some of my thoughts. I am looking at the problem from the point of view of the ELAPI interface. When the event is created by the application it should have a time stamp. But what it should be? Let us look at what can happen with the event. The event can be : a) Written to remote or local file b) Sent to syslog c) Sent over to central location (audit storage) d) Inserted into a database ... And one event can be sent to several of those destinations at the same time. John above suggests that the event then should have two parts of information: UTC time and time zone info. This information is enough to be able to convert the time back and forth and compare it. But it my opinion one significant piece is missing for such conversion - the locale. I guess the question I have is why would we need to convert it? If the event has UTC and all other events have UTC then they can easily compared and related to each other. Time zone info is not needed for such comparison. So the timezone info is needed only if we want to convert the time on the central server to some local representation. Hm... and why would we want to spend cycles doing this conversion on the central server anyways? Why not just sent as a separate field the local time in the format related to locale defined on the machine? Such approach has a lot of benefits: a) You do not need platform dependent code to get time zone b) You do not need to deliver locale to the central server c) You do not need to spend cycles on the central server doing conversions d) You can use the local time as is in the local logs (as syslog does) The downside is that the local time takes some space in the event. Well it is not going to be significantly longer than the time zone information, so I do not see it to be a big issue. One may argue it is redundant information. Well, yes, so what? It is very convenient information though and allows us to avoid a lot of unnecessary complexity. I took a look at the Windows event log - they do not store the time zone, they store just UTC which makes perfect sense for me. I view the local time stamp as a very convenient field for administrators to take a look at when they are analyzing the logs. There is not need to parse it or convert it. It is just for presentation but it is originated from the machine it came (factoring it locale). If admin would find this field confusing or not needed we would always have an option to not display it. Also the RSA Authentication manager logs has two time stamps like that: local time and UTC time in one event record. I have not heard any complaints from the customers (in 10 years) about this approach but on the contrary administrators find this approach sufficient and useful. So based on this I do not see a real reason to over engineer the ELAPI and try to read time zone information and be able to do conversion of the time - IMO it is not needed. The local time stamp and the UTC time provide sufficient information for the use cases ELAPI has to deal with. So unless there is a strong argument for doing it differently I would continue with the "local" + "UTC approach. I am open for discussion though :) -- 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 Wed Jul 15 15:21:13 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 15 Jul 2009 11:21:13 -0400 Subject: [Freeipa-devel] Re: [PATCH] COLLECTION patches resending In-Reply-To: <4A5B2A02.3000908@redhat.com> References: <4A567092.9050908@redhat.com> <20090710103116.GF29325@localhost.localdomain> <4A57511B.1090204@redhat.com> <4A5762CA.4060606@redhat.com> <20090710211551.GB22416@localhost.localdomain> <4A57B2A2.8070703@redhat.com> <4A5B2430.9000502@redhat.com> <4A5B2A02.3000908@redhat.com> Message-ID: <4A5DF3E9.6010002@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/13/2009 08:35 AM, Dmitri Pal wrote: > Stephen Gallagher wrote: >> On 07/10/2009 05:29 PM, Dmitri Pal wrote: >>>>>> These unsigned values are the size of the internal stack or depth >> level. >>>>>> They need to always be positive this is why they are unsigned. >>>>>> I do not want obfuscate the error by preventing them to go below 0. >>>>>> If it goes the program will crash and we will see the problem. >>>>>> >>>> Are you sure that the program will crash or maybe just override some >>>> random memory? If you use a macro you can call abort() if the value is >>>> 0 and the program will definitely exit. >>>> >>>> >>> It will become MAX unsigned. Since the variable is used as an index to >>> the array it will point to some unrelated memory and program will get >>> memory violation. >> >> You cannot and MUST NOT rely on a "memory violation", since it's >> possible for you to be working on a machine with copious amounts of >> memory, where max unsigned might still be addressable (see PAE kernels >> for examples of this). Sumit is correct, you need to do this with a >> macro that calls abort() if a program attempts to decrement the stack >> counter when it's already zero. >> > I do not agree with your argument and I do not like the abort(). > IMO it is a theoretical discussion anyways. We are talking about bad > things happening if there is a bug. > The whole point is not to hide it if it is there. But the bigger point > is not to have a bug. > The latest patch addresses all the issues with "--". > > If you look at the code closely you will see that: > 1) In walk_items the depth is incremented at the entry to the function > and decremented at exit - no check is needed there. > 2) In the iterator the check happens at the top of the loop and at the > beginning the stack_size is set to 1. > 3) The only problem was in the iterate_up function that is now reworked > with the second patch. > > Please review and ack/nack. > > Thanks > Dmitri Ack 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/ iEYEARECAAYFAkpd8+MACgkQeiVVYja6o6PveQCbBNiv+tH3DEKU4pZxglPS2+RT A4UAoI3BRGt1GMXpIN1Njl95Bz+Vs7yz =LlxN -----END PGP SIGNATURE----- From ssorce at redhat.com Wed Jul 15 15:58:13 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 15 Jul 2009 15:58:13 +0000 Subject: [Freeipa-devel] timestamps In-Reply-To: <4A5DF095.8030308@redhat.com> References: <4A5DDD4E.6080506@redhat.com> <4A5DF095.8030308@redhat.com> Message-ID: <1247673493.29458.92.camel@localhost.localdomain> Dmitri Pal wrote: > Why not just sent as a separate field the local > time in the format related to locale defined on the machine? > Such approach has a lot of benefits: > > a) You do not need platform dependent code to get time zone > b) You do not need to deliver locale to the central server > c) You do not need to spend cycles on the central server doing conversions > d) You can use the local time as is in the local logs (as syslog does) Uhmmm I think using *localized* local time has one crucial problem, you don't have a way to present what was the local time in other locales. Take an example of a server in China, this would be a local time (if you can't read it it is because you don't have the right fonts, I installed cjkunifonts-uming.noarch): 2009? 07? 01? ??? 11:35:25 EDT Now if I have admins on a 24x7 basis it means 2 shifts a day will be base in countries were people most probably don't speak chinese. I am not even able to tell reliably given a random locale if it is Jan 7th or Jul 1st. (I know it is July first in this case, that's not the point :-) You can certainly ignore the local time in the logs, but then you do not have enough information to convert UTC to the local time in your language (say spanish: "mi? jul 15 11:42:05 EDT 2009", not the month is not present in numbers even.) So even if you store the local time you should still store the timezone info. John Dennis wrote: > > Dmitri and I were discussing the storage of timestamps yesterday. My > > understanding of best practice (after much investigation) is to store > > timestamps in UTC paired with the current zoneinfo (important > > clarification, *not* the local offset, rather the *zoneinfo* [1]). Now on this argument that you must store the zoneinfo and *not* the displacement. I think in this case this rule is not relevant. You want to know the zoneinfo when you have a random daytime and you want to stick to it *within* the zoneinfo. Example: 12:00 in NYC Without a date the zoneinfo is crucial to be able to determine what is 12:00 in NYC on any given day. But in logs this is not important, we have the exact UTC date at the time of the event and the displacement *at the time of the event*. It doesn't matter if we check this log now or in 1000 years. The displacement *at the time of the event* do not change no matter what (unless you are into rewriting history :-). --- Conclusion: I think that UTC + displacement is perfectly fine and conveys all the data you need without adding unnecessary localized output that is relevant only to a fraction of the people that may be actually analyzing logs. You may *also* add the localized local time, but you must add the current local offset as well (in numbers like: -400 or +530 not in letters as in EDT) or the zoneinfo. Given zoneinfo is too difficult to get reliably the numeric time displacement is fine. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Wed Jul 15 15:58:23 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 15 Jul 2009 11:58:23 -0400 Subject: [Freeipa-devel] [PATCH] INI Refactoring code a bit Message-ID: <4A5DFC9F.2030800@redhat.com> The inefficient function from ini_config.c is replaced with the function provided now by the collection interface. Also the unit test is updated to run from the local directory. -- 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-INI-Refactoring-code-a-bit.patch Type: text/x-patch Size: 6056 bytes Desc: not available URL: From ssorce at redhat.com Wed Jul 15 16:05:39 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 15 Jul 2009 12:05:39 -0400 Subject: [Freeipa-devel] [PATCH] add infrastructure to handle new backend targets In-Reply-To: <20090715125300.GD3219@localhost.localdomain> References: <20090715125300.GD3219@localhost.localdomain> Message-ID: <1247673939.29458.95.camel@localhost.localdomain> On Wed, 2009-07-15 at 14:53 +0200, Sumit Bose wrote: > Hi, > > this patch adds the handling of the new backend targets access (a.k.a. > authorization) and chpass to the data provider infrastructure. I have > changed the way the current id and auth targets are handled to avoid > multiple loading of a single backend and to avoid massive code > duplication. This patch touches the backends only where necessary. This > means that the sssd can be complied successfully and id and auth are > working as expected (at least in my test :-). The access target is set > to a default permit target. I will provide a patch for the backends if > this patch and the new scheme of handling the backends and their targets > is accepted. Ack, architecture looks good to me, and a general look at the code seem ok. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Wed Jul 15 17:29:55 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 15 Jul 2009 13:29:55 -0400 Subject: [Freeipa-devel] timestamps In-Reply-To: <1247673493.29458.92.camel@localhost.localdomain> References: <4A5DDD4E.6080506@redhat.com> <4A5DF095.8030308@redhat.com> <1247673493.29458.92.camel@localhost.localdomain> Message-ID: <4A5E1213.6000506@redhat.com> Simo Sorce wrote: > Dmitri Pal wrote: > >> Why not just sent as a separate field the local >> time in the format related to locale defined on the machine? >> Such approach has a lot of benefits: >> >> a) You do not need platform dependent code to get time zone >> b) You do not need to deliver locale to the central server >> c) You do not need to spend cycles on the central server doing conversions >> d) You can use the local time as is in the local logs (as syslog does) >> > > Uhmmm I think using *localized* local time has one crucial problem, you > don't have a way to present what was the local time in other locales. > > Take an example of a server in China, this would be a local time > (if you can't read it it is because you don't have the right fonts, I > installed cjkunifonts-uming.noarch): > > 2009? 07? 01? ??? 11:35:25 EDT > > Now if I have admins on a 24x7 basis it means 2 shifts a day will be > base in countries were people most probably don't speak chinese. > I am not even able to tell reliably given a random locale if it is Jan > 7th or Jul 1st. > (I know it is July first in this case, that's not the point :-) > > You can certainly ignore the local time in the logs, but then you do not > have enough information to convert UTC to the local time in your > language (say spanish: "mi? jul 15 11:42:05 EDT 2009", not the month is > not present in numbers even.) > > So even if you store the local time you should still store the timezone > info. > > > Makes sense but rises another interesting issue with the whole log collection and aggregation logic. Besides the event we also collect log files. It might be that the application creates its log file in local locale (including time stamp). How we would be able to index and co-relate log files potentially written in different languages or with elements that are language specific. I think the only good answer to that is to tell IT admins to configure the logging applications to use a specific locale while logging. So this means that ELAPI configuration (if the log file is created using it) should support an override locale that will be used for things like timestamps. Such approach would allow to configure systems to emit consistently readable logs. If admins what to see all the local dates in Chinese then they would be able to configure that. So to summarize this part: a) I still see a value in local time stamp but there should be a way to configure specific locale b) This local time stamp presence should be configurable > John Dennis wrote: > >>> Dmitri and I were discussing the storage of timestamps yesterday. My >>> understanding of best practice (after much investigation) is to store >>> timestamps in UTC paired with the current zoneinfo (important >>> clarification, *not* the local offset, rather the *zoneinfo* [1]). >>> > > Now on this argument that you must store the zoneinfo and *not* the > displacement. > > I think in this case this rule is not relevant. > > You want to know the zoneinfo when you have a random daytime and you > want to stick to it *within* the zoneinfo. Example: 12:00 in NYC > Without a date the zoneinfo is crucial to be able to determine what is > 12:00 in NYC on any given day. > > But in logs this is not important, we have the exact UTC date at the > time of the event and the displacement *at the time of the event*. > It doesn't matter if we check this log now or in 1000 years. The > displacement *at the time of the event* do not change no matter what > (unless you are into rewriting history :-). > > --- > Conclusion: > > I think that UTC + displacement is perfectly fine and conveys all the > data you need without adding unnecessary localized output that is > relevant only to a fraction of the people that may be actually analyzing > logs. > > You may *also* add the localized local time, but you must add the > current local offset as well (in numbers like: -400 or +530 not in > letters as in EDT) or the zoneinfo. > Given zoneinfo is too difficult to get reliably the numeric time > displacement is fine. > > The problem will occur for the time zones that change its offset due to some political decisions (which happens all the time -more than once per year). The tools that will be used in future (on the server) will not have enough information (from the event) to calculate local time at the moment of the event creation using just offset. To do the right conversion they need to have the right time zone info so that they can lookup the history and do the proper conversion. With just offset the error will be the difference between the time zone offset at the moment of the event creation and current timezone offset. If the time stamp is written once at the creation (in the locale the admin chooses) we avoid these problems altogether. > Simo. > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Wed Jul 15 18:06:21 2009 From: jdennis at redhat.com (John Dennis) Date: Wed, 15 Jul 2009 14:06:21 -0400 Subject: [Freeipa-devel] timestamps In-Reply-To: <1247673493.29458.92.camel@localhost.localdomain> References: <4A5DDD4E.6080506@redhat.com> <4A5DF095.8030308@redhat.com> <1247673493.29458.92.camel@localhost.localdomain> Message-ID: <4A5E1A9D.1090209@redhat.com> On 07/15/2009 11:58 AM, Simo Sorce wrote: > Dmitri Pal wrote: > Uhmmm I think using *localized* local time has one crucial problem, you > don't have a way to present what was the local time in other locales. Simo is exactly correct, this is the essential problem, you can't convert the timestamp to another locale which can be very valuable when an organization has sites in multiple locales. Also, don't look to Windows for best practices. Windows has a long history of screwing up time/date calculations. > Conclusion: > > I think that UTC + displacement is perfectly fine In the limited case of log timestamps I agree with Simo UTC + *numeric* displacement is fine. It's not adequate in other scenarios. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Wed Jul 15 18:38:54 2009 From: jdennis at redhat.com (John Dennis) Date: Wed, 15 Jul 2009 14:38:54 -0400 Subject: [Freeipa-devel] timestamps In-Reply-To: <4A5E1213.6000506@redhat.com> References: <4A5DDD4E.6080506@redhat.com> <4A5DF095.8030308@redhat.com> <1247673493.29458.92.camel@localhost.localdomain> <4A5E1213.6000506@redhat.com> Message-ID: <4A5E223E.6080401@redhat.com> On 07/15/2009 01:29 PM, Dmitri Pal wrote: > Makes sense but rises another interesting issue with the whole log > collection and aggregation logic. > Besides the event we also collect log files. It might be that the > application creates its log file in local locale (including time stamp). > How we would be able to index and co-relate log files potentially > written in different languages or with elements that are language specific. > I think the only good answer to that is to tell IT admins to configure > the logging applications to use a specific locale while logging. > So this means that ELAPI configuration (if the log file is created using > it) should support an override locale that will be used for things like > timestamps. > Such approach would allow to configure systems to emit consistently > readable logs. If admins what to see all the local dates in Chinese then > they would be able to configure that. We can't fix broken applications. If they log timestamps without any timezone information it's a bug and they need to fix it. However we can assure we always do the right thing. According to my watch :-) it's 2009, almost a decade after the Y2K debacle, programmers have hopefully learned some lessons in the interim about time/date values. We have the ISO 8601 standard for time/date representation. Not everything is using 8601 yet, but it's getting better. FWIW, in everything I've coded for IPA I'm using ISO 8601 representations. > So to summarize this part: > > a) I still see a value in local time stamp but there should be a way to > configure specific locale I don't see any value in it. The local time stamp is trivially derivable from UTC + offset. Adding another timestamp is just redundant information. Basically you have two choices, you can store UTC+offset or you can store 8601+offset, the only difference is whether you trivially convert from UTC to local or from local to UTC (it's a difference only in the basis of the value). These links have great resources: http://www.exit109.com/~ghealton/y2k/yrexamples.html http://www.exit109.com/~ghealton/.dates.html -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Wed Jul 15 18:48:43 2009 From: jdennis at redhat.com (John Dennis) Date: Wed, 15 Jul 2009 14:48:43 -0400 Subject: [Freeipa-devel] timestamps In-Reply-To: <4A5E1A9D.1090209@redhat.com> References: <4A5DDD4E.6080506@redhat.com> <4A5DF095.8030308@redhat.com> <1247673493.29458.92.camel@localhost.localdomain> <4A5E1A9D.1090209@redhat.com> Message-ID: <4A5E248B.50505@redhat.com> On 07/15/2009 02:06 PM, John Dennis wrote: > In the limited case of log timestamps I agree with Simo UTC + *numeric* > displacement is fine. Or better yet, use 8601 Here is another good link which is a quick read: http://www.w3.org/TR/NOTE-datetime -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Wed Jul 15 18:55:57 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 15 Jul 2009 18:55:57 +0000 Subject: [Freeipa-devel] timestamps In-Reply-To: <4A5E248B.50505@redhat.com> References: <4A5DDD4E.6080506@redhat.com> <4A5DF095.8030308@redhat.com> <1247673493.29458.92.camel@localhost.localdomain> <4A5E1A9D.1090209@redhat.com> <4A5E248B.50505@redhat.com> Message-ID: <1247684157.29458.98.camel@localhost.localdomain> On Wed, 2009-07-15 at 14:48 -0400, John Dennis wrote: > On 07/15/2009 02:06 PM, John Dennis wrote: > > > In the limited case of log timestamps I agree with Simo UTC + *numeric* > > displacement is fine. > > Or better yet, use 8601 > > Here is another good link which is a quick read: > http://www.w3.org/TR/NOTE-datetime Ah I was not implying a format when I said UTC, any format that is a recognized standard is fine by me. I can only note that "number of sencods since X" maybe a little easier to parse from a text field that 8601, but I am in no way in love with that way to represent a date in time. As long as the date format represents UTC+offset I am fine. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Wed Jul 15 19:05:48 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 15 Jul 2009 15:05:48 -0400 Subject: [Freeipa-devel] timestamps In-Reply-To: <4A5E1213.6000506@redhat.com> References: <4A5DDD4E.6080506@redhat.com> <4A5DF095.8030308@redhat.com> <1247673493.29458.92.camel@localhost.localdomain> <4A5E1213.6000506@redhat.com> Message-ID: <4A5E288C.8030102@redhat.com> Hi We had a phone conversation with Simo and came to agreement. He is looking at the problem from the "computer" point of view, I am trying to look from the perspective of the user (admin) who looks at the result of the search against the log data. >From computer point of view UTC + offset is needed for the use case I was not thinking about: Give me all the login attempts after 6PM local time for last month for servers all over the world. Since such query would require comparison done in local time the offset is crucial for such use case. But Simo agrees that for the user looking at the log results it might be important to see the full local time stamp in the format "Wed Jul 15 13:51:51 EDT 2009" or similar. The timezone in this case may be a valuable hint to the administrator. Such time stamp can't be generated from UTC + offset on the central server. The problem with such time stamp is the locale. If the time stamp is logged in the locale of the machine it might not be readable to the administrator and thus be useless. I suggested that we might be able to configure an overriding locale without changing the process' locale. I think it is possible but I might be wrong. I will investigate and come back with more details. -- 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 Wed Jul 15 19:07:08 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 15 Jul 2009 15:07:08 -0400 Subject: [Freeipa-devel] timestamps In-Reply-To: <1247684157.29458.98.camel@localhost.localdomain> References: <4A5DDD4E.6080506@redhat.com> <4A5DF095.8030308@redhat.com> <1247673493.29458.92.camel@localhost.localdomain> <4A5E1A9D.1090209@redhat.com> <4A5E248B.50505@redhat.com> <1247684157.29458.98.camel@localhost.localdomain> Message-ID: <4A5E28DC.503@redhat.com> Simo Sorce wrote: > On Wed, 2009-07-15 at 14:48 -0400, John Dennis wrote: > >> On 07/15/2009 02:06 PM, John Dennis wrote: >> >> >>> In the limited case of log timestamps I agree with Simo UTC + *numeric* >>> displacement is fine. >>> >> Or better yet, use 8601 >> >> Here is another good link which is a quick read: >> http://www.w3.org/TR/NOTE-datetime >> > > Ah I was not implying a format when I said UTC, any format that is a > recognized standard is fine by me. > > I can only note that "number of sencods since X" maybe a little easier > to parse from a text field that 8601, but I am in no way in love with > that way to represent a date in time. As long as the date format > represents UTC+offset I am fine. > > Simo. > > Agree. UTC time is just a number. Offset probably a number too. -- 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 Wed Jul 15 19:20:17 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 15 Jul 2009 15:20:17 -0400 Subject: [Freeipa-devel] [PATCH] COLLECTION Add remove item functions Message-ID: <4A5E2BF1.30004@redhat.com> COLLECTION Add remove item functions The remove functions extract and remove items, they act differently from the way the delete_property function works. The new functions allow deletion with the disposition while the delete_property only deletes specified property. The delete_property function is left as is since there are some use cases when it is more efficient to use it rather than new remove_item_xxx ones. -- 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-COLLECTION-Add-remove-item-functions.patch Type: text/x-patch Size: 27315 bytes Desc: not available URL: From jdennis at redhat.com Wed Jul 15 19:25:46 2009 From: jdennis at redhat.com (John Dennis) Date: Wed, 15 Jul 2009 15:25:46 -0400 Subject: [Freeipa-devel] timestamps In-Reply-To: <4A5E288C.8030102@redhat.com> References: <4A5DDD4E.6080506@redhat.com> <4A5DF095.8030308@redhat.com> <1247673493.29458.92.camel@localhost.localdomain> <4A5E1213.6000506@redhat.com> <4A5E288C.8030102@redhat.com> Message-ID: <4A5E2D3A.2080309@redhat.com> On 07/15/2009 03:05 PM, Dmitri Pal wrote: > Hi > > We had a phone conversation with Simo and came to agreement. > He is looking at the problem from the "computer" point of view, I am > trying to look from the perspective of the user (admin) who looks at the > result of the search against the log data. > > From computer point of view UTC + offset is needed for the use case I > was not thinking about: > Give me all the login attempts after 6PM local time for last month for > servers all over the world. Absolutely, I was trying to say this before, but I guess I wasn't clear. > > Since such query would require comparison done in local time the offset > is crucial for such use case. > > But Simo agrees that for the user looking at the log results it might be > important to see the full local time stamp in the format "Wed Jul 15 > 13:51:51 EDT 2009" or similar. > The timezone in this case may be a valuable hint to the administrator. > Such time stamp can't be generated from UTC + offset on the central server. > The problem with such time stamp is the locale. If the time stamp is > logged in the locale of the machine it might not be readable to the > administrator and thus be useless. This is one of the primary reasons why ISO 8601 was invented and why what is cited above is deprecated and discouraged. If someone wants to view a timestamp in their locale because they prefer the locale's formatting over the 8601 formatting then the proper procedure is to take the 8601 timestamp and format it according to the preferred locale during *presentation*. This is a rendering issue, *not* a data issue. Never under any circumstances should timestamps be stored in locale specific formats. > I suggested that we might be able to configure an overriding locale > without changing the process' locale. > I think it is possible but I might be wrong. I will investigate and come > back with more details. > -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Jul 15 21:34:12 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 15 Jul 2009 17:34:12 -0400 Subject: [Freeipa-devel] [PATCH] COLLECTION Improving searches Message-ID: <4A5E4B54.2020706@redhat.com> Addressing ticket https://fedorahosted.org/sssd/ticket/71 -- 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-COLLECTION-Improving-searches.patch Type: text/x-patch Size: 6637 bytes Desc: not available URL: From mnagy at redhat.com Thu Jul 16 06:04:44 2009 From: mnagy at redhat.com (Martin Nagy) Date: Thu, 16 Jul 2009 08:04:44 +0200 Subject: [Freeipa-devel] [PATCH] Set of patches to enable DNS work in replica In-Reply-To: <4A5DDC10.8080405@redhat.com> References: <20090715152104.38042d30@wolverine.englab.brq.redhat.com> <4A5DDC10.8080405@redhat.com> Message-ID: <20090716080444.6063f762@wolverine.englab.brq.redhat.com> On Wed, 15 Jul 2009 09:39:28 -0400, Rob Crittenden wrote: > Martin Nagy wrote: > > Patches are attached. Now we also provide an option --setup-dns to > > ipa-replica-install that will set up BIND, but will only create the > > zone if it didn't exist before. One patch also introduces reverse > > zone, which we didn't have before. > > > > Martin > > > > A couple of questions. > > So when installing a replica a bind instance isn't required? In other > words, you could have a mixed environment where some IPA servers do > DNS and others don't? > > Looks like the reverse_host and reverse_subnet code you are adding to > bindinstance.py won't work on IPv6. I took a look at the code in ipa-server-install and it seems that it doesn't have to work on IPv6. If you look on resolve_host() in there (and I practically copied almost the same code for ipa-replica-install), you'll notice that it uses the socket.gethostbyname() function. This function, according to [1] does not support IPv6. We probably should think about reworking the code to support IPv6 and ideally also test it. But at least for now, I think the code for zones is good enough, given that we don't support IPv6. Martin [1] http://docs.python.org/library/socket.html#socket.gethostbyname From sgallagh at redhat.com Thu Jul 16 10:59:26 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 16 Jul 2009 06:59:26 -0400 Subject: [Freeipa-devel] [PATCH] COLLECTION Improving searches In-Reply-To: <4A5E4B54.2020706@redhat.com> References: <4A5E4B54.2020706@redhat.com> Message-ID: <4A5F080E.6040401@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/15/2009 05:34 PM, Dmitri Pal wrote: > Addressing ticket https://fedorahosted.org/sssd/ticket/71 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel You've added a check in col_find_item_and_do() for a trailing '.', which is illegal, but you didn't add a corresponding unit test to verify that this is behaving as expected. Please add that unit test, then this will be an 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/ iEYEARECAAYFAkpfCAkACgkQeiVVYja6o6O/lACfaabQZWLNQZTQYx1LELrfWU/Z aiUAoKChUHnS0BFgqxBlqGHM4PTMby2P =VaU0 -----END PGP SIGNATURE----- From dpal at redhat.com Thu Jul 16 13:29:28 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 16 Jul 2009 09:29:28 -0400 Subject: [Freeipa-devel] [PATCH] COLLECTION Improving searches In-Reply-To: <4A5F080E.6040401@redhat.com> References: <4A5E4B54.2020706@redhat.com> <4A5F080E.6040401@redhat.com> Message-ID: <4A5F2B38.5050502@redhat.com> Stephen Gallagher wrote: > On 07/15/2009 05:34 PM, Dmitri Pal wrote: > > Addressing ticket https://fedorahosted.org/sssd/ticket/71 > > > > > ------------------------------------------------------------------------ > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > You've added a check in col_find_item_and_do() for a trailing '.', which > is illegal, but you didn't add a corresponding unit test to verify that > this is behaving as expected. > > Please add that unit test, then this will be an ack. > Sure, what about other two patches? Anything needs to be corrected there? I would prefer to make changes in one pass if possible. Also the question is: since the patches are relatively small can I squash them together? I am not sure I want to do it but I wanted to ask anyways what the best approach is. _______________________________________________ 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 sgallagh at redhat.com Thu Jul 16 14:24:25 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 16 Jul 2009 10:24:25 -0400 Subject: [Freeipa-devel] [PATCH] COLLECTION Improving searches In-Reply-To: <4A5F2B38.5050502@redhat.com> References: <4A5E4B54.2020706@redhat.com> <4A5F080E.6040401@redhat.com> <4A5F2B38.5050502@redhat.com> Message-ID: <4A5F3819.4090405@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/16/2009 09:29 AM, Dmitri Pal wrote: > Stephen Gallagher wrote: >> On 07/15/2009 05:34 PM, Dmitri Pal wrote: >>> Addressing ticket https://fedorahosted.org/sssd/ticket/71 >> >> >>> ------------------------------------------------------------------------ >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> You've added a check in col_find_item_and_do() for a trailing '.', which >> is illegal, but you didn't add a corresponding unit test to verify that >> this is behaving as expected. >> >> Please add that unit test, then this will be an ack. >> > Sure, what about other two patches? > Anything needs to be corrected there? > I would prefer to make changes in one pass if possible. > Also the question is: since the patches are relatively small can I > squash them together? > I am not sure I want to do it but I wanted to ask anyways what the best > approach is. > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > The general rule we follow with patches is that it should be one patch per logical change. Only squash patches together if they are 100% codependent (i.e. Patch A depends on Patch B, but Patch B also depends on Patch A) I'll look at the other patches. Oddly they didn't show up in my email until about an hour ago. Strange routing glitch, I expect. - -- 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/ iEYEARECAAYFAkpfOBUACgkQeiVVYja6o6PXgQCfY7OMz8jgOMywc3WuQmN1Reg2 wccAoIIxcTLnqGWn3vkoOYZFPzIk+wAK =8N48 -----END PGP SIGNATURE----- From sgallagh at redhat.com Thu Jul 16 16:53:07 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 16 Jul 2009 12:53:07 -0400 Subject: [Freeipa-devel] [PATCH] Run ini_config unit test with "make check" Message-ID: <4A5F5AF3.70402@redhat.com> Run ini_config unit test with "make check" Also adds support for running ini_config_ut under a parallel build directory. -- 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-Run-ini_config-unit-test-with-make-check.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 Thu Jul 16 16:53:54 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 16 Jul 2009 12:53:54 -0400 Subject: [Freeipa-devel] [PATCH] INI Refactoring code a bit In-Reply-To: <4A5DFC9F.2030800@redhat.com> References: <4A5DFC9F.2030800@redhat.com> Message-ID: <4A5F5B22.3080709@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/15/2009 11:58 AM, Dmitri Pal wrote: > The inefficient function from ini_config.c is > replaced with the function provided now by the > collection interface. Also the unit test is updated > to run from the local directory. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/ iEYEARECAAYFAkpfWyIACgkQeiVVYja6o6NXWQCePQLr8JwPpmqdZ3Ous6Z8yFB9 504An2P01PVSNvowNxnS0OOuGH1OQlMF =boNl -----END PGP SIGNATURE----- From sgallagh at redhat.com Thu Jul 16 16:59:26 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 16 Jul 2009 12:59:26 -0400 Subject: [Freeipa-devel] [PATCH] Run libcollection unit tests with 'make check' Message-ID: <4A5F5C6E.1010308@redhat.com> $SUBJECT -- 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-Run-libcollection-unit-tests-with-make-check.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 Thu Jul 16 17:03:34 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 16 Jul 2009 13:03:34 -0400 Subject: [Freeipa-devel] [PATCH] COLLECTION Add remove item functions In-Reply-To: <4A5E2BF1.30004@redhat.com> References: <4A5E2BF1.30004@redhat.com> Message-ID: <4A5F5D66.5040403@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/15/2009 03:20 PM, Dmitri Pal wrote: > COLLECTION Add remove item functions > > The remove functions extract and remove > items, they act differently from the way > the delete_property function works. > The new functions allow deletion with > the disposition while the delete_property > only deletes specified property. > The delete_property function is left as is > since there are some use cases when it is > more efficient to use it rather than new > remove_item_xxx ones. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/ iEYEARECAAYFAkpfXWUACgkQeiVVYja6o6MecACbBS9cOldRS1yiCNS5Pqfard6Q Yw0AoIZnlHDmrGtphm6KP6foLgBis8UM =vjzc -----END PGP SIGNATURE----- From jdennis at redhat.com Thu Jul 16 17:45:37 2009 From: jdennis at redhat.com (John Dennis) Date: Thu, 16 Jul 2009 13:45:37 -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: <4A5F6741.3050800@redhat.com> On 06/29/2009 06:34 PM, Dmitri Pal wrote: > 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. No, the expression is: h = h * PRIME_1 ^ (*k - ' '); which has 3 expressions: h * PRIME_1 *k - ' ' and the exclusive-or of the two above expressions on the first iteration h is zero and the expression h * PRIME_1 evaluates to zero, but then that is exclusive-or'ed with *k - ' ' which is then assigned to h. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Thu Jul 16 20:23:38 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 16 Jul 2009 16:23:38 -0400 Subject: [Freeipa-devel] [PATCH] Run libcollection unit tests with 'make check' In-Reply-To: <4A5F5C6E.1010308@redhat.com> References: <4A5F5C6E.1010308@redhat.com> Message-ID: <4A5F8C4A.70503@redhat.com> Stephen Gallagher wrote: > $SUBJECT > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Ack. -- 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 Jul 16 20:25:13 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 16 Jul 2009 16:25:13 -0400 Subject: [Freeipa-devel] [PATCH] Run ini_config unit test with "make check" In-Reply-To: <4A5F5AF3.70402@redhat.com> References: <4A5F5AF3.70402@redhat.com> Message-ID: <4A5F8CA9.80108@redhat.com> Stephen Gallagher wrote: > Run ini_config unit test with "make check" > > Also adds support for running ini_config_ut under a parallel build > directory. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Ack. I will add a print statement before error return later. -- 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 Thu Jul 16 20:31:16 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 16 Jul 2009 16:31:16 -0400 Subject: [Freeipa-devel] [PATCH] INI Refactoring code a bit In-Reply-To: <4A5F5B22.3080709@redhat.com> References: <4A5DFC9F.2030800@redhat.com> <4A5F5B22.3080709@redhat.com> Message-ID: <4A5F8E14.30200@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/16/2009 12:53 PM, Stephen Gallagher wrote: > On 07/15/2009 11:58 AM, Dmitri Pal wrote: >> The inefficient function from ini_config.c is >> replaced with the function provided now by the >> collection interface. Also the unit test is updated >> to run from the local directory. > > > >> ------------------------------------------------------------------------ > >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Ack. > Pushed to master. _______________________________________________ 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/ iEYEARECAAYFAkpfjg8ACgkQeiVVYja6o6MY7wCfX/EZESqlUONFBqgOhW42ySCx JOIAoKLCWNfZWusKiPdBNdCSDDH/WC1b =lYgk -----END PGP SIGNATURE----- From sgallagh at redhat.com Thu Jul 16 20:31:47 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 16 Jul 2009 16:31:47 -0400 Subject: [Freeipa-devel] [PATCH] COLLECTION Add remove item functions In-Reply-To: <4A5F5D66.5040403@redhat.com> References: <4A5E2BF1.30004@redhat.com> <4A5F5D66.5040403@redhat.com> Message-ID: <4A5F8E33.80005@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/16/2009 01:03 PM, Stephen Gallagher wrote: > On 07/15/2009 03:20 PM, Dmitri Pal wrote: >> COLLECTION Add remove item functions > >> The remove functions extract and remove >> items, they act differently from the way >> the delete_property function works. >> The new functions allow deletion with >> the disposition while the delete_property >> only deletes specified property. >> The delete_property function is left as is >> since there are some use cases when it is >> more efficient to use it rather than new >> remove_item_xxx ones. > > > >> ------------------------------------------------------------------------ > >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Ack > Pushed to master. _______________________________________________ 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/ iEYEARECAAYFAkpfjjMACgkQeiVVYja6o6MAiwCdFmMTgoGd8hxvqBjFfxLM6etg n3IAnR4iD5dyiTuiz2qkaidiDFlr8zLK =+ics -----END PGP SIGNATURE----- From sgallagh at redhat.com Thu Jul 16 20:32:02 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 16 Jul 2009 16:32:02 -0400 Subject: [Freeipa-devel] [PATCH] Run libcollection unit tests with 'make check' In-Reply-To: <4A5F8C4A.70503@redhat.com> References: <4A5F5C6E.1010308@redhat.com> <4A5F8C4A.70503@redhat.com> Message-ID: <4A5F8E42.3040400@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/16/2009 04:23 PM, Dmitri Pal wrote: > Stephen Gallagher wrote: >> $SUBJECT >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > 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/ iEYEARECAAYFAkpfjkIACgkQeiVVYja6o6NTRgCgiv84/I1ixiASlq125huOdA45 KLEAoJcB9YD3bqS8dYvEmoJQEc2z+eOr =To9H -----END PGP SIGNATURE----- From sgallagh at redhat.com Thu Jul 16 20:32:12 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 16 Jul 2009 16:32:12 -0400 Subject: [Freeipa-devel] [PATCH] Run ini_config unit test with "make check" In-Reply-To: <4A5F8CA9.80108@redhat.com> References: <4A5F5AF3.70402@redhat.com> <4A5F8CA9.80108@redhat.com> Message-ID: <4A5F8E4C.1090809@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/16/2009 04:25 PM, Dmitri Pal wrote: > Stephen Gallagher wrote: >> Run ini_config unit test with "make check" >> >> Also adds support for running ini_config_ut under a parallel build >> directory. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Ack. I will add a print statement before error return later. > 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/ iEYEARECAAYFAkpfjkwACgkQeiVVYja6o6M2oACfeTxw1MOQ43R02DGxhAjiBHhX yZwAmwZurgXzp9z5GoOKv21Fm1GBskrj =GiZf -----END PGP SIGNATURE----- From jdennis at redhat.com Thu Jul 16 20:49:56 2009 From: jdennis at redhat.com (John Dennis) Date: Thu, 16 Jul 2009 16:49:56 -0400 Subject: [Freeipa-devel] [PATCH] initial commit of log watcher (lwatch) Message-ID: <4A5F9274.8080906@redhat.com> This is a big patch, sorry, but there just isn't a realistic way to develop a major piece of code into a working state given our checkin policy which requires peer review for every change, it's just easier to develop elsewhere and submit the working result. This is the basic framework for the client audit code, it produces an executable called lwatch. In it's default mode lwatch watches a set of (log) files. It understands how log files are rotated. When a log file reaches a modification threshold it's newly appended data is prepared for transport to the audit server. When the log file is rotated, created, renamed, etc. the appropriate actions take place. lwatch maintains it's persistent state in a sqlite database. You can start and stop lwatch and it self synchronizes based on what is in the database and what it finds in the file system. lwatch is also capable of listing every log under a directory root, this can be handy for initializing the set of log files to watch. lwatch can also dump in a pretty format the current state of the SQL database. lwatch is not completely finished, but it's been in reasonable working shape for a while now, but sitting in my own git repository, it's time to get into the project's repository. What it needs next is better configuration options and to link in the code for audit server transmission (coming soon). Just one note about the patch, it includes a trivial one line fix to dhash.h which was missing a const declaration. I realize that should have been in a separate patch, but it got included here. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Initial-commit-of-log-watching-code.patch Type: text/x-patch Size: 163452 bytes Desc: not available URL: From sgallagh at redhat.com Thu Jul 16 20:50:23 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 16 Jul 2009 16:50:23 -0400 Subject: [Freeipa-devel] [PATCHES][SSSD] Config monitoring patches In-Reply-To: <1246388023.25726.10.camel@localhost.localdomain> References: <4A421B00.8060907@redhat.com> <1246388023.25726.10.camel@localhost.localdomain> Message-ID: <4A5F928F.5080002@redhat.com> On 06/30/2009 02:53 PM, Simo Sorce wrote: > 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's review changes are incorporated into these new versions. Please re-review. I opted to just wait five seconds between retries for a total of 30 seconds. The progressive increase seemed like overkill, since I expect it to be very rare that someone would be manually moving the config file out of the way and then putting it back. -- 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 dpal at redhat.com Thu Jul 16 21:17:36 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 16 Jul 2009 17:17:36 -0400 Subject: [Freeipa-devel] [PATCH] COLLECTION Improving searches (resending) In-Reply-To: <4A5F3819.4090405@redhat.com> References: <4A5E4B54.2020706@redhat.com> <4A5F080E.6040401@redhat.com> <4A5F2B38.5050502@redhat.com> <4A5F3819.4090405@redhat.com> Message-ID: <4A5F98F0.9000806@redhat.com> Stephen Gallagher wrote: > On 07/16/2009 09:29 AM, Dmitri Pal wrote: > > Stephen Gallagher wrote: > >> On 07/15/2009 05:34 PM, Dmitri Pal wrote: > >>> Addressing ticket https://fedorahosted.org/sssd/ticket/71 > >> > >>> > ------------------------------------------------------------------------ > >>> _______________________________________________ > >>> Freeipa-devel mailing list > >>> Freeipa-devel at redhat.com > >>> https://www.redhat.com/mailman/listinfo/freeipa-devel > >> You've added a check in col_find_item_and_do() for a trailing '.', > which > >> is illegal, but you didn't add a corresponding unit test to verify that > >> this is behaving as expected. > >> > >> Please add that unit test, then this will be an ack. > >> > > Sure, what about other two patches? > > Anything needs to be corrected there? > > I would prefer to make changes in one pass if possible. > > Also the question is: since the patches are relatively small can I > > squash them together? > > I am not sure I want to do it but I wanted to ask anyways what the best > > approach is. > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > > > The general rule we follow with patches is that it should be one patch > per logical change. Only squash patches together if they are 100% > codependent (i.e. Patch A depends on Patch B, but Patch B also depends > on Patch A) > > I'll look at the other patches. Oddly they didn't show up in my email > until about an hour ago. Strange routing glitch, I expect. > Updated patch 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-COLLECTION-Improving-searches.patch Type: text/x-patch Size: 11955 bytes Desc: not available URL: From sgallagh at redhat.com Thu Jul 16 21:29:59 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 16 Jul 2009 17:29:59 -0400 Subject: [Freeipa-devel] Re: [PATCH] COLLECTION Improving searches (resending) In-Reply-To: <4A5F98F0.9000806@redhat.com> References: <4A5E4B54.2020706@redhat.com> <4A5F080E.6040401@redhat.com> <4A5F2B38.5050502@redhat.com> <4A5F3819.4090405@redhat.com> <4A5F98F0.9000806@redhat.com> Message-ID: <4A5F9BD7.2020000@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/16/2009 05:17 PM, Dmitri Pal wrote: > Stephen Gallagher wrote: >> On 07/16/2009 09:29 AM, Dmitri Pal wrote: >>> Stephen Gallagher wrote: >>>> On 07/15/2009 05:34 PM, Dmitri Pal wrote: >>>>> Addressing ticket https://fedorahosted.org/sssd/ticket/71 >> ------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> You've added a check in col_find_item_and_do() for a trailing '.', >> which >>>> is illegal, but you didn't add a corresponding unit test to verify that >>>> this is behaving as expected. >>>> >>>> Please add that unit test, then this will be an ack. >>>> >>> Sure, what about other two patches? >>> Anything needs to be corrected there? >>> I would prefer to make changes in one pass if possible. >>> Also the question is: since the patches are relatively small can I >>> squash them together? >>> I am not sure I want to do it but I wanted to ask anyways what the best >>> approach is. >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> >> >> The general rule we follow with patches is that it should be one patch >> per logical change. Only squash patches together if they are 100% >> codependent (i.e. Patch A depends on Patch B, but Patch B also depends >> on Patch A) >> >> I'll look at the other patches. Oddly they didn't show up in my email >> until about an hour ago. Strange routing glitch, I expect. >> > Updated patch attached > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > Ack 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/ iEYEARECAAYFAkpfm9MACgkQeiVVYja6o6MjQwCglB1vl/pDSW4XyOE8bLD85Uw4 ENUAnRloaqqmhx3JpAFsFa1/LQ8L2TkF =kymO -----END PGP SIGNATURE----- From dpal at redhat.com Fri Jul 17 23:25:46 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 17 Jul 2009 19:25:46 -0400 Subject: [Freeipa-devel] [PATCH] COLLECTION & INI Cleanup Message-ID: <4A61087A.2080307@redhat.com> I started to cleanup the unit tests from the type cust around NULL and found several problems that I had to address: 1) The choice of the "." as a search separator turned out to be a poor choice. The problem was that the file name has "." and INI was relaying on files to be used as property names. I corrected that part in the INI but after discussion with Simo we decided to switch from "." to "!" as special symbol anyways. 2) Found that the property rename was not reinitializing the hash. Corrected. Added ticket to add unit tests around it (#83). -- 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-COLLECTION-INI-Cleanup.patch Type: text/x-patch Size: 28306 bytes Desc: not available URL: From ssorce at redhat.com Mon Jul 20 13:51:25 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 20 Jul 2009 09:51:25 -0400 Subject: [Freeipa-devel] [PATCH] Fix saving new nextID In-Reply-To: <4A5DC879.6040904@redhat.com> References: <4A5DB3E2.4000009@redhat.com> <1247659735.29458.57.camel@localhost.localdomain> <4A5DC879.6040904@redhat.com> Message-ID: <1248097885.29458.216.camel@localhost.localdomain> On Wed, 2009-07-15 at 14:15 +0200, Jakub Hrozek wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/15/2009 02:08 PM, Simo Sorce wrote: > > Nack, we already have the value in state->base_dn, this look like it was > > just a typo state->base->dn instead of state->base_dn > > > > Simo. > > > > True, new patch that just fixes the typo is attached. ack and pushed -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Jul 20 13:51:46 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 20 Jul 2009 09:51:46 -0400 Subject: [Freeipa-devel] [PATCH] add infrastructure to handle new backend targets In-Reply-To: <1247673939.29458.95.camel@localhost.localdomain> References: <20090715125300.GD3219@localhost.localdomain> <1247673939.29458.95.camel@localhost.localdomain> Message-ID: <1248097906.29458.217.camel@localhost.localdomain> On Wed, 2009-07-15 at 12:05 -0400, Simo Sorce wrote: > On Wed, 2009-07-15 at 14:53 +0200, Sumit Bose wrote: > > Hi, > > > > this patch adds the handling of the new backend targets access (a.k.a. > > authorization) and chpass to the data provider infrastructure. I have > > changed the way the current id and auth targets are handled to avoid > > multiple loading of a single backend and to avoid massive code > > duplication. This patch touches the backends only where necessary. This > > means that the sssd can be complied successfully and id and auth are > > working as expected (at least in my test :-). The access target is set > > to a default permit target. I will provide a patch for the backends if > > this patch and the new scheme of handling the backends and their targets > > is accepted. > > Ack, > architecture looks good to me, and a general look at the code seem ok. pushed Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Jul 20 13:57:45 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 20 Jul 2009 13:57:45 +0000 Subject: [Freeipa-devel] [PATCHES] Infrastructure fixes Message-ID: <1248098265.29458.222.camel@localhost.localdomain> 1/3: Add timestamps when the debug level is set higher then 8 When doing some tests it may be important to have the timestamp at which each operation happened. add automatically a timestamp when the level is high enough 2/3: raise the level of the client negotiation debug messages to 5. Level 4 is the level I use most to see what is going on, and these messages are little more than trace calls. Moved to 5 for now, maybe they should go higher. 3/3: Rework the use of openldap libraries in the ldap driver. Se the commit for a brief explanation. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-timestamps-when-the-log-level-is-high-enough.patch Type: text/x-patch Size: 1916 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Raise-debug-level-for-version-negotiation.patch Type: text/x-patch Size: 1450 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Rework-the-engine-that-deals-with-openldap-libraries.patch Type: text/x-patch Size: 52534 bytes Desc: not available URL: From sgallagh at redhat.com Mon Jul 20 14:11:53 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 20 Jul 2009 10:11:53 -0400 Subject: [Freeipa-devel] [PATCHES] tools and debug tidyups In-Reply-To: <1247523089.29458.14.camel@localhost.localdomain> References: <1247523089.29458.14.camel@localhost.localdomain> Message-ID: <4A647B29.6020005@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/13/2009 06:11 PM, Simo Sorce wrote: > Fixes and tidyups to tools and debugging of memberof. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Ack. (My previous nack was due to an unrelated issue) - -- 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/ iEYEARECAAYFAkpkeyUACgkQeiVVYja6o6P42wCgk3BZ1zDvBQWqJQVQdJJYKV3g acEAn0jwpSQc8RqOLeizrfGjuoiofaFr =jzS6 -----END PGP SIGNATURE----- From sgallagh at redhat.com Mon Jul 20 14:12:25 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 20 Jul 2009 10:12:25 -0400 Subject: [Freeipa-devel] [PATCH] COLLECTION & INI Cleanup In-Reply-To: <4A61087A.2080307@redhat.com> References: <4A61087A.2080307@redhat.com> Message-ID: <4A647B49.9090404@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/17/2009 07:25 PM, Dmitri Pal wrote: > I started to cleanup the unit tests from the type cust around NULL and > found several problems that I had to address: > 1) The choice of the "." as a search separator > turned out to be a poor choice. > The problem was that the file name has "." > and INI was relaying on files to be used as > property names. > I corrected that part in the INI but after discussion > with Simo we decided to switch from "." to "!" > as special symbol anyways. > 2) Found that the property rename was not > reinitializing the hash. Corrected. > Added ticket to add unit tests around it (#83). > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/ iEYEARECAAYFAkpke0kACgkQeiVVYja6o6PO3QCaAwozqOq23IHJQFcv2Cy1r+4+ pCQAn1TaHa/CtytktyZc3diPBfwIZguS =5G3L -----END PGP SIGNATURE----- From ssorce at redhat.com Mon Jul 20 14:53:48 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 20 Jul 2009 10:53:48 -0400 Subject: [Freeipa-devel] [PATCHES][SSSD] Config monitoring patches In-Reply-To: <4A5F928F.5080002@redhat.com> References: <4A421B00.8060907@redhat.com> <1246388023.25726.10.camel@localhost.localdomain> <4A5F928F.5080002@redhat.com> Message-ID: <1248101628.29458.223.camel@localhost.localdomain> On Thu, 2009-07-16 at 16:50 -0400, Stephen Gallagher wrote: > > Simo's review changes are incorporated into these new versions. Please > re-review. > > I opted to just wait five seconds between retries for a total of 30 > seconds. The progressive increase seemed like overkill, since I expect > it to be very rare that someone would be manually moving the config > file > out of the way and then putting it back. > Ack and pushed. After fixing (and squashing into the second patch) an obvoius segfault. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Jul 20 14:54:38 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 20 Jul 2009 10:54:38 -0400 Subject: [Freeipa-devel] [PATCH] COLLECTION & INI Cleanup In-Reply-To: <4A61087A.2080307@redhat.com> References: <4A61087A.2080307@redhat.com> Message-ID: <1248101678.29458.224.camel@localhost.localdomain> On Fri, 2009-07-17 at 19:25 -0400, Dmitri Pal wrote: > I started to cleanup the unit tests from the type cust around NULL and > found several problems that I had to address: > 1) The choice of the "." as a search separator > turned out to be a poor choice. > The problem was that the file name has "." > and INI was relaying on files to be used as > property names. > I corrected that part in the INI but after discussion > with Simo we decided to switch from "." to "!" > as special symbol anyways. > 2) Found that the property rename was not > reinitializing the hash. Corrected. > Added ticket to add unit tests around it (#83). This fixes a fatal error at sssd startup. tested and pushed. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Jul 20 14:58:36 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 20 Jul 2009 10:58:36 -0400 Subject: [Freeipa-devel] [PATCHES] tools and debug tidyups In-Reply-To: <4A647B29.6020005@redhat.com> References: <1247523089.29458.14.camel@localhost.localdomain> <4A647B29.6020005@redhat.com> Message-ID: <1248101916.29458.225.camel@localhost.localdomain> On Mon, 2009-07-20 at 10:11 -0400, Stephen Gallagher wrote: > Ack. (My previous nack was due to an unrelated issue) Pushed -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Jul 20 15:41:38 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 20 Jul 2009 11:41:38 -0400 Subject: [Freeipa-devel] [PATCHES] Infrastructure fixes In-Reply-To: <1248098265.29458.222.camel@localhost.localdomain> References: <1248098265.29458.222.camel@localhost.localdomain> Message-ID: <1248104498.29458.232.camel@localhost.localdomain> On Mon, 2009-07-20 at 13:57 +0000, Simo Sorce wrote: > 1/3: Add timestamps when the debug level is set higher then 8 > When doing some tests it may be important to have the timestamp at which > each operation happened. add automatically a timestamp when the level is > high enough Some people complained on IRC about this one, and said they would prefer to have a separate option to tell when to add a timestamp. Attached patch that substitute 1/3 Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-option-to-add-timestamps-to-debug-output.patch Type: text/x-patch Size: 5219 bytes Desc: not available URL: From ssorce at redhat.com Mon Jul 20 15:57:45 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 20 Jul 2009 11:57:45 -0400 Subject: [Freeipa-devel] [PATCH] added pam_probe and session state In-Reply-To: <4A1C5BA8.3010602@redhat.com> References: <4A1C5BA8.3010602@redhat.com> Message-ID: <1248105465.29458.234.camel@localhost.localdomain> On Tue, 2009-05-26 at 23:14 +0200, Sumit Bose wrote: > Hi, > > this patch add a new, initial pam call to the pam client protocol and > let the pam responder save the states of previous pam operations. > This patch kept being postponed in my patch queue. After a brief discussion with Sumit we decided to retire and rethink it for now. The new authz/changepw backend targets make it worth considering other ways. Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Mon Jul 20 18:03:28 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 20 Jul 2009 14:03:28 -0400 Subject: [Freeipa-devel] [PATCHES][SSSD] Some general cleanup patches Message-ID: <4A64B170.1030405@redhat.com> Patch 0001: There was a typo (misnamed file) in Makefile.am. Because of this 'make dist' (and by extension 'make rpms') failed. Patch 0002: We have decided that the InfoPipe code was never sufficient to meet the needs of the Gnome/KDE people, so we are retiring it before anyone starts using it. This patch removes all traces of it from HEAD. -- 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-typo-in-elapi-s-Makefile.am-that-breaks-make-di.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-Remove-unused-InfoPipe-and-PolicyKit-code.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 Mon Jul 20 18:14:33 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 20 Jul 2009 14:14:33 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Fix sssd.spec Message-ID: <4A64B409.2010700@redhat.com> Explicitly use /var/lib in the sssd.spec The source code currently hardcodes the path to /var/lib, but the sssd.spec relies on the value of %{_sharedstatedir}. This is broken on systems like RHEL5 where %{_sharedstatedir} resolves to /usr/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-Explicitly-use-var-lib-in-the-sssd.spec.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 Jul 20 18:17:00 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 20 Jul 2009 14:17:00 -0400 Subject: [Freeipa-devel] [PATCHES] Infrastructure fixes In-Reply-To: <1248098265.29458.222.camel@localhost.localdomain> References: <1248098265.29458.222.camel@localhost.localdomain> Message-ID: <1248113820.29458.240.camel@localhost.localdomain> On Mon, 2009-07-20 at 13:57 +0000, Simo Sorce wrote: > > 3/3: Rework the use of openldap libraries in the ldap driver. Se the > commit for a brief explanation. Sumit found a degfault bug where we were not removing the fde event before killing the connection resulting in a callback to be called and using sh->ldap, now freed an null. I reworked the sdap_handle to store the fde directly instead of the fd as it was originally. This way we can properly free the event before killing the ldap context. Patch replaces 3/3 Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Rework-the-engine-that-deals-with-openldap-libraries.patch Type: text/x-patch Size: 53295 bytes Desc: not available URL: From ssorce at redhat.com Mon Jul 20 18:28:57 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 20 Jul 2009 18:28:57 +0000 Subject: [Freeipa-devel] [PATCH][SSSD] Fix sssd.spec In-Reply-To: <4A64B409.2010700@redhat.com> References: <4A64B409.2010700@redhat.com> Message-ID: <1248114537.29458.250.camel@localhost.localdomain> On Mon, 2009-07-20 at 14:14 -0400, Stephen Gallagher wrote: > Explicitly use /var/lib in the sssd.spec > > The source code currently hardcodes the path to /var/lib, but the > sssd.spec relies on the value of %{_sharedstatedir}. This is > broken on systems like RHEL5 where %{_sharedstatedir} resolves to > /usr/com > Nack, please define a new variable and assign it differently depending on the platfrom, either by checking directly for disttags or release names, or by using a define Something like: %if 0%{fedora} > 11 %define sssd_var_lib %{_sharedstatedir} %else %define sssd_var_lib /var/lib %endif Then always use %{sssd_var_lib} Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Mon Jul 20 18:40:52 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 20 Jul 2009 14:40:52 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Fix sssd.spec In-Reply-To: <1248114537.29458.250.camel@localhost.localdomain> References: <4A64B409.2010700@redhat.com> <1248114537.29458.250.camel@localhost.localdomain> Message-ID: <4A64BA34.9090900@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/20/2009 02:28 PM, Simo Sorce wrote: > On Mon, 2009-07-20 at 14:14 -0400, Stephen Gallagher wrote: >> Explicitly use /var/lib in the sssd.spec >> >> The source code currently hardcodes the path to /var/lib, but the >> sssd.spec relies on the value of %{_sharedstatedir}. This is >> broken on systems like RHEL5 where %{_sharedstatedir} resolves to >> /usr/com >> > Nack, > please define a new variable and assign it differently depending on the > platfrom, either by checking directly for disttags or release names, or > by using a define > > Something like: > %if 0%{fedora} > 11 > %define sssd_var_lib %{_sharedstatedir} > %else > %define sssd_var_lib /var/lib > %endif > > Then always use %{sssd_var_lib} > > Simo. > I disagree. This doesn't make any sense. That statement parses to: If the sharedstatedir == /var/lib, use sharedstatedir, otherwise, use /var/lib. It seems incongruous to use another variable there. If we're going to nack it, I'd rather we just state outright that we need to fix the code to always create the pipes in sharedstatedir, rather than hard-coding /var/lib. This fix was just meant to hold us over until we get around to doing that. - -- 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/ iEYEARECAAYFAkpkui4ACgkQeiVVYja6o6NcdgCbBWWl2SUvWAw71zxreSYshHXB XR8An07IMbWMyGKykFOZiP4kaVA+pNNa =4iU7 -----END PGP SIGNATURE----- From ssorce at redhat.com Mon Jul 20 18:41:15 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 20 Jul 2009 14:41:15 -0400 Subject: [Freeipa-devel] [PATCHES][SSSD] Some general cleanup patches In-Reply-To: <4A64B170.1030405@redhat.com> References: <4A64B170.1030405@redhat.com> Message-ID: <1248115275.29458.251.camel@localhost.localdomain> On Mon, 2009-07-20 at 14:03 -0400, Stephen Gallagher wrote: > Patch 0001: There was a typo (misnamed file) in Makefile.am. Because > of > this 'make dist' (and by extension 'make rpms') failed. ack > Patch 0002: We have decided that the InfoPipe code was never > sufficient > to meet the needs of the Gnome/KDE people, so we are retiring it > before > anyone starts using it. This patch removes all traces of it from HEAD. ack and pushed both Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Mon Jul 20 18:52:03 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 20 Jul 2009 14:52:03 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Add 'make srpms' target Message-ID: <4A64BCD3.7090401@redhat.com> $SUBJECT This will be useful for setting up automated builds. We can generate a single SRPM and then use mock to create the RPMS for multiple platforms. -- 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-make-srpms-target.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 Mon Jul 20 19:12:30 2009 From: sbose at redhat.com (Sumit Bose) Date: Mon, 20 Jul 2009 21:12:30 +0200 Subject: [Freeipa-devel] [PATCHES] Infrastructure fixes In-Reply-To: <1248113820.29458.240.camel@localhost.localdomain> References: <1248098265.29458.222.camel@localhost.localdomain> <1248113820.29458.240.camel@localhost.localdomain> Message-ID: <20090720191230.GD3020@localhost.localdomain> On Mon, Jul 20, 2009 at 02:17:00PM -0400, Simo Sorce wrote: > On Mon, 2009-07-20 at 13:57 +0000, Simo Sorce wrote: > > > > 3/3: Rework the use of openldap libraries in the ldap driver. Se the > > commit for a brief explanation. > > Sumit found a degfault bug where we were not removing the fde event > before killing the connection resulting in a callback to be called and > using sh->ldap, now freed an null. > > I reworked the sdap_handle to store the fde directly instead of the fd > as it was originally. This way we can properly free the event before > killing the ldap context. > > Patch replaces 3/3 > ACK to this patch, ACK to the second version of the timestamp patch ACK to the raise of debuglevel patch bye, Sumit From ssorce at redhat.com Mon Jul 20 19:27:21 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 20 Jul 2009 19:27:21 +0000 Subject: [Freeipa-devel] [PATCH][SSSD] Fix sssd.spec In-Reply-To: <4A64BA34.9090900@redhat.com> References: <4A64B409.2010700@redhat.com> <1248114537.29458.250.camel@localhost.localdomain> <4A64BA34.9090900@redhat.com> Message-ID: <1248118042.29458.259.camel@localhost.localdomain> On Mon, 2009-07-20 at 14:40 -0400, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/20/2009 02:28 PM, Simo Sorce wrote: > > On Mon, 2009-07-20 at 14:14 -0400, Stephen Gallagher wrote: > >> Explicitly use /var/lib in the sssd.spec > >> > >> The source code currently hardcodes the path to /var/lib, but the > >> sssd.spec relies on the value of %{_sharedstatedir}. This is > >> broken on systems like RHEL5 where %{_sharedstatedir} resolves to > >> /usr/com > >> > > Nack, > > please define a new variable and assign it differently depending on the > > platfrom, either by checking directly for disttags or release names, or > > by using a define > > > > Something like: > > %if 0%{fedora} > 11 > > %define sssd_var_lib %{_sharedstatedir} > > %else > > %define sssd_var_lib /var/lib > > %endif > > > > Then always use %{sssd_var_lib} > > > > Simo. > > > > I disagree. This doesn't make any sense. That statement parses to: > If the sharedstatedir == /var/lib, use sharedstatedir, otherwise, use > /var/lib. It seems incongruous to use another variable there. No the statement I made is: if Fedora >= 11 use %{_sharedstatedir} otherwise use /var/lib of course the idea is to pass sssd_var_lib to the appropriate ./configure switch > If we're going to nack it, I'd rather we just state outright that we > need to fix the code to always create the pipes in sharedstatedir, > rather than hard-coding /var/lib. Yes, we should not hardcode /var/lib in our source, just do the above int he rpm. > This fix was just meant to hold us over until we get around to doing that. The example I made would still be valid once you have the configure option. You still want to use sharedstatedir in Fedora >= 11 but not in RHEL5. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Jul 20 19:27:36 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 20 Jul 2009 15:27:36 -0400 Subject: [Freeipa-devel] [PATCHES] Infrastructure fixes In-Reply-To: <20090720191230.GD3020@localhost.localdomain> References: <1248098265.29458.222.camel@localhost.localdomain> <1248113820.29458.240.camel@localhost.localdomain> <20090720191230.GD3020@localhost.localdomain> Message-ID: <1248118056.29458.260.camel@localhost.localdomain> On Mon, 2009-07-20 at 21:12 +0200, Sumit Bose wrote: > On Mon, Jul 20, 2009 at 02:17:00PM -0400, Simo Sorce wrote: > > On Mon, 2009-07-20 at 13:57 +0000, Simo Sorce wrote: > > > > > > 3/3: Rework the use of openldap libraries in the ldap driver. Se the > > > commit for a brief explanation. > > > > Sumit found a degfault bug where we were not removing the fde event > > before killing the connection resulting in a callback to be called and > > using sh->ldap, now freed an null. > > > > I reworked the sdap_handle to store the fde directly instead of the fd > > as it was originally. This way we can properly free the event before > > killing the ldap context. > > > > Patch replaces 3/3 > > > > ACK to this patch, > ACK to the second version of the timestamp patch > ACK to the raise of debuglevel patch pushed Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Mon Jul 20 19:44:36 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 20 Jul 2009 15:44:36 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Fix sssd.spec In-Reply-To: <1248118042.29458.259.camel@localhost.localdomain> References: <4A64B409.2010700@redhat.com> <1248114537.29458.250.camel@localhost.localdomain> <4A64BA34.9090900@redhat.com> <1248118042.29458.259.camel@localhost.localdomain> Message-ID: <4A64C924.6050904@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/20/2009 03:27 PM, Simo Sorce wrote: > On Mon, 2009-07-20 at 14:40 -0400, Stephen Gallagher wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 07/20/2009 02:28 PM, Simo Sorce wrote: >>> On Mon, 2009-07-20 at 14:14 -0400, Stephen Gallagher wrote: >>>> Explicitly use /var/lib in the sssd.spec >>>> >>>> The source code currently hardcodes the path to /var/lib, but the >>>> sssd.spec relies on the value of %{_sharedstatedir}. This is >>>> broken on systems like RHEL5 where %{_sharedstatedir} resolves to >>>> /usr/com >>>> >>> Nack, >>> please define a new variable and assign it differently depending on the >>> platfrom, either by checking directly for disttags or release names, or >>> by using a define >>> >>> Something like: >>> %if 0%{fedora} > 11 >>> %define sssd_var_lib %{_sharedstatedir} >>> %else >>> %define sssd_var_lib /var/lib >>> %endif >>> >>> Then always use %{sssd_var_lib} >>> >>> Simo. >>> >> I disagree. This doesn't make any sense. That statement parses to: >> If the sharedstatedir == /var/lib, use sharedstatedir, otherwise, use >> /var/lib. It seems incongruous to use another variable there. > > No the statement I made is: > if Fedora >= 11 use %{_sharedstatedir} > otherwise use /var/lib > > of course the idea is to pass sssd_var_lib to the > appropriate ./configure switch > >> If we're going to nack it, I'd rather we just state outright that we >> need to fix the code to always create the pipes in sharedstatedir, >> rather than hard-coding /var/lib. > > Yes, we should not hardcode /var/lib in our source, just do the above > int he rpm. > >> This fix was just meant to hold us over until we get around to doing that. > > The example I made would still be valid once you have the configure > option. You still want to use sharedstatedir in Fedora >= 11 but not in > RHEL5. > > Simo. > I'm not sure why we wouldn't want to just use sharedstatedir on all platforms, assuming that we also used sharedstatedir when creating the pipes in the first place. Basically, I'm saying that either we should change the sssd.spec to match what we're doing in the code (hardcoding /var/lib), or we should change the code to match what we're doing in sssd.spec (put the pipes under sharedstatedir for the platform). Either one is valid. Saying "we'll use sharedstatedir on Fedora 11+" doesn't work, because they could STILL pass a different --sharedstatedir line to configure and it would break again. - -- 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/ iEYEARECAAYFAkpkyR8ACgkQeiVVYja6o6PKgACeNSE0da0bj/LUOiVqXAS5+BOB bcgAoIwjT2591BUGyGimidc2DtNHWpr+ =65vl -----END PGP SIGNATURE----- From ssorce at redhat.com Mon Jul 20 19:49:03 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 20 Jul 2009 15:49:03 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Fix sssd.spec In-Reply-To: <4A64C924.6050904@redhat.com> References: <4A64B409.2010700@redhat.com> <1248114537.29458.250.camel@localhost.localdomain> <4A64BA34.9090900@redhat.com> <1248118042.29458.259.camel@localhost.localdomain> <4A64C924.6050904@redhat.com> Message-ID: <1248119343.29458.264.camel@localhost.localdomain> On Mon, 2009-07-20 at 15:44 -0400, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/20/2009 03:27 PM, Simo Sorce wrote: > > On Mon, 2009-07-20 at 14:40 -0400, Stephen Gallagher wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> On 07/20/2009 02:28 PM, Simo Sorce wrote: > >>> On Mon, 2009-07-20 at 14:14 -0400, Stephen Gallagher wrote: > >>>> Explicitly use /var/lib in the sssd.spec > >>>> > >>>> The source code currently hardcodes the path to /var/lib, but the > >>>> sssd.spec relies on the value of %{_sharedstatedir}. This is > >>>> broken on systems like RHEL5 where %{_sharedstatedir} resolves to > >>>> /usr/com > >>>> > >>> Nack, > >>> please define a new variable and assign it differently depending on the > >>> platfrom, either by checking directly for disttags or release names, or > >>> by using a define > >>> > >>> Something like: > >>> %if 0%{fedora} > 11 > >>> %define sssd_var_lib %{_sharedstatedir} > >>> %else > >>> %define sssd_var_lib /var/lib > >>> %endif > >>> > >>> Then always use %{sssd_var_lib} > >>> > >>> Simo. > >>> > >> I disagree. This doesn't make any sense. That statement parses to: > >> If the sharedstatedir == /var/lib, use sharedstatedir, otherwise, use > >> /var/lib. It seems incongruous to use another variable there. > > > > No the statement I made is: > > if Fedora >= 11 use %{_sharedstatedir} > > otherwise use /var/lib > > > > of course the idea is to pass sssd_var_lib to the > > appropriate ./configure switch > > > >> If we're going to nack it, I'd rather we just state outright that we > >> need to fix the code to always create the pipes in sharedstatedir, > >> rather than hard-coding /var/lib. > > > > Yes, we should not hardcode /var/lib in our source, just do the above > > int he rpm. > > > >> This fix was just meant to hold us over until we get around to doing that. > > > > The example I made would still be valid once you have the configure > > option. You still want to use sharedstatedir in Fedora >= 11 but not in > > RHEL5. > > > > Simo. > > > > I'm not sure why we wouldn't want to just use sharedstatedir on all > platforms, assuming that we also used sharedstatedir when creating the > pipes in the first place. I guess I was not clear. > Basically, I'm saying that either we should change the sssd.spec to > match what we're doing in the code (hardcoding /var/lib), or we should > change the code to match what we're doing in sssd.spec (put the pipes > under sharedstatedir for the platform). We want to change the code to take whatever directory as a ./configure option. In Fedora 11 the spec will pass sharedstatedir, on RHEL5 we won't (we don't put stuff in /usr/com), there we will pass /var/lib > Either one is valid. Saying "we'll use sharedstatedir on Fedora 11+" > doesn't work, because they could STILL pass a different --sharedstatedir > line to configure and it would break again. The point is that we will explicitly pass --sssd_sharedstatedir= %{sssd_sharedstatedir}, so whatever we do it will always be consistent. Simo. -- Simo Sorce * Red Hat, Inc * New York From nalin at redhat.com Mon Jul 20 21:53:28 2009 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 20 Jul 2009 17:53:28 -0400 Subject: [Freeipa-devel] [PATCH] handle kdb stash being a keytab Message-ID: <20090720215328.GA10770@redhat.com> In krb5 1.7 and later, the stash file (/var/kerberos/krb5kdc/.k5.$REALM on Fedora) is created in the regular keytab format instead of the older less-portable one. Based from comments and code in kt_file.c, here's a change to try to recognize that case (the file starts with a magic number) and read the master key from Python. The KDC will still read either format, so I left the bits that set things up on replicas alone (advice appreciated). The patch works as expected on my 64-bit box, both on RHEL5 (krb5 1.6.1 with a traditional stash file) and on Raw Hide (krb5 1.7 with a keytab). Nalin -------------- next part -------------- diff --git a/ipaserver/install/krbinstance.py b/ipaserver/install/krbinstance.py index 1c34897..16ec8b4 100644 --- a/ipaserver/install/krbinstance.py +++ b/ipaserver/install/krbinstance.py @@ -324,12 +324,68 @@ class KrbInstance(service.Service): self._ldap_mod("pwd-extop-conf.ldif", self.sub_dict) def __add_master_key(self): + #check for a keytab file by checking if the header magic is for a keytab + def __is_keytab(header): + if header == 0x0502 or header == 0x0501 or header == 0x0205 or header == 0x0105: + return 1 + else: + return 0 + #check whether a keytab file is v1 or v2 + def __keytab_version(header): + if header == 0x0502 or header == 0x0205: + return 2 + elif header == 0x0501 or header == 0x0105: + return 1 + else: + return 0 #get the Master Key from the stash file try: stash = open("/var/kerberos/krb5kdc/.k5."+self.realm, "r") keytype = struct.unpack('h', stash.read(2))[0] - keylen = struct.unpack('i', stash.read(4))[0] - keydata = stash.read(keylen) + if __is_keytab(keytype): + #in v2, all numbers are stored in network order + if __keytab_version(keytype) > 1: + __endian = '!' + else: + __endian = '' + #walk the first entry (there should only be one) + keyentrylen = struct.unpack(__endian + 'i', stash.read(4))[0] + #number of components in the principal name + keyprinccomps = struct.unpack(__endian + 'h', stash.read(2))[0] + #version 1 counted the realm as a component, version 2 doesn't + if __keytab_version(keytype) == 1: + keyprinccomps = keyprinccomps - 1 + keyprinc = [] + #read the components. the realm goes first, so we should + #end up with (realm, "K", "M") + for i in range(keyprinccomps + 1): + keyprinccompsize = struct.unpack(__endian + 'h', stash.read(2))[0] + keyprinc = keyprinc + [stash.read(keyprinccompsize)] + #version 2 added the principal name type, otherwise we just + #assume it's a regular old principal name + if __keytab_version(keytype) > 1: + keyprinctype = struct.unpack(__endian + 'i', stash.read(4))[0] + else: + keyprinctype = 1 + #date the key was added to this keytab + keydate = struct.unpack(__endian + 'i', stash.read(4))[0] + #kvno + keyversion = struct.unpack('B', stash.read(1))[0] + #read the real enctype + keytype = struct.unpack(__endian + 'h', stash.read(2))[0] + keylen = struct.unpack(__endian + 'h', stash.read(2))[0] + keydata = stash.read(keylen) + #check that we parsed the whole file, so no surprises + keyoffset = stash.tell() + stash.seek(0,2) + if stash.tell() != keyoffset: + logging.critical("Unexpected unprocessed data in Stash file (processed %ld bytes, %ld left)." % (keyoffset, stash.tell() - keyoffset)) + else: + keyversion = 1 + keyprinctype = 1 + keyprinc = [self.realm,"K","M"] + keylen = struct.unpack('i', stash.read(4))[0] + keydata = stash.read(keylen) except os.error: logging.critical("Failed to retrieve Master Key from Stash file: %s") #encode it in the asn.1 attribute @@ -337,7 +393,7 @@ class KrbInstance(service.Service): MasterKey.setComponentByPosition(0, univ.Integer(keytype)) MasterKey.setComponentByPosition(1, univ.OctetString(keydata)) krbMKey = univ.Sequence() - krbMKey.setComponentByPosition(0, univ.Integer(0)) #we have no kvno + krbMKey.setComponentByPosition(0, univ.Integer(keyversion)) krbMKey.setComponentByPosition(1, MasterKey) asn1key = pyasn1.codec.ber.encoder.encode(krbMKey) From sbose at redhat.com Tue Jul 21 12:45:39 2009 From: sbose at redhat.com (Sumit Bose) Date: Tue, 21 Jul 2009 14:45:39 +0200 Subject: [Freeipa-devel] [PATCHES] added chpass target to proxy and LDAP backend Message-ID: <20090721124539.GF3285@localhost.localdomain> Hi, the included patches will add the chpass target to the proxy and LDAP backend (one of them will add the access target to then proxy backend, too). While the proxy targets are simply calls to the old pam handler, the LDAP chpass target uses the latest scheme pushed by Simo yesterday. Simo can you please check if I got it right? bye, Sumit -------------- next part -------------- >From 5e8ed566296d5390d51def73f041c9bd9f510995 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Thu, 16 Jul 2009 16:40:29 +0200 Subject: [PATCH 1/2] add handling of the new backend targets to proxy backend --- server/providers/proxy.c | 30 ++++++++++++++++++++++++++++++ 1 files changed, 30 insertions(+), 0 deletions(-) diff --git a/server/providers/proxy.c b/server/providers/proxy.c index aa5b1c9..ddfbe39 100644 --- a/server/providers/proxy.c +++ b/server/providers/proxy.c @@ -2069,6 +2069,18 @@ struct bet_ops proxy_auth_ops = { .finalize = proxy_auth_shutdown }; +struct bet_ops proxy_access_ops = { + .check_online = proxy_check_online, + .handler = proxy_pam_handler, + .finalize = proxy_auth_shutdown +}; + +struct bet_ops proxy_chpass_ops = { + .check_online = proxy_check_online, + .handler = proxy_pam_handler, + .finalize = proxy_auth_shutdown +}; + static void *proxy_dlsym(void *handle, const char *functemp, char *libname) { char *funcname; @@ -2238,3 +2250,21 @@ done: } return ret; } + +int sssm_proxy_access_init(struct be_ctx *bectx, + struct bet_ops **ops, void **pvt_data) +{ + int ret; + ret = sssm_proxy_auth_init(bectx, ops, pvt_data); + *ops = &proxy_access_ops; + return ret; +} + +int sssm_proxy_chpass_init(struct be_ctx *bectx, + struct bet_ops **ops, void **pvt_data) +{ + int ret; + ret = sssm_proxy_auth_init(bectx, ops, pvt_data); + *ops = &proxy_chpass_ops; + return ret; +} -- 1.6.2.5 -------------- next part -------------- >From 4db372c4e0ccbb4e06864d56da9e28a62fec3de9 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 20 Jul 2009 17:27:02 +0200 Subject: [PATCH 2/2] added LDAP change password backend target --- server/providers/data_provider_be.c | 8 ++- server/providers/ldap/ldap_auth.c | 168 +++++++++++++++++++++++++++++++++++ server/providers/ldap/sdap_async.c | 137 ++++++++++++++++++++++++++++ server/providers/ldap/sdap_async.h | 8 ++ 4 files changed, 319 insertions(+), 2 deletions(-) diff --git a/server/providers/data_provider_be.c b/server/providers/data_provider_be.c index 5cd5994..2e0c1cf 100644 --- a/server/providers/data_provider_be.c +++ b/server/providers/data_provider_be.c @@ -631,8 +631,10 @@ static int be_pam_handler(DBusMessage *message, struct sbus_conn_ctx *sconn) } be_req = talloc_zero(ctx, struct be_req); - if (!be_req) + if (!be_req) { + DEBUG(7, ("talloc_zero failed.\n")); goto done; + } be_req->be_ctx = ctx; be_req->fn = be_pam_handler_callback; @@ -640,8 +642,10 @@ static int be_pam_handler(DBusMessage *message, struct sbus_conn_ctx *sconn) be_req->req_data = pd; ret = be_file_request(ctx, ctx->bet_info[target].bet_ops->handler, be_req); - if (ret != EOK) + if (ret != EOK) { + DEBUG(7, ("be_file_request failed.\n")); goto done; + } return EOK; diff --git a/server/providers/ldap/ldap_auth.c b/server/providers/ldap/ldap_auth.c index 2c53032..78f893e 100644 --- a/server/providers/ldap/ldap_auth.c +++ b/server/providers/ldap/ldap_auth.c @@ -300,7 +300,159 @@ int auth_recv(struct tevent_req *req, enum sdap_result *result) return EOK; } +int auth4chpass_recv(struct tevent_req *req, enum sdap_result *result, + TALLOC_CTX *memctx, struct sdap_handle **sh, char **dn) +{ + struct auth_state *state = tevent_req_data(req, struct auth_state); + enum tevent_req_state tstate; + uint64_t err; + + if (tevent_req_is_error(req, &tstate, &err)) { + *result = SDAP_ERROR; + return err; + } + + *sh = talloc_steal(memctx, state->sh); + if (!*sh) return ENOMEM; + + *dn = talloc_steal(memctx, state->dn); + if (!*dn) return ENOMEM; + + *result = state->result; + return EOK; +} + +/* ==Perform-Password-Change===================== */ + +struct sdap_pam_chpass_state { + struct be_req *breq; + struct pam_data *pd; + const char *username; + char *dn; + char *password; + char *new_password; + struct sdap_handle *sh; +}; + +static void sdap_auth4chpass_done(struct tevent_req *req); +static void sdap_pam_chpass_done(struct tevent_req *req); +static void sdap_pam_auth_reply(struct be_req *breq, int result); +static void sdap_pam_chpass_send(struct be_req *breq) +{ + struct sdap_pam_chpass_state *state; + struct sdap_auth_ctx *ctx; + struct tevent_req *subreq; + struct pam_data *pd; + + ctx = talloc_get_type(breq->be_ctx->bet_info[BET_CHPASS].pvt_bet_data, + struct sdap_auth_ctx); + pd = talloc_get_type(breq->req_data, struct pam_data); + + DEBUG(2, ("starting password change request for user [%s].\n", pd->user)); + + pd->pam_status = PAM_SYSTEM_ERR; + + if (pd->cmd != SSS_PAM_CHAUTHTOK) { + DEBUG(2, ("chpass target was called by wrong pam command.\n")); + goto done; + } + + state = talloc_zero(breq, struct sdap_pam_chpass_state); + if (!state) goto done; + + state->breq = breq; + state->pd = pd; + state->username = pd->user; + state->password = talloc_strndup(state, + (char *)pd->authtok, pd->authtok_size); + if (!state->password) goto done; + talloc_set_destructor((TALLOC_CTX *)state->password, + password_destructor); + state->new_password = talloc_strndup(state, + (char *)pd->newauthtok, + pd->newauthtok_size); + if (!state->new_password) goto done; + talloc_set_destructor((TALLOC_CTX *)state->new_password, + password_destructor); + + subreq = auth_send(breq, breq->be_ctx->ev, + ctx, state->username, state->password); + if (!subreq) goto done; + + tevent_req_set_callback(subreq, sdap_auth4chpass_done, state); + return; +done: + sdap_pam_auth_reply(breq, pd->pam_status); +} + +static void sdap_auth4chpass_done(struct tevent_req *req) +{ + struct sdap_pam_chpass_state *state = + tevent_req_callback_data(req, struct sdap_pam_chpass_state); + struct tevent_req *subreq; + enum sdap_result result; + int ret; + + ret = auth4chpass_recv(req, &result, state, &state->sh, &state->dn); + talloc_zfree(req); + if (ret) { + state->pd->pam_status = PAM_SYSTEM_ERR; + goto done; + } + + + switch (result) { + case SDAP_AUTH_SUCCESS: + DEBUG(7, ("user [%s] successfully authenticated.\n", state->dn)); + subreq = sdap_exop_modify_passwd_send(state, + state->breq->be_ctx->ev, + state->sh, + state->dn, + state->password, + state->new_password); + + if (!subreq) { + DEBUG(2, ("Failed to change password for %s\n", state->username)); + goto done; + } + + tevent_req_set_callback(subreq, sdap_pam_chpass_done, state); + return; + break; + default: + state->pd->pam_status = PAM_SYSTEM_ERR; + } + +done: + sdap_pam_auth_reply(state->breq, state->pd->pam_status); +} + +static void sdap_pam_chpass_done(struct tevent_req *req) +{ + struct sdap_pam_chpass_state *state = + tevent_req_callback_data(req, struct sdap_pam_chpass_state); + enum sdap_result result; + int ret; + + ret = sdap_exop_modify_passwd_recv(req, &result); + talloc_zfree(req); + if (ret) { + state->pd->pam_status = PAM_SYSTEM_ERR; + goto done; + } + + switch (result) { + case SDAP_SUCCESS: + state->pd->pam_status = PAM_SUCCESS; + break; + default: + state->pd->pam_status = PAM_SYSTEM_ERR; + } + +done: + sdap_pam_auth_reply(state->breq, state->pd->pam_status); +} /* ==Perform-User-Authentication-and-Password-Caching===================== */ struct sdap_pam_auth_state { @@ -453,6 +605,12 @@ struct bet_ops sdap_auth_ops = { .finalize = sdap_shutdown }; +struct bet_ops sdap_chpass_ops = { + .check_online = NULL, + .handler = sdap_pam_chpass_send, + .finalize = sdap_shutdown +}; + int sssm_ldap_auth_init(struct be_ctx *bectx, struct bet_ops **ops, void **pvt_data) @@ -514,3 +672,13 @@ done: } return ret; } + +int sssm_ldap_chpass_init(struct be_ctx *bectx, + struct bet_ops **ops, + void **pvt_data) +{ + int ret; + ret = sssm_ldap_auth_init(bectx, ops, pvt_data); + *ops = &sdap_chpass_ops; + return ret; +} diff --git a/server/providers/ldap/sdap_async.c b/server/providers/ldap/sdap_async.c index 57234e3..01142ca 100644 --- a/server/providers/ldap/sdap_async.c +++ b/server/providers/ldap/sdap_async.c @@ -1639,3 +1639,140 @@ int sdap_get_initgr_recv(struct tevent_req *req) return EOK; } +struct sdap_exop_modify_passwd_state { + struct sdap_handle *sh; + int msgid; + char *user_dn; + char *password; + char *new_password; + int result; + struct sdap_msg *reply; + BerElement *ber; + struct berval *bv; +}; + +static void sdap_exop_modify_passwd_done(void *pvt, int error, struct sdap_msg *reply); + +struct tevent_req *sdap_exop_modify_passwd_send(TALLOC_CTX *memctx, + struct tevent_context *ev, + struct sdap_handle *sh, + char *user_dn, + char *password, + char *new_password) +{ + struct tevent_req *req = NULL; + struct sdap_exop_modify_passwd_state *state; + int ret; + + req = tevent_req_create(memctx, &state, + struct sdap_exop_modify_passwd_state); + if (!req) return NULL; + + state->sh = sh; + + state->reply = talloc(state, struct sdap_msg); + if (state->reply == NULL) { + DEBUG(7, ("talloc failed.\n")); + talloc_zfree(req); + return NULL; + } + + state->ber = ber_alloc_t( LBER_USE_DER ); + if (state->ber == NULL) { + DEBUG(7, ("ber_alloc_t failed.\n")); + talloc_zfree(req); + return NULL; + } + + ret = ber_printf( state->ber, "{tststs}", LDAP_TAG_EXOP_MODIFY_PASSWD_ID, + user_dn, + LDAP_TAG_EXOP_MODIFY_PASSWD_OLD, password, + LDAP_TAG_EXOP_MODIFY_PASSWD_NEW, new_password); + if (ret == -1) { + DEBUG(1, ("ber_printf failed.\n")); + talloc_zfree(req); + return NULL; + } + + ret = ber_flatten(state->ber, &state->bv); + if (ret == -1) { + DEBUG(1, ("ber_flatten failed.\n")); + talloc_zfree(req); + return NULL; + } + + DEBUG(4, ("Executing extended operation\n")); + + ret = ldap_extended_operation(state->sh->ldap, LDAP_EXOP_MODIFY_PASSWD, + state->bv, NULL, NULL, &state->msgid); + if (ret == -1 || state->msgid == -1) { + DEBUG(1, ("ldap_extended_operation failed\n")); + goto fail; + } + DEBUG(8, ("ldap_extended_operation sent, msgid = %d\n", state->msgid)); + + /* FIXME: get timeouts from configuration, for now 5 secs. */ + ret = sdap_op_add(state, ev, state->sh, state->msgid, + sdap_exop_modify_passwd_done, req, 5); + if (ret) { + DEBUG(1, ("Failed to set up operation!\n")); + goto fail; + } + + return req; + +fail: + tevent_req_error(req, EIO); + tevent_req_post(req, ev); + return req; +} + +static void sdap_exop_modify_passwd_done(void *pvt, int error, struct sdap_msg *reply) +{ + struct tevent_req *req = talloc_get_type(pvt, struct tevent_req); + struct sdap_exop_modify_passwd_state *state = tevent_req_data(req, + struct sdap_exop_modify_passwd_state); + char *errmsg; + int ret; + + if (error) { + tevent_req_error(req, error); + return; + } + + state->reply = talloc_steal(state, reply); + + ret = ldap_parse_result(state->sh->ldap, state->reply->msg, + &state->result, NULL, &errmsg, NULL, NULL, 0); + if (ret != LDAP_SUCCESS) { + DEBUG(2, ("ldap_parse_result failed (%d)\n", state->msgid)); + tevent_req_error(req, EIO); + return; + } + + DEBUG(3, ("ldap_extended_operation result: %s(%d), %s\n", + ldap_err2string(state->result), state->result, errmsg)); + + tevent_req_done(req); +} + +int sdap_exop_modify_passwd_recv(struct tevent_req *req, + enum sdap_result *result) +{ + struct sdap_exop_modify_passwd_state *state = tevent_req_data(req, + struct sdap_exop_modify_passwd_state); + enum tevent_req_state tstate; + uint64_t err; + + *result = SDAP_ERROR; + + if (tevent_req_is_error(req, &tstate, &err)) { + return err; + } + + if (state->result == LDAP_SUCCESS) { + *result = SDAP_SUCCESS; + } + + return EOK; +} diff --git a/server/providers/ldap/sdap_async.h b/server/providers/ldap/sdap_async.h index 6ed9532..4012729 100644 --- a/server/providers/ldap/sdap_async.h +++ b/server/providers/ldap/sdap_async.h @@ -85,3 +85,11 @@ struct tevent_req *sdap_get_initgr_send(TALLOC_CTX *memctx, const char *name, const char **grp_attrs); int sdap_get_initgr_recv(struct tevent_req *req); + +struct tevent_req *sdap_exop_modify_passwd_send(TALLOC_CTX *memctx, + struct tevent_context *ev, + struct sdap_handle *sh, + char *user_dn, + char *password, + char *new_password); +int sdap_exop_modify_passwd_recv(struct tevent_req *req, enum sdap_result *result); -- 1.6.2.5 From sbose at redhat.com Tue Jul 21 13:00:23 2009 From: sbose at redhat.com (Sumit Bose) Date: Tue, 21 Jul 2009 15:00:23 +0200 Subject: [Freeipa-devel] [PATCHES] added chpass target to proxy and LDAP backend In-Reply-To: <20090721124539.GF3285@localhost.localdomain> References: <20090721124539.GF3285@localhost.localdomain> Message-ID: <20090721130023.GG3285@localhost.localdomain> On Tue, Jul 21, 2009 at 02:45:39PM +0200, Sumit Bose wrote: > Hi, > > the included patches will add the chpass target to the proxy and LDAP > backend (one of them will add the access target to then proxy backend, > too). While the proxy targets are simply calls to the old pam handler, > the LDAP chpass target uses the latest scheme pushed by Simo yesterday. > Simo can you please check if I got it right? > ah, I forgot. While testing I recognised that pam_sss does not play well with pam_cracklib. password sufficient pam_unix.so sha512 shadow nullok try_first_pass password sufficient pam_sss.so password required pam_deny.so will work. I'm quite sure I have already written a patch for this, but cannot find it. Is there a way to ask git to show all patches in all branches which changes a specific file? bye, Sumit From sgallagh at redhat.com Tue Jul 21 13:08:29 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 21 Jul 2009 09:08:29 -0400 Subject: [Freeipa-devel] [PATCHES] added chpass target to proxy and LDAP backend In-Reply-To: <20090721130023.GG3285@localhost.localdomain> References: <20090721124539.GF3285@localhost.localdomain> <20090721130023.GG3285@localhost.localdomain> Message-ID: <4A65BDCD.2060202@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/21/2009 09:00 AM, Sumit Bose wrote: > On Tue, Jul 21, 2009 at 02:45:39PM +0200, Sumit Bose wrote: >> Hi, >> >> the included patches will add the chpass target to the proxy and LDAP >> backend (one of them will add the access target to then proxy backend, >> too). While the proxy targets are simply calls to the old pam handler, >> the LDAP chpass target uses the latest scheme pushed by Simo yesterday. >> Simo can you please check if I got it right? >> > > ah, I forgot. While testing I recognised that pam_sss does not play well > with pam_cracklib. > > password sufficient pam_unix.so sha512 shadow nullok try_first_pass > password sufficient pam_sss.so > password required pam_deny.so > > will work. > > I'm quite sure I have already written a patch for this, but cannot find > it. Is there a way to ask git to show all patches in all branches which > changes a specific file? In the gitweb interface, select the file and look at its history. I don't think that deals with multiple branches at once, but it should narrow your search. > > 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/ iEYEARECAAYFAkplvcYACgkQeiVVYja6o6PR/wCeJOE7y4nF/UGii4KeGhn4XD9J JekAmgI9yq+X9whG9Qj5LLtZu/8gm41w =WwrD -----END PGP SIGNATURE----- From ssorce at redhat.com Tue Jul 21 15:50:13 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 21 Jul 2009 11:50:13 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Add 'make srpms' target In-Reply-To: <4A64BCD3.7090401@redhat.com> References: <4A64BCD3.7090401@redhat.com> Message-ID: <1248191413.29458.279.camel@localhost.localdomain> On Mon, 2009-07-20 at 14:52 -0400, Stephen Gallagher wrote: > > > This will be useful for setting up automated builds. We can generate a > single SRPM and then use mock to create the RPMS for multiple > platforms. Ack Simo. -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Tue Jul 21 15:56:27 2009 From: sbose at redhat.com (Sumit Bose) Date: Tue, 21 Jul 2009 17:56:27 +0200 Subject: [Freeipa-devel] [PATCHES] added chpass target to proxy and LDAP backend In-Reply-To: <20090721124539.GF3285@localhost.localdomain> References: <20090721124539.GF3285@localhost.localdomain> Message-ID: <20090721155627.GA32433@localhost.localdomain> On Tue, Jul 21, 2009 at 02:45:39PM +0200, Sumit Bose wrote: > Hi, > > the included patches will add the chpass target to the proxy and LDAP > backend (one of them will add the access target to then proxy backend, > too). While the proxy targets are simply calls to the old pam handler, > the LDAP chpass target uses the latest scheme pushed by Simo yesterday. > Simo can you please check if I got it right? > In response to a discussion on irc I've made to following changes: - auth_recv and auth4chpass_recv are united into auth_recv - remove BER stuff from the state structure and make sure is it freed after use - init state->result with NULL. bye, Sumit -------------- next part -------------- >From 5e8ed566296d5390d51def73f041c9bd9f510995 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Thu, 16 Jul 2009 16:40:29 +0200 Subject: [PATCH 1/2] add handling of the new backend targets to proxy backend --- server/providers/proxy.c | 30 ++++++++++++++++++++++++++++++ 1 files changed, 30 insertions(+), 0 deletions(-) diff --git a/server/providers/proxy.c b/server/providers/proxy.c index aa5b1c9..ddfbe39 100644 --- a/server/providers/proxy.c +++ b/server/providers/proxy.c @@ -2069,6 +2069,18 @@ struct bet_ops proxy_auth_ops = { .finalize = proxy_auth_shutdown }; +struct bet_ops proxy_access_ops = { + .check_online = proxy_check_online, + .handler = proxy_pam_handler, + .finalize = proxy_auth_shutdown +}; + +struct bet_ops proxy_chpass_ops = { + .check_online = proxy_check_online, + .handler = proxy_pam_handler, + .finalize = proxy_auth_shutdown +}; + static void *proxy_dlsym(void *handle, const char *functemp, char *libname) { char *funcname; @@ -2238,3 +2250,21 @@ done: } return ret; } + +int sssm_proxy_access_init(struct be_ctx *bectx, + struct bet_ops **ops, void **pvt_data) +{ + int ret; + ret = sssm_proxy_auth_init(bectx, ops, pvt_data); + *ops = &proxy_access_ops; + return ret; +} + +int sssm_proxy_chpass_init(struct be_ctx *bectx, + struct bet_ops **ops, void **pvt_data) +{ + int ret; + ret = sssm_proxy_auth_init(bectx, ops, pvt_data); + *ops = &proxy_chpass_ops; + return ret; +} -- 1.6.2.5 -------------- next part -------------- >From 7ba6da90c2a2fb7300f0443aa4fad9960245fd04 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 20 Jul 2009 17:27:02 +0200 Subject: [PATCH 2/2] added LDAP change password backend target --- server/providers/data_provider_be.c | 8 ++- server/providers/ldap/ldap_auth.c | 163 ++++++++++++++++++++++++++++++++++- server/providers/ldap/sdap_async.c | 134 ++++++++++++++++++++++++++++ server/providers/ldap/sdap_async.h | 8 ++ 4 files changed, 309 insertions(+), 4 deletions(-) diff --git a/server/providers/data_provider_be.c b/server/providers/data_provider_be.c index 5cd5994..2e0c1cf 100644 --- a/server/providers/data_provider_be.c +++ b/server/providers/data_provider_be.c @@ -631,8 +631,10 @@ static int be_pam_handler(DBusMessage *message, struct sbus_conn_ctx *sconn) } be_req = talloc_zero(ctx, struct be_req); - if (!be_req) + if (!be_req) { + DEBUG(7, ("talloc_zero failed.\n")); goto done; + } be_req->be_ctx = ctx; be_req->fn = be_pam_handler_callback; @@ -640,8 +642,10 @@ static int be_pam_handler(DBusMessage *message, struct sbus_conn_ctx *sconn) be_req->req_data = pd; ret = be_file_request(ctx, ctx->bet_info[target].bet_ops->handler, be_req); - if (ret != EOK) + if (ret != EOK) { + DEBUG(7, ("be_file_request failed.\n")); goto done; + } return EOK; diff --git a/server/providers/ldap/ldap_auth.c b/server/providers/ldap/ldap_auth.c index 2c53032..aa4f139 100644 --- a/server/providers/ldap/ldap_auth.c +++ b/server/providers/ldap/ldap_auth.c @@ -283,7 +283,8 @@ static void auth_bind_user_done(struct tevent_req *subreq) tevent_req_done(req); } -int auth_recv(struct tevent_req *req, enum sdap_result *result) +int auth_recv(struct tevent_req *req, enum sdap_result *result, + TALLOC_CTX *memctx, struct sdap_handle **sh, char **dn) { struct auth_state *state = tevent_req_data(req, struct auth_state); @@ -296,11 +297,153 @@ int auth_recv(struct tevent_req *req, enum sdap_result *result) return EOK; } + if (memctx != NULL) { + if (sh != NULL) { + *sh = talloc_steal(memctx, state->sh); + if (*sh == NULL) return ENOMEM; + } + + if (dn != NULL) { + *dn = talloc_steal(memctx, state->dn); + if (*dn == NULL) return ENOMEM; + } + } + *result = state->result; return EOK; } +/* ==Perform-Password-Change===================== */ + +struct sdap_pam_chpass_state { + struct be_req *breq; + struct pam_data *pd; + const char *username; + char *dn; + char *password; + char *new_password; + struct sdap_handle *sh; +}; + +static void sdap_auth4chpass_done(struct tevent_req *req); +static void sdap_pam_chpass_done(struct tevent_req *req); +static void sdap_pam_auth_reply(struct be_req *breq, int result); + +static void sdap_pam_chpass_send(struct be_req *breq) +{ + struct sdap_pam_chpass_state *state; + struct sdap_auth_ctx *ctx; + struct tevent_req *subreq; + struct pam_data *pd; + + ctx = talloc_get_type(breq->be_ctx->bet_info[BET_CHPASS].pvt_bet_data, + struct sdap_auth_ctx); + pd = talloc_get_type(breq->req_data, struct pam_data); + + DEBUG(2, ("starting password change request for user [%s].\n", pd->user)); + + pd->pam_status = PAM_SYSTEM_ERR; + + if (pd->cmd != SSS_PAM_CHAUTHTOK) { + DEBUG(2, ("chpass target was called by wrong pam command.\n")); + goto done; + } + + state = talloc_zero(breq, struct sdap_pam_chpass_state); + if (!state) goto done; + + state->breq = breq; + state->pd = pd; + state->username = pd->user; + state->password = talloc_strndup(state, + (char *)pd->authtok, pd->authtok_size); + if (!state->password) goto done; + talloc_set_destructor((TALLOC_CTX *)state->password, + password_destructor); + state->new_password = talloc_strndup(state, + (char *)pd->newauthtok, + pd->newauthtok_size); + if (!state->new_password) goto done; + talloc_set_destructor((TALLOC_CTX *)state->new_password, + password_destructor); + + subreq = auth_send(breq, breq->be_ctx->ev, + ctx, state->username, state->password); + if (!subreq) goto done; + + tevent_req_set_callback(subreq, sdap_auth4chpass_done, state); + return; +done: + sdap_pam_auth_reply(breq, pd->pam_status); +} + +static void sdap_auth4chpass_done(struct tevent_req *req) +{ + struct sdap_pam_chpass_state *state = + tevent_req_callback_data(req, struct sdap_pam_chpass_state); + struct tevent_req *subreq; + enum sdap_result result; + int ret; + + ret = auth_recv(req, &result, state, &state->sh, &state->dn); + talloc_zfree(req); + if (ret) { + state->pd->pam_status = PAM_SYSTEM_ERR; + goto done; + } + + + switch (result) { + case SDAP_AUTH_SUCCESS: + DEBUG(7, ("user [%s] successfully authenticated.\n", state->dn)); + subreq = sdap_exop_modify_passwd_send(state, + state->breq->be_ctx->ev, + state->sh, + state->dn, + state->password, + state->new_password); + + if (!subreq) { + DEBUG(2, ("Failed to change password for %s\n", state->username)); + goto done; + } + + tevent_req_set_callback(subreq, sdap_pam_chpass_done, state); + return; + break; + default: + state->pd->pam_status = PAM_SYSTEM_ERR; + } + +done: + sdap_pam_auth_reply(state->breq, state->pd->pam_status); +} + +static void sdap_pam_chpass_done(struct tevent_req *req) +{ + struct sdap_pam_chpass_state *state = + tevent_req_callback_data(req, struct sdap_pam_chpass_state); + enum sdap_result result; + int ret; + ret = sdap_exop_modify_passwd_recv(req, &result); + talloc_zfree(req); + if (ret) { + state->pd->pam_status = PAM_SYSTEM_ERR; + goto done; + } + + switch (result) { + case SDAP_SUCCESS: + state->pd->pam_status = PAM_SUCCESS; + break; + default: + state->pd->pam_status = PAM_SYSTEM_ERR; + } + +done: + sdap_pam_auth_reply(state->breq, state->pd->pam_status); +} /* ==Perform-User-Authentication-and-Password-Caching===================== */ struct sdap_pam_auth_state { @@ -369,7 +512,7 @@ static void sdap_pam_auth_done(struct tevent_req *req) enum sdap_result result; int ret; - ret = auth_recv(req, &result); + ret = auth_recv(req, &result, NULL, NULL, NULL); talloc_zfree(req); if (ret) { state->pd->pam_status = PAM_SYSTEM_ERR; @@ -453,6 +596,12 @@ struct bet_ops sdap_auth_ops = { .finalize = sdap_shutdown }; +struct bet_ops sdap_chpass_ops = { + .check_online = NULL, + .handler = sdap_pam_chpass_send, + .finalize = sdap_shutdown +}; + int sssm_ldap_auth_init(struct be_ctx *bectx, struct bet_ops **ops, void **pvt_data) @@ -514,3 +663,13 @@ done: } return ret; } + +int sssm_ldap_chpass_init(struct be_ctx *bectx, + struct bet_ops **ops, + void **pvt_data) +{ + int ret; + ret = sssm_ldap_auth_init(bectx, ops, pvt_data); + *ops = &sdap_chpass_ops; + return ret; +} diff --git a/server/providers/ldap/sdap_async.c b/server/providers/ldap/sdap_async.c index 57234e3..d5e42f0 100644 --- a/server/providers/ldap/sdap_async.c +++ b/server/providers/ldap/sdap_async.c @@ -1639,3 +1639,137 @@ int sdap_get_initgr_recv(struct tevent_req *req) return EOK; } +struct sdap_exop_modify_passwd_state { + struct sdap_handle *sh; + int msgid; + char *user_dn; + char *password; + char *new_password; + int result; + struct sdap_msg *reply; +}; + +static void sdap_exop_modify_passwd_done(void *pvt, int error, struct sdap_msg *reply); + +struct tevent_req *sdap_exop_modify_passwd_send(TALLOC_CTX *memctx, + struct tevent_context *ev, + struct sdap_handle *sh, + char *user_dn, + char *password, + char *new_password) +{ + struct tevent_req *req = NULL; + struct sdap_exop_modify_passwd_state *state; + int ret; + BerElement *ber = NULL; + struct berval *bv = NULL; + + req = tevent_req_create(memctx, &state, + struct sdap_exop_modify_passwd_state); + if (!req) return NULL; + + state->sh = sh; + state->reply = NULL; + + ber = ber_alloc_t( LBER_USE_DER ); + if (ber == NULL) { + DEBUG(7, ("ber_alloc_t failed.\n")); + talloc_zfree(req); + return NULL; + } + + ret = ber_printf( ber, "{tststs}", LDAP_TAG_EXOP_MODIFY_PASSWD_ID, + user_dn, + LDAP_TAG_EXOP_MODIFY_PASSWD_OLD, password, + LDAP_TAG_EXOP_MODIFY_PASSWD_NEW, new_password); + if (ret == -1) { + DEBUG(1, ("ber_printf failed.\n")); + ber_free(ber, 1); + talloc_zfree(req); + return NULL; + } + + ret = ber_flatten(ber, &bv); + ber_free(ber, 1); + if (ret == -1) { + DEBUG(1, ("ber_flatten failed.\n")); + talloc_zfree(req); + return NULL; + } + + DEBUG(4, ("Executing extended operation\n")); + + ret = ldap_extended_operation(state->sh->ldap, LDAP_EXOP_MODIFY_PASSWD, + bv, NULL, NULL, &state->msgid); + ber_bvfree(bv); + if (ret == -1 || state->msgid == -1) { + DEBUG(1, ("ldap_extended_operation failed\n")); + goto fail; + } + DEBUG(8, ("ldap_extended_operation sent, msgid = %d\n", state->msgid)); + + /* FIXME: get timeouts from configuration, for now 5 secs. */ + ret = sdap_op_add(state, ev, state->sh, state->msgid, + sdap_exop_modify_passwd_done, req, 5); + if (ret) { + DEBUG(1, ("Failed to set up operation!\n")); + goto fail; + } + + return req; + +fail: + tevent_req_error(req, EIO); + tevent_req_post(req, ev); + return req; +} + +static void sdap_exop_modify_passwd_done(void *pvt, int error, struct sdap_msg *reply) +{ + struct tevent_req *req = talloc_get_type(pvt, struct tevent_req); + struct sdap_exop_modify_passwd_state *state = tevent_req_data(req, + struct sdap_exop_modify_passwd_state); + char *errmsg; + int ret; + + if (error) { + tevent_req_error(req, error); + return; + } + + state->reply = talloc_steal(state, reply); + + ret = ldap_parse_result(state->sh->ldap, state->reply->msg, + &state->result, NULL, &errmsg, NULL, NULL, 0); + if (ret != LDAP_SUCCESS) { + DEBUG(2, ("ldap_parse_result failed (%d)\n", state->msgid)); + tevent_req_error(req, EIO); + return; + } + + DEBUG(3, ("ldap_extended_operation result: %s(%d), %s\n", + ldap_err2string(state->result), state->result, errmsg)); + + tevent_req_done(req); +} + +int sdap_exop_modify_passwd_recv(struct tevent_req *req, + enum sdap_result *result) +{ + struct sdap_exop_modify_passwd_state *state = tevent_req_data(req, + struct sdap_exop_modify_passwd_state); + enum tevent_req_state tstate; + uint64_t err; + + *result = SDAP_ERROR; + + if (tevent_req_is_error(req, &tstate, &err)) { + return err; + } + + if (state->result == LDAP_SUCCESS) { + *result = SDAP_SUCCESS; + } + + return EOK; +} diff --git a/server/providers/ldap/sdap_async.h b/server/providers/ldap/sdap_async.h index 6ed9532..4012729 100644 --- a/server/providers/ldap/sdap_async.h +++ b/server/providers/ldap/sdap_async.h @@ -85,3 +85,11 @@ struct tevent_req *sdap_get_initgr_send(TALLOC_CTX *memctx, const char *name, const char **grp_attrs); int sdap_get_initgr_recv(struct tevent_req *req); + +struct tevent_req *sdap_exop_modify_passwd_send(TALLOC_CTX *memctx, + struct tevent_context *ev, + struct sdap_handle *sh, + char *user_dn, + char *password, + char *new_password); +int sdap_exop_modify_passwd_recv(struct tevent_req *req, enum sdap_result *result); -- 1.6.2.5 From sgallagh at redhat.com Tue Jul 21 15:58:36 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 21 Jul 2009 11:58:36 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Add 'make srpms' target In-Reply-To: <1248191413.29458.279.camel@localhost.localdomain> References: <4A64BCD3.7090401@redhat.com> <1248191413.29458.279.camel@localhost.localdomain> Message-ID: <4A65E5AC.3080105@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/21/2009 11:50 AM, Simo Sorce wrote: > On Mon, 2009-07-20 at 14:52 -0400, Stephen Gallagher wrote: >> >> This will be useful for setting up automated builds. We can generate a >> single SRPM and then use mock to create the RPMS for multiple >> platforms. > > Ack > 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/ iEUEARECAAYFAkpl5aUACgkQeiVVYja6o6MGowCfd8omL4cm2LcFiOjCcsJC3r5s +BEAliad5FkHvK58KahI56i1F7ZBjzM= =v/6O -----END PGP SIGNATURE----- From sbose at redhat.com Tue Jul 21 16:58:58 2009 From: sbose at redhat.com (Sumit Bose) Date: Tue, 21 Jul 2009 18:58:58 +0200 Subject: [Freeipa-devel] [PATCHES] added chpass target to proxy and LDAP backend In-Reply-To: <20090721155627.GA32433@localhost.localdomain> References: <20090721124539.GF3285@localhost.localdomain> <20090721155627.GA32433@localhost.localdomain> Message-ID: <20090721165858.GB32433@localhost.localdomain> On Tue, Jul 21, 2009 at 05:56:27PM +0200, Sumit Bose wrote: > On Tue, Jul 21, 2009 at 02:45:39PM +0200, Sumit Bose wrote: > > Hi, > > > > the included patches will add the chpass target to the proxy and LDAP > > backend (one of them will add the access target to then proxy backend, > > too). While the proxy targets are simply calls to the old pam handler, > > the LDAP chpass target uses the latest scheme pushed by Simo yesterday. > > Simo can you please check if I got it right? > > > > In response to a discussion on irc I've made to following changes: > > - auth_recv and auth4chpass_recv are united into auth_recv > - remove BER stuff from the state structure and make sure is it freed > after use > - init state->result with NULL. > removed the memctx == NULL check. bye, Sumit -------------- next part -------------- >From 5e8ed566296d5390d51def73f041c9bd9f510995 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Thu, 16 Jul 2009 16:40:29 +0200 Subject: [PATCH 1/2] add handling of the new backend targets to proxy backend --- server/providers/proxy.c | 30 ++++++++++++++++++++++++++++++ 1 files changed, 30 insertions(+), 0 deletions(-) diff --git a/server/providers/proxy.c b/server/providers/proxy.c index aa5b1c9..ddfbe39 100644 --- a/server/providers/proxy.c +++ b/server/providers/proxy.c @@ -2069,6 +2069,18 @@ struct bet_ops proxy_auth_ops = { .finalize = proxy_auth_shutdown }; +struct bet_ops proxy_access_ops = { + .check_online = proxy_check_online, + .handler = proxy_pam_handler, + .finalize = proxy_auth_shutdown +}; + +struct bet_ops proxy_chpass_ops = { + .check_online = proxy_check_online, + .handler = proxy_pam_handler, + .finalize = proxy_auth_shutdown +}; + static void *proxy_dlsym(void *handle, const char *functemp, char *libname) { char *funcname; @@ -2238,3 +2250,21 @@ done: } return ret; } + +int sssm_proxy_access_init(struct be_ctx *bectx, + struct bet_ops **ops, void **pvt_data) +{ + int ret; + ret = sssm_proxy_auth_init(bectx, ops, pvt_data); + *ops = &proxy_access_ops; + return ret; +} + +int sssm_proxy_chpass_init(struct be_ctx *bectx, + struct bet_ops **ops, void **pvt_data) +{ + int ret; + ret = sssm_proxy_auth_init(bectx, ops, pvt_data); + *ops = &proxy_chpass_ops; + return ret; +} -- 1.6.2.5 -------------- next part -------------- >From fb6ca1baf3a302f2629560f2c0ec1ab30159a69c Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 20 Jul 2009 17:27:02 +0200 Subject: [PATCH 2/2] added LDAP change password backend target --- server/providers/data_provider_be.c | 8 ++- server/providers/ldap/ldap_auth.c | 161 ++++++++++++++++++++++++++++++++++- server/providers/ldap/sdap_async.c | 134 +++++++++++++++++++++++++++++ server/providers/ldap/sdap_async.h | 8 ++ 4 files changed, 307 insertions(+), 4 deletions(-) diff --git a/server/providers/data_provider_be.c b/server/providers/data_provider_be.c index 5cd5994..2e0c1cf 100644 --- a/server/providers/data_provider_be.c +++ b/server/providers/data_provider_be.c @@ -631,8 +631,10 @@ static int be_pam_handler(DBusMessage *message, struct sbus_conn_ctx *sconn) } be_req = talloc_zero(ctx, struct be_req); - if (!be_req) + if (!be_req) { + DEBUG(7, ("talloc_zero failed.\n")); goto done; + } be_req->be_ctx = ctx; be_req->fn = be_pam_handler_callback; @@ -640,8 +642,10 @@ static int be_pam_handler(DBusMessage *message, struct sbus_conn_ctx *sconn) be_req->req_data = pd; ret = be_file_request(ctx, ctx->bet_info[target].bet_ops->handler, be_req); - if (ret != EOK) + if (ret != EOK) { + DEBUG(7, ("be_file_request failed.\n")); goto done; + } return EOK; diff --git a/server/providers/ldap/ldap_auth.c b/server/providers/ldap/ldap_auth.c index 2c53032..f0b12a0 100644 --- a/server/providers/ldap/ldap_auth.c +++ b/server/providers/ldap/ldap_auth.c @@ -283,7 +283,8 @@ static void auth_bind_user_done(struct tevent_req *subreq) tevent_req_done(req); } -int auth_recv(struct tevent_req *req, enum sdap_result *result) +int auth_recv(struct tevent_req *req, enum sdap_result *result, + TALLOC_CTX *memctx, struct sdap_handle **sh, char **dn) { struct auth_state *state = tevent_req_data(req, struct auth_state); @@ -296,11 +297,151 @@ int auth_recv(struct tevent_req *req, enum sdap_result *result) return EOK; } + if (sh != NULL) { + *sh = talloc_steal(memctx, state->sh); + if (*sh == NULL) return ENOMEM; + } + + if (dn != NULL) { + *dn = talloc_steal(memctx, state->dn); + if (*dn == NULL) return ENOMEM; + } + *result = state->result; return EOK; } +/* ==Perform-Password-Change===================== */ + +struct sdap_pam_chpass_state { + struct be_req *breq; + struct pam_data *pd; + const char *username; + char *dn; + char *password; + char *new_password; + struct sdap_handle *sh; +}; +static void sdap_auth4chpass_done(struct tevent_req *req); +static void sdap_pam_chpass_done(struct tevent_req *req); +static void sdap_pam_auth_reply(struct be_req *breq, int result); + +static void sdap_pam_chpass_send(struct be_req *breq) +{ + struct sdap_pam_chpass_state *state; + struct sdap_auth_ctx *ctx; + struct tevent_req *subreq; + struct pam_data *pd; + + ctx = talloc_get_type(breq->be_ctx->bet_info[BET_CHPASS].pvt_bet_data, + struct sdap_auth_ctx); + pd = talloc_get_type(breq->req_data, struct pam_data); + + DEBUG(2, ("starting password change request for user [%s].\n", pd->user)); + + pd->pam_status = PAM_SYSTEM_ERR; + + if (pd->cmd != SSS_PAM_CHAUTHTOK) { + DEBUG(2, ("chpass target was called by wrong pam command.\n")); + goto done; + } + + state = talloc_zero(breq, struct sdap_pam_chpass_state); + if (!state) goto done; + + state->breq = breq; + state->pd = pd; + state->username = pd->user; + state->password = talloc_strndup(state, + (char *)pd->authtok, pd->authtok_size); + if (!state->password) goto done; + talloc_set_destructor((TALLOC_CTX *)state->password, + password_destructor); + state->new_password = talloc_strndup(state, + (char *)pd->newauthtok, + pd->newauthtok_size); + if (!state->new_password) goto done; + talloc_set_destructor((TALLOC_CTX *)state->new_password, + password_destructor); + + subreq = auth_send(breq, breq->be_ctx->ev, + ctx, state->username, state->password); + if (!subreq) goto done; + + tevent_req_set_callback(subreq, sdap_auth4chpass_done, state); + return; +done: + sdap_pam_auth_reply(breq, pd->pam_status); +} + +static void sdap_auth4chpass_done(struct tevent_req *req) +{ + struct sdap_pam_chpass_state *state = + tevent_req_callback_data(req, struct sdap_pam_chpass_state); + struct tevent_req *subreq; + enum sdap_result result; + int ret; + + ret = auth_recv(req, &result, state, &state->sh, &state->dn); + talloc_zfree(req); + if (ret) { + state->pd->pam_status = PAM_SYSTEM_ERR; + goto done; + } + + + switch (result) { + case SDAP_AUTH_SUCCESS: + DEBUG(7, ("user [%s] successfully authenticated.\n", state->dn)); + subreq = sdap_exop_modify_passwd_send(state, + state->breq->be_ctx->ev, + state->sh, + state->dn, + state->password, + state->new_password); + + if (!subreq) { + DEBUG(2, ("Failed to change password for %s\n", state->username)); + goto done; + } + + tevent_req_set_callback(subreq, sdap_pam_chpass_done, state); + return; + break; + default: + state->pd->pam_status = PAM_SYSTEM_ERR; + } + +done: + sdap_pam_auth_reply(state->breq, state->pd->pam_status); +} + +static void sdap_pam_chpass_done(struct tevent_req *req) +{ + struct sdap_pam_chpass_state *state = + tevent_req_callback_data(req, struct sdap_pam_chpass_state); + enum sdap_result result; + int ret; + + ret = sdap_exop_modify_passwd_recv(req, &result); + talloc_zfree(req); + if (ret) { + state->pd->pam_status = PAM_SYSTEM_ERR; + goto done; + } + + switch (result) { + case SDAP_SUCCESS: + state->pd->pam_status = PAM_SUCCESS; + break; + default: + state->pd->pam_status = PAM_SYSTEM_ERR; + } + +done: + sdap_pam_auth_reply(state->breq, state->pd->pam_status); +} /* ==Perform-User-Authentication-and-Password-Caching===================== */ struct sdap_pam_auth_state { @@ -369,7 +510,7 @@ static void sdap_pam_auth_done(struct tevent_req *req) enum sdap_result result; int ret; - ret = auth_recv(req, &result); + ret = auth_recv(req, &result, NULL, NULL, NULL); talloc_zfree(req); if (ret) { state->pd->pam_status = PAM_SYSTEM_ERR; @@ -453,6 +594,12 @@ struct bet_ops sdap_auth_ops = { .finalize = sdap_shutdown }; +struct bet_ops sdap_chpass_ops = { + .check_online = NULL, + .handler = sdap_pam_chpass_send, + .finalize = sdap_shutdown +}; + int sssm_ldap_auth_init(struct be_ctx *bectx, struct bet_ops **ops, void **pvt_data) @@ -514,3 +661,13 @@ done: } return ret; } + +int sssm_ldap_chpass_init(struct be_ctx *bectx, + struct bet_ops **ops, + void **pvt_data) +{ + int ret; + ret = sssm_ldap_auth_init(bectx, ops, pvt_data); + *ops = &sdap_chpass_ops; + return ret; +} diff --git a/server/providers/ldap/sdap_async.c b/server/providers/ldap/sdap_async.c index 57234e3..d5e42f0 100644 --- a/server/providers/ldap/sdap_async.c +++ b/server/providers/ldap/sdap_async.c @@ -1639,3 +1639,137 @@ int sdap_get_initgr_recv(struct tevent_req *req) return EOK; } +struct sdap_exop_modify_passwd_state { + struct sdap_handle *sh; + int msgid; + char *user_dn; + char *password; + char *new_password; + int result; + struct sdap_msg *reply; +}; + +static void sdap_exop_modify_passwd_done(void *pvt, int error, struct sdap_msg *reply); + +struct tevent_req *sdap_exop_modify_passwd_send(TALLOC_CTX *memctx, + struct tevent_context *ev, + struct sdap_handle *sh, + char *user_dn, + char *password, + char *new_password) +{ + struct tevent_req *req = NULL; + struct sdap_exop_modify_passwd_state *state; + int ret; + BerElement *ber = NULL; + struct berval *bv = NULL; + + req = tevent_req_create(memctx, &state, + struct sdap_exop_modify_passwd_state); + if (!req) return NULL; + + state->sh = sh; + state->reply = NULL; + + ber = ber_alloc_t( LBER_USE_DER ); + if (ber == NULL) { + DEBUG(7, ("ber_alloc_t failed.\n")); + talloc_zfree(req); + return NULL; + } + + ret = ber_printf( ber, "{tststs}", LDAP_TAG_EXOP_MODIFY_PASSWD_ID, + user_dn, + LDAP_TAG_EXOP_MODIFY_PASSWD_OLD, password, + LDAP_TAG_EXOP_MODIFY_PASSWD_NEW, new_password); + if (ret == -1) { + DEBUG(1, ("ber_printf failed.\n")); + ber_free(ber, 1); + talloc_zfree(req); + return NULL; + } + + ret = ber_flatten(ber, &bv); + ber_free(ber, 1); + if (ret == -1) { + DEBUG(1, ("ber_flatten failed.\n")); + talloc_zfree(req); + return NULL; + } + + DEBUG(4, ("Executing extended operation\n")); + + ret = ldap_extended_operation(state->sh->ldap, LDAP_EXOP_MODIFY_PASSWD, + bv, NULL, NULL, &state->msgid); + ber_bvfree(bv); + if (ret == -1 || state->msgid == -1) { + DEBUG(1, ("ldap_extended_operation failed\n")); + goto fail; + } + DEBUG(8, ("ldap_extended_operation sent, msgid = %d\n", state->msgid)); + + /* FIXME: get timeouts from configuration, for now 5 secs. */ + ret = sdap_op_add(state, ev, state->sh, state->msgid, + sdap_exop_modify_passwd_done, req, 5); + if (ret) { + DEBUG(1, ("Failed to set up operation!\n")); + goto fail; + } + + return req; + +fail: + tevent_req_error(req, EIO); + tevent_req_post(req, ev); + return req; +} + +static void sdap_exop_modify_passwd_done(void *pvt, int error, struct sdap_msg *reply) +{ + struct tevent_req *req = talloc_get_type(pvt, struct tevent_req); + struct sdap_exop_modify_passwd_state *state = tevent_req_data(req, + struct sdap_exop_modify_passwd_state); + char *errmsg; + int ret; + + if (error) { + tevent_req_error(req, error); + return; + } + + state->reply = talloc_steal(state, reply); + + ret = ldap_parse_result(state->sh->ldap, state->reply->msg, + &state->result, NULL, &errmsg, NULL, NULL, 0); + if (ret != LDAP_SUCCESS) { + DEBUG(2, ("ldap_parse_result failed (%d)\n", state->msgid)); + tevent_req_error(req, EIO); + return; + } + + DEBUG(3, ("ldap_extended_operation result: %s(%d), %s\n", + ldap_err2string(state->result), state->result, errmsg)); + + tevent_req_done(req); +} + +int sdap_exop_modify_passwd_recv(struct tevent_req *req, + enum sdap_result *result) +{ + struct sdap_exop_modify_passwd_state *state = tevent_req_data(req, + struct sdap_exop_modify_passwd_state); + enum tevent_req_state tstate; + uint64_t err; + + *result = SDAP_ERROR; + + if (tevent_req_is_error(req, &tstate, &err)) { + return err; + } + + if (state->result == LDAP_SUCCESS) { + *result = SDAP_SUCCESS; + } + + return EOK; +} diff --git a/server/providers/ldap/sdap_async.h b/server/providers/ldap/sdap_async.h index 6ed9532..4012729 100644 --- a/server/providers/ldap/sdap_async.h +++ b/server/providers/ldap/sdap_async.h @@ -85,3 +85,11 @@ struct tevent_req *sdap_get_initgr_send(TALLOC_CTX *memctx, const char *name, const char **grp_attrs); int sdap_get_initgr_recv(struct tevent_req *req); + +struct tevent_req *sdap_exop_modify_passwd_send(TALLOC_CTX *memctx, + struct tevent_context *ev, + struct sdap_handle *sh, + char *user_dn, + char *password, + char *new_password); +int sdap_exop_modify_passwd_recv(struct tevent_req *req, enum sdap_result *result); -- 1.6.2.5 From jhrozek at redhat.com Tue Jul 21 17:09:45 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 21 Jul 2009 19:09:45 +0200 Subject: [Freeipa-devel] [PATCHES] c-ares integration Message-ID: <4A65F659.9020409@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, The three attached patches integrate the c-ares async resolver library into SSSD. It is a follow-up to the code posted on this list earlier [1]. [PATCH 1/3] Async DNS integration This patch is the actual integration work with interface integrated with tevent and talloc which follows the _send/_recv notation. It also contains code to support build (like configure checks). [PATCH 2/3] Add ares helpers into sssd The second patch contains ares_parse_srv_reply() and ares_parse_txt_reply() routines that I sent to ares upstream. Also contains configure-time detection of these in the system ares library and builds them only if necessary. [PATCH 3/3] Add async resolver tests A basic unit test. One of the tests resolves a name on the Internet, so it must be explicitly enabled. Thanks, Jakub [1] https://www.redhat.com/archives/freeipa-devel/2009-July/msg00012.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpl9lkACgkQHsardTLnvCVimwCgvtElP389BQ/qZOnxLAfzCEtl XLMAoOSXW293BmQ5jzB1Vf7zVM/L38IO =Vdz0 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Async-DNS-integration.patch Type: text/x-patch Size: 23378 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-ares-helpers-into-sssd.patch Type: text/x-patch Size: 19593 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-async-resolver-tests.patch Type: text/x-patch Size: 10271 bytes Desc: not available URL: From ssorce at redhat.com Tue Jul 21 18:39:20 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 21 Jul 2009 14:39:20 -0400 Subject: [Freeipa-devel] [PATCHES] c-ares integration In-Reply-To: <4A65F659.9020409@redhat.com> References: <4A65F659.9020409@redhat.com> Message-ID: <1248201560.29458.304.camel@localhost.localdomain> On Tue, 2009-07-21 at 19:09 +0200, Jakub Hrozek wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > The three attached patches integrate the c-ares async resolver library > into SSSD. It is a follow-up to the code posted on this list earlier [1]. > > [PATCH 1/3] Async DNS integration > This patch is the actual integration work with interface integrated with > tevent and talloc which follows the _send/_recv notation. It also > contains code to support build (like configure checks). I am a bit concerned about memory hierarchies here. In fd_event_add() you add a new event context allocating it on the tevent_context memory context: + fde = tevent_add_fd(ctx->ev_ctx, ctx, s, TEVENT_FD_READ, fd_input_available, watch); This is bad because if I talloc_free() the resolv context later on on, all the events will not be freed but will stay around and watch->ctx will point to freed memory. Allocating the watch itself on the tevent_context is equally bad. Another potential problem I see is that, if I read the code correctly, resolv_gethostbyname_done() maybe called even if the original request was freed, this may cause the code to segfault when it calls tevent_req_XXX(req, ...) functions and tries to access freed memory. > [PATCH 2/3] Add ares helpers into sssd > The second patch contains ares_parse_srv_reply() and > ares_parse_txt_reply() routines that I sent to ares upstream. Also > contains configure-time detection of these in the system ares library > and builds them only if necessary. I am not an expert in c-ares, but it looks like the code is sane, one minor thing though. Unless upstream demands copyright assignment to MIT, I think we can maintain the copyright, and even if assignment is required we can do it only with the patches submitted to ares, no need to do so with code into the sssd repo itself. In any case the (C) is certainly not 1998. That is, unless you traveled back in time to write it :-) > [PATCH 3/3] Add async resolver tests > A basic unit test. One of the tests resolves a name on the Internet, so > it must be explicitly enabled. This look fine. Maybe when you take in account my comment to 1/3 you may want to add a test that does something like this: make a _send call then set a timer of 1 second and free the resolv_ctx, add another time of 1 second and then terminate. Perform this test with a firewall or a network cable disconnected so that you run into delays. Do the same but instead of freeing the resolv_ctx, simply free the tevent_req pointer returned by the _send() function. If the code survives without segfaults then it is probably correct. Ping me on IRC if you need some clarification on how to attain that. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Jul 21 18:42:39 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 21 Jul 2009 14:42:39 -0400 Subject: [Freeipa-devel] [PATCHES] added chpass target to proxy and LDAP backend In-Reply-To: <20090721165858.GB32433@localhost.localdomain> References: <20090721124539.GF3285@localhost.localdomain> <20090721155627.GA32433@localhost.localdomain> <20090721165858.GB32433@localhost.localdomain> Message-ID: <1248201759.29458.305.camel@localhost.localdomain> On Tue, 2009-07-21 at 18:58 +0200, Sumit Bose wrote: > > In response to a discussion on irc I've made to following changes: > > > > - auth_recv and auth4chpass_recv are united into auth_recv > > - remove BER stuff from the state structure and make sure is it > freed > > after use > > - init state->result with NULL. > > > > removed the memctx == NULL check. ack and pushed. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Jul 21 19:08:41 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 21 Jul 2009 15:08:41 -0400 Subject: [Freeipa-devel] [PATCH] handle kdb stash being a keytab In-Reply-To: <20090720215328.GA10770@redhat.com> References: <20090720215328.GA10770@redhat.com> Message-ID: <1248203321.29458.314.camel@localhost.localdomain> On Mon, 2009-07-20 at 17:53 -0400, Nalin Dahyabhai wrote: > In krb5 1.7 and later, the stash file > (/var/kerberos/krb5kdc/.k5.$REALM > on Fedora) is created in the regular keytab format instead of the > older > less-portable one. Based from comments and code in kt_file.c, here's > a > change to try to recognize that case (the file starts with a magic > number) and read the master key from Python. > > The KDC will still read either format, so I left the bits that set > things up on replicas alone (advice appreciated). The patch works as > expected on my 64-bit box, both on RHEL5 (krb5 1.6.1 with a > traditional > stash file) and on Raw Hide (krb5 1.7 with a keytab). Ack Simo. -- Simo Sorce * Red Hat, Inc * New York From kwade at redhat.com Wed Jul 22 05:20:36 2009 From: kwade at redhat.com (Karsten Wade) Date: Tue, 21 Jul 2009 22:20:36 -0700 Subject: [Freeipa-devel] contribution policy draft In-Reply-To: <4A5DB003.3030404@redhat.com> References: <20090715044601.GB29035@calliope.phig.org> <4A5DB003.3030404@redhat.com> Message-ID: <20090722052036.GG12672@calliope.phig.org> On Wed, Jul 15, 2009 at 06:31:31AM -0400, Stephen Gallagher wrote: > Karsten, I'd also like to put together something similar for the SSSD > contribution page (not currently existing in any useful form). The SSSD > has some different licensing requirements, however. While all portions > of the server should be GPL (version debatable), we have several shared > libraries that need to be LGPL, and we also have a nebulous set of > plugins that are loaded by server-processes*. These last present a > somewhat troublesome legal question. Stephen: Have you had a chance to talk with RHT Legal about this? What I'd recommend is that we forward the details and make an appointment with Richard Fontana; I think the high-bandwidth of a phone call works especially well with lawyers, unless it's all clear to him via email. We can report back here the results; I'd like to participate as part of coordinating license and contribution policies. If that sounds good, I can forward your email and see where it leads us next; I'm widely available for a call. - 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 sbose at redhat.com Wed Jul 22 10:52:22 2009 From: sbose at redhat.com (Sumit Bose) Date: Wed, 22 Jul 2009 12:52:22 +0200 Subject: [Freeipa-devel] [PATCH] cleanup of pam_sss Message-ID: <20090722105222.GA30242@localhost.localdomain> Hi, this patch should make pam_sss.c considerably more readable and should allow to use modules like pam_cracklib together with pam_sss. I hope I have caught all corner cases. bye, Sumit -------------- next part -------------- >From 6ef2163a793e52d02faeb922d74c4fb29cb725d0 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 22 Jul 2009 12:46:24 +0200 Subject: [PATCH] cleanup of pam_sss - make pam_sss work with pam_cracklib and similar pam modules - clean up the if-&&-else-|| jungle to make clear what is happening --- sss_client/pam_sss.c | 487 +++++++++++++++++++++++++------------------------- 1 files changed, 241 insertions(+), 246 deletions(-) diff --git a/sss_client/pam_sss.c b/sss_client/pam_sss.c index bec6469..71c66ef 100644 --- a/sss_client/pam_sss.c +++ b/sss_client/pam_sss.c @@ -1,4 +1,3 @@ - #define PAM_SM_AUTH #define PAM_SM_ACCOUNT #define PAM_SM_SESSION @@ -121,7 +120,8 @@ static size_t add_string_item(enum pam_item_type type, const char *str, return rp; } -static int pack_message_v2(struct pam_items *pi, size_t *size, uint8_t **buffer) { +static int pack_message_v2(struct pam_items *pi, size_t *size, + uint8_t **buffer) { int len; uint8_t *buf; int rp; @@ -199,77 +199,6 @@ static int pack_message_v2(struct pam_items *pi, size_t *size, uint8_t **buffer) return 0; } -#if 0 -static int pack_message(struct pam_items *pi, size_t *size, uint8_t **buffer) { - int len; - uint8_t *buf; - int rp; - - len = pi->pam_user_size + - pi->pam_service_size + - pi->pam_tty_size + - pi->pam_ruser_size + - pi->pam_rhost_size + - 2*sizeof(uint32_t) + pi->pam_authtok_size + - 2*sizeof(uint32_t) + pi->pam_newauthtok_size + - sizeof(uint32_t); - - buf = malloc(len); - if (buf == NULL) { - D(("malloc failed.")); - return PAM_BUF_ERR; - } - - memcpy(buf, pi->pam_user, pi->pam_user_size); - rp = pi->pam_user_size; - - memcpy(&buf[rp], pi->pam_service, pi->pam_service_size); - rp += pi->pam_service_size; - - memcpy(&buf[rp], pi->pam_tty, pi->pam_tty_size); - rp += pi->pam_tty_size; - - memcpy(&buf[rp], pi->pam_ruser, pi->pam_ruser_size); - rp += pi->pam_ruser_size; - - memcpy(&buf[rp], pi->pam_rhost, pi->pam_rhost_size); - rp += pi->pam_rhost_size; - - ((uint32_t *)(&buf[rp]))[0] = pi->pam_authtok_type; - rp += sizeof(uint32_t); - ((uint32_t *)(&buf[rp]))[0] = pi->pam_authtok_size; - rp += sizeof(uint32_t); - memcpy(&buf[rp], pi->pam_authtok, pi->pam_authtok_size); - rp += pi->pam_authtok_size; - _pam_overwrite((void *)pi->pam_authtok); - free((void *)pi->pam_authtok); - pi->pam_authtok = NULL; - - ((uint32_t *)(&buf[rp]))[0] = pi->pam_newauthtok_type; - rp += sizeof(uint32_t); - ((uint32_t *)(&buf[rp]))[0] = pi->pam_newauthtok_size; - rp += sizeof(uint32_t); - memcpy(&buf[rp], pi->pam_newauthtok, pi->pam_newauthtok_size); - rp += pi->pam_newauthtok_size; - _pam_overwrite((void *)pi->pam_newauthtok); - free((void *)pi->pam_newauthtok); - pi->pam_newauthtok = NULL; - - ((uint32_t *)(&buf[rp]))[0] = END_OF_PAM_REQUEST; - rp += sizeof(uint32_t); - - if (rp != len) { - D(("error during packet creation.")); - return PAM_BUF_ERR; - } - - *size = len; - *buffer = buf; - - return 0; -} -#endif - static int null_strcmp(const char *s1, const char *s2) { if (s1 == NULL && s2 == NULL) return 0; if (s1 == NULL && s2 != NULL) return -1; @@ -297,7 +226,8 @@ static int do_pam_conversation(pam_handle_t *pamh, const int msg_style, if ((msg_style == PAM_TEXT_INFO || msg_style == PAM_ERROR_MSG) && msg == NULL) return PAM_SYSTEM_ERR; - if ((msg_style == PAM_PROMPT_ECHO_OFF || msg_style == PAM_PROMPT_ECHO_ON) && + if ((msg_style == PAM_PROMPT_ECHO_OFF || + msg_style == PAM_PROMPT_ECHO_ON) && (msg == NULL || answer == NULL)) return PAM_SYSTEM_ERR; ret=pam_get_item(pamh, PAM_CONV, (const void **) &conv); @@ -325,7 +255,8 @@ static int do_pam_conversation(pam_handle_t *pamh, const int msg_style, return ret; } - if (msg_style == PAM_PROMPT_ECHO_OFF || msg_style == PAM_PROMPT_ECHO_ON) { + if (msg_style == PAM_PROMPT_ECHO_OFF || + msg_style == PAM_PROMPT_ECHO_ON) { if (resp == NULL) { D(("response expected, but resp==NULL")); return PAM_SYSTEM_ERR; @@ -342,8 +273,8 @@ static int do_pam_conversation(pam_handle_t *pamh, const int msg_style, *answer = NULL; } ret = do_pam_conversation(pamh, PAM_ERROR_MSG, - _("Passwords do not match"), NULL, - NULL); + _("Passwords do not match"), + NULL, NULL); if (ret != PAM_SUCCESS) { D(("do_pam_conversation failed.")); return PAM_SYSTEM_ERR; @@ -493,9 +424,17 @@ static int get_pam_items(pam_handle_t *pamh, struct pam_items *pi) ret = pam_get_item(pamh, PAM_USER, (const void **) &(pi->pam_user)); if (ret != PAM_SUCCESS) return ret; - if (pi->pam_user == NULL) pi->pam_user=""; + if (pi->pam_user == NULL) { + D(("No user found, aborting.")); + return PAM_BAD_ITEM; + } + if (strcmp(pi->pam_user, "root") == 0) { + D(("pam_sss will not handle root.")); + return PAM_USER_UNKNOWN; + } pi->pam_user_size=strlen(pi->pam_user)+1; + ret = pam_get_item(pamh, PAM_TTY, (const void **) &(pi->pam_tty)); if (ret != PAM_SUCCESS) return ret; if (pi->pam_tty == NULL) pi->pam_tty=""; @@ -511,11 +450,13 @@ static int get_pam_items(pam_handle_t *pamh, struct pam_items *pi) if (pi->pam_rhost == NULL) pi->pam_rhost=""; pi->pam_rhost_size=strlen(pi->pam_rhost)+1; - ret = pam_get_item(pamh, PAM_AUTHTOK, (const void **) &(pi->pamstack_authtok)); + ret = pam_get_item(pamh, PAM_AUTHTOK, + (const void **) &(pi->pamstack_authtok)); if (ret != PAM_SUCCESS) return ret; if (pi->pamstack_authtok == NULL) pi->pamstack_authtok=""; - ret = pam_get_item(pamh, PAM_OLDAUTHTOK, (const void **) &(pi->pamstack_oldauthtok)); + ret = pam_get_item(pamh, PAM_OLDAUTHTOK, + (const void **) &(pi->pamstack_oldauthtok)); if (ret != PAM_SUCCESS) return ret; if (pi->pamstack_oldauthtok == NULL) pi->pamstack_oldauthtok=""; @@ -531,183 +472,44 @@ static int get_pam_items(pam_handle_t *pamh, struct pam_items *pi) return PAM_SUCCESS; } -static void print_pam_items(struct pam_items pi) +static void print_pam_items(struct pam_items *pi) { - D(("Service: %s", *pi.pam_service!='\0' ? pi.pam_service : "(not available)")); - D(("User: %s", *pi.pam_user!='\0' ? pi.pam_user : "(not available)")); - D(("Tty: %s", *pi.pam_tty!='\0' ? pi.pam_tty : "(not available)")); - D(("Ruser: %s", *pi.pam_ruser!='\0' ? pi.pam_ruser : "(not available)")); - D(("Rhost: %s", *pi.pam_rhost!='\0' ? pi.pam_rhost : "(not available)")); - D(("Pamstack_Authtok: %s", *pi.pamstack_authtok!='\0' ? pi.pamstack_authtok : "(not available)")); - D(("Pamstack_Oldauthtok: %s", *pi.pamstack_oldauthtok!='\0' ? pi.pamstack_oldauthtok : "(not available)")); - if (pi.pam_authtok != NULL) { - D(("Authtok: %s", *pi.pam_authtok!='\0' ? pi.pam_authtok : "(not available)")); + D(("Service: %s", *pi->pam_service!='\0' ? pi->pam_service : + "(not available)")); + D(("User: %s", *pi->pam_user!='\0' ? pi->pam_user : "(not available)")); + D(("Tty: %s", *pi->pam_tty!='\0' ? pi->pam_tty : "(not available)")); + D(("Ruser: %s", *pi->pam_ruser!='\0' ? pi->pam_ruser : "(not available)")); + D(("Rhost: %s", *pi->pam_rhost!='\0' ? pi->pam_rhost : "(not available)")); + D(("Pamstack_Authtok: %s", *pi->pamstack_authtok!='\0' ? + pi->pamstack_authtok : "(not available)")); + D(("Pamstack_Oldauthtok: %s", *pi->pamstack_oldauthtok!='\0' ? + pi->pamstack_oldauthtok : "(not available)")); + if (pi->pam_authtok != NULL) { + D(("Authtok: %s", *pi->pam_authtok!='\0' ? pi->pam_authtok : + "(not available)")); } - if (pi.pam_newauthtok != NULL) { - D(("Newauthtok: %s", *pi.pam_newauthtok!='\0' ? pi.pam_newauthtok : "(not available)")); + if (pi->pam_newauthtok != NULL) { + D(("Newauthtok: %s", *pi->pam_newauthtok!='\0' ? pi->pam_newauthtok : + "(not available)")); } - D(("Locale: %s", *pi.pam_cli_locale!='\0' ? pi.pam_cli_locale : "(not available)")); + D(("Locale: %s", *pi->pam_cli_locale!='\0' ? pi->pam_cli_locale : + "(not available)")); } -static int pam_sss(int task, pam_handle_t *pamh, int pam_flags, int argc, - const char **argv) +static int send_and_receive(pam_handle_t *pamh, struct pam_items *pi, + enum sss_cli_command task) { int ret; int errnop; - struct pam_items pi; struct sss_cli_req_data rd; - uint8_t *buf=NULL; - uint8_t *repbuf=NULL; + uint8_t *buf = NULL; + uint8_t *repbuf = NULL; size_t replen; - int pam_status; - uint32_t flags = 0; - char *answer; - - bindtextdomain(PACKAGE, LOCALEDIR); - - D(("Hello pam_sssd: %d", task)); - - for (; argc-- > 0; ++argv) { - if (strcmp(*argv, "forward_pass") == 0) { - flags |= FLAGS_FORWARD_PASS; - } else if (strcmp(*argv, "use_first_pass") == 0) { - flags |= FLAGS_USE_FIRST_PASS; - } else if (strcmp(*argv, "use_authtok") == 0) { - flags |= FLAGS_USE_AUTHTOK; - } else { - logger(pamh, LOG_WARNING, "unknown option: %s", *argv); - } - } - -/* TODO: add useful prelim check */ - if (task == SSS_PAM_CHAUTHTOK && (pam_flags & PAM_PRELIM_CHECK)) { - D(("ignoring PAM_PRELIM_CHECK")); - return PAM_SUCCESS; - } - - ret = get_pam_items(pamh, &pi); - if (ret != PAM_SUCCESS) { - D(("get items returned error: %s", pam_strerror(pamh,ret))); - return ret; - } - - if (*pi.pam_user == '\0') { - D(("No user found, aborting.")); - return PAM_BAD_ITEM; - } - - if (strcmp(pi.pam_user, "root") == 0) { - D(("pam_sss will not handle root.")); - return PAM_USER_UNKNOWN; - } - - if (task == SSS_PAM_AUTHENTICATE || - (task == SSS_PAM_CHAUTHTOK && getuid() != 0)) { - if (flags & FLAGS_USE_FIRST_PASS) { - pi.pam_authtok_type = SSS_AUTHTOK_TYPE_PASSWORD; - if (task == SSS_PAM_AUTHENTICATE) { - pi.pam_authtok = strdup(pi.pamstack_authtok); - } else if (task == SSS_PAM_CHAUTHTOK) { - pi.pam_authtok = strdup(pi.pamstack_oldauthtok); - } else { - D(("internal logic error")); - return PAM_SYSTEM_ERR; - } - if (pi.pam_authtok == NULL) { - pam_status = PAM_BUF_ERR; - goto done; - } - pi.pam_authtok_size = strlen(pi.pam_authtok); - } else { - ret = do_pam_conversation(pamh, PAM_PROMPT_ECHO_OFF, "Password: ", - NULL, &answer); - if (ret != PAM_SUCCESS) { - D(("do_pam_conversation failed.")); - pam_status = ret; - goto done; - } - - if (answer == NULL) { - pi.pam_authtok = NULL; - pi.pam_authtok_type = SSS_AUTHTOK_TYPE_EMPTY; - pi.pam_authtok_size=0; - } else { - pi.pam_authtok = strdup(answer); - _pam_overwrite((void *)answer); - free(answer); - answer=NULL; - if (pi.pam_authtok == NULL) { - pam_status = PAM_BUF_ERR; - goto done; - } - pi.pam_authtok_type = SSS_AUTHTOK_TYPE_PASSWORD; - pi.pam_authtok_size=strlen(pi.pam_authtok); - } - - if (flags & FLAGS_FORWARD_PASS) { - if (task == SSS_PAM_AUTHENTICATE) { - ret = pam_set_item(pamh, PAM_AUTHTOK, pi.pam_authtok); - } else if (task == SSS_PAM_CHAUTHTOK) { - ret = pam_set_item(pamh, PAM_OLDAUTHTOK, pi.pam_authtok); - } else { - D(("internal logic error")); - return PAM_SYSTEM_ERR; - } - if (ret != PAM_SUCCESS) { - D(("Failed to set PAM_AUTHTOK, authtok may not be available for other modules")); - } - } - } - } - - if (task == SSS_PAM_CHAUTHTOK) { - if (flags & FLAGS_USE_AUTHTOK) { - pi.pam_newauthtok_type = SSS_AUTHTOK_TYPE_PASSWORD; - pi.pam_newauthtok = strdup(pi.pamstack_authtok); - if (pi.pam_newauthtok == NULL) { - pam_status = PAM_BUF_ERR; - goto done; - } - pi.pam_newauthtok_size = strlen(pi.pam_newauthtok); - } else { - ret = do_pam_conversation(pamh, PAM_PROMPT_ECHO_OFF, - "New Password: ", - "Reenter new Password: ", - &answer); - if (ret != PAM_SUCCESS) { - D(("do_pam_conversation failed.")); - pam_status = ret; - goto done; - } - if (answer == NULL) { - pi.pam_newauthtok = NULL; - pi.pam_newauthtok_type = SSS_AUTHTOK_TYPE_EMPTY; - pi.pam_newauthtok_size=0; - } else { - pi.pam_newauthtok = strdup(answer); - _pam_overwrite((void *)answer); - free(answer); - answer=NULL; - if (pi.pam_newauthtok == NULL) { - pam_status = PAM_BUF_ERR; - goto done; - } - pi.pam_newauthtok_type = SSS_AUTHTOK_TYPE_PASSWORD; - pi.pam_newauthtok_size=strlen(pi.pam_newauthtok); - } - - if (flags & FLAGS_FORWARD_PASS) { - ret = pam_set_item(pamh, PAM_AUTHTOK, pi.pam_newauthtok); - if (ret != PAM_SUCCESS) { - D(("Failed to set PAM_AUTHTOK, authtok may not be available for other modules")); - } - } - } - } + int pam_status = PAM_SYSTEM_ERR; print_pam_items(pi); - ret = pack_message_v2(&pi, &rd.len, &buf); + ret = pack_message_v2(pi, &rd.len, &buf); if (ret != 0) { D(("pack_message failed.")); pam_status = PAM_SYSTEM_ERR; @@ -738,7 +540,7 @@ static int pam_sss(int task, pam_handle_t *pamh, int pam_flags, int argc, goto done; } logger(pamh, (pam_status == PAM_SUCCESS ? LOG_INFO : LOG_NOTICE), - "received for user %s: %d (%s)", pi.pam_user, pam_status, + "received for user %s: %d (%s)", pi->pam_user, pam_status, pam_strerror(pamh,pam_status)); done: @@ -746,11 +548,204 @@ done: _pam_overwrite_n((void *)buf, rd.len); free(buf); } - if (repbuf != NULL) free(repbuf); + free(repbuf); return pam_status; } +static int prompt_password(pam_handle_t *pamh, struct pam_items *pi) +{ + int ret; + char *answer = NULL; + + ret = do_pam_conversation(pamh, PAM_PROMPT_ECHO_OFF, "Password: ", + NULL, &answer); + if (ret != PAM_SUCCESS) { + D(("do_pam_conversation failed.")); + return ret; + } + + if (answer == NULL) { + pi->pam_authtok = NULL; + pi->pam_authtok_type = SSS_AUTHTOK_TYPE_EMPTY; + pi->pam_authtok_size=0; + } else { + pi->pam_authtok = strdup(answer); + _pam_overwrite((void *)answer); + free(answer); + answer=NULL; + if (pi->pam_authtok == NULL) { + return PAM_BUF_ERR; + } + pi->pam_authtok_type = SSS_AUTHTOK_TYPE_PASSWORD; + pi->pam_authtok_size=strlen(pi->pam_authtok); + } + + return PAM_SUCCESS; +} + +static int prompt_new_password(pam_handle_t *pamh, struct pam_items *pi) +{ + int ret; + char *answer = NULL; + + ret = do_pam_conversation(pamh, PAM_PROMPT_ECHO_OFF, + "New Password: ", + "Reenter new Password: ", + &answer); + if (ret != PAM_SUCCESS) { + D(("do_pam_conversation failed.")); + return ret; + } + if (answer == NULL) { + pi->pam_newauthtok = NULL; + pi->pam_newauthtok_type = SSS_AUTHTOK_TYPE_EMPTY; + pi->pam_newauthtok_size=0; + } else { + pi->pam_newauthtok = strdup(answer); + _pam_overwrite((void *)answer); + free(answer); + answer=NULL; + if (pi->pam_newauthtok == NULL) { + return PAM_BUF_ERR; + } + pi->pam_newauthtok_type = SSS_AUTHTOK_TYPE_PASSWORD; + pi->pam_newauthtok_size=strlen(pi->pam_newauthtok); + } + + return PAM_SUCCESS; +} + +static void eval_argv(pam_handle_t *pamh, int argc, const char **argv, + uint32_t *flags) +{ + for (; argc-- > 0; ++argv) { + if (strcmp(*argv, "forward_pass") == 0) { + *flags |= FLAGS_FORWARD_PASS; + } else if (strcmp(*argv, "use_first_pass") == 0) { + *flags |= FLAGS_USE_FIRST_PASS; + } else if (strcmp(*argv, "use_authtok") == 0) { + *flags |= FLAGS_USE_AUTHTOK; + } else { + logger(pamh, LOG_WARNING, "unknown option: %s", *argv); + } + } + + return; +} + +static int pam_sss(enum sss_cli_command task, pam_handle_t *pamh, + int pam_flags, int argc, const char **argv) +{ + int ret; + struct pam_items pi; + uint32_t flags = 0; + + bindtextdomain(PACKAGE, LOCALEDIR); + + D(("Hello pam_sssd: %d", task)); + + eval_argv(pamh, argc, argv, &flags); + + ret = get_pam_items(pamh, &pi); + if (ret != PAM_SUCCESS) { + D(("get items returned error: %s", pam_strerror(pamh,ret))); + return ret; + } + + + switch(task) { + case SSS_PAM_AUTHENTICATE: + if (flags & FLAGS_USE_FIRST_PASS) { + pi.pam_authtok_type = SSS_AUTHTOK_TYPE_PASSWORD; + pi.pam_authtok = strdup(pi.pamstack_authtok); + if (pi.pam_authtok == NULL) { + D(("option use_first_pass set, but no password found")); + return PAM_BUF_ERR; + } + pi.pam_authtok_size = strlen(pi.pam_authtok); + } else { + prompt_password(pamh, &pi); + + if (flags & FLAGS_FORWARD_PASS) { + ret = pam_set_item(pamh, PAM_AUTHTOK, pi.pam_authtok); + if (ret != PAM_SUCCESS) { + D(("Failed to set PAM_AUTHTOK [%s], " + "authtok may not be available for other modules", + pam_strerror(pamh,ret))); + } + } + } + + break; + case SSS_PAM_CHAUTHTOK: + /* we query for the old password during PAM_PRELIM_CHECK to make + * pam_sss work e.g. with pam_cracklib */ + if (pam_flags & PAM_PRELIM_CHECK) { + if (getuid() != 0 && !(flags & FLAGS_USE_FIRST_PASS)) { + prompt_password(pamh, &pi); + + ret = pam_set_item(pamh, PAM_OLDAUTHTOK, pi.pam_authtok); + if (ret != PAM_SUCCESS) { + D(("Failed to set PAM_OLDAUTHTOK [%s], " + "oldauthtok may not be available", + pam_strerror(pamh,ret))); + return ret; + } + } + + return PAM_SUCCESS; + } + + if (getuid() != 0) { + pi.pam_authtok_type = SSS_AUTHTOK_TYPE_PASSWORD; + pi.pam_authtok = strdup(pi.pamstack_oldauthtok); + if (pi.pam_authtok == NULL) { + D(("no password found for chauthtok")); + return PAM_BUF_ERR; + } + pi.pam_authtok_size = strlen(pi.pam_authtok); + } else { + pi.pam_authtok_type = SSS_AUTHTOK_TYPE_EMPTY; + pi.pam_authtok = NULL; + pi.pam_authtok_size = 0; + } + + if (flags & FLAGS_USE_AUTHTOK) { + pi.pam_newauthtok_type = SSS_AUTHTOK_TYPE_PASSWORD; + pi.pam_newauthtok = strdup(pi.pamstack_authtok); + if (pi.pam_newauthtok == NULL) { + D(("option use_authtok set, but no new password found")); + return PAM_BUF_ERR; + } + pi.pam_newauthtok_size = strlen(pi.pam_newauthtok); + } else { + prompt_new_password(pamh, &pi); + + if (flags & FLAGS_FORWARD_PASS) { + ret = pam_set_item(pamh, PAM_AUTHTOK, pi.pam_newauthtok); + if (ret != PAM_SUCCESS) { + D(("Failed to set PAM_AUTHTOK [%s], " + "oldauthtok may not be available", + pam_strerror(pamh,ret))); + } + } + } + + break; + case SSS_PAM_ACCT_MGMT: + case SSS_PAM_SETCRED: + case SSS_PAM_OPEN_SESSION: + case SSS_PAM_CLOSE_SESSION: + break; + default: + D(("Illegal task [%d]", task)); + return PAM_SYSTEM_ERR; + } + + return send_and_receive(pamh, &pi, task); +} + PAM_EXTERN int pam_sm_authenticate(pam_handle_t *pamh, int flags, int argc, const char **argv ) { -- 1.6.2.5 From sgallagh at redhat.com Wed Jul 22 11:00:09 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 22 Jul 2009 07:00:09 -0400 Subject: [Freeipa-devel] contribution policy draft In-Reply-To: <20090722052036.GG12672@calliope.phig.org> References: <20090715044601.GB29035@calliope.phig.org> <4A5DB003.3030404@redhat.com> <20090722052036.GG12672@calliope.phig.org> Message-ID: <4A66F139.3060309@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/22/2009 01:20 AM, Karsten Wade wrote: > On Wed, Jul 15, 2009 at 06:31:31AM -0400, Stephen Gallagher wrote: > >> Karsten, I'd also like to put together something similar for the SSSD >> contribution page (not currently existing in any useful form). The SSSD >> has some different licensing requirements, however. While all portions >> of the server should be GPL (version debatable), we have several shared >> libraries that need to be LGPL, and we also have a nebulous set of >> plugins that are loaded by server-processes*. These last present a >> somewhat troublesome legal question. > > Stephen: > > Have you had a chance to talk with RHT Legal about this? What I'd > recommend is that we forward the details and make an appointment with > Richard Fontana; I think the high-bandwidth of a phone call works > especially well with lawyers, unless it's all clear to him via email. > We can report back here the results; I'd like to participate as part > of coordinating license and contribution policies. > > If that sounds good, I can forward your email and see where it leads > us next; I'm widely available for a call. > > - Karsten > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I have not yet had a chance to do so. Please, by all means, start the ball rolling on this. I can be available for a phone call between 0700- 1800 EDT almost any weekday. - -- 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/ iEYEARECAAYFAkpm8TUACgkQeiVVYja6o6PSaQCfajvpvGSAtbW57xuaiMqww3rx nXkAoJHqjuXRStx0dkaFrvRMWUI6WvAV =7JgA -----END PGP SIGNATURE----- From sgallagh at redhat.com Wed Jul 22 11:46:53 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 22 Jul 2009 07:46:53 -0400 Subject: [Freeipa-devel] [PATCH] cleanup of pam_sss In-Reply-To: <20090722105222.GA30242@localhost.localdomain> References: <20090722105222.GA30242@localhost.localdomain> Message-ID: <4A66FC2D.5020602@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/22/2009 06:52 AM, Sumit Bose wrote: > Hi, > > this patch should make pam_sss.c considerably more readable and should > allow to use modules like pam_cracklib together with pam_sss. I hope I > have caught all corner cases. > > bye, > Sumit > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Nack. It would be wise in print_pam_items() to check whether pi is NULL before attempting to dereference it to print all of its members. Similarly, It's unsafe to check whether dereferencing a pointer == 0 before checking whether that pointer itself is valid. I'd suggest creating a macro to do that comparison, something like PI_STRING_VALID_AND_NONZERO(*pi->pam_service). In prompt_password(), shouldn't the password prompt be localized? - -- 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/ iEYEARECAAYFAkpm/CYACgkQeiVVYja6o6OepwCgnOp+gTAFHJu/2gix6xIPvGYk vzEAoKK3QPvrjbRTKu4ELIE07369ybzX =B/Tr -----END PGP SIGNATURE----- From ssorce at redhat.com Wed Jul 22 12:46:13 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 22 Jul 2009 08:46:13 -0400 Subject: [Freeipa-devel] [PATCH] cleanup of pam_sss In-Reply-To: <20090722105222.GA30242@localhost.localdomain> References: <20090722105222.GA30242@localhost.localdomain> Message-ID: <1248266773.895.9.camel@localhost.localdomain> On Wed, 2009-07-22 at 12:52 +0200, Sumit Bose wrote: > > this patch should make pam_sss.c considerably more readable and should > allow to use modules like pam_cracklib together with pam_sss. I hope I > have caught all corner cases. Sumit, it would be nice to have reformatting and new functionality in 2 separate patches. Simo. -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Wed Jul 22 12:59:43 2009 From: sbose at redhat.com (Sumit Bose) Date: Wed, 22 Jul 2009 14:59:43 +0200 Subject: [Freeipa-devel] [PATCH] cleanup of pam_sss In-Reply-To: <4A66FC2D.5020602@redhat.com> References: <20090722105222.GA30242@localhost.localdomain> <4A66FC2D.5020602@redhat.com> Message-ID: <20090722125943.GB30242@localhost.localdomain> On Wed, Jul 22, 2009 at 07:46:53AM -0400, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/22/2009 06:52 AM, Sumit Bose wrote: > > Hi, > > > > this patch should make pam_sss.c considerably more readable and should > > allow to use modules like pam_cracklib together with pam_sss. I hope I > > have caught all corner cases. > > > > bye, > > Sumit > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Nack. > > It would be wise in print_pam_items() to check whether pi is NULL before > attempting to dereference it to print all of its members. Similarly, > It's unsafe to check whether dereferencing a pointer == 0 before > checking whether that pointer itself is valid. I'd suggest creating a > macro to do that comparison, something like > PI_STRING_VALID_AND_NONZERO(*pi->pam_service). > > In prompt_password(), shouldn't the password prompt be localized? > Thanks for reviewing. The new version address your comments. bye, Sumit -------------- next part -------------- >From 5fd4240fd3752b849049c09b2f728d076cfe77ff Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 22 Jul 2009 12:46:24 +0200 Subject: [PATCH] cleanup of pam_sss - make pam_sss work with pam_cracklib and similar pam modules - clean up the if-&&-else-|| jungle to make clear what is happening --- sss_client/pam_sss.c | 491 +++++++++++++++++++++++++------------------------- 1 files changed, 241 insertions(+), 250 deletions(-) diff --git a/sss_client/pam_sss.c b/sss_client/pam_sss.c index bec6469..9ffd302 100644 --- a/sss_client/pam_sss.c +++ b/sss_client/pam_sss.c @@ -1,4 +1,3 @@ - #define PAM_SM_AUTH #define PAM_SM_ACCOUNT #define PAM_SM_SESSION @@ -50,6 +49,8 @@ struct pam_items { }; #define DEBUG_MGS_LEN 1024 +#define MAX_AUTHTOK_SIZE (1024*1024) +#define CHECK_AND_RETURN_PI_STRING(s) ((s != NULL && *s != '\0')? s : "(not available)") static void logger(pam_handle_t *pamh, int level, const char *fmt, ...) { va_list ap; @@ -121,7 +122,8 @@ static size_t add_string_item(enum pam_item_type type, const char *str, return rp; } -static int pack_message_v2(struct pam_items *pi, size_t *size, uint8_t **buffer) { +static int pack_message_v2(struct pam_items *pi, size_t *size, + uint8_t **buffer) { int len; uint8_t *buf; int rp; @@ -199,77 +201,6 @@ static int pack_message_v2(struct pam_items *pi, size_t *size, uint8_t **buffer) return 0; } -#if 0 -static int pack_message(struct pam_items *pi, size_t *size, uint8_t **buffer) { - int len; - uint8_t *buf; - int rp; - - len = pi->pam_user_size + - pi->pam_service_size + - pi->pam_tty_size + - pi->pam_ruser_size + - pi->pam_rhost_size + - 2*sizeof(uint32_t) + pi->pam_authtok_size + - 2*sizeof(uint32_t) + pi->pam_newauthtok_size + - sizeof(uint32_t); - - buf = malloc(len); - if (buf == NULL) { - D(("malloc failed.")); - return PAM_BUF_ERR; - } - - memcpy(buf, pi->pam_user, pi->pam_user_size); - rp = pi->pam_user_size; - - memcpy(&buf[rp], pi->pam_service, pi->pam_service_size); - rp += pi->pam_service_size; - - memcpy(&buf[rp], pi->pam_tty, pi->pam_tty_size); - rp += pi->pam_tty_size; - - memcpy(&buf[rp], pi->pam_ruser, pi->pam_ruser_size); - rp += pi->pam_ruser_size; - - memcpy(&buf[rp], pi->pam_rhost, pi->pam_rhost_size); - rp += pi->pam_rhost_size; - - ((uint32_t *)(&buf[rp]))[0] = pi->pam_authtok_type; - rp += sizeof(uint32_t); - ((uint32_t *)(&buf[rp]))[0] = pi->pam_authtok_size; - rp += sizeof(uint32_t); - memcpy(&buf[rp], pi->pam_authtok, pi->pam_authtok_size); - rp += pi->pam_authtok_size; - _pam_overwrite((void *)pi->pam_authtok); - free((void *)pi->pam_authtok); - pi->pam_authtok = NULL; - - ((uint32_t *)(&buf[rp]))[0] = pi->pam_newauthtok_type; - rp += sizeof(uint32_t); - ((uint32_t *)(&buf[rp]))[0] = pi->pam_newauthtok_size; - rp += sizeof(uint32_t); - memcpy(&buf[rp], pi->pam_newauthtok, pi->pam_newauthtok_size); - rp += pi->pam_newauthtok_size; - _pam_overwrite((void *)pi->pam_newauthtok); - free((void *)pi->pam_newauthtok); - pi->pam_newauthtok = NULL; - - ((uint32_t *)(&buf[rp]))[0] = END_OF_PAM_REQUEST; - rp += sizeof(uint32_t); - - if (rp != len) { - D(("error during packet creation.")); - return PAM_BUF_ERR; - } - - *size = len; - *buffer = buf; - - return 0; -} -#endif - static int null_strcmp(const char *s1, const char *s2) { if (s1 == NULL && s2 == NULL) return 0; if (s1 == NULL && s2 != NULL) return -1; @@ -297,7 +228,8 @@ static int do_pam_conversation(pam_handle_t *pamh, const int msg_style, if ((msg_style == PAM_TEXT_INFO || msg_style == PAM_ERROR_MSG) && msg == NULL) return PAM_SYSTEM_ERR; - if ((msg_style == PAM_PROMPT_ECHO_OFF || msg_style == PAM_PROMPT_ECHO_ON) && + if ((msg_style == PAM_PROMPT_ECHO_OFF || + msg_style == PAM_PROMPT_ECHO_ON) && (msg == NULL || answer == NULL)) return PAM_SYSTEM_ERR; ret=pam_get_item(pamh, PAM_CONV, (const void **) &conv); @@ -325,7 +257,8 @@ static int do_pam_conversation(pam_handle_t *pamh, const int msg_style, return ret; } - if (msg_style == PAM_PROMPT_ECHO_OFF || msg_style == PAM_PROMPT_ECHO_ON) { + if (msg_style == PAM_PROMPT_ECHO_OFF || + msg_style == PAM_PROMPT_ECHO_ON) { if (resp == NULL) { D(("response expected, but resp==NULL")); return PAM_SYSTEM_ERR; @@ -342,8 +275,8 @@ static int do_pam_conversation(pam_handle_t *pamh, const int msg_style, *answer = NULL; } ret = do_pam_conversation(pamh, PAM_ERROR_MSG, - _("Passwords do not match"), NULL, - NULL); + _("Passwords do not match"), + NULL, NULL); if (ret != PAM_SUCCESS) { D(("do_pam_conversation failed.")); return PAM_SYSTEM_ERR; @@ -357,11 +290,11 @@ static int do_pam_conversation(pam_handle_t *pamh, const int msg_style, D(("Empty password")); *answer = NULL; } else { - *answer = strdup(resp[0].resp); + *answer = strndup(resp[0].resp, MAX_AUTHTOK_SIZE); _pam_overwrite((void *)resp[0].resp); free(resp[0].resp); if(*answer == NULL) { - D(("strdup failed")); + D(("strndup failed")); return PAM_BUF_ERR; } } @@ -493,9 +426,17 @@ static int get_pam_items(pam_handle_t *pamh, struct pam_items *pi) ret = pam_get_item(pamh, PAM_USER, (const void **) &(pi->pam_user)); if (ret != PAM_SUCCESS) return ret; - if (pi->pam_user == NULL) pi->pam_user=""; + if (pi->pam_user == NULL) { + D(("No user found, aborting.")); + return PAM_BAD_ITEM; + } + if (strcmp(pi->pam_user, "root") == 0) { + D(("pam_sss will not handle root.")); + return PAM_USER_UNKNOWN; + } pi->pam_user_size=strlen(pi->pam_user)+1; + ret = pam_get_item(pamh, PAM_TTY, (const void **) &(pi->pam_tty)); if (ret != PAM_SUCCESS) return ret; if (pi->pam_tty == NULL) pi->pam_tty=""; @@ -511,11 +452,13 @@ static int get_pam_items(pam_handle_t *pamh, struct pam_items *pi) if (pi->pam_rhost == NULL) pi->pam_rhost=""; pi->pam_rhost_size=strlen(pi->pam_rhost)+1; - ret = pam_get_item(pamh, PAM_AUTHTOK, (const void **) &(pi->pamstack_authtok)); + ret = pam_get_item(pamh, PAM_AUTHTOK, + (const void **) &(pi->pamstack_authtok)); if (ret != PAM_SUCCESS) return ret; if (pi->pamstack_authtok == NULL) pi->pamstack_authtok=""; - ret = pam_get_item(pamh, PAM_OLDAUTHTOK, (const void **) &(pi->pamstack_oldauthtok)); + ret = pam_get_item(pamh, PAM_OLDAUTHTOK, + (const void **) &(pi->pamstack_oldauthtok)); if (ret != PAM_SUCCESS) return ret; if (pi->pamstack_oldauthtok == NULL) pi->pamstack_oldauthtok=""; @@ -531,183 +474,38 @@ static int get_pam_items(pam_handle_t *pamh, struct pam_items *pi) return PAM_SUCCESS; } -static void print_pam_items(struct pam_items pi) +static void print_pam_items(struct pam_items *pi) { - D(("Service: %s", *pi.pam_service!='\0' ? pi.pam_service : "(not available)")); - D(("User: %s", *pi.pam_user!='\0' ? pi.pam_user : "(not available)")); - D(("Tty: %s", *pi.pam_tty!='\0' ? pi.pam_tty : "(not available)")); - D(("Ruser: %s", *pi.pam_ruser!='\0' ? pi.pam_ruser : "(not available)")); - D(("Rhost: %s", *pi.pam_rhost!='\0' ? pi.pam_rhost : "(not available)")); - D(("Pamstack_Authtok: %s", *pi.pamstack_authtok!='\0' ? pi.pamstack_authtok : "(not available)")); - D(("Pamstack_Oldauthtok: %s", *pi.pamstack_oldauthtok!='\0' ? pi.pamstack_oldauthtok : "(not available)")); - if (pi.pam_authtok != NULL) { - D(("Authtok: %s", *pi.pam_authtok!='\0' ? pi.pam_authtok : "(not available)")); - } - if (pi.pam_newauthtok != NULL) { - D(("Newauthtok: %s", *pi.pam_newauthtok!='\0' ? pi.pam_newauthtok : "(not available)")); - } - D(("Locale: %s", *pi.pam_cli_locale!='\0' ? pi.pam_cli_locale : "(not available)")); + if (pi == NULL) return; + + D(("Service: %s", CHECK_AND_RETURN_PI_STRING(pi->pam_service))); + D(("User: %s", CHECK_AND_RETURN_PI_STRING(pi->pam_user))); + D(("Tty: %s", CHECK_AND_RETURN_PI_STRING(pi->pam_tty))); + D(("Ruser: %s", CHECK_AND_RETURN_PI_STRING(pi->pam_ruser))); + D(("Rhost: %s", CHECK_AND_RETURN_PI_STRING(pi->pam_rhost))); + D(("Pamstack_Authtok: %s", + CHECK_AND_RETURN_PI_STRING(pi->pamstack_authtok))); + D(("Pamstack_Oldauthtok: %s", + CHECK_AND_RETURN_PI_STRING(pi->pamstack_oldauthtok))); + D(("Authtok: %s", CHECK_AND_RETURN_PI_STRING(pi->pam_authtok))); + D(("Newauthtok: %s", CHECK_AND_RETURN_PI_STRING(pi->pam_newauthtok))); + D(("Locale: %s", CHECK_AND_RETURN_PI_STRING(pi->pam_cli_locale))); } -static int pam_sss(int task, pam_handle_t *pamh, int pam_flags, int argc, - const char **argv) +static int send_and_receive(pam_handle_t *pamh, struct pam_items *pi, + enum sss_cli_command task) { int ret; int errnop; - struct pam_items pi; struct sss_cli_req_data rd; - uint8_t *buf=NULL; - uint8_t *repbuf=NULL; + uint8_t *buf = NULL; + uint8_t *repbuf = NULL; size_t replen; - int pam_status; - uint32_t flags = 0; - char *answer; - - bindtextdomain(PACKAGE, LOCALEDIR); - - D(("Hello pam_sssd: %d", task)); - - for (; argc-- > 0; ++argv) { - if (strcmp(*argv, "forward_pass") == 0) { - flags |= FLAGS_FORWARD_PASS; - } else if (strcmp(*argv, "use_first_pass") == 0) { - flags |= FLAGS_USE_FIRST_PASS; - } else if (strcmp(*argv, "use_authtok") == 0) { - flags |= FLAGS_USE_AUTHTOK; - } else { - logger(pamh, LOG_WARNING, "unknown option: %s", *argv); - } - } - -/* TODO: add useful prelim check */ - if (task == SSS_PAM_CHAUTHTOK && (pam_flags & PAM_PRELIM_CHECK)) { - D(("ignoring PAM_PRELIM_CHECK")); - return PAM_SUCCESS; - } - - ret = get_pam_items(pamh, &pi); - if (ret != PAM_SUCCESS) { - D(("get items returned error: %s", pam_strerror(pamh,ret))); - return ret; - } - - if (*pi.pam_user == '\0') { - D(("No user found, aborting.")); - return PAM_BAD_ITEM; - } - - if (strcmp(pi.pam_user, "root") == 0) { - D(("pam_sss will not handle root.")); - return PAM_USER_UNKNOWN; - } - - if (task == SSS_PAM_AUTHENTICATE || - (task == SSS_PAM_CHAUTHTOK && getuid() != 0)) { - if (flags & FLAGS_USE_FIRST_PASS) { - pi.pam_authtok_type = SSS_AUTHTOK_TYPE_PASSWORD; - if (task == SSS_PAM_AUTHENTICATE) { - pi.pam_authtok = strdup(pi.pamstack_authtok); - } else if (task == SSS_PAM_CHAUTHTOK) { - pi.pam_authtok = strdup(pi.pamstack_oldauthtok); - } else { - D(("internal logic error")); - return PAM_SYSTEM_ERR; - } - if (pi.pam_authtok == NULL) { - pam_status = PAM_BUF_ERR; - goto done; - } - pi.pam_authtok_size = strlen(pi.pam_authtok); - } else { - ret = do_pam_conversation(pamh, PAM_PROMPT_ECHO_OFF, "Password: ", - NULL, &answer); - if (ret != PAM_SUCCESS) { - D(("do_pam_conversation failed.")); - pam_status = ret; - goto done; - } - - if (answer == NULL) { - pi.pam_authtok = NULL; - pi.pam_authtok_type = SSS_AUTHTOK_TYPE_EMPTY; - pi.pam_authtok_size=0; - } else { - pi.pam_authtok = strdup(answer); - _pam_overwrite((void *)answer); - free(answer); - answer=NULL; - if (pi.pam_authtok == NULL) { - pam_status = PAM_BUF_ERR; - goto done; - } - pi.pam_authtok_type = SSS_AUTHTOK_TYPE_PASSWORD; - pi.pam_authtok_size=strlen(pi.pam_authtok); - } - - if (flags & FLAGS_FORWARD_PASS) { - if (task == SSS_PAM_AUTHENTICATE) { - ret = pam_set_item(pamh, PAM_AUTHTOK, pi.pam_authtok); - } else if (task == SSS_PAM_CHAUTHTOK) { - ret = pam_set_item(pamh, PAM_OLDAUTHTOK, pi.pam_authtok); - } else { - D(("internal logic error")); - return PAM_SYSTEM_ERR; - } - if (ret != PAM_SUCCESS) { - D(("Failed to set PAM_AUTHTOK, authtok may not be available for other modules")); - } - } - } - } - - if (task == SSS_PAM_CHAUTHTOK) { - if (flags & FLAGS_USE_AUTHTOK) { - pi.pam_newauthtok_type = SSS_AUTHTOK_TYPE_PASSWORD; - pi.pam_newauthtok = strdup(pi.pamstack_authtok); - if (pi.pam_newauthtok == NULL) { - pam_status = PAM_BUF_ERR; - goto done; - } - pi.pam_newauthtok_size = strlen(pi.pam_newauthtok); - } else { - ret = do_pam_conversation(pamh, PAM_PROMPT_ECHO_OFF, - "New Password: ", - "Reenter new Password: ", - &answer); - if (ret != PAM_SUCCESS) { - D(("do_pam_conversation failed.")); - pam_status = ret; - goto done; - } - if (answer == NULL) { - pi.pam_newauthtok = NULL; - pi.pam_newauthtok_type = SSS_AUTHTOK_TYPE_EMPTY; - pi.pam_newauthtok_size=0; - } else { - pi.pam_newauthtok = strdup(answer); - _pam_overwrite((void *)answer); - free(answer); - answer=NULL; - if (pi.pam_newauthtok == NULL) { - pam_status = PAM_BUF_ERR; - goto done; - } - pi.pam_newauthtok_type = SSS_AUTHTOK_TYPE_PASSWORD; - pi.pam_newauthtok_size=strlen(pi.pam_newauthtok); - } - - if (flags & FLAGS_FORWARD_PASS) { - ret = pam_set_item(pamh, PAM_AUTHTOK, pi.pam_newauthtok); - if (ret != PAM_SUCCESS) { - D(("Failed to set PAM_AUTHTOK, authtok may not be available for other modules")); - } - } - } - } + int pam_status = PAM_SYSTEM_ERR; print_pam_items(pi); - ret = pack_message_v2(&pi, &rd.len, &buf); + ret = pack_message_v2(pi, &rd.len, &buf); if (ret != 0) { D(("pack_message failed.")); pam_status = PAM_SYSTEM_ERR; @@ -738,7 +536,7 @@ static int pam_sss(int task, pam_handle_t *pamh, int pam_flags, int argc, goto done; } logger(pamh, (pam_status == PAM_SUCCESS ? LOG_INFO : LOG_NOTICE), - "received for user %s: %d (%s)", pi.pam_user, pam_status, + "received for user %s: %d (%s)", pi->pam_user, pam_status, pam_strerror(pamh,pam_status)); done: @@ -746,11 +544,204 @@ done: _pam_overwrite_n((void *)buf, rd.len); free(buf); } - if (repbuf != NULL) free(repbuf); + free(repbuf); return pam_status; } +static int prompt_password(pam_handle_t *pamh, struct pam_items *pi) +{ + int ret; + char *answer = NULL; + + ret = do_pam_conversation(pamh, PAM_PROMPT_ECHO_OFF, _("Password: "), + NULL, &answer); + if (ret != PAM_SUCCESS) { + D(("do_pam_conversation failed.")); + return ret; + } + + if (answer == NULL) { + pi->pam_authtok = NULL; + pi->pam_authtok_type = SSS_AUTHTOK_TYPE_EMPTY; + pi->pam_authtok_size=0; + } else { + pi->pam_authtok = strdup(answer); + _pam_overwrite((void *)answer); + free(answer); + answer=NULL; + if (pi->pam_authtok == NULL) { + return PAM_BUF_ERR; + } + pi->pam_authtok_type = SSS_AUTHTOK_TYPE_PASSWORD; + pi->pam_authtok_size=strlen(pi->pam_authtok); + } + + return PAM_SUCCESS; +} + +static int prompt_new_password(pam_handle_t *pamh, struct pam_items *pi) +{ + int ret; + char *answer = NULL; + + ret = do_pam_conversation(pamh, PAM_PROMPT_ECHO_OFF, + _("New Password: "), + _("Reenter new Password: "), + &answer); + if (ret != PAM_SUCCESS) { + D(("do_pam_conversation failed.")); + return ret; + } + if (answer == NULL) { + pi->pam_newauthtok = NULL; + pi->pam_newauthtok_type = SSS_AUTHTOK_TYPE_EMPTY; + pi->pam_newauthtok_size=0; + } else { + pi->pam_newauthtok = strdup(answer); + _pam_overwrite((void *)answer); + free(answer); + answer=NULL; + if (pi->pam_newauthtok == NULL) { + return PAM_BUF_ERR; + } + pi->pam_newauthtok_type = SSS_AUTHTOK_TYPE_PASSWORD; + pi->pam_newauthtok_size=strlen(pi->pam_newauthtok); + } + + return PAM_SUCCESS; +} + +static void eval_argv(pam_handle_t *pamh, int argc, const char **argv, + uint32_t *flags) +{ + for (; argc-- > 0; ++argv) { + if (strcmp(*argv, "forward_pass") == 0) { + *flags |= FLAGS_FORWARD_PASS; + } else if (strcmp(*argv, "use_first_pass") == 0) { + *flags |= FLAGS_USE_FIRST_PASS; + } else if (strcmp(*argv, "use_authtok") == 0) { + *flags |= FLAGS_USE_AUTHTOK; + } else { + logger(pamh, LOG_WARNING, "unknown option: %s", *argv); + } + } + + return; +} + +static int pam_sss(enum sss_cli_command task, pam_handle_t *pamh, + int pam_flags, int argc, const char **argv) +{ + int ret; + struct pam_items pi; + uint32_t flags = 0; + + bindtextdomain(PACKAGE, LOCALEDIR); + + D(("Hello pam_sssd: %d", task)); + + eval_argv(pamh, argc, argv, &flags); + + ret = get_pam_items(pamh, &pi); + if (ret != PAM_SUCCESS) { + D(("get items returned error: %s", pam_strerror(pamh,ret))); + return ret; + } + + + switch(task) { + case SSS_PAM_AUTHENTICATE: + if (flags & FLAGS_USE_FIRST_PASS) { + pi.pam_authtok_type = SSS_AUTHTOK_TYPE_PASSWORD; + pi.pam_authtok = strdup(pi.pamstack_authtok); + if (pi.pam_authtok == NULL) { + D(("option use_first_pass set, but no password found")); + return PAM_BUF_ERR; + } + pi.pam_authtok_size = strlen(pi.pam_authtok); + } else { + prompt_password(pamh, &pi); + + if (flags & FLAGS_FORWARD_PASS) { + ret = pam_set_item(pamh, PAM_AUTHTOK, pi.pam_authtok); + if (ret != PAM_SUCCESS) { + D(("Failed to set PAM_AUTHTOK [%s], " + "authtok may not be available for other modules", + pam_strerror(pamh,ret))); + } + } + } + + break; + case SSS_PAM_CHAUTHTOK: + /* we query for the old password during PAM_PRELIM_CHECK to make + * pam_sss work e.g. with pam_cracklib */ + if (pam_flags & PAM_PRELIM_CHECK) { + if (getuid() != 0 && !(flags & FLAGS_USE_FIRST_PASS)) { + prompt_password(pamh, &pi); + + ret = pam_set_item(pamh, PAM_OLDAUTHTOK, pi.pam_authtok); + if (ret != PAM_SUCCESS) { + D(("Failed to set PAM_OLDAUTHTOK [%s], " + "oldauthtok may not be available", + pam_strerror(pamh,ret))); + return ret; + } + } + + return PAM_SUCCESS; + } + + if (getuid() != 0) { + pi.pam_authtok_type = SSS_AUTHTOK_TYPE_PASSWORD; + pi.pam_authtok = strdup(pi.pamstack_oldauthtok); + if (pi.pam_authtok == NULL) { + D(("no password found for chauthtok")); + return PAM_BUF_ERR; + } + pi.pam_authtok_size = strlen(pi.pam_authtok); + } else { + pi.pam_authtok_type = SSS_AUTHTOK_TYPE_EMPTY; + pi.pam_authtok = NULL; + pi.pam_authtok_size = 0; + } + + if (flags & FLAGS_USE_AUTHTOK) { + pi.pam_newauthtok_type = SSS_AUTHTOK_TYPE_PASSWORD; + pi.pam_newauthtok = strdup(pi.pamstack_authtok); + if (pi.pam_newauthtok == NULL) { + D(("option use_authtok set, but no new password found")); + return PAM_BUF_ERR; + } + pi.pam_newauthtok_size = strlen(pi.pam_newauthtok); + } else { + prompt_new_password(pamh, &pi); + + if (flags & FLAGS_FORWARD_PASS) { + ret = pam_set_item(pamh, PAM_AUTHTOK, pi.pam_newauthtok); + if (ret != PAM_SUCCESS) { + D(("Failed to set PAM_AUTHTOK [%s], " + "oldauthtok may not be available", + pam_strerror(pamh,ret))); + } + } + } + + break; + case SSS_PAM_ACCT_MGMT: + case SSS_PAM_SETCRED: + case SSS_PAM_OPEN_SESSION: + case SSS_PAM_CLOSE_SESSION: + break; + default: + D(("Illegal task [%d]", task)); + return PAM_SYSTEM_ERR; + } + + return send_and_receive(pamh, &pi, task); +} + PAM_EXTERN int pam_sm_authenticate(pam_handle_t *pamh, int flags, int argc, const char **argv ) { -- 1.6.2.5 From sbose at redhat.com Wed Jul 22 13:04:05 2009 From: sbose at redhat.com (Sumit Bose) Date: Wed, 22 Jul 2009 15:04:05 +0200 Subject: [Freeipa-devel] [PATCH] cleanup of pam_sss In-Reply-To: <1248266773.895.9.camel@localhost.localdomain> References: <20090722105222.GA30242@localhost.localdomain> <1248266773.895.9.camel@localhost.localdomain> Message-ID: <20090722130405.GC30242@localhost.localdomain> On Wed, Jul 22, 2009 at 08:46:13AM -0400, Simo Sorce wrote: > On Wed, 2009-07-22 at 12:52 +0200, Sumit Bose wrote: > > > > this patch should make pam_sss.c considerably more readable and should > > allow to use modules like pam_cracklib together with pam_sss. I hope I > > have caught all corner cases. > > Sumit, it would be nice to have reformatting and new functionality in 2 > separate patches. > > Simo. > Yes, Stephen asked me to keep that in mind, too. The only functional change is during the password change. The current password is now requested during PAM_PRELIM_CHECK and not during PAM_UPDATE_AUTHTOK. bye, Sumit From jdennis at redhat.com Wed Jul 22 13:42:40 2009 From: jdennis at redhat.com (John Dennis) Date: Wed, 22 Jul 2009 09:42:40 -0400 Subject: [Freeipa-devel] how to exercise lwatch Message-ID: <4A671750.7020405@redhat.com> Attached is a README explaining how to exercise the lwatch code submitted for patch review. It illustrates some of lwatch's features. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: README URL: From sgallagh at redhat.com Wed Jul 22 14:02:15 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 22 Jul 2009 10:02:15 -0400 Subject: [Freeipa-devel] [PATCH] cleanup of pam_sss In-Reply-To: <20090722125943.GB30242@localhost.localdomain> References: <20090722105222.GA30242@localhost.localdomain> <4A66FC2D.5020602@redhat.com> <20090722125943.GB30242@localhost.localdomain> Message-ID: <4A671BE7.1060600@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/22/2009 08:59 AM, Sumit Bose wrote: > On Wed, Jul 22, 2009 at 07:46:53AM -0400, Stephen Gallagher wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 07/22/2009 06:52 AM, Sumit Bose wrote: >>> Hi, >>> >>> this patch should make pam_sss.c considerably more readable and should >>> allow to use modules like pam_cracklib together with pam_sss. I hope I >>> have caught all corner cases. >>> >>> bye, >>> Sumit >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Nack. >> >> It would be wise in print_pam_items() to check whether pi is NULL before >> attempting to dereference it to print all of its members. Similarly, >> It's unsafe to check whether dereferencing a pointer == 0 before >> checking whether that pointer itself is valid. I'd suggest creating a >> macro to do that comparison, something like >> PI_STRING_VALID_AND_NONZERO(*pi->pam_service). >> >> In prompt_password(), shouldn't the password prompt be localized? >> > > Thanks for reviewing. The new version address your comments. > > bye, > Sumit Ack, 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/ iEYEARECAAYFAkpnG+AACgkQeiVVYja6o6P8WQCgsMMWHLlcIdSD/YxulKyMzDN1 HKEAniFJiOjBGximC2TiHjyOQfPZHm1M =0oCe -----END PGP SIGNATURE----- From rcritten at redhat.com Wed Jul 22 14:08:33 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 22 Jul 2009 10:08:33 -0400 Subject: [Freeipa-devel] [PATCH] Set of patches to enable DNS work in replica In-Reply-To: <20090716080444.6063f762@wolverine.englab.brq.redhat.com> References: <20090715152104.38042d30@wolverine.englab.brq.redhat.com> <4A5DDC10.8080405@redhat.com> <20090716080444.6063f762@wolverine.englab.brq.redhat.com> Message-ID: <4A671D61.6070107@redhat.com> Martin Nagy wrote: > On Wed, 15 Jul 2009 09:39:28 -0400, Rob Crittenden > wrote: > >> Martin Nagy wrote: >>> Patches are attached. Now we also provide an option --setup-dns to >>> ipa-replica-install that will set up BIND, but will only create the >>> zone if it didn't exist before. One patch also introduces reverse >>> zone, which we didn't have before. >>> >>> Martin >>> >> A couple of questions. >> >> So when installing a replica a bind instance isn't required? In other >> words, you could have a mixed environment where some IPA servers do >> DNS and others don't? >> >> Looks like the reverse_host and reverse_subnet code you are adding to >> bindinstance.py won't work on IPv6. > > I took a look at the code in ipa-server-install and it seems that it > doesn't have to work on IPv6. If you look on resolve_host() in there > (and I practically copied almost the same code for > ipa-replica-install), you'll notice that it uses the > socket.gethostbyname() function. This function, according to [1] does > not support IPv6. > > We probably should think about reworking the code to support IPv6 and > ideally also test it. But at least for now, I think the code for zones > is good enough, given that we don't support IPv6. > > Martin > > [1] http://docs.python.org/library/socket.html#socket.gethostbyname Ok, ack then. 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 mnagy at redhat.com Wed Jul 22 16:04:19 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 22 Jul 2009 18:04:19 +0200 Subject: [Freeipa-devel] [PATCH] Set of patches to enable DNS work in replica In-Reply-To: <4A671D61.6070107@redhat.com> References: <20090715152104.38042d30@wolverine.englab.brq.redhat.com> <4A5DDC10.8080405@redhat.com> <20090716080444.6063f762@wolverine.englab.brq.redhat.com> <4A671D61.6070107@redhat.com> Message-ID: <20090722180419.5e353f35@wolverine.englab.brq.redhat.com> On Wed, 22 Jul 2009 10:08:33 -0400, Rob Crittenden wrote: > Martin Nagy wrote: > > On Wed, 15 Jul 2009 09:39:28 -0400, Rob Crittenden > > wrote: > > > >> Martin Nagy wrote: > >>> Patches are attached. Now we also provide an option --setup-dns to > >>> ipa-replica-install that will set up BIND, but will only create > >>> the zone if it didn't exist before. One patch also introduces > >>> reverse zone, which we didn't have before. > >>> > >>> Martin > >>> > >> A couple of questions. > >> > >> So when installing a replica a bind instance isn't required? In > >> other words, you could have a mixed environment where some IPA > >> servers do DNS and others don't? > >> > >> Looks like the reverse_host and reverse_subnet code you are adding > >> to bindinstance.py won't work on IPv6. > > > > I took a look at the code in ipa-server-install and it seems that it > > doesn't have to work on IPv6. If you look on resolve_host() in there > > (and I practically copied almost the same code for > > ipa-replica-install), you'll notice that it uses the > > socket.gethostbyname() function. This function, according to [1] > > does not support IPv6. > > > > We probably should think about reworking the code to support IPv6 > > and ideally also test it. But at least for now, I think the code > > for zones is good enough, given that we don't support IPv6. > > > > Martin > > > > [1] http://docs.python.org/library/socket.html#socket.gethostbyname > > Ok, ack then. > > rob Pushed to master. Martin From sgallagh at redhat.com Wed Jul 22 16:40:09 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 22 Jul 2009 12:40:09 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Minor cleanups in monitor.c Message-ID: <4A6740E9.1010407@redhat.com> * Forgot to check for successful allocation * Used the wrong mem_ctx when allocating a timer event. -- 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-Minor-cleanups-in-monitor.c.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 Jul 22 17:09:39 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 22 Jul 2009 13:09:39 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Minor cleanups in monitor.c In-Reply-To: <4A6740E9.1010407@redhat.com> References: <4A6740E9.1010407@redhat.com> Message-ID: <1248282580.3136.2.camel@localhost.localdomain> On Wed, 2009-07-22 at 12:40 -0400, Stephen Gallagher wrote: > * Forgot to check for successful allocation > * Used the wrong mem_ctx when allocating a timer event. ack Simo. From jdennis at redhat.com Wed Jul 22 17:54:41 2009 From: jdennis at redhat.com (John Dennis) Date: Wed, 22 Jul 2009 13:54:41 -0400 Subject: [Freeipa-devel] [PATCH] initial commit of audit server code Message-ID: <4A675261.404@redhat.com> In the spirit of small patches this is the most minimal patch possible to get any part of the audit server in. It contains the basic autotools framework and just 1 c++ component, the logger facility used by the audit server. Because it's minimal you can't do anything with it except review 2 source files and build the documentation for it. To build the doc you'll need doxygen installed, then: cd doc make doc Then open in your web browser doc/api/html/index.html I'll keep sending patches for the other files one at a time. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Initial-commit-of-audit_server.patch Type: text/x-patch Size: 115364 bytes Desc: not available URL: From jhrozek at redhat.com Wed Jul 22 18:09:29 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 22 Jul 2009 20:09:29 +0200 Subject: [Freeipa-devel] [PATCHES] c-ares integration In-Reply-To: <1248201560.29458.304.camel@localhost.localdomain> References: <4A65F659.9020409@redhat.com> <1248201560.29458.304.camel@localhost.localdomain> Message-ID: <4A6755D9.80104@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All three patches with corrections are attached. Some comments inline. On 07/21/2009 08:39 PM, Simo Sorce wrote: > On Tue, 2009-07-21 at 19:09 +0200, Jakub Hrozek wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hello, >> The three attached patches integrate the c-ares async resolver library >> into SSSD. It is a follow-up to the code posted on this list earlier [1]. >> >> [PATCH 1/3] Async DNS integration >> This patch is the actual integration work with interface integrated with >> tevent and talloc which follows the _send/_recv notation. It also >> contains code to support build (like configure checks). > > I am a bit concerned about memory hierarchies here. > > In fd_event_add() you add a new event context allocating it on the > tevent_context memory context: > + fde = tevent_add_fd(ctx->ev_ctx, ctx, s, TEVENT_FD_READ, fd_input_available, watch); > > This is bad because if I talloc_free() the resolv context later on on, > all the events will not be freed but will stay around and watch->ctx > will point to freed memory. Allocating the watch itself on the > tevent_context is equally bad. > We changed the memory contexts a bit -- the watch structure is now allocated on resolv_ctx and the watch instance is in turn passed to tevent_add_fd to allocate the tevent_fd on. We also added a destructor to the watch instances, which invalidates the file descriptor before freeing the memory. > Another potential problem I see is that, if I read the code correctly, > resolv_gethostbyname_done() maybe called even if the original request > was freed, this may cause the code to segfault when it calls > tevent_req_XXX(req, ...) functions and tries to access freed memory. > If resolv_ctx is freed, destructor is called, which calls ares_destroy - and ares would cancel all the pending requests from the queue, so resolv_gethostbyname_done (which is a callback called from ares) would not be called. >> [PATCH 2/3] Add ares helpers into sssd >> The second patch contains ares_parse_srv_reply() and >> ares_parse_txt_reply() routines that I sent to ares upstream. Also >> contains configure-time detection of these in the system ares library >> and builds them only if necessary. > > I am not an expert in c-ares, but it looks like the code is sane, one > minor thing though. Unless upstream demands copyright assignment to MIT, > I think we can maintain the copyright, and even if assignment is > required we can do it only with the patches submitted to ares, no need > to do so with code into the sssd repo itself. > In any case the (C) is certainly not 1998. That is, unless you traveled > back in time to write it :-) > OK, I simply copied what I sent to upstream. They use (C) 1998 even for new code (which struck me, too, but as these parsing functions were my first submission, I did not want to propose too many changes at once..). As discussed on IRC, since the code is based on other parsing function in c-ares, I also left the original MIT notice there. >> [PATCH 3/3] Add async resolver tests >> A basic unit test. One of the tests resolves a name on the Internet, so >> it must be explicitly enabled. > > This look fine. > > Maybe when you take in account my comment to 1/3 you may want to add a > test that does something like this: > > make a _send call then set a timer of 1 second and free the resolv_ctx, > add another time of 1 second and then terminate. Perform this test with > a firewall or a network cable disconnected so that you run into delays. > Do the same but instead of freeing the resolv_ctx, simply free the > tevent_req pointer returned by the _send() function. > > If the code survives without segfaults then it is probably correct. > Ping me on IRC if you need some clarification on how to attain that. > > Simo. > I added these two testcases to the test code. Survived in both networked and offline environment. Thank you for the review, Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpnVdEACgkQHsardTLnvCV3OQCfUMmm7FT49/f5ZBo7s62lbq2Q 4K8AnAvjvSHwGL1hN574KMijEb5AuPu+ =7KuA -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Async-DNS-integration.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-Add-ares-helpers-into-sssd.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0003-Add-async-resolver-tests.patch URL: From sgallagh at redhat.com Wed Jul 22 18:11:52 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 22 Jul 2009 14:11:52 -0400 Subject: [Freeipa-devel] [PATCH][SSSD] Minor cleanups in monitor.c In-Reply-To: <1248282580.3136.2.camel@localhost.localdomain> References: <4A6740E9.1010407@redhat.com> <1248282580.3136.2.camel@localhost.localdomain> Message-ID: <4A675668.4030102@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/22/2009 01:09 PM, Simo Sorce wrote: > On Wed, 2009-07-22 at 12:40 -0400, Stephen Gallagher wrote: >> * Forgot to check for successful allocation >> * Used the wrong mem_ctx when allocating a timer event. > > ack > > Simo. > > _______________________________________________ > 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/ iEYEARECAAYFAkpnVmEACgkQeiVVYja6o6OnnwCeLmaINzlq1e9Lx80QJpVJbXXl oZ4AoJ89mChJ38vJEctnwHxpizBqzyjt =5Vc6 -----END PGP SIGNATURE----- From mathiaz at ubuntu.com Wed Jul 22 18:11:53 2009 From: mathiaz at ubuntu.com (Mathias Gug) Date: Wed, 22 Jul 2009 14:11:53 -0400 Subject: [Freeipa-devel] Ubuntu interests in FreeIPA In-Reply-To: <1246368630.13348.31.camel@localhost.localdomain> References: <20090629232054.GI5965@mathiaz.mathiaz.net> <1246368630.13348.31.camel@localhost.localdomain> Message-ID: Hi, Sorry for not following up earlier on this, but this topic has been recently brought on the Ubuntu freeipa team mailing list [1] [1]: https://lists.launchpad.net/freeipa/msg00009.html Here are my comments mainly related to supporting openldap instead of 389DS in FreeIPA: On Tue, Jun 30, 2009 at 9:30 AM, Simo Sorce wrote: > On Mon, 2009-06-29 at 19:20 -0400, Mathias Gug wrote: >> ?* 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. > Looking at freeipa-1.2.1/ipa-server/ipa-slapi-plugins/, there are 4 plugins: * dna: Distributed Numeric Assignment plug-in I don't know of an openldap plugin providing the same functionality. However one solution could be to use the uniq overlay to make sure the uids are unique: The Attribute Uniqueness overlay can be used with a backend database such as slapd-bdb(5) to enforce the uniqueness of some or all attributes within a scope. This subtree defaults to all objects within the subtree of the database for which the Uniqueness overlay is config? ured. For example, if uniqueness were enforced for the uid attribute, the subtree would be searched for any other records which also have a uid attribute containing the same value. If any are found, the request is rejected. That would also require some modification in the administration tools by pushing the logic to generate a new user id from the slapd server to the administration tools. The code responsible for creating a new user should take into account the possibility that the ldap add operation might fail because of an existing uid and update the uid accordingly before retrying. * ipa-memberof: IPA memberof plugin There is a similar overlay in openldap: The memberof overlay to slapd(8) allows automatic reverse group member? ship maintenance. Any time a group entry is modified, its members are modified as appropriate in order to keep a DN-valued "is member of" attribute updated with the DN of the group. * ipa-pwd-extop: Password Modify - LDAP Extended Operation There is a similar overlay in openldap/contrib: The smbk5pwd that extends the PasswordModify Extended Operation to update Kerberos keys and Samba password hashes for an LDAP user. However the code is currently written for Heimdal kerberos and should be ported to MIT Kerberos. * ipa-winsync: Windows Synchronization Plug-in for IPA I don't know of an openldap overlay that provides all the functionality of ipa-winsync. However the translucent overlay may be leverage to provide part of the functionality. What are the exact functionality provided by this plugin? It should also be noted that openldap support slapi plugins, which means that some FreeIPA plugins could be supported in openldap (to be tested though). Are there any other plugins that I've missed? > 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. > Noted. > ACIs are slightly different between 389DS and openLDAP, that would > require to change part of the installation and management tools. > Noted. > 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. > Agreed. The other option is bring in 389 DS in the archive. My main concern here is about resource to maintain the package once it's in the archive. As there already is a good ldap server in Ubuntu I'm not sure what we would gain for having *another* ldap server to maintain. >> ?* 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. > Agreed. > 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). > Agreed. -- Mathias Gug Ubuntu Developer http://www.ubuntu.com From sgallagh at redhat.com Wed Jul 22 19:05:10 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 22 Jul 2009 15:05:10 -0400 Subject: [Freeipa-devel] [PATCH] initial commit of log watcher (lwatch) In-Reply-To: <4A5F9274.8080906@redhat.com> References: <4A5F9274.8080906@redhat.com> Message-ID: <4A6762E6.6070309@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/16/2009 04:49 PM, John Dennis wrote: > This is a big patch, sorry, but there just isn't a realistic way to > develop a major piece of code into a working state given our checkin > policy which requires peer review for every change, it's just easier to > develop elsewhere and submit the working result. > > This is the basic framework for the client audit code, it produces an > executable called lwatch. In it's default mode lwatch watches a set of > (log) files. It understands how log files are rotated. When a log file > reaches a modification threshold it's newly appended data is prepared > for transport to the audit server. When the log file is rotated, > created, renamed, etc. the appropriate actions take place. > > lwatch maintains it's persistent state in a sqlite database. You can > start and stop lwatch and it self synchronizes based on what is in the > database and what it finds in the file system. > > lwatch is also capable of listing every log under a directory root, this > can be handy for initializing the set of log files to watch. > > lwatch can also dump in a pretty format the current state of the SQL > database. > > lwatch is not completely finished, but it's been in reasonable working > shape for a while now, but sitting in my own git repository, it's time > to get into the project's repository. What it needs next is better > configuration options and to link in the code for audit server > transmission (coming soon). > > Just one note about the patch, it includes a trivial one line fix to > dhash.h which was missing a const declaration. I realize that should > have been in a separate patch, but it got included here. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Nack. The following things must be corrected before this patch will be accepted. General: The log file /tmp/lwatch.log is not usable by two users simultaneously. Each user should have his/her own log file or there should be a mechanism in place to log safely to the common log. There is a similar problem with the sqlite database. The first user to execute lwatch gains permissions on the database. No other users have write access after that (except root). DEBUG messages should be controlled by a commandline parameter. /lwatch/configure.ac: You need to have a configure test for sqlite3. /lwatch/src/Makefile.am: Don't use $(srcdir) as a path to built binaries. This doesn't support parallel build trees. For linking dhash and path_utils, it needs to be relative to $(builddir). Creation of /var/lib/lwatch needs to be part of 'make install' (e.g. create an install-exec-hook rule) /lwatch/src/lwatch.c: The return values from file_event_string should be localized. log_msg() should be a macro. It's very ugly reading __FUNCTION__ all over the code. In process_file_rename() and many other places, you are using strncpy unsafely. If the source string is equal or longer than the destination string, strncpy() does not null-terminate. As a result, reading from it could wander off the page. It's always wise to do strncpy(dest, orig, sizeof(dest)-1); dest[sizeof(dest)-1] = '\0'; lwatch_event_string() is using snprintf() unsafely. If the string (after substitution) exceeds "buf_end-p", the function will only write buf_end-p values, but it will return the TOTAL size that would have been written if it had not been truncated. You need to test for that. Things that aren't necessarily worth holding up the commit for: I'd like to recommend that you switch to using tevent for processing your mainloop and signal handlers. It's much safer for the latter than just catching signals, as it will just queue the handler processing for the next loop, instead of breaking execution. compare_stat_info() makes an assumption that if the filesize is larger, then it's been appended to. It's possible that a larger file has been moved into place atop the older file. Perhaps you can check whether the inode number has changed? I have so far only reviewed lwatch.c. I will review other components over the next day or two, but I figured I'd send back these comments first. - -- 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/ iEYEARECAAYFAkpnYuEACgkQeiVVYja6o6OOEACeIW5DTfraYeShxwMeRVb81Z63 hPwAnjr6jYd9/nMAnZ6qkN7SeTlkS6qG =qL61 -----END PGP SIGNATURE----- From jdennis at redhat.com Wed Jul 22 19:58:26 2009 From: jdennis at redhat.com (John Dennis) Date: Wed, 22 Jul 2009 15:58:26 -0400 Subject: [Freeipa-devel] [PATCH] initial commit of log watcher (lwatch) In-Reply-To: <4A6762E6.6070309@redhat.com> References: <4A5F9274.8080906@redhat.com> <4A6762E6.6070309@redhat.com> Message-ID: <4A676F62.6070702@redhat.com> On 07/22/2009 03:05 PM, Stephen Gallagher wrote: > Nack. The following things must be corrected before this patch will be > accepted. > > General: > The log file /tmp/lwatch.log is not usable by two users simultaneously. > Each user should have his/her own log file or there should be a > mechanism in place to log safely to the common log. > There is a similar problem with the sqlite database. The first user to > execute lwatch gains permissions on the database. No other users have > write access after that (except root). There is no concept of per user, this will morph into a system daemon thus there is no need for any of the above. The use of of /tmp/lwatch.log is just pre-production staging, final production code will move it to a configured logging location (default /var/log/lwatch.log) > DEBUG messages should be controlled by a commandline parameter. of course :-) > > /lwatch/configure.ac: > You need to have a configure test for sqlite3. good point and I am aware of it. > /lwatch/src/Makefile.am: > Don't use $(srcdir) as a path to built binaries. This doesn't support > parallel build trees. For linking dhash and path_utils, it needs to be > relative to $(builddir). O.K., but note some of the existing Makefile.am's don't do this. > Creation of /var/lib/lwatch needs to be part of 'make install' (e.g. > create an install-exec-hook rule) FWIW I think the location of the sqlite database should be a (yet to be created) config parameter. I do realize things like install rules and configuration parameters are absent, it's pre-production, but I will add them now rather than later. > > /lwatch/src/lwatch.c: > The return values from file_event_string should be localized. > log_msg() should be a macro. It's very ugly reading __FUNCTION__ all > over the code. > In process_file_rename() and many other places, you are using strncpy > unsafely. If the source string is equal or longer than the destination > string, strncpy() does not null-terminate. As a result, reading from it > could wander off the page. It's always wise to do strncpy(dest, orig, > sizeof(dest)-1); > dest[sizeof(dest)-1] = '\0'; > lwatch_event_string() is using snprintf() unsafely. If the string (after > substitution) exceeds "buf_end-p", the function will only write > buf_end-p values, but it will return the TOTAL size that would have been > written if it had not been truncated. You need to test for that. > > > > Things that aren't necessarily worth holding up the commit for: > > I'd like to recommend that you switch to using tevent for processing > your mainloop and signal handlers. It's much safer for the latter than > just catching signals, as it will just queue the handler processing for > the next loop, instead of breaking execution. yes, that's on the to-do list. > > compare_stat_info() makes an assumption that if the filesize is larger, > then it's been appended to. It's possible that a larger file has been > moved into place atop the older file. Perhaps you can check whether the > inode number has changed? It does check: /* If the device or inode is different it must be a different file */ if ((stat_info->st_dev != path_info->dev) || (stat_info->st_ino != path_info->inode)) { result = FILE_REPLACED; } Thank you for your review Stephen, I'll push out a updated patch shortly to address your concerns. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Wed Jul 22 20:11:33 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 22 Jul 2009 16:11:33 -0400 Subject: [Freeipa-devel] [PATCHES] c-ares integration In-Reply-To: <4A6755D9.80104@redhat.com> References: <4A65F659.9020409@redhat.com> <1248201560.29458.304.camel@localhost.localdomain> <4A6755D9.80104@redhat.com> Message-ID: <1248293493.3136.10.camel@localhost.localdomain> On Wed, 2009-07-22 at 20:09 +0200, Jakub Hrozek wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > All three patches with corrections are attached. Some comments inline. Patches look good to me, ack to all three. Simo. From dpal at redhat.com Wed Jul 22 20:44:49 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 22 Jul 2009 16:44:49 -0400 Subject: [Freeipa-devel] Ubuntu interests in FreeIPA In-Reply-To: References: <20090629232054.GI5965@mathiaz.mathiaz.net> <1246368630.13348.31.camel@localhost.localdomain> Message-ID: <4A677A41.3060009@redhat.com> > Looking at freeipa-1.2.1/ipa-server/ipa-slapi-plugins/, there are 4 plugins: > > * dna: Distributed Numeric Assignment plug-in > > I don't know of an openldap plugin providing the same functionality. > > However one solution could be to use the uniq overlay to make sure the > uids are unique: > > The Attribute Uniqueness overlay can be used with a backend database > such as slapd-bdb(5) to enforce the uniqueness of some or all > attributes within a scope. This subtree defaults to all objects within > the subtree of the database for which the Uniqueness overlay is config? > ured. > > For example, if uniqueness were enforced > for the uid attribute, the subtree would be searched for any other > records which also have a uid attribute containing the same value. If > any are found, the request is rejected. > > That would also require some modification in the administration tools > by pushing the logic to generate a new user id from the slapd server > to the administration tools. The code responsible for creating a new > user should take into account the possibility that the ldap add > operation might fail because of an existing uid and update the uid > accordingly before retrying. > > You need to take replication into the account. The DNA plugin guarantees uniqueness across the whole deployment, not just one server. AFAIK the replication in OpenLDAP is done differently and the DNA plugin does the range negotiation between replicas as a part of the replication protocol. -- 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 Wed Jul 22 21:25:48 2009 From: mathiaz at ubuntu.com (Mathias Gug) Date: Wed, 22 Jul 2009 17:25:48 -0400 Subject: [Freeipa-devel] Ubuntu interests in FreeIPA In-Reply-To: <4A677A41.3060009@redhat.com> References: <20090629232054.GI5965@mathiaz.mathiaz.net> <1246368630.13348.31.camel@localhost.localdomain> <4A677A41.3060009@redhat.com> Message-ID: <20090722212547.GK5764@mathiaz.mathiaz.net> On Wed, Jul 22, 2009 at 04:44:49PM -0400, Dmitri Pal wrote: > > > Looking at freeipa-1.2.1/ipa-server/ipa-slapi-plugins/, there are 4 plugins: > > > > * dna: Distributed Numeric Assignment plug-in > > > > I don't know of an openldap plugin providing the same functionality. > > > > However one solution could be to use the uniq overlay to make sure the > > uids are unique: > > > > The Attribute Uniqueness overlay can be used with a backend database > > such as slapd-bdb(5) to enforce the uniqueness of some or all > > attributes within a scope. This subtree defaults to all objects within > > the subtree of the database for which the Uniqueness overlay is config? > > ured. > > > > For example, if uniqueness were enforced > > for the uid attribute, the subtree would be searched for any other > > records which also have a uid attribute containing the same value. If > > any are found, the request is rejected. > > > > That would also require some modification in the administration tools > > by pushing the logic to generate a new user id from the slapd server > > to the administration tools. The code responsible for creating a new > > user should take into account the possibility that the ldap add > > operation might fail because of an existing uid and update the uid > > accordingly before retrying. > > > > > You need to take replication into the account. The DNA plugin guarantees > uniqueness across the whole deployment, not just one server. > AFAIK the replication in OpenLDAP is done differently and the DNA plugin > does the range negotiation between replicas as a part of the replication > protocol. > Right. One proposal is to have a MirrorMode configuration [1] with the chain overlay configured on all slaves. That way all writes are eventually done on one server where the uniqueness of the uid value is asserted. [1]: http://www.openldap.org/doc/admin24/replication.html#MirrorMode%20replication -- 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 dpal at redhat.com Wed Jul 22 22:07:41 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 22 Jul 2009 18:07:41 -0400 Subject: [Freeipa-devel] Ubuntu interests in FreeIPA In-Reply-To: <20090722212547.GK5764@mathiaz.mathiaz.net> References: <20090629232054.GI5965@mathiaz.mathiaz.net> <1246368630.13348.31.camel@localhost.localdomain> <4A677A41.3060009@redhat.com> <20090722212547.GK5764@mathiaz.mathiaz.net> Message-ID: <4A678DAD.6020208@redhat.com> Mathias Gug wrote: > On Wed, Jul 22, 2009 at 04:44:49PM -0400, Dmitri Pal wrote: > >>> Looking at freeipa-1.2.1/ipa-server/ipa-slapi-plugins/, there are 4 plugins: >>> >>> * dna: Distributed Numeric Assignment plug-in >>> >>> I don't know of an openldap plugin providing the same functionality. >>> >>> However one solution could be to use the uniq overlay to make sure the >>> uids are unique: >>> >>> The Attribute Uniqueness overlay can be used with a backend database >>> such as slapd-bdb(5) to enforce the uniqueness of some or all >>> attributes within a scope. This subtree defaults to all objects within >>> the subtree of the database for which the Uniqueness overlay is config? >>> ured. >>> >>> For example, if uniqueness were enforced >>> for the uid attribute, the subtree would be searched for any other >>> records which also have a uid attribute containing the same value. If >>> any are found, the request is rejected. >>> >>> That would also require some modification in the administration tools >>> by pushing the logic to generate a new user id from the slapd server >>> to the administration tools. The code responsible for creating a new >>> user should take into account the possibility that the ldap add >>> operation might fail because of an existing uid and update the uid >>> accordingly before retrying. >>> >>> >>> >> You need to take replication into the account. The DNA plugin guarantees >> uniqueness across the whole deployment, not just one server. >> AFAIK the replication in OpenLDAP is done differently and the DNA plugin >> does the range negotiation between replicas as a part of the replication >> protocol. >> >> > > Right. One proposal is to have a MirrorMode configuration [1] with the > chain overlay configured on all slaves. That way all writes are > eventually done on one server where the uniqueness of the uid value is > asserted. > > [1]: http://www.openldap.org/doc/admin24/replication.html#MirrorMode%20replication > > Yes but this significantly limits the functionality. The whole point use of 389 is its rock solid MMR and updates done on multiple machines. -- 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 Wed Jul 22 22:10:26 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 22 Jul 2009 18:10:26 -0400 Subject: [Freeipa-devel] [PATCHES] one for INI another for ELAPI Message-ID: <4A678E52.1030007@redhat.com> Patch 1 (small) [PATCH] INI Simple fix to properly process multi value config parameters. Also fixed a typo in the header file. Patch 2 (big) [PATCH] ELAPI Next round of functionality - logging part of the interface a) Added the main logging interface which allows creating dispatcher and logging messages or events. Can't actually log anything yet since the sinks are stubbed out. b) Made default template be a part of the default dispatcher. c) Updated UNIT test. d) Added preview of the async interface (subject to change when I actually try to implement it and see what is missing). e) Some of the calls are stubbed out but they are there to indicate where next round of work will be. -- 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-INI-Simple-fix-to-properly-process-multi-value-confi.patch Type: text/x-patch Size: 1708 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-ELAPI-Next-round-of-functionality-logging-part-of.patch Type: text/x-patch Size: 65346 bytes Desc: not available URL: From jhrozek at redhat.com Thu Jul 23 08:56:02 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 23 Jul 2009 10:56:02 +0200 Subject: [Freeipa-devel] [PATCHES] c-ares integration In-Reply-To: <1248293493.3136.10.camel@localhost.localdomain> References: <4A65F659.9020409@redhat.com> <1248201560.29458.304.camel@localhost.localdomain> <4A6755D9.80104@redhat.com> <1248293493.3136.10.camel@localhost.localdomain> Message-ID: <4A6825A2.90800@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/22/2009 10:11 PM, Simo Sorce wrote: > Patches look good to me, ack to all three. > > Simo. > Thank you for the review, attached are rebased versions as those I sent did not apply cleanly on top of current HEAD. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpoJaIACgkQHsardTLnvCXJowCglkxaITDdOCzqm8E3kgFzigWX IaIAn1eFgbwFNqO1MOtrKiKUM3ftcFMG =LBir -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Async-DNS-integration.patch Type: text/x-patch Size: 23578 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-ares-helpers-into-sssd.patch Type: text/x-patch Size: 21156 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-async-resolver-tests.patch Type: text/x-patch Size: 14020 bytes Desc: not available URL: From sgallagh at redhat.com Thu Jul 23 15:08:13 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 23 Jul 2009 11:08:13 -0400 Subject: [Freeipa-devel] [PATCH] initial commit of log watcher (lwatch) In-Reply-To: <4A676F62.6070702@redhat.com> References: <4A5F9274.8080906@redhat.com> <4A6762E6.6070309@redhat.com> <4A676F62.6070702@redhat.com> Message-ID: <4A687CDD.9070304@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/22/2009 03:58 PM, John Dennis wrote: > On 07/22/2009 03:05 PM, Stephen Gallagher wrote: >> Nack. The following things must be corrected before this patch will be >> accepted. >> >> General: >> The log file /tmp/lwatch.log is not usable by two users simultaneously. >> Each user should have his/her own log file or there should be a >> mechanism in place to log safely to the common log. >> There is a similar problem with the sqlite database. The first user to >> execute lwatch gains permissions on the database. No other users have >> write access after that (except root). > > There is no concept of per user, this will morph into a system daemon > thus there is no need for any of the above. > > The use of of /tmp/lwatch.log is just pre-production staging, final > production code will move it to a configured logging location (default > /var/log/lwatch.log) > >> DEBUG messages should be controlled by a commandline parameter. > > of course :-) > >> >> /lwatch/configure.ac: >> You need to have a configure test for sqlite3. > > good point and I am aware of it. > >> /lwatch/src/Makefile.am: >> Don't use $(srcdir) as a path to built binaries. This doesn't support >> parallel build trees. For linking dhash and path_utils, it needs to be >> relative to $(builddir). > > O.K., but note some of the existing Makefile.am's don't do this. > Can you point me at examples of this? I build exclusively in parallel trees (mainly to catch cases where it fails) and the build system is working correctly. $(builddir) should be used wherever built files are needed, and $(srcdir) should be used wherever the path needs to be relative to the uncompiled sources. >> Creation of /var/lib/lwatch needs to be part of 'make install' (e.g. >> create an install-exec-hook rule) > > FWIW I think the location of the sqlite database should be a (yet to be > created) config parameter. I do realize things like install rules and > configuration parameters are absent, it's pre-production, but I will add > them now rather than later. > Thanks. I agree that it should be a configure parameter. I was just going to let that one slide for first commit. >> >> /lwatch/src/lwatch.c: >> The return values from file_event_string should be localized. >> log_msg() should be a macro. It's very ugly reading __FUNCTION__ all >> over the code. >> In process_file_rename() and many other places, you are using strncpy >> unsafely. If the source string is equal or longer than the destination >> string, strncpy() does not null-terminate. As a result, reading from it >> could wander off the page. It's always wise to do strncpy(dest, orig, >> sizeof(dest)-1); >> dest[sizeof(dest)-1] = '\0'; >> lwatch_event_string() is using snprintf() unsafely. If the string (after >> substitution) exceeds "buf_end-p", the function will only write >> buf_end-p values, but it will return the TOTAL size that would have been >> written if it had not been truncated. You need to test for that. >> >> >> >> Things that aren't necessarily worth holding up the commit for: >> >> I'd like to recommend that you switch to using tevent for processing >> your mainloop and signal handlers. It's much safer for the latter than >> just catching signals, as it will just queue the handler processing for >> the next loop, instead of breaking execution. > > yes, that's on the to-do list. > >> >> compare_stat_info() makes an assumption that if the filesize is larger, >> then it's been appended to. It's possible that a larger file has been >> moved into place atop the older file. Perhaps you can check whether the >> inode number has changed? > > It does check: > > /* If the device or inode is different it must be a different file */ > if ((stat_info->st_dev != path_info->dev) || (stat_info->st_ino != > path_info->inode)) { > result = FILE_REPLACED; > } Sorry missed that in my review. > > > Thank you for your review Stephen, I'll push out a updated patch shortly > to address your concerns. > Thanks for the replies. I'm still working on my review. Expect more comments later today. - -- 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/ iEYEARECAAYFAkpofNgACgkQeiVVYja6o6OI9QCcC2yS/QY4IcI2qwJ2bm3jGoKS DB0AnRZ1yOgA/IZoLncXItWpMmz8a4GJ =KyHJ -----END PGP SIGNATURE----- From rcritten at redhat.com Thu Jul 23 16:25:38 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 23 Jul 2009 12:25:38 -0400 Subject: [Freeipa-devel] [PATCH] 240 Better cert nickname handling Message-ID: <4A688F02.9070307@redhat.com> A few issues were found in the way we identify the root cert to trust when importing PKCS#12 files. The regex was not specific enough and there is no need to explicitly trust root CAs that are built into NSS. I also did a little bit of code cleanup to add logging and remove an unused import. And finally, I added a bit of code that should help a basic install on Fedora 11. The certutil on Fedora 11 doesn't return untrusted CAs in its -O output. This will fix the self-signed IPA default CA case anway. If acked I'll push a similar patch to the 1-2 branch as well. We lack the self-signed CA awareness so I'm not sure how I'm going to tackle that yet but I suspect that I'll simply make it the default if no CA is found (along with a log entry saying so). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-240-certs.patch Type: text/x-patch Size: 2279 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 Thu Jul 23 18:19:37 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 23 Jul 2009 14:19:37 -0400 Subject: [Freeipa-devel] [PATCH] Missing ELAPI patch Message-ID: <4A68A9B9.2000000@redhat.com> This is a missing patch. It just corrects some basic naming and adds offset property to the template. The patches: INI-Simple-fix-to-properly-process-multi-value-confi.patch ELAPI-Next-round-of-functionality-logging-part-of.patch should be applied on top of it. -- 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-ELAPI-Adding-core-functionality.patch Type: text/x-patch Size: 4858 bytes Desc: not available URL: From rcritten at redhat.com Thu Jul 23 19:00:04 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 23 Jul 2009 15:00:04 -0400 Subject: [Freeipa-devel] [PATCH] Fix SELinux compilation on Fedora 11 In-Reply-To: <1247325218.6317.228.camel@localhost.localdomain> References: <4A4BBE97.9010907@redhat.com> <1247325218.6317.228.camel@localhost.localdomain> Message-ID: <4A68B334.5040302@redhat.com> Simo Sorce wrote: > On Wed, 2009-07-01 at 15:52 -0400, Rob Crittenden wrote: >> Fedora 11 replaced a SELinux macro which was causing the build to fail. >> Dan Walsh provided a patch to fix it and this patch integrates it into >> the tree. I've added a conditional so that the same policy file should >> build against even old SELinux policies (I tested on Fedora 9 and 11). >> >> I've included patches for both the master and ipa-1-2 branches. > > ack > Finally got around to pushing to master and ipa-1-2 branch 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 Thu Jul 23 19:14:05 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 23 Jul 2009 15:14:05 -0400 Subject: [Freeipa-devel] [PATCH] initial commit of log watcher (lwatch) In-Reply-To: <4A5F9274.8080906@redhat.com> References: <4A5F9274.8080906@redhat.com> Message-ID: <4A68B67D.1010808@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/16/2009 04:49 PM, John Dennis wrote: > This is a big patch, sorry, but there just isn't a realistic way to > develop a major piece of code into a working state given our checkin > policy which requires peer review for every change, it's just easier to > develop elsewhere and submit the working result. > > This is the basic framework for the client audit code, it produces an > executable called lwatch. In it's default mode lwatch watches a set of > (log) files. It understands how log files are rotated. When a log file > reaches a modification threshold it's newly appended data is prepared > for transport to the audit server. When the log file is rotated, > created, renamed, etc. the appropriate actions take place. > > lwatch maintains it's persistent state in a sqlite database. You can > start and stop lwatch and it self synchronizes based on what is in the > database and what it finds in the file system. > > lwatch is also capable of listing every log under a directory root, this > can be handy for initializing the set of log files to watch. > > lwatch can also dump in a pretty format the current state of the SQL > database. > > lwatch is not completely finished, but it's been in reasonable working > shape for a while now, but sitting in my own git repository, it's time > to get into the project's repository. What it needs next is better > configuration options and to link in the code for audit server > transmission (coming soon). > > Just one note about the patch, it includes a trivial one line fix to > dhash.h which was missing a const declaration. I realize that should > have been in a separate patch, but it got included here. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Review Part II lwatch/watch_database.c: sqlite3_result_string() - typo in the default case. "unkown" -> "unknown" table_exists() - You're looping through results to see if the table exists, but the SELECT query suggests that you should only be expecting a single result. If you get more than one result back, shouldn't that imply that the database has been corrupted and be treated as an error? populate_path_info() - misuse of strncpy(). Not ensuring null termination. You do this in many other places, so I will not repeat this complaint again. It would be prudent to have the positions of the values in the statement be #defines instead of magic numbers, to make it easier to change later if you add or remove columns. path_info_flags_string() - Same snprintf() misuse as I mentioned in my earlier review. Repeated in several other functions, so I will not repeat myself. util.c: pathname_table_string() - You are misusing realloc(). If realloc() returns NULL, you have leaked the original memory for tbl_string. regexp.c: Please prefer using the fully expanded error string PCRE_ERROR_* (as you do with the SQLite error strings in watch_database.c) inotify_watch.c: I don't see any additional problems other than those indicated above. This concludes my review of this iteration of the patch. - -- 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/ iEYEARECAAYFAkpotnUACgkQeiVVYja6o6MImgCfZf3qaMt+8wugE+WQTl5lKzYV f3IAnjzMmsLz+g0s8iwH8NhexE6yoeya =Utcx -----END PGP SIGNATURE----- From jderose at redhat.com Thu Jul 23 19:54:19 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Thu, 23 Jul 2009 13:54:19 -0600 Subject: [Freeipa-devel] [PATCH] 240 Better cert nickname handling In-Reply-To: <4A688F02.9070307@redhat.com> References: <4A688F02.9070307@redhat.com> Message-ID: <1248378860.2739.0.camel@jgd-flap> On Thu, 2009-07-23 at 12:25 -0400, Rob Crittenden wrote: > A few issues were found in the way we identify the root cert to trust > when importing PKCS#12 files. The regex was not specific enough and > there is no need to explicitly trust root CAs that are built into NSS. > > I also did a little bit of code cleanup to add logging and remove an > unused import. > > And finally, I added a bit of code that should help a basic install on > Fedora 11. The certutil on Fedora 11 doesn't return untrusted CAs in its > -O output. This will fix the self-signed IPA default CA case anway. > > If acked I'll push a similar patch to the 1-2 branch as well. We lack > the self-signed CA awareness so I'm not sure how I'm going to tackle > that yet but I suspect that I'll simply make it the default if no CA is > found (along with a log entry saying so). > > rob ack. pushed to master. From rcritten at redhat.com Thu Jul 23 20:18:07 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 23 Jul 2009 16:18:07 -0400 Subject: [Freeipa-devel] [PATCH] jderose 011 Fleshed out krb plugin and added example of scripting against Python API In-Reply-To: <1246950430.6198.55.camel@jgd-flap> References: <1246950430.6198.55.camel@jgd-flap> Message-ID: <4A68C57F.2070904@redhat.com> Jason Gerard DeRose wrote: > This patch adds the first example of scripting against the IPA Python > API in doc/examples/python-api.py. > > It also finally fleshes out the ipalib.plugins.kerberos.krb plugin. It > wraps the krbV bindings and does correct Unicode encoding/decoding. > More work will be coming shortly with some exception handling cleanup > and porting code to use Backend.krb instead of krbV, but this is a > start. > > I'm still trying to decide on a good solution for implementing the > connection creation in a generic and plugable way (to replace the > hard-coded Executioner.create_context() method). The difficulty is 1) > we need it to be plugable, we want to be able to add new backends that > authenticate using their own mechanisms, while at the same time 2) we > only want to expose connections (but not credentials of any kind) on > request.context, and to make things worse, we 3) want to lazily create > connections whenever possible. > > I took a couple of stabs at the above, but didn't like any of them, so > for now doc/examples/python-api.py just uses a similar hard-coded > connection setup to what Executioner.create_context() uses, specifically > it does this: > > if api.env.in_server: > api.Backend.ldap2.connect( > ccache=api.Backend.krb.default_ccname() > ) > else: > api.Backend.xmlclient.connect() > > This will be replaced eventually with some common method, but this works > for now. > > One last thing: to be consisted with the Kerberos library (right?) and > SASL, I think we should consistently use `ccname` to mean the path of > the file containing the credential cache. We use `ccache` a lot > instead, which can also be confused with the krbV.CCache object. What > does everyone think about this? > > Cheers, > Jason 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 ssorce at redhat.com Thu Jul 23 20:18:15 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 23 Jul 2009 16:18:15 -0400 Subject: [Freeipa-devel] [PATCH] Fix race condition leading to segfaults Message-ID: <1248380295.17697.81.camel@localhost.localdomain> Sumit found out that ldap auth would segfault from time to time. The problem was the way ldap_result() works you don't know how many results are in the pipe so you have to keep polling, once the fde fired, until you get back a 0. The problem although, was that once a result was received the calling function, upon getting called by op->callback(), could decide to free the sdap_handle and all dependent memory like it happens in sdap_pam_auth_done() which is called through a chain of callbacks from sdap_process_message() The following patch addresses the problem using, temporarily a timer event to schedule any other call only after the callback is finished. The events are appended on the sdap_handle, so that if the function being called actually frees it, all pending events are also freed without risk. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-race-condition-that-was-causing-segfaults.patch Type: text/x-patch Size: 9503 bytes Desc: not available URL: From rcritten at redhat.com Thu Jul 23 21:01:05 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 23 Jul 2009 17:01:05 -0400 Subject: [Freeipa-devel] [PATCH] 241 fix deprecation warning in certs.py Message-ID: <4A68CF91.4030705@redhat.com> Fix deprecation warning for the sha library on Python 2.6 sha has been replaced by hashlib. We need to support Python 2.4 - 2.6 so this will use hashlib if available but fall back onto sha if not. Fortunately they use the same API for the function we need. This is a partial fix for bug 509042 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-241-sha.patch Type: application/mbox Size: 1578 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 Thu Jul 23 21:57:02 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 23 Jul 2009 17:57:02 -0400 Subject: [Freeipa-devel] [PATCH] 242 new method to identify CAs to trust Message-ID: <4A68DCAE.7060206@redhat.com> A new way to identify the CAs to trust when importing a PKCS#12 file (like during replica installation). We used to use certutil -O but Fedora 11 changed certutil so it doesn't show untrusted CAs (the whole point of running the command). Instead parse the output of pk12util -l to find the nicknames of the CAs to trust. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-242-trust.patch Type: application/mbox Size: 4015 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 Jul 24 01:01:51 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 23 Jul 2009 21:01:51 -0400 Subject: [Freeipa-devel] [PATCH] initial commit of log watcher (lwatch) In-Reply-To: <4A5F9274.8080906@redhat.com> References: <4A5F9274.8080906@redhat.com> Message-ID: <4A6907FF.5080001@redhat.com> John Dennis wrote: > This is a big patch, sorry, but there just isn't a realistic way to > develop a major piece of code into a working state given our checkin > policy which requires peer review for every change, it's just easier > to develop elsewhere and submit the working result. > > This is the basic framework for the client audit code, it produces an > executable called lwatch. In it's default mode lwatch watches a set of > (log) files. It understands how log files are rotated. When a log file > reaches a modification threshold it's newly appended data is prepared > for transport to the audit server. When the log file is rotated, > created, renamed, etc. the appropriate actions take place. > > lwatch maintains it's persistent state in a sqlite database. You can > start and stop lwatch and it self synchronizes based on what is in the > database and what it finds in the file system. > > lwatch is also capable of listing every log under a directory root, > this can be handy for initializing the set of log files to watch. > > lwatch can also dump in a pretty format the current state of the SQL > database. > > lwatch is not completely finished, but it's been in reasonable working > shape for a while now, but sitting in my own git repository, it's time > to get into the project's repository. What it needs next is better > configuration options and to link in the code for audit server > transmission (coming soon). > > Just one note about the patch, it includes a trivial one line fix to > dhash.h which was missing a const declaration. I realize that should > have been in a separate patch, but it got included here. > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel John, Steve wanted me to take a look at this code too. Just to have a second pair of eyes. I am doing it and will write notes as I go. I do not know if any of those are blockers and would trigger nacks and which can be treated as "work" in progress. Let us use bast judgment. I have not read Steven's note on purpose so that I do not narrow my vision. Here we go: 1) There is generally a lack of comments in the code. it is very hard to read. IMO the lack of comments is a style issue rather then maturity of the code issue. It seems funny that function that trims spaces is commented. It would have been very easy to understand what the function does by its name. And the code is pretty simple. While more complex functions around do not have any line on comments. It would think that the following practice should be employed: Each function is commented on in the header or in the module (better in both). It least in one of these two places it is necessary to explain what the function does, why it is needed and where it used. For example: /* Allocates and builds a memory buffer out the hash table entries. Used when ... */ char *pathname_table_string(hash_table_t *table) The more complex the function is the better it should be commented. 2) In many places the spaces are missing around commas, "-", "+". It is hard to read. Again would be nice for it to follow standard. I find these things in my code to and try to correct them as I see them. Just a suggestion to try a bit harder make things more readable. There are many places that can be improved. 3) Heavy use of the complex constructs: if ((tbl_string = realloc(tbl_string, alloc_len = alloc_len+MAX(needed_len,alloc_increment))) == NULL) { Would be much more readable if things like that are split into two lines. alloc_len += MAX(needed_len, alloc_increment); if ((tbl_string = realloc(tbl_string, alloc_len)) == NULL) { 4) In multiple places there is just one line of code inside the {} after if for example: if ((tbl_string = malloc(alloc_len = alloc_increment)) == NULL) { return NULL; } should be: if ((tbl_string = malloc(alloc_len = alloc_increment)) == NULL) return NULL; but I would even prefer something like: alloc_len = alloc_increment; tbl_string = malloc(alloc_len); if (!tbl_string) { return NULL; } 5) Variables are not initialized at the top of the function. It is generally a good practice to initialize things at the top of the function. 6) In several places I noticed you miss va_end macro where you use va_list and va_start(). >From vsnprintf man page: These functions do not call the va_end macro. Consequently, the value of ap is undefined after the call. The application should call va_end(ap) itself afterwards. 7) It should be a practice of using thread safe versions of system functions like localtime (localtime_r) , getgrgid (getgrgid_r) etc. We are considering combining the log monitor with audit collection. These are two separate functions it would be logical to have them in separate threads. This is undecided but at least I think it would be better to be on the safe side and not use unsafe calls. Just good defensive programming practice. 8) A lot of static global data. It would be beneficial to combine these things together in some kind of context structure and pass it around. Even if you keep it static for now it would be easier to refine code later. Currently too many low level functions rely the global data so it would require a significant refactoring effort to get rid of those down the road. 9) SSSD and Common and Audit all three use tree different ways of tracing/debugging things. Shouldn't we get to some consistency there? It would be better if the log_msg be a macro from the very beginning. This way it would be easier to make it conditionally compiled debugging. Currently is is function and would require significant effort to go through the code and make it consistent. I would argue that a) Tracing/debugging should be conditionally compiled day 1 b) Debugging strings do not require translation c) Tracing pattern should be consistent - every error should be traced otherwise it is hard to find problems. Just something to think about... 10) Such code will not produce right results since there are multiple ways why function can return NULL and not in all cases the errno is set. if ((pw = new_path_watch(existing_directory_ancestor)) == NULL) { + error = errno; + log_msg(LOG_ERROR, _("%s: could not allocate new watch for \"%s\" (%s)\n"), + __FUNCTION__, existing_directory_ancestor, error_string(error)); + return error; Better approach to such cases would be either pw = new_path_watch(existing_directory_ancestor, &error); if (!pw) { ... or which I prefer more: error = new_path_watch(&pw, existing_directory_ancestor); if(error) { ... 11) From our design discussions I remember that you mentioned that there was an issue with recursive directories and monitoring nested paths or something like this. It seems that find_existing_directory_ancestor() has to do with this issue. I was expecting to see some extended comment about this somewhere around create_watch() function. 12) In search for some functions I looked at path_utils. First in general I am a bit scared about using static buffers to hold paths. Is it still an Ok practice? In the SSSD all code is allocated in collections and ini the only place where the static buffer was used was some parsing of the file where the reasonable length of the line in the ini file is less than 100 bytes while buffer is about 64K. Should we use dynamic memory for paths? Start with malloc(MAX_PATH) and then realloc if needed? 13) I was amazed how well the path_util interface is defined and documented . I will consider using it whenever I need to deal with paths. This is all for now. A general comment is that without running the code and playing with it for some time it is hard to find any specific issues (if any) in logic. On the surface things seem well thought through and the functions are not big and modular but lack of comments makes it really hard to digest. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jderose at redhat.com Fri Jul 24 02:04:40 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Thu, 23 Jul 2009 20:04:40 -0600 Subject: [Freeipa-devel] [PATCH] 241 fix deprecation warning in certs.py In-Reply-To: <4A68CF91.4030705@redhat.com> References: <4A68CF91.4030705@redhat.com> Message-ID: <1248401080.2713.0.camel@jgd-flap> On Thu, 2009-07-23 at 17:01 -0400, Rob Crittenden wrote: > Fix deprecation warning for the sha library on Python 2.6 > > sha has been replaced by hashlib. We need to support Python 2.4 - 2.6 so > this will use hashlib if available but fall back onto sha if not. > Fortunately they use the same API for the function we need. > > This is a partial fix for bug 509042 > > rob ack. pushed to master. From jderose at redhat.com Fri Jul 24 03:00:54 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Thu, 23 Jul 2009 21:00:54 -0600 Subject: [Freeipa-devel] [PATCH] 242 new method to identify CAs to trust In-Reply-To: <4A68DCAE.7060206@redhat.com> References: <4A68DCAE.7060206@redhat.com> Message-ID: <1248404454.2713.1.camel@jgd-flap> On Thu, 2009-07-23 at 17:57 -0400, Rob Crittenden wrote: > A new way to identify the CAs to trust when importing a PKCS#12 file > (like during replica installation). We used to use certutil -O but > Fedora 11 changed certutil so it doesn't show untrusted CAs (the whole > point of running the command). > > Instead parse the output of pk12util -l to find the nicknames of the CAs > to trust. > > rob The code looks fine, but I can't get it to apply. From sbose at redhat.com Fri Jul 24 08:15:25 2009 From: sbose at redhat.com (Sumit Bose) Date: Fri, 24 Jul 2009 10:15:25 +0200 Subject: [Freeipa-devel] [PATCH] Fix race condition leading to segfaults In-Reply-To: <1248380295.17697.81.camel@localhost.localdomain> References: <1248380295.17697.81.camel@localhost.localdomain> Message-ID: <20090724081525.GB3154@localhost.localdomain> On Thu, Jul 23, 2009 at 04:18:15PM -0400, Simo Sorce wrote: > > Sumit found out that ldap auth would segfault from time to time. > > The problem was the way ldap_result() works you don't know how many > results are in the pipe so you have to keep polling, once the fde fired, > until you get back a 0. > > The problem although, was that once a result was received the calling > function, upon getting called by op->callback(), could decide to free > the sdap_handle and all dependent memory like it happens in > sdap_pam_auth_done() which is called through a chain of callbacks from > sdap_process_message() > > The following patch addresses the problem using, temporarily a timer > event to schedule any other call only after the callback is finished. > The events are appended on the sdap_handle, so that if the function > being called actually frees it, all pending events are also freed > without risk. No more segfaults (so far :-) But I think the following piece of code might be an example where gcc might optimize away a check, because the pointers to check (sh->ldap) are already referenced in the debug statement. The glibc printf which is used by DEBUG can handle NULL pointers and will not segfault here and if the check is optimized away ldap_result won't like sh->ldap being NULL. > + > + DEBUG(8, ("Trace: sh[%p], connected[%d], ops[%p], fde[%p], ldap[%p]\n", > + sh, (int)sh->connected, sh->ops, sh->fde, sh->ldap)); > + > + if (!sh->connected || !sh->ldap) { > + DEBUG(2, ("ERROR: LDAP connection is not connected!\n")); > + return; > + } > + > + ret = ldap_result(sh->ldap, LDAP_RES_ANY, 0, &no_timeout, &msg); bye, Sumit From sgallagh at redhat.com Fri Jul 24 11:47:22 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 24 Jul 2009 07:47:22 -0400 Subject: [Freeipa-devel] [PATCH] initial commit of log watcher (lwatch) In-Reply-To: <4A6907FF.5080001@redhat.com> References: <4A5F9274.8080906@redhat.com> <4A6907FF.5080001@redhat.com> Message-ID: <4A699F4A.5010405@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/23/2009 09:01 PM, Dmitri Pal wrote: > > 9) SSSD and Common and Audit all three use tree different ways of > tracing/debugging things. > Shouldn't we get to some consistency there? > It would be better if the log_msg be a macro from the very beginning. > This way it would be easier > to make it conditionally compiled debugging. Currently is is function > and would require significant > effort to go through the code and make it consistent. I would argue that > a) Tracing/debugging should be conditionally compiled day 1 > b) Debugging strings do not require translation > c) Tracing pattern should be consistent - every error should be traced > otherwise it is hard to find problems. > Debug messages should NEVER be conditionally compiled. For an executable, they should always be set by a runtime flag, and for a library they should always be set by an argument to the initialization function or by an environment variable. It should always be possible for someone running the code in a production environment to get additional information about a crash without requiring an instrumented build. Furthermore, "tracing" should be a special case of debugging (i.e. it should just be a very high debug_level. > Just something to think about... > > 10) Such code will not produce right results since there are multiple > ways why function can return NULL and not in all cases > the errno is set. > > if ((pw = new_path_watch(existing_directory_ancestor)) == NULL) { > + error = errno; > + log_msg(LOG_ERROR, _("%s: could not allocate new watch for > \"%s\" (%s)\n"), > + __FUNCTION__, existing_directory_ancestor, > error_string(error)); > + return error; > > Better approach to such cases would be either > > pw = new_path_watch(existing_directory_ancestor, &error); > if (!pw) { > ... > > or which I prefer more: > > error = new_path_watch(&pw, existing_directory_ancestor); > if(error) { > ... This second approach is more in line with the rest of the code in the SSSD. We do this all over the code. Also, our preference is for this error code to remain in line with the errno set, so things like ENOENT and ENOMEM are standard. (We also defined EOK which is identical to EXIT_SUCCESS for convenience) > > 11) From our design discussions I remember that you mentioned that > there was an issue with recursive directories and monitoring nested > paths or something like this. > It seems that find_existing_directory_ancestor() has to do with this issue. > I was expecting to see some extended comment about this somewhere around > create_watch() function. > > 12) In search for some functions I looked at path_utils. > First in general I am a bit scared about using static buffers to hold paths. > Is it still an Ok practice? In the SSSD all code is allocated in > collections > and ini the only place where the static buffer was used was some > parsing of the > file where the reasonable length of the line in the ini file is less > than 100 bytes > while buffer is about 64K. Should we use dynamic memory for paths? > Start with malloc(MAX_PATH) and then realloc if needed? > The idea behind MAX_PATH is that it's defined on every system to be the largest legitimate value of a path that the system can handle internally. malloc(MAX_PATH) doesn't gain anything over path[MAX_PATH] except a need to manage the memory. I generally prefer, however, only to allocate memory as-needed. This will come in handy in the future if anyone should want to include this daemon on a limited-memory device (such as a Linux-based router). That said, for speed and ease of use, you can't beat this static buffer. I just balk at always using a full memory page for every path, when in most cases you're going to need < 100 bytes. Considering that the whole purpose of this tool is to easily manage large numbers of paths, that 4kiB (on Linux; 8kiB or more on some other systems) can really add up. > 13) I was amazed how well the path_util interface is defined and > documented . > I will consider using it whenever I need to deal with paths. > > This is all for now. > A general comment is that without running the code and playing with it > for some time > it is hard to find any specific issues (if any) in logic. On the surface > things > seem well thought through and the functions are not big and modular but > lack of comments makes it really hard to digest. > - -- 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/ iEYEARECAAYFAkppn0UACgkQeiVVYja6o6Ps8wCgkDcTyeAVLbUMYilhGGoJBDiL Cr4AnAlRVq+GYqLHzp8x/XPLDTfJghAk =SEqh -----END PGP SIGNATURE----- From dpal at redhat.com Fri Jul 24 13:06:22 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 24 Jul 2009 09:06:22 -0400 Subject: [Freeipa-devel] [PATCH] initial commit of log watcher (lwatch) In-Reply-To: <4A699F4A.5010405@redhat.com> References: <4A5F9274.8080906@redhat.com> <4A6907FF.5080001@redhat.com> <4A699F4A.5010405@redhat.com> Message-ID: <4A69B1CE.60601@redhat.com> > > Debug messages should NEVER be conditionally compiled. For an > executable, they should always be set by a runtime flag, and for a > library they should always be set by an argument to the initialization > function or by an environment variable. It should always be possible for > someone running the code in a production environment to get additional > information about a crash without requiring an instrumented build. > > Furthermore, "tracing" should be a special case of debugging (i.e. it > should just be a very high debug_level. Steve, Here we disagree. Let us set terminology first: logging - unconditional output of the program about its normal operation or issues it encountered. debugging - conditional output for testing at runtime tracing - conditionally compiled low level output for debugging specific area of the code. There should be a good balance between all three. logging and debugging is needed for any service as you said to be able to understand what is happening and troubleshoot at run time. Tracing is more for the low level libraries. Keep in mind that it becomes extremely costly to have tracing always compiled in. The libraries should be delivered as .so so building an so with enabled tracing and swapping it should not be a big problem. Spo tracing is not a special form of debugging. This is "one size fits all approach" and it is wrong in this case. A caution and discretion should be used. This however does not mean that we can't standardize on ways to do each of the three things. ELAPI should eventually become our logging api, it can be used for debugging too so it will cover these two. But tracing should be very low level and very simple conditionally compiled printout statements that would allow tracing the ELAPI itself. -- 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 Jul 24 13:30:34 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 24 Jul 2009 09:30:34 -0400 Subject: [Freeipa-devel] [PATCH] 242 new method to identify CAs to trust In-Reply-To: <1248404454.2713.1.camel@jgd-flap> References: <4A68DCAE.7060206@redhat.com> <1248404454.2713.1.camel@jgd-flap> Message-ID: <4A69B77A.9030809@redhat.com> Jason Gerard DeRose wrote: > On Thu, 2009-07-23 at 17:57 -0400, Rob Crittenden wrote: >> A new way to identify the CAs to trust when importing a PKCS#12 file >> (like during replica installation). We used to use certutil -O but >> Fedora 11 changed certutil so it doesn't show untrusted CAs (the whole >> point of running the command). >> >> Instead parse the output of pk12util -l to find the nicknames of the CAs >> to trust. >> >> rob > > The code looks fine, but I can't get it to apply. > I needed to do a rebase. New patch attached that should apply cleanly to the tip. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-242-2-trust.patch Type: application/mbox Size: 4278 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 sbose at redhat.com Fri Jul 24 13:52:00 2009 From: sbose at redhat.com (Sumit Bose) Date: Fri, 24 Jul 2009 15:52:00 +0200 Subject: [Freeipa-devel] [PATCH] Fix race condition leading to segfaults In-Reply-To: <20090724081525.GB3154@localhost.localdomain> References: <1248380295.17697.81.camel@localhost.localdomain> <20090724081525.GB3154@localhost.localdomain> Message-ID: <20090724135200.GC3154@localhost.localdomain> On Fri, Jul 24, 2009 at 10:15:25AM +0200, Sumit Bose wrote: > On Thu, Jul 23, 2009 at 04:18:15PM -0400, Simo Sorce wrote: > > > > Sumit found out that ldap auth would segfault from time to time. > > > > The problem was the way ldap_result() works you don't know how many > > results are in the pipe so you have to keep polling, once the fde fired, > > until you get back a 0. > > > > The problem although, was that once a result was received the calling > > function, upon getting called by op->callback(), could decide to free > > the sdap_handle and all dependent memory like it happens in > > sdap_pam_auth_done() which is called through a chain of callbacks from > > sdap_process_message() > > > > The following patch addresses the problem using, temporarily a timer > > event to schedule any other call only after the callback is finished. > > The events are appended on the sdap_handle, so that if the function > > being called actually frees it, all pending events are also freed > > without risk. > > No more segfaults (so far :-) > > But I think the following piece of code might be an example where gcc > might optimize away a check, because the pointers to check > (sh->ldap) are already referenced in the debug > statement. The glibc printf which is used by DEBUG can handle NULL > pointers and will not segfault here and if the check is optimized away > ldap_result won't like sh->ldap being NULL. > > > + > > + DEBUG(8, ("Trace: sh[%p], connected[%d], ops[%p], fde[%p], ldap[%p]\n", > > + sh, (int)sh->connected, sh->ops, sh->fde, sh->ldap)); > > + > > + if (!sh->connected || !sh->ldap) { > > + DEBUG(2, ("ERROR: LDAP connection is not connected!\n")); > > + return; > > + } > > + > > + ret = ldap_result(sh->ldap, LDAP_RES_ANY, 0, &no_timeout, &msg); > > After a discussion on irc Simo and I came to the conclusion that the conditional code in DEBUG would prevent gcc from optimizing away the check. ACK bye, Sumit From ssorce at redhat.com Fri Jul 24 14:23:35 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 24 Jul 2009 10:23:35 -0400 Subject: [Freeipa-devel] [PATCH] Fix race condition leading to segfaults In-Reply-To: <20090724135200.GC3154@localhost.localdomain> References: <1248380295.17697.81.camel@localhost.localdomain> <20090724081525.GB3154@localhost.localdomain> <20090724135200.GC3154@localhost.localdomain> Message-ID: <1248445415.17697.93.camel@localhost.localdomain> On Fri, 2009-07-24 at 15:52 +0200, Sumit Bose wrote: > > After a discussion on irc Simo and I came to the conclusion that the > conditional code in DEBUG would prevent gcc from optimizing away the > check. > > ACK pushed. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Jul 24 14:23:53 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 24 Jul 2009 10:23:53 -0400 Subject: [Freeipa-devel] [PATCHES] c-ares integration In-Reply-To: <4A6825A2.90800@redhat.com> References: <4A65F659.9020409@redhat.com> <1248201560.29458.304.camel@localhost.localdomain> <4A6755D9.80104@redhat.com> <1248293493.3136.10.camel@localhost.localdomain> <4A6825A2.90800@redhat.com> Message-ID: <1248445433.17697.94.camel@localhost.localdomain> On Thu, 2009-07-23 at 10:56 +0200, Jakub Hrozek wrote: > On 07/22/2009 10:11 PM, Simo Sorce wrote: > > Patches look good to me, ack to all three. > > > > Simo. > > > > Thank you for the review, attached are rebased versions as those I > sent > did not apply cleanly on top of current HEAD. > Pushed. Simo. -- Simo Sorce * Red Hat, Inc * New York From jdennis at redhat.com Fri Jul 24 14:55:31 2009 From: jdennis at redhat.com (John Dennis) Date: Fri, 24 Jul 2009 10:55:31 -0400 Subject: [Freeipa-devel] [PATCH] initial commit of log watcher (lwatch) In-Reply-To: <4A699F4A.5010405@redhat.com> References: <4A5F9274.8080906@redhat.com> <4A6907FF.5080001@redhat.com> <4A699F4A.5010405@redhat.com> Message-ID: <4A69CB63.1030004@redhat.com> >> 10) Such code will not produce right results since there are multiple >> ways why function can return NULL and not in all cases >> the errno is set. >> >> if ((pw = new_path_watch(existing_directory_ancestor)) == NULL) { >> + error = errno; >> + log_msg(LOG_ERROR, _("%s: could not allocate new watch for >> \"%s\" (%s)\n"), >> + __FUNCTION__, existing_directory_ancestor, >> error_string(error)); >> + return error; >> >> Better approach to such cases would be either >> >> pw = new_path_watch(existing_directory_ancestor,&error); >> if (!pw) { >> ... >> >> or which I prefer more: >> >> error = new_path_watch(&pw, existing_directory_ancestor); >> if(error) { >> ... > > This second approach is more in line with the rest of the code in the > SSSD. We do this all over the code. Also, our preference is for this > error code to remain in line with the errno set, so things like ENOENT > and ENOMEM are standard. (We also defined EOK which is identical to > EXIT_SUCCESS for convenience) Hopefully you'll have noticed the 2nd approach, the preferred one used in SSSD, is the one I used for virtually all function definitions. The function cited above is an anomaly. It's good your review caught it (BTW, the reason it was coded that way originally was it was originally just an "allocator" function whose only failure would have been no memory, but it grew new functionality and it should have been modified at that point to return an error status just like everything else does. >> 12) In search for some functions I looked at path_utils. >> First in general I am a bit scared about using static buffers to hold paths. >> Is it still an Ok practice? In the SSSD all code is allocated in >> collections >> and ini the only place where the static buffer was used was some >> parsing of the >> file where the reasonable length of the line in the ini file is less >> than 100 bytes >> while buffer is about 64K. Should we use dynamic memory for paths? >> Start with malloc(MAX_PATH) and then realloc if needed? >> > > The idea behind MAX_PATH is that it's defined on every system to be the > largest legitimate value of a path that the system can handle > internally. malloc(MAX_PATH) doesn't gain anything over path[MAX_PATH] > except a need to manage the memory. I generally prefer, however, only to > allocate memory as-needed. This will come in handy in the future if > anyone should want to include this daemon on a limited-memory device > (such as a Linux-based router). That said, for speed and ease of use, > you can't beat this static buffer. I just balk at always using a full > memory page for every path, when in most cases you're going to need< > 100 bytes. Considering that the whole purpose of this tool is to easily > manage large numbers of paths, that 4kiB (on Linux; 8kiB or more on some > other systems) can really add up. I think one can make two equally valid arguments with respect to storing path names. Pre-declaring a variable or structure member of sufficient size to hold any pathname has the advantage of simplicity, simplicity tends to lead toward more robust and efficient code (less mistakes to make and fewer cycles spent trying to optimize memory use). However, Stephen is right on the money when he observes in most cases the bulk of the memory allocated won't be used and this *may* be a liability. First of all one needs to be aware that much of the use of the construct "path[MAX_PATH]" occurs in automatic variables on the stack. In this context it's hard to argue the unused memory in the string is a liability, the memory comes into existence and is freed by a simple adjustment of the stack pointer and has a very short lifetime (yes, it does cost extra stack space). The alternative is more complex memory management, either alloca on the stack or from the heap, both require more complex logic with a greater opportunity for program error and many more processor cycles (don't forget these path variables only come into existence because we need to manipulate them which means one must always be doing bounds checking and reallocations on virtually all operations). There are places where buffers of size MAX_PATH are members of heap allocated objects. These are better candidates for memory optimization, however it does incur much more complex program logic. In fact the problem really reduces to: Dynamic String Objects E.g. in C++ std::string. It's not just a matter of dynamic buffer management, it also requires functions to be bound to the underlying buffer which can perform various string operations. To the best of my knowledge we don't have a library available to us in C which has been blessed for our use which implements this. Just like we were required to write our own hash table implementation we would be required to write our own dynamic string library. So when the choice came as to whether to write a new string library or declare paths using MAX_PATH and utilize the existing clib string functions (plus some customs functions) it seemed to me to be clearly a win to opt for simplicity, processor efficiency, shorter development time and proven library correctness. That's not to say there isn't a good argument on the other side too. Perhaps it would be possible to use macros in the current implemention which would allow switching to dynamic operations later down the road. Of course we could also just wait and see if it's an issue in practice. The golden rule of optimization is *not* to optimize in the beginning, rather keep things simple, concentrate on program correctness, and only later come back and tweak specific problem areas. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Jul 24 15:03:06 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 24 Jul 2009 11:03:06 -0400 Subject: [Freeipa-devel] [PATCH] initial commit of log watcher (lwatch) In-Reply-To: <4A69CB63.1030004@redhat.com> References: <4A5F9274.8080906@redhat.com> <4A6907FF.5080001@redhat.com> <4A699F4A.5010405@redhat.com> <4A69CB63.1030004@redhat.com> Message-ID: <4A69CD2A.5080804@redhat.com> John Dennis wrote: >>> 10) Such code will not produce right results since there are multiple >>> ways why function can return NULL and not in all cases >>> the errno is set. >>> >>> if ((pw = new_path_watch(existing_directory_ancestor)) == >>> NULL) { >>> + error = errno; >>> + log_msg(LOG_ERROR, _("%s: could not allocate new watch for >>> \"%s\" (%s)\n"), >>> + __FUNCTION__, existing_directory_ancestor, >>> error_string(error)); >>> + return error; >>> >>> Better approach to such cases would be either >>> >>> pw = new_path_watch(existing_directory_ancestor,&error); >>> if (!pw) { >>> ... >>> >>> or which I prefer more: >>> >>> error = new_path_watch(&pw, existing_directory_ancestor); >>> if(error) { >>> ... >> >> This second approach is more in line with the rest of the code in the >> SSSD. We do this all over the code. Also, our preference is for this >> error code to remain in line with the errno set, so things like ENOENT >> and ENOMEM are standard. (We also defined EOK which is identical to >> EXIT_SUCCESS for convenience) > > Hopefully you'll have noticed the 2nd approach, the preferred one used > in SSSD, is the one I used for virtually all function definitions. The > function cited above is an anomaly. It's good your review caught it > (BTW, the reason it was coded that way originally was it was > originally just an "allocator" function whose only failure would have > been no memory, but it grew new functionality and it should have been > modified at that point to return an error status just like everything > else does. > >>> 12) In search for some functions I looked at path_utils. >>> First in general I am a bit scared about using static buffers to >>> hold paths. >>> Is it still an Ok practice? In the SSSD all code is allocated in >>> collections >>> and ini the only place where the static buffer was used was some >>> parsing of the >>> file where the reasonable length of the line in the ini file is less >>> than 100 bytes >>> while buffer is about 64K. Should we use dynamic memory for paths? >>> Start with malloc(MAX_PATH) and then realloc if needed? >>> >> >> The idea behind MAX_PATH is that it's defined on every system to be the >> largest legitimate value of a path that the system can handle >> internally. malloc(MAX_PATH) doesn't gain anything over path[MAX_PATH] >> except a need to manage the memory. I generally prefer, however, only to >> allocate memory as-needed. This will come in handy in the future if >> anyone should want to include this daemon on a limited-memory device >> (such as a Linux-based router). That said, for speed and ease of use, >> you can't beat this static buffer. I just balk at always using a full >> memory page for every path, when in most cases you're going to need< >> 100 bytes. Considering that the whole purpose of this tool is to easily >> manage large numbers of paths, that 4kiB (on Linux; 8kiB or more on some >> other systems) can really add up. > > I think one can make two equally valid arguments with respect to > storing path names. Pre-declaring a variable or structure member of > sufficient size to hold any pathname has the advantage of simplicity, > simplicity tends to lead toward more robust and efficient code (less > mistakes to make and fewer cycles spent trying to optimize memory use). > > However, Stephen is right on the money when he observes in most cases > the bulk of the memory allocated won't be used and this *may* be a > liability. > > First of all one needs to be aware that much of the use of the > construct "path[MAX_PATH]" occurs in automatic variables on the stack. > In this context it's hard to argue the unused memory in the string is > a liability, the memory comes into existence and is freed by a simple > adjustment of the stack pointer and has a very short lifetime (yes, it > does cost extra stack space). The alternative is more complex memory > management, either alloca on the stack or from the heap, both require > more complex logic with a greater opportunity for program error and > many more processor cycles (don't forget these path variables only > come into existence because we need to manipulate them which means one > must always be doing bounds checking and reallocations on virtually > all operations). > > There are places where buffers of size MAX_PATH are members of heap > allocated objects. These are better candidates for memory > optimization, however it does incur much more complex program logic. > In fact the problem really reduces to: > > Dynamic String Objects > > E.g. in C++ std::string. It's not just a matter of dynamic buffer > management, it also requires functions to be bound to the underlying > buffer which can perform various string operations. > > To the best of my knowledge we don't have a library available to us in > C which has been blessed for our use which implements this. Just like > we were required to write our own hash table implementation we would > be required to write our own dynamic string library. > > So when the choice came as to whether to write a new string library or > declare paths using MAX_PATH and utilize the existing clib string > functions (plus some customs functions) it seemed to me to be clearly > a win to opt for simplicity, processor efficiency, shorter development > time and proven library correctness. > > That's not to say there isn't a good argument on the other side too. > Perhaps it would be possible to use macros in the current implemention > which would allow switching to dynamic operations later down the road. > > Of course we could also just wait and see if it's an issue in > practice. The golden rule of optimization is *not* to optimize in the > beginning, rather keep things simple, concentrate on program > correctness, and only later come back and tweak specific problem areas. > Agree. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Fri Jul 24 15:53:21 2009 From: jdennis at redhat.com (John Dennis) Date: Fri, 24 Jul 2009 11:53:21 -0400 Subject: [Freeipa-devel] [PATCH] initial commit of log watcher (lwatch) In-Reply-To: <4A6907FF.5080001@redhat.com> References: <4A5F9274.8080906@redhat.com> <4A6907FF.5080001@redhat.com> Message-ID: <4A69D8F1.2060201@redhat.com> On 07/23/2009 09:01 PM, Dmitri Pal wrote: > 1) There is generally a lack of comments in the code. it is very hard to > read. > IMO the lack of comments is a style issue rather then maturity of the > code issue. > 13) I was amazed how well the path_util interface is defined and > documented . As you observe I generally document my code well, you can see similar good documentation the C++ logger I just submitted as well. FWIW I usually document once the code stablizes. To me this is more an issue of being asked to submit the code for review before I was ready to "publish" it. > 2) In many places the spaces are missing around commas, "-", "+". Will fix in next patch. > 3) Heavy use of the complex constructs: O.K. I'll break these up as I encounter them. > 4) In multiple places there is just one line of code inside the {} > after if for example: Our coding standard recommends no braces when there is only a single expression. However I strongly disagree with this, in fact many coding standard recommend exactly the opposite, to always use braces! Why? Because I've seen plenty examples of bugs introduced when a programmer added a new expression to the conditional and totally broke the program logic. Usually these mistakes aren't caught until much later when things mysterously fail. I consider the use of braces a simple and effective example of defensive programming. > 7) It should be a practice of using thread safe versions of system > functions Just good defensive programming practice. O.K. I'll switch over as time allows. FWIW the code wasn't designed to be thread safe, I never imagined it being run in seperate threads. But perhaps that should be one of our coding standards, that all code needs to be thread safe irrespective of it's intended usage. I'm aware of some other areas which are not thread safe at the moment, it was always my intention to clean those up anyway. > 8) A lot of static global data. It would be beneficial to combine these > things together in some kind of context structure and pass it around. Actually it's not static, but you're right a number of the major data structures are singletons. At the moment I can't think of a reason why we would need multiple independent copies of the state, but perhaps down the road such a need might come up and having them hung off of a context would be necessary in that case. It's not needed now, but if it's not too difficult I'll gather them up in a context. > Even if you keep it static for now it would be easier to refine code > later. Currently too many low level functions rely the global data > so it would require a significant refactoring effort to get rid of those > down the road. > > 9) SSSD and Common and Audit all three use tree different ways of > tracing/debugging things. > Shouldn't we get to some consistency there? yes, consistency would be better, the audit server adds a 4th (but in the case of the audit server I believe it's logging must be independent of ELAPI etc. because otherwise it creates a vicious cycle). I would have used ELAPI but it wasn't ready when the code was written. > It would be better if the log_msg be a macro from the very beginning. It's a macro now :-) > 11) From our design discussions I remember that you mentioned that > there was an issue with recursive directories and monitoring nested > paths or something like this. > It seems that find_existing_directory_ancestor() has to do with this issue. > I was expecting to see some extended comment about this somewhere around > create_watch() function. Yup, as indicated above, more extensive documentation is on the to-do list. > This is all for now. Thank you for your review and attention. I'm preparing a new patch. I've got all of Stephen's issues fixed and I'll move on now to folding in your suggestions, the patch will follow. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Fri Jul 24 18:09:45 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 24 Jul 2009 14:09:45 -0400 Subject: [Freeipa-devel] [PATCH] initial commit of log watcher (lwatch) In-Reply-To: <4A69D8F1.2060201@redhat.com> References: <4A5F9274.8080906@redhat.com> <4A6907FF.5080001@redhat.com> <4A69D8F1.2060201@redhat.com> Message-ID: <1248458985.17697.104.camel@localhost.localdomain> On Fri, 2009-07-24 at 11:53 -0400, John Dennis wrote: > Our coding standard recommends no braces when there is only a single > expression. However I strongly disagree with this, in fact many > coding > standard recommend exactly the opposite, to always use braces! Why? > Because I've seen plenty examples of bugs introduced when a > programmer > added a new expression to the conditional and totally broke the > program > logic. Usually these mistakes aren't caught until much later when > things > mysterously fail. I consider the use of braces a simple and effective > example of defensive programming. > Please propose to amend the coding style in a separate mail. I have had mixed feelings about this, but I think I might agree with you on this point, so maybe we will get enough support to change the coding style on this point. Simo. -- Simo Sorce * Red Hat, Inc * New York From jdennis at redhat.com Fri Jul 24 18:57:07 2009 From: jdennis at redhat.com (John Dennis) Date: Fri, 24 Jul 2009 14:57:07 -0400 Subject: [Freeipa-devel] Proposed modification to C coding standard Message-ID: <4A6A0403.6060700@redhat.com> Our coding standards highly recommended *not* using braces following a conditional when there is a single expression http://freeipa.com/page/Coding_Style#Conditions_and_Statements I propose to amend this so that it is highly recommended to always use braces. Discussion: By not using braces to form a block there is an opportunity to introduce a bug if a programmer adds another expression and fails to notice braces are now needed to preserve program logic. Always using braces is simple defensive programming practice and is recommended by many coding standards. Practical experience has shown the failure to introduce braces when none were there previously is a common mistake which introduces bugs often not found until much later, this can be eliminated by always using braces, readability is not compromised. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sbose at redhat.com Fri Jul 24 19:02:15 2009 From: sbose at redhat.com (Sumit Bose) Date: Fri, 24 Jul 2009 21:02:15 +0200 Subject: [Freeipa-devel] Proposed modification to C coding standard In-Reply-To: <4A6A0403.6060700@redhat.com> References: <4A6A0403.6060700@redhat.com> Message-ID: <20090724190215.GD3154@localhost.localdomain> On Fri, Jul 24, 2009 at 02:57:07PM -0400, John Dennis wrote: > Our coding standards highly recommended *not* using braces following a > conditional when there is a single expression > > http://freeipa.com/page/Coding_Style#Conditions_and_Statements > > I propose to amend this so that it is highly recommended to always use > braces. > > Discussion: > > By not using braces to form a block there is an opportunity to introduce > a bug if a programmer adds another expression and fails to notice braces > are now needed to preserve program logic. Always using braces is simple > defensive programming practice and is recommended by many coding > standards. Practical experience has shown the failure to introduce > braces when none were there previously is a common mistake which > introduces bugs often not found until much later, this can be eliminated > by always using braces, readability is not compromised. > +1 bye, Sumit From sgallagh at redhat.com Fri Jul 24 19:04:06 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 24 Jul 2009 15:04:06 -0400 Subject: [Freeipa-devel] Proposed modification to C coding standard In-Reply-To: <4A6A0403.6060700@redhat.com> References: <4A6A0403.6060700@redhat.com> Message-ID: <4A6A05A6.5050804@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/24/2009 02:57 PM, John Dennis wrote: > Our coding standards highly recommended *not* using braces following a > conditional when there is a single expression > > http://freeipa.com/page/Coding_Style#Conditions_and_Statements > > I propose to amend this so that it is highly recommended to always use > braces. > > Discussion: > > By not using braces to form a block there is an opportunity to introduce > a bug if a programmer adds another expression and fails to notice braces > are now needed to preserve program logic. Always using braces is simple > defensive programming practice and is recommended by many coding > standards. Practical experience has shown the failure to introduce > braces when none were there previously is a common mistake which > introduces bugs often not found until much later, this can be eliminated > by always using braces, readability is not compromised. > I concur (and have mostly been ignoring the previous policy up to this point). The only comment I might make is that it may still be acceptable for true single-line if statements, e.g. str = malloc(10); if(!str) return ENOMEM; - -- 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/ iEYEARECAAYFAkpqBaEACgkQeiVVYja6o6P5ugCffuMYmQovLieM8+VF7vEbLvpa 1C4An2gC+tkN89YRxi5C/f30iVxi1Bnd =Cx9g -----END PGP SIGNATURE----- From ssorce at redhat.com Fri Jul 24 19:08:51 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 24 Jul 2009 15:08:51 -0400 Subject: [Freeipa-devel] Proposed modification to C coding standard In-Reply-To: <4A6A0403.6060700@redhat.com> References: <4A6A0403.6060700@redhat.com> Message-ID: <1248462532.17697.106.camel@localhost.localdomain> On Fri, 2009-07-24 at 14:57 -0400, John Dennis wrote: > Our coding standards highly recommended *not* using braces following a > conditional when there is a single expression > > http://freeipa.com/page/Coding_Style#Conditions_and_Statements > > I propose to amend this so that it is highly recommended to always use > braces. > > Discussion: > > By not using braces to form a block there is an opportunity to introduce > a bug if a programmer adds another expression and fails to notice braces > are now needed to preserve program logic. Always using braces is simple > defensive programming practice and is recommended by many coding > standards. Practical experience has shown the failure to introduce > braces when none were there previously is a common mistake which > introduces bugs often not found until much later, this can be eliminated > by always using braces, readability is not compromised. +1 Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Jul 24 19:38:53 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 24 Jul 2009 15:38:53 -0400 Subject: [Freeipa-devel] Proposed modification to C coding standard In-Reply-To: <4A6A0403.6060700@redhat.com> References: <4A6A0403.6060700@redhat.com> Message-ID: <4A6A0DCD.3090207@redhat.com> John Dennis wrote: > Our coding standards highly recommended *not* using braces following a > conditional when there is a single expression > > http://freeipa.com/page/Coding_Style#Conditions_and_Statements > > I propose to amend this so that it is highly recommended to always use > braces. > > Discussion: > > By not using braces to form a block there is an opportunity to > introduce a bug if a programmer adds another expression and fails to > notice braces are now needed to preserve program logic. Always using > braces is simple defensive programming practice and is recommended by > many coding standards. Practical experience has shown the failure to > introduce braces when none were there previously is a common mistake > which introduces bugs often not found until much later, this can be > eliminated by always using braces, readability is not compromised. > Now I know how to change what I do not like in the standard :) +1 -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Fri Jul 24 20:14:43 2009 From: jdennis at redhat.com (John Dennis) Date: Fri, 24 Jul 2009 16:14:43 -0400 Subject: [Freeipa-devel] Proposed modification to C coding standard In-Reply-To: <4A6A05A6.5050804@redhat.com> References: <4A6A0403.6060700@redhat.com> <4A6A05A6.5050804@redhat.com> Message-ID: <4A6A1633.4050703@redhat.com> On 07/24/2009 03:04 PM, Stephen Gallagher wrote: > I concur (and have mostly been ignoring the previous policy up to this > point). > > The only comment I might make is that it may still be acceptable for > true single-line if statements, e.g. yes, I would agree with this. > str = malloc(10); > if(!str) return ENOMEM; However in this particular example I would prefer if ((str = malloc(10)) == NULL) return ENOMEM; This keeps it as a true single line and is consistent with: RECOMMENDED: Use the full condition syntax like (NULL == str) rather than (!str). I think some folks have an issue with this type of compound expression but I find it much more readable and expressive of intent, YMMV. FWIW the coding standard doesn't cover compound expressions. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sgallagh at redhat.com Fri Jul 24 20:23:42 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 24 Jul 2009 16:23:42 -0400 Subject: [Freeipa-devel] Proposed modification to C coding standard In-Reply-To: <4A6A1633.4050703@redhat.com> References: <4A6A0403.6060700@redhat.com> <4A6A05A6.5050804@redhat.com> <4A6A1633.4050703@redhat.com> Message-ID: <4A6A184E.5040501@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/24/2009 04:14 PM, John Dennis wrote: > On 07/24/2009 03:04 PM, Stephen Gallagher wrote: >> I concur (and have mostly been ignoring the previous policy up to this >> point). >> >> The only comment I might make is that it may still be acceptable for >> true single-line if statements, e.g. > > yes, I would agree with this. > >> str = malloc(10); >> if(!str) return ENOMEM; > > However in this particular example I would prefer > > if ((str = malloc(10)) == NULL) return ENOMEM; > > This keeps it as a true single line and is consistent with: > > RECOMMENDED: Use the full condition syntax like (NULL == str) rather > than (!str). > > I think some folks have an issue with this type of compound expression > but I find it much more readable and expressive of intent, YMMV. FWIW > the coding standard doesn't cover compound expressions. > Actually, I had been using "if (str != NULL)" in my code, and was told to simplify it to !str - -- 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/ iEYEARECAAYFAkpqGEcACgkQeiVVYja6o6NQdACfXWzRUh+wI614aOt9duIDN8eT f+EAn31iiM2yHCV36lqpKW9EHjnkXMUJ =CBlL -----END PGP SIGNATURE----- From dpal at redhat.com Fri Jul 24 21:00:42 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 24 Jul 2009 17:00:42 -0400 Subject: [Freeipa-devel] Proposed modification to C coding standard In-Reply-To: <4A6A184E.5040501@redhat.com> References: <4A6A0403.6060700@redhat.com> <4A6A05A6.5050804@redhat.com> <4A6A1633.4050703@redhat.com> <4A6A184E.5040501@redhat.com> Message-ID: <4A6A20FA.8090202@redhat.com> Stephen Gallagher wrote: > On 07/24/2009 04:14 PM, John Dennis wrote: > > On 07/24/2009 03:04 PM, Stephen Gallagher wrote: > >> I concur (and have mostly been ignoring the previous policy up to this > >> point). > >> > >> The only comment I might make is that it may still be acceptable for > >> true single-line if statements, e.g. > > yes, I would agree with this. > > >> str = malloc(10); > >> if(!str) return ENOMEM; > > However in this particular example I would prefer > > > if ((str = malloc(10)) == NULL) return ENOMEM; > > > This keeps it as a true single line and is consistent with: > > > RECOMMENDED: Use the full condition syntax like (NULL == str) rather > > than (!str). > > > I think some folks have an issue with this type of compound expression > > but I find it much more readable and expressive of intent, YMMV. FWIW > > the coding standard doesn't cover compound expressions. > > > Actually, I had been using "if (str != NULL)" in my code, and was told > to simplify it to !str > > Me too and I would prefer two lines. _______________________________________________ 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 Fri Jul 24 21:05:45 2009 From: sbose at redhat.com (Sumit Bose) Date: Fri, 24 Jul 2009 23:05:45 +0200 Subject: [Freeipa-devel] [PATCH] add configure check for errno_t Message-ID: <20090724210545.GE3154@localhost.localdomain> Hi, we regular use functions returning errno error code like ENOMEN or EINVAL. The return type of these functions is usually int. To underline that the return code is only an error code and should not be used otherwise a special type can be used. There is the ISO/ICE technical report 24731-1 which recommends they type errno_t for this purpose. I think it makes sense to stick with this recommendation (and I hope people don't mind that the same TR also recommends the not so smart *_s replacements for most of the standard libc functions). The attached patch add a configure check for errno_t and defines it if not present in the system. bye, Sumit -------------- next part -------------- >From ad5a2894e9404a3fba0f5f94a3a01b7f42b8df82 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Fri, 24 Jul 2009 22:41:17 +0200 Subject: [PATCH] add configure check for errno_t --- server/configure.ac | 2 ++ server/util/util.h | 4 ++++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/server/configure.ac b/server/configure.ac index 5a9888b..d9e1e0e 100644 --- a/server/configure.ac +++ b/server/configure.ac @@ -31,6 +31,8 @@ AM_CONDITIONAL([HAVE_GCC], [test "$ac_cv_prog_gcc" = yes]) AC_CHECK_HEADERS(stdint.h dlfcn.h) AC_CONFIG_HEADER(config.h) +AC_CHECK_TYPES([errno_t], [], [], [[#include ]]) + TESTS="" EXTRA_OBJ="" diff --git a/server/util/util.h b/server/util/util.h index 02916c1..b60dfa8 100644 --- a/server/util/util.h +++ b/server/util/util.h @@ -14,6 +14,10 @@ #include "tevent.h" #include "ldb.h" +#ifndef HAVE_ERRNO_T +typedef int errno_t; +#endif + extern const char *debug_prg_name; extern int debug_level; extern int debug_timestamps; -- 1.6.2.5 From jhrozek at redhat.com Sat Jul 25 10:29:12 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sat, 25 Jul 2009 12:29:12 +0200 Subject: [Freeipa-devel] Proposed modification to C coding standard In-Reply-To: <4A6A0403.6060700@redhat.com> References: <4A6A0403.6060700@redhat.com> Message-ID: <4A6ADE78.8070408@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/24/2009 08:57 PM, John Dennis wrote: > Our coding standards highly recommended *not* using braces following a > conditional when there is a single expression > > http://freeipa.com/page/Coding_Style#Conditions_and_Statements > > I propose to amend this so that it is highly recommended to always use > braces. > > Discussion: > > By not using braces to form a block there is an opportunity to introduce > a bug if a programmer adds another expression and fails to notice braces > are now needed to preserve program logic. Always using braces is simple > defensive programming practice and is recommended by many coding > standards. Practical experience has shown the failure to introduce > braces when none were there previously is a common mistake which > introduces bugs often not found until much later, this can be eliminated > by always using braces, readability is not compromised. > As someone who has been largely ignoring the previous recommendation of not using braces, +1. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpq3nIACgkQHsardTLnvCVSxgCfTEJ1cDnIMXpQdQnJRt8jJ57O UacAoIX85tBjfM6va0tBZo+9KhBeEB5i =tdh+ -----END PGP SIGNATURE----- From jdennis at redhat.com Sat Jul 25 15:13:54 2009 From: jdennis at redhat.com (John Dennis) Date: Sat, 25 Jul 2009 11:13:54 -0400 Subject: [Freeipa-devel] [PATCH] initial commit of log watcher (lwatch) In-Reply-To: <4A6907FF.5080001@redhat.com> References: <4A5F9274.8080906@redhat.com> <4A6907FF.5080001@redhat.com> Message-ID: <4A6B2132.8030309@redhat.com> On 07/23/2009 09:01 PM, Dmitri Pal wrote: > We are considering combining the log monitor with audit collection. > These are two separate functions it would be logical > to have them in separate threads. The architecture is and will be event driven with a main event loop. In most cases event loops are superior to threads, both from a performance and complexity perspective. The only reason I could envision needing to use threads is if some operation was subject to blocking. But then again event loops are particularly adept at handling non-blocking IO so the only reason I could see a need for threads is if there were some reason we couldn't use asynchronous non-blocking methods. Asynchronous non-blocking methods are to the best of my knowledge the preferred approach in the project. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sgallagh at redhat.com Mon Jul 27 13:53:23 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 27 Jul 2009 09:53:23 -0400 Subject: [Freeipa-devel] [PATCH] add configure check for errno_t In-Reply-To: <20090724210545.GE3154@localhost.localdomain> References: <20090724210545.GE3154@localhost.localdomain> Message-ID: <4A6DB153.7090209@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/24/2009 05:05 PM, Sumit Bose wrote: > Hi, > > we regular use functions returning errno error code like ENOMEN or > EINVAL. The return type of these functions is usually int. To underline > that the return code is only an error code and should not be used > otherwise a special type can be used. There is the ISO/ICE technical > report 24731-1 which recommends they type errno_t for this purpose. I > think it makes sense to stick with this recommendation (and I hope > people don't mind that the same TR also recommends the not so smart *_s > replacements for most of the standard libc functions). > > The attached patch add a configure check for errno_t and defines it if > not present in the system. > > bye, > Sumit > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Nack. Please include a patch that modifies the configure scripts of the sss_client and common directories. - -- 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/ iEYEARECAAYFAkptsVMACgkQeiVVYja6o6N4cgCeIKzywIS82xrCbLfQuiOG2YZ5 qqoAn3QFVYC8UySAgC5iXSU1o2u5fCm+ =qpbz -----END PGP SIGNATURE----- From jhrozek at redhat.com Mon Jul 27 18:12:09 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 27 Jul 2009 20:12:09 +0200 Subject: [Freeipa-devel] [PATCH] initial commit of audit server code In-Reply-To: <4A675261.404@redhat.com> References: <4A675261.404@redhat.com> Message-ID: <4A6DEDF9.5000905@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello John, On 07/22/2009 07:54 PM, John Dennis wrote: > In the spirit of small patches this is the most minimal patch possible > to get any part of the audit server in. It contains the basic autotools > framework and just 1 c++ component, the logger facility used by the > audit server. Because it's minimal you can't do anything with it except > review 2 source files and build the documentation for it. > I would argue that the patch is too minimal..or maybe it seems like ripped out of context. On one hand, it defines bin_PROGRAMS=audit_server, on the other hand, there is no main() in audit_server_SOURCES to build audit_server with. Also, why is audit_server_LDADD commented out? At least -lboost_regex is needed for the current patch. Anyway, I did not perform any testing aside from compiling the code, I just read the code during the review. * The patch introduces whitespace errors, which is by no means a reason to nack the work, but perhaps it is something that can be remedied with a simple editor setting (like let g:c_space_errors=1 for vim)? * Not sure if including a license and/or copyright notice in source files is a requirement for the project. Is it licensed in same way as sssd is? * Is there a unit test for the module? There are some code examples in doxygen comment headers, maybe they could be the basis of tests. (Also a more general question - if we write unit tests for C++ code, have we agreed on some common framework, like check is used for C code in SSSD?) * I did not understand why LogLevelTraits is declared as struct..I thought the the reason for this is usually to get default-public inheritance (and access, but that could be done with modifiers more cleanly, IMHO), but no classes seem to inherit from LogLevelTraits (yet?). Maybe it's worth a comment in the declaration? * I also do not understand exactly how filtering by categories works, the code in is_filtered_by category looks like it will return true on first non-match, so the category must match all the patterns in category_include. Is that correct? Nitpicking: * I spotted several typos..maybe worth fixing for future: 248: formated (formatted) 250: messgae (message) 333: to adopted (to be adopted) * Only a matter of style, but I do not like how the instance.log() call is duplicated in Logger::log(), I think it's more readable to do something like: - ------- if (perform_filtering && is_filtered(msg.get_level(), msg.get_category()) { return; } Logger::instance().log(msg.format(prefix, unknown_string)); - ------- * Most methods begin with the opening curly brace on its own line, Msg::insert() and some in class Logger do not. It would probably be nice to stick to one style. * Some reference parameters seem to be declared as "type& name" and some as "type &name", not sure if it's following any convention. > To build the doc you'll need doxygen installed, then: > > cd doc > make doc > > Then open in your web browser doc/api/html/index.html Thanks, I really like how thorough the code is documented. Does it make sense to set PROJECT_NAME=audit_server or similar to Doxyfile? Also, would it make sense to remove the api subdirectory if it already exists, so refreshing documentation is easier? Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpt7fkACgkQHsardTLnvCVtYwCgpDCy2AGNICJZx9I14meV1+jp urEAnjJPS+EkhX8+gkU38ViJOrFt2Rpy =JR0b -----END PGP SIGNATURE----- From rcritten at redhat.com Mon Jul 27 20:59:37 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 27 Jul 2009 16:59:37 -0400 Subject: [Freeipa-devel] Needs testing: Replace IPA CA Message-ID: <4A6E1539.2050907@redhat.com> We were improperly creating the IPA self-signed CA during installation. It lacked a certificate extension marking it as a CA. This causes the certificates that IPA generates to not work with Firefox 3.5. I'm working on a fix for this. If someone wants to give it a test that would be helpful. There are several steps you need to take on the initial master. If you have replica's I'll get back to that: - Apply the patch to certs.py to (/usr/lib/python*/site-packages/ipaserver/certs.py) - Back up /etc/dirsrv/slapd-INSTANCE/*.db and *.txt - Back up /etc/httpd/alias/*.db - Run ipa-ca with the following options As root: # service dirsrv stop # service httpd stop # rm -f /etc/dirsrv/slapd-/cert8.db # python ipa-ca -g # python ipa-ca -i -s yourhost.example.com -o ds.p12 -p password # python ipa-ca -i -s yourhost.example.com -o http.p12 -p password # pk12util -i ds.p12 -d /etc/dirsrv/slapd- -k /etc/dirsrv/slapd-/pwdfile.txt # rm -f /etc/httpd/alias/*.db # certutil -N -d /etc/httpd/alias (press enter twice, no password) # chown apache /etc/httpd/alias/*.db # pk12util -i http.p12 -d /etc/httpd/alias # certutil -M -t "CT,,C" -n "CA certificate" -d /etc/httpd/alias # service dirsrv start # service httpd start Your new CA is in /etc/dirsrv/slapd-INSTANCE/cacert.p12. You'll want to back this up somewhere (and probably remove the .p12 file). This should generate a new CA, issue 2 certificates and put them into PKCS#12 files, then import them into your instances. If you have any replicas then do the same steps without the "ipa-ca -g" step. ipa-ca should always be run on the initial IPA master. The basic idea is that 'ipa-ca -g' generates a new CA using the certs.py patch that you applied. Then you create a PKCS#12 file for each of the two services on each IPA instace. The process of generating a new CA creates a new DS database so you just have to import the cert you generated. For Apache we have to remove the database and re-create it, fixing permissions along the way. Then the cert is imported and the CA trusted. This works for me with IPA v1.2. I wouldn't recommend doing this on a production server yet. rob -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: certs.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ipa-ca 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 Mon Jul 27 22:06:10 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 27 Jul 2009 22:06:10 +0000 Subject: [Freeipa-devel] [PATCH] 242 new method to identify CAs to trust In-Reply-To: <4A69B77A.9030809@redhat.com> References: <4A68DCAE.7060206@redhat.com> <1248404454.2713.1.camel@jgd-flap> <4A69B77A.9030809@redhat.com> Message-ID: <1248732370.2682.0.camel@jgd-flap> On Fri, 2009-07-24 at 09:30 -0400, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > On Thu, 2009-07-23 at 17:57 -0400, Rob Crittenden wrote: > >> A new way to identify the CAs to trust when importing a PKCS#12 file > >> (like during replica installation). We used to use certutil -O but > >> Fedora 11 changed certutil so it doesn't show untrusted CAs (the whole > >> point of running the command). > >> > >> Instead parse the output of pk12util -l to find the nicknames of the CAs > >> to trust. > >> > >> rob > > > > The code looks fine, but I can't get it to apply. > > > > I needed to do a rebase. New patch attached that should apply cleanly to > the tip. > > rob ack. pushed to master. From nkinder at redhat.com Tue Jul 28 05:51:01 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 27 Jul 2009 22:51:01 -0700 Subject: [Freeipa-devel] Ubuntu interests in FreeIPA In-Reply-To: References: <20090629232054.GI5965@mathiaz.mathiaz.net> <1246368630.13348.31.camel@localhost.localdomain> Message-ID: <4A6E91C5.4000602@redhat.com> On 07/22/2009 11:11 AM, Mathias Gug wrote: > Hi, > > Sorry for not following up earlier on this, but this topic has been > recently brought on the Ubuntu freeipa team mailing list [1] > > [1]: https://lists.launchpad.net/freeipa/msg00009.html > > Here are my comments mainly related to supporting openldap instead of > 389DS in FreeIPA: > > On Tue, Jun 30, 2009 at 9:30 AM, Simo Sorce wrote: > >> On Mon, 2009-06-29 at 19:20 -0400, Mathias Gug wrote: >> >>> * 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. >> >> > > * ipa-memberof: IPA memberof plugin > > There is a similar overlay in openldap: > > The memberof overlay to slapd(8) allows automatic reverse group member? > ship maintenance. Any time a group entry is modified, its members are > modified as appropriate in order to keep a DN-valued "is member of" > attribute updated with the DN of the group. > My understanding is that the memberOf overlay does not deal with nested membership. It is strictly a 1:1 relationship (forward pointer, reverse pointer). The 389 memberOf plug-in maintains reverse pointers for inherited membership, which IPA takes advantage of. Take this with a grain of salt as I haven't confirmed this by looking at the overlay code personally. > -- > Mathias Gug > Ubuntu Developer http://www.ubuntu.com > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > From jhrozek at redhat.com Tue Jul 28 12:58:07 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 28 Jul 2009 14:58:07 +0200 Subject: [Freeipa-devel] [PATCH] Improve error messages Message-ID: <4A6EF5DF.70908@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jenny found several cases where our error messages were not very descriptive. This patch adds a ERROR() call for those cases. The error message for adding a user with existing UID and name is the same, since the error code from sysdb is EEXIST in both cases..I hope this is OK. Also fixes one typo where useradd would say it cannot "modify user" instead of "add user". Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpu9d8ACgkQHsardTLnvCV1fgCdFJLJ/oOvtpwrOn+Qv9Dkf0Uf LAwAoIjHB/KlgR4tAvN8QvOeAZkIHQWs =n3Jt -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Improve-error-messages.patch Type: text/x-patch Size: 3925 bytes Desc: not available URL: From jhrozek at redhat.com Tue Jul 28 12:58:12 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 28 Jul 2009 14:58:12 +0200 Subject: [Freeipa-devel] [PATCH] Don't segfault on adding user outside domains In-Reply-To: <4A1BD608.3060001@redhat.com> References: <1243254918.24078.8.camel@zeppelin.englab.brq.redhat.com> <4A1BD608.3060001@redhat.com> Message-ID: <4A6EF5E4.6030509@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/26/2009 01:44 PM, Stephen Gallagher wrote: > On 05/25/2009 08:35 AM, Jakub Hrozek wrote: >> Found this when working on tools testsuite.. >> >> If the user enters UID outside any domain ranges, we invoke the legacy >> tools. But that was broken since the code read on domain->xxx even in >> this case, when domain == NULL. Fix attached. >> >> Jakub >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > I'm sorry, I absolutely forgot about this thread. Luckily, Jenny reminded me with ticket #86 :-) > Nack. > The only way to enter the useradd_legacy() function is for the domain to > be NULL. There will never be a case where the USERADD_UID_MIN/MAX will > be used. I think we need to rethink how to generate that portion of the > parameter, because we want to ensure that the legacy useradd doesn't > step on the toes of one of our domains. > I disagree, it you consider having two domains LEGACYLOCAL that handles IDs of 500-999 and LOCAL that handles 1000-1999, there are two ways to enter the useradd_legacy function: 1) specify UID in the LEGACYLOCAL range, i.e. "sss_useradd -u 999 foo" 2) specify UID outside any known domain There will be a third way once I implement a fix for #513670 and that would be "sss_useradd foo at LEGACYLOCAL" - where you really need to pass USERADD_UID_MIN/MAX since you don't care about the specific UID, you only want it to be in the range given by LEGACYLOCAL domain. > Perhaps try creating local users where the USERADD_UID_MAX is the value > of the lowest supported domain, except where this is impossible (we have > a domain handling UID 1), in which case we set the USERADD_UID_MIN to > the highest max domain range. If this is also impossible (such as having > a domain with no maximum), then exit out and instruct the user to > specify the uid and gid manually because no automatic value could be > determined. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpu9eQACgkQHsardTLnvCUS1gCg3mxRf/mXSdF1gUo6oMbPePSS +ysAnAqz2pEyy2Tl37VK9GIwY7waT9Hu =qjU/ -----END PGP SIGNATURE----- From sgallagh at redhat.com Tue Jul 28 14:02:52 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 28 Jul 2009 10:02:52 -0400 Subject: [Freeipa-devel] [PATCH] Don't segfault on adding user outside domains In-Reply-To: <4A6EF5E4.6030509@redhat.com> References: <1243254918.24078.8.camel@zeppelin.englab.brq.redhat.com> <4A1BD608.3060001@redhat.com> <4A6EF5E4.6030509@redhat.com> Message-ID: <4A6F050C.3010704@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/28/2009 08:58 AM, Jakub Hrozek wrote: > On 05/26/2009 01:44 PM, Stephen Gallagher wrote: >> On 05/25/2009 08:35 AM, Jakub Hrozek wrote: >>> Found this when working on tools testsuite.. >>> >>> If the user enters UID outside any domain ranges, we invoke the legacy >>> tools. But that was broken since the code read on domain->xxx even in >>> this case, when domain == NULL. Fix attached. >>> >>> Jakub >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel > > I'm sorry, I absolutely forgot about this thread. Luckily, Jenny > reminded me with ticket #86 :-) > >> Nack. >> The only way to enter the useradd_legacy() function is for the domain to >> be NULL. There will never be a case where the USERADD_UID_MIN/MAX will >> be used. I think we need to rethink how to generate that portion of the >> parameter, because we want to ensure that the legacy useradd doesn't >> step on the toes of one of our domains. > > > I disagree, it you consider having two domains LEGACYLOCAL that handles > IDs of 500-999 and LOCAL that handles 1000-1999, there are two ways to > enter the useradd_legacy function: > 1) specify UID in the LEGACYLOCAL range, i.e. "sss_useradd -u 999 foo" > 2) specify UID outside any known domain > > There will be a third way once I implement a fix for #513670 and that > would be "sss_useradd foo at LEGACYLOCAL" - where you really need to pass > USERADD_UID_MIN/MAX since you don't care about the specific UID, you > only want it to be in the range given by LEGACYLOCAL domain. > > >> Perhaps try creating local users where the USERADD_UID_MAX is the value >> of the lowest supported domain, except where this is impossible (we have >> a domain handling UID 1), in which case we set the USERADD_UID_MIN to >> the highest max domain range. If this is also impossible (such as having >> a domain with no maximum), then exit out and instruct the user to >> specify the uid and gid manually because no automatic value could be >> determined. > > My understanding was that we were trying to avoid using domain names as reserved words. That's why we're using provider=local instead of the LOCAL domain name. The problem is that LEGACYLOCAL is just a special case of the proxy. If we wanted to do this, we need to add a provider=legacylocal that is an alias for proxy. (This way they can name their domain whatever they want) _______________________________________________ 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/ iEYEARECAAYFAkpvBQgACgkQeiVVYja6o6NSfwCdGugk/OFNrcfHATxTA7h3Lsx2 MkcAoIQdTNFhkjCeYXVwhOPhrImrF9We =0RwI -----END PGP SIGNATURE----- From sgallagh at redhat.com Tue Jul 28 14:21:37 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 28 Jul 2009 10:21:37 -0400 Subject: [Freeipa-devel] [PATCH] Improve error messages In-Reply-To: <4A6EF5DF.70908@redhat.com> References: <4A6EF5DF.70908@redhat.com> Message-ID: <4A6F0971.1030907@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/28/2009 08:58 AM, Jakub Hrozek wrote: > Jenny found several cases where our error messages were not very > descriptive. This patch adds a ERROR() call for those cases. > > The error message for adding a user with existing UID and name is the > same, since the error code from sysdb is EEXIST in both cases..I hope > this is OK. > > Also fixes one typo where useradd would say it cannot "modify user" > instead of "add user". > > Jakub > Ack. Looks good to me. - ------------------------------------------------------------------------ _______________________________________________ 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/ iEYEARECAAYFAkpvCWwACgkQeiVVYja6o6MKVwCgpFQNttnFTC78VdzlU38LzdBE 7RcAniRpGx6d97lkYEecJhNn7YwMmwgQ =2fig -----END PGP SIGNATURE----- From jderose at redhat.com Tue Jul 28 20:06:27 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 28 Jul 2009 14:06:27 -0600 Subject: [Freeipa-devel] [PATCH] jderose 013 Add secure session storage Message-ID: <1248811587.2678.59.camel@jgd-flap> This patch adds code to securely store the ccache in an encrypted session on the server (as previously discussed). There are two things we still need to decide: 1. Where we store the Sqlite session table. This can't be a random temporary file because all the Apache processes must use the same file, must know in advance. There's no reason to write anything to a physical disk, so I recommend we use something like /dev/shm/ipa-session.sqlite. Whatever the default value, we'll make it configurable. 2. Where we write the temporary clear-text ccache when resuming the session. We need to write the ccache to a temporary file just long enough to bind to LDAP, after which we'll delete it. This needs to be a securely created, randomly named temporary file. Using /tmp/ is fine, but as with the session table, there's no reason to write anything to a physical disk, so for performance it's far better if we write the ccache to a memory-based file system like /dev/shm/. I think creating a directory like /dev/shm/ipa-tmp/ would be good, then we can write all the ccache temp files in there. There are a few features I left out of the Session class for now to make it easier to review the basic implementation (and because these features are trivial to add). But on this list are: 1. We should probably store the IP address that a session is started from and only allow the session to be resumed from the same IP address. My implementation certainly doesn't require this to be secure, but it provides a bit of extra assurance that some may want (to the extend that the IP address can be trusted, for which the prudent assumption is "not at all"). 2. We should probably store the principal (extracted from the ccache) in the session table. My main reason for this is debugging, just so it's easy to see what sessions exist and who has them. I'm currently using python-crypto to do the encryption, but this might change in the future. Does anyone have an opinion as to whether NSS is appropriate for doing purely symmetric crypto? John mentioned that he can add symmetric crypto to the python-nss bindings. I'm also using SQLAlchemy to interact with Sqlite. SQLAlchemy provides solid protection against SQL injection (and is just a cool library), but if people have a problem with this additional dependency, I can rework it to run raw statements against the sqlite3 DB-API interface. If anyone is missing these packages, just yum install python-crypto python-sqlalchemy. You may also need the python-sqlite package if running under Pyhon2.4. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-013-add-secure-session-storage.patch Type: text/x-patch Size: 19270 bytes Desc: not available URL: From jdennis at redhat.com Tue Jul 28 20:16:14 2009 From: jdennis at redhat.com (John Dennis) Date: Tue, 28 Jul 2009 16:16:14 -0400 Subject: [Freeipa-devel] [PATCH] jderose 013 Add secure session storage In-Reply-To: <1248811587.2678.59.camel@jgd-flap> References: <1248811587.2678.59.camel@jgd-flap> Message-ID: <4A6F5C8E.40304@redhat.com> On 07/28/2009 04:06 PM, Jason Gerard DeRose wrote: > I'm also using SQLAlchemy to interact with Sqlite. SQLAlchemy provides > solid protection against SQL injection (and is just a cool library), but > if people have a problem with this additional dependency, I can rework > it to run raw statements against the sqlite3 DB-API interface. SQLAlchemy rocks! -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Jul 29 14:12:51 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 29 Jul 2009 10:12:51 -0400 Subject: [Freeipa-devel] [PATCH] 243 clean up v1.2 LDAP module Message-ID: <4A7058E3.50403@redhat.com> The 1.2 LDAP module was throwing a deprecation warning for using popen2 and pychecker found a slew of other issues as well. This patch removes a bunch of unused imports, renames some variables that shadowed builtins and renames some functions. exportLDIF() calls a function that isn't provided. This must have gotten left over from when I ported this from Rich's original LDAP module which did all sorts of stuff. I think we can drop this as it doesn't even work but wanted to throw it out there on the off-chance that someone found a way to use it. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-243-cleanup.patch Type: application/mbox Size: 9506 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 Jul 29 17:40:09 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 29 Jul 2009 13:40:09 -0400 Subject: [Freeipa-devel] [PATCH] Fixes for IPA 1.2 Message-ID: <4A708979.3060300@redhat.com> Here are 3 patches for the ipa-1-2 branch: 1. Backports a bunch of certificate patches recently committed to master. This should fix replication installation on F-11. 2. Remove a deprecation warning related to BaseException.message 3. Fix a previous backport attempt to fix make SELinux compile on systems from RHEL 5 -> F-11. I've tested this on F-9, F-11 and RHEL 5. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-244-certs.patch Type: application/mbox Size: 5355 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-245-error.patch Type: application/mbox Size: 10908 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-246-selinux.patch Type: application/mbox Size: 1297 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 hyc at symas.com Thu Jul 30 00:01:38 2009 From: hyc at symas.com (Howard Chu) Date: Wed, 29 Jul 2009 17:01:38 -0700 Subject: [Freeipa-devel] Ubuntu interests in FreeIPA Message-ID: <4A70E2E2.8010907@symas.com> From Mathias Gug: > Hi, > > Sorry for not following up earlier on this, but this topic has been > recently brought on the Ubuntu freeipa team mailing list [1] > > [1]: https://lists.launchpad.net/freeipa/msg00009.html > > Here are my comments mainly related to supporting openldap instead of > 389DS in FreeIPA: > > On Tue, Jun 30, 2009 at 9:30 AM, Simo Sorce wrote: >> On Mon, 2009-06-29 at 19:20 -0400, Mathias Gug wrote: >>> * 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. OpenLDAP has supported SLAPI since 2002; if the necessary plugins don't work out of the box we can easily fix whatever's needed. > Looking at freeipa-1.2.1/ipa-server/ipa-slapi-plugins/, there are 4 plugins: > > * dna: Distributed Numeric Assignment plug-in > > I don't know of an openldap plugin providing the same functionality. This can also be written easily as a native slapd overlay. > However one solution could be to use the uniq overlay to make sure the > uids are unique: > * ipa-memberof: IPA memberof plugin > > There is a similar overlay in openldap: > > The memberof overlay to slapd(8) allows automatic reverse group member? > ship maintenance. Any time a group entry is modified, its members are > modified as appropriate in order to keep a DN-valued "is member of" > attribute updated with the DN of the group. re: nested groups, that support can be added if necessary. > * ipa-pwd-extop: Password Modify - LDAP Extended Operation > > There is a similar overlay in openldap/contrib: > > The smbk5pwd that extends the PasswordModify Extended Operation to > update Kerberos keys and Samba password hashes for an LDAP user. > > However the code is currently written for Heimdal kerberos and should > be ported to MIT Kerberos. I would still be quite leery of this; the history of MIT Kerberos wrt thread safety has always been poor. The performance of the later "threadsafe" releases has lagged significantly behind Heimdal's the rare times it wasn't simply hung or dead. I guess if someone contributes the patches we'll integrate them, but I'm not going to write this on my own initiative until I'm convinced there's actually any technical merit in supporting MIT. Thus far I haven't had time to rerun the benchmarks to see how things have changed in current MIT releases. > * ipa-winsync: Windows Synchronization Plug-in for IPA > > I don't know of an openldap overlay that provides all the > functionality of ipa-winsync. However the translucent overlay may be > leverage to provide part of the functionality. What are the exact > functionality provided by this plugin? I haven't looked at this code yet but there are a few different things one can consider in terms of Windows sync. Even as a replication peer, passwords are not exposed via LDAP so you still need a separate password synch agent (e.g. http://www.microsoft.com/downloads/details.aspx?familyid=2BA5C443-D972-4B13-81EF-8AD20F779F51&displaylang=en ) This synch protocol is pretty trivial, we have an overlay for it (not yet released). > It should also be noted that openldap support slapi plugins, which > means that some FreeIPA plugins could be supported in openldap (to be > tested though). > Are there any other plugins that I've missed? >> 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. >> > > Noted. > >> ACIs are slightly different between 389DS and openLDAP, that would >> require to change part of the installation and management tools. > Noted. > >> 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. > Agreed. The other option is bring in 389 DS in the archive. My main > concern here is about resource to maintain the package once it's in > the archive. As there already is a good ldap server in Ubuntu I'm not > sure what we would gain for having *another* ldap server to maintain. >>> * 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. We're taking steps to unify the MIT and Heimdal schema. https://lists.anl.gov/pipermail/ietf-krb-wg/2009-July/007790.html Since the response from the IETF folks has been sparse but mostly positive, we'll likely move ahead without waiting for further IETF response and just present the completed work in the near future. > Agreed. > >> 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). >> > > Agreed. > > -- > Mathias Gug > Ubuntu Developer http://www.ubuntu.com -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From mnagy at redhat.com Thu Jul 30 05:37:31 2009 From: mnagy at redhat.com (Martin Nagy) Date: Thu, 30 Jul 2009 07:37:31 +0200 Subject: [Freeipa-devel] [PATCH] 243 clean up v1.2 LDAP module In-Reply-To: <4A7058E3.50403@redhat.com> References: <4A7058E3.50403@redhat.com> Message-ID: <20090730073731.5191a534@wolverine.englab.brq.redhat.com> On Wed, 29 Jul 2009 10:12:51 -0400, Rob Crittenden wrote: > The 1.2 LDAP module was throwing a deprecation warning for using > popen2 and pychecker found a slew of other issues as well. > > This patch removes a bunch of unused imports, renames some variables > that shadowed builtins and renames some functions. > > exportLDIF() calls a function that isn't provided. This must have > gotten left over from when I ported this from Rich's original LDAP > module which did all sorts of stuff. I think we can drop this as it > doesn't even work but wanted to throw it out there on the off-chance > that someone found a way to use it. > > rob Ack Martin From mnagy at redhat.com Thu Jul 30 05:54:51 2009 From: mnagy at redhat.com (Martin Nagy) Date: Thu, 30 Jul 2009 07:54:51 +0200 Subject: [Freeipa-devel] [PATCH] Fixes for IPA 1.2 In-Reply-To: <4A708979.3060300@redhat.com> References: <4A708979.3060300@redhat.com> Message-ID: <20090730075451.17f38d63@wolverine.englab.brq.redhat.com> On Wed, 29 Jul 2009 13:40:09 -0400, Rob Crittenden wrote: > Here are 3 patches for the ipa-1-2 branch: > > 1. Backports a bunch of certificate patches recently committed to > master. This should fix replication installation on F-11. > > 2. Remove a deprecation warning related to BaseException.message > > 3. Fix a previous backport attempt to fix make SELinux compile on > systems from RHEL 5 -> F-11. > > I've tested this on F-9, F-11 and RHEL 5. > > rob One typo in the first patch: > + logging.debug("Unable to identify root certificate to > trust. Continueing but things are likely to fail.") s/Continueing/Continuing Other than that all three look good to me. Ack. Martin From jhrozek at redhat.com Thu Jul 30 16:49:56 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 30 Jul 2009 18:49:56 +0200 Subject: [Freeipa-devel] [PATCH] Use correct return codes Message-ID: <4A71CF34.1030402@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A copy-paste-error caused that some code paths which should exit with an error used potentionally incorrect return code. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpxzzQACgkQHsardTLnvCUmrQCfUwBlbc0QChtDl8Xh4hHmJ27e 0pYAn1W5FXZqb1UQJVbufVlAeGO3X+Wm =pmS9 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-correct-return-codes.patch Type: text/x-patch Size: 2668 bytes Desc: not available URL: From jhrozek at redhat.com Thu Jul 30 16:50:16 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 30 Jul 2009 18:50:16 +0200 Subject: [Freeipa-devel] [PATCH] Correct check for local domain in tools Message-ID: <4A71CF48.5030705@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As Stephen noted in a recent post[1], the check for a local non-legacy domain should be done with checking if provider == local, not by comparing the domain name. The attached patch fixes this in the tools. Jakub [1] https://www.redhat.com/archives/freeipa-devel/2009-July/msg00336.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpxz0gACgkQHsardTLnvCUmfQCgp++wmosCFlQvoCb5syFzRu1R HpoAoOVZxwA1tYKBNVd+REhqfOyQmPDW =Xql7 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Correct-check-for-local-domain-in-tools.patch Type: text/x-patch Size: 2313 bytes Desc: not available URL: From jhrozek at redhat.com Thu Jul 30 16:50:31 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 30 Jul 2009 18:50:31 +0200 Subject: [Freeipa-devel] [PATCH] Notify user when deleting nonexistent user or group Message-ID: <4A71CF57.2000007@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Before a deletion, search the sysdb for the entity and error out if it cannot be found. Fixes: RHBZ #513247, RHBZ #513250 Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpxz1cACgkQHsardTLnvCUDKgCgzysB1MIWtWcfeGSK+T0ZFIh5 jZAAnAk1YmPZx/WT3ry4ilzKqHZZLFUm =LShj -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Notify-user-when-deleting-nonexistent-user-or-group.patch Type: text/x-patch Size: 6665 bytes Desc: not available URL: From sgallagh at redhat.com Thu Jul 30 17:01:26 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 30 Jul 2009 13:01:26 -0400 Subject: [Freeipa-devel] [PATCH] Use correct return codes In-Reply-To: <4A71CF34.1030402@redhat.com> References: <4A71CF34.1030402@redhat.com> Message-ID: <4A71D1E6.40500@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/30/2009 12:49 PM, Jakub Hrozek wrote: > A copy-paste-error caused that some code paths which should exit with an > error used potentionally incorrect return code. > > 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/ iEYEARECAAYFAkpx0eAACgkQeiVVYja6o6OESwCeIpi9kGfCFoLUohLQuVa+srBL CasAoKRaxPZJLIF+jUvnfZtcJiGgMD/H =xsqt -----END PGP SIGNATURE----- From jhrozek at redhat.com Thu Jul 30 17:36:12 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 30 Jul 2009 19:36:12 +0200 Subject: [Freeipa-devel] [PATCH] Notify user when deleting nonexistent user or group In-Reply-To: <4A71CF57.2000007@redhat.com> References: <4A71CF57.2000007@redhat.com> Message-ID: <4A71DA0C.1010207@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/30/2009 06:50 PM, Jakub Hrozek wrote: > Before a deletion, search the sysdb for the entity and error > out if it cannot be found. > > Fixes: RHBZ #513247, RHBZ #513250 > > Jakub This patch did conflict with the return codes patch. Attached are rebased versions that can be applied on top of one another. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpx2gwACgkQHsardTLnvCXRRACgvl0bHJxnwE4ppviWFVpanbHK z/QAmwSILZVA0Gd+w9sAyLGY8h4XmROb =BaJy -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-correct-return-codes.patch Type: text/x-patch Size: 2671 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Notify-user-when-deleting-nonexistent-user-or-group.patch Type: text/x-patch Size: 6667 bytes Desc: not available URL: From rcritten at redhat.com Thu Jul 30 17:56:25 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 30 Jul 2009 13:56:25 -0400 Subject: [Freeipa-devel] [PATCH] 243 clean up v1.2 LDAP module In-Reply-To: <20090730073731.5191a534@wolverine.englab.brq.redhat.com> References: <4A7058E3.50403@redhat.com> <20090730073731.5191a534@wolverine.englab.brq.redhat.com> Message-ID: <4A71DEC9.6010702@redhat.com> Martin Nagy wrote: > On Wed, 29 Jul 2009 10:12:51 -0400, Rob Crittenden > wrote: > >> The 1.2 LDAP module was throwing a deprecation warning for using >> popen2 and pychecker found a slew of other issues as well. >> >> This patch removes a bunch of unused imports, renames some variables >> that shadowed builtins and renames some functions. >> >> exportLDIF() calls a function that isn't provided. This must have >> gotten left over from when I ported this from Rich's original LDAP >> module which did all sorts of stuff. I think we can drop this as it >> doesn't even work but wanted to throw it out there on the off-chance >> that someone found a way to use it. >> >> rob > > Ack > > Martin Pushed to ipa-1-2 -------------- 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 Jul 30 17:56:42 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 30 Jul 2009 13:56:42 -0400 Subject: [Freeipa-devel] [PATCH] Fixes for IPA 1.2 In-Reply-To: <20090730075451.17f38d63@wolverine.englab.brq.redhat.com> References: <4A708979.3060300@redhat.com> <20090730075451.17f38d63@wolverine.englab.brq.redhat.com> Message-ID: <4A71DEDA.9070607@redhat.com> Martin Nagy wrote: > On Wed, 29 Jul 2009 13:40:09 -0400, Rob Crittenden > wrote: > >> Here are 3 patches for the ipa-1-2 branch: >> >> 1. Backports a bunch of certificate patches recently committed to >> master. This should fix replication installation on F-11. >> >> 2. Remove a deprecation warning related to BaseException.message >> >> 3. Fix a previous backport attempt to fix make SELinux compile on >> systems from RHEL 5 -> F-11. >> >> I've tested this on F-9, F-11 and RHEL 5. >> >> rob > > One typo in the first patch: >> + logging.debug("Unable to identify root certificate to >> trust. Continueing but things are likely to fail.") > s/Continueing/Continuing > > Other than that all three look good to me. > Ack. > > Martin Fixed typo in patch and pushed all three to ipa-1-2 -------------- 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 Thu Jul 30 18:45:16 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 30 Jul 2009 14:45:16 -0400 Subject: [Freeipa-devel] [PATCH] Notify user when deleting nonexistent user or group In-Reply-To: <4A71DA0C.1010207@redhat.com> References: <4A71CF57.2000007@redhat.com> <4A71DA0C.1010207@redhat.com> Message-ID: <4A71EA3C.7080905@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/30/2009 01:36 PM, Jakub Hrozek wrote: > On 07/30/2009 06:50 PM, Jakub Hrozek wrote: >> Before a deletion, search the sysdb for the entity and error >> out if it cannot be found. > >> Fixes: RHBZ #513247, RHBZ #513250 > >> Jakub > > This patch did conflict with the return codes patch. Attached are > rebased versions that can be applied on top of one another. > > Jakub The return codes patch remains acked. I'm going to nack the user notification patch. I think we need to think some more about this. The sysdb has an interface in place for returning ENOENT when trying to delete, we're just setting it state->ignore_not_found = true; in sysdb_delete_entry_send(). I think the correct thing to do would be to modify that function so that it accepted a boolean value for whether or not to ignore it if it's not found. This way, we aren't doing an extra search. - ------------------------------------------------------------------------ _______________________________________________ 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/ iEYEARECAAYFAkpx6jcACgkQeiVVYja6o6MsZQCglbRO/wJp5IT2OswjadNCGP5V ojIAn2ZmfYlWjnIpmgNwGpp5KvDk8TkT =uGcx -----END PGP SIGNATURE----- From jhrozek at redhat.com Fri Jul 31 10:02:01 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 31 Jul 2009 12:02:01 +0200 Subject: [Freeipa-devel] [PATCH] Notify user when deleting nonexistent user or group In-Reply-To: <4A71EA3C.7080905@redhat.com> References: <4A71CF57.2000007@redhat.com> <4A71DA0C.1010207@redhat.com> <4A71EA3C.7080905@redhat.com> Message-ID: <4A72C119.70801@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/30/2009 08:45 PM, Stephen Gallagher wrote: > I'm going to nack the user notification patch. I think we need to think > some more about this. The sysdb has an interface in place for returning > ENOENT when trying to delete, we're just setting it > state->ignore_not_found = true; in sysdb_delete_entry_send(). > > I think the correct thing to do would be to modify that function so that > it accepted a boolean value for whether or not to ignore it if it's not > found. > > This way, we aren't doing an extra search. I agree, I didn't realize there was this option. Thanks for the review. Attached are three patches: * [PATCH 1/3] Add ignore_not_found parameter to sysdb delete functions changes the sysdb API, its invocations in the code and adds a test for the change * [PATCH 2/3] Use correct return codes The already-acked patch, included for clarity * [PATCH 3/3] Notify user when deleting nonexistent user or group Changes tools code to react with appropriate error message to ENOENT Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpywRkACgkQHsardTLnvCXZxACgpoTd+OQHRec9YpzR+JQH+8SN FlgAoNVZM838bstekX49AdxE/X2iCOUH =tMJo -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-ignore_not_found-parameter-to-sysdb-delete-funct.patch Type: text/x-patch Size: 16069 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Use-correct-return-codes.patch Type: text/x-patch Size: 2671 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Notify-user-when-deleting-nonexistent-user-or-group.patch Type: text/x-patch Size: 2771 bytes Desc: not available URL: From sgallagh at redhat.com Fri Jul 31 15:55:57 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 31 Jul 2009 11:55:57 -0400 Subject: [Freeipa-devel] [PATCH] Notify user when deleting nonexistent user or group In-Reply-To: <4A72C119.70801@redhat.com> References: <4A71CF57.2000007@redhat.com> <4A71DA0C.1010207@redhat.com> <4A71EA3C.7080905@redhat.com> <4A72C119.70801@redhat.com> Message-ID: <4A73140D.6090406@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/31/2009 06:02 AM, Jakub Hrozek wrote: > On 07/30/2009 08:45 PM, Stephen Gallagher wrote: >> I'm going to nack the user notification patch. I think we need to think >> some more about this. The sysdb has an interface in place for returning >> ENOENT when trying to delete, we're just setting it >> state->ignore_not_found = true; in sysdb_delete_entry_send(). > >> I think the correct thing to do would be to modify that function so that >> it accepted a boolean value for whether or not to ignore it if it's not >> found. > >> This way, we aren't doing an extra search. > > I agree, I didn't realize there was this option. Thanks for the review. > > Attached are three patches: > * [PATCH 1/3] Add ignore_not_found parameter to sysdb delete functions > changes the sysdb API, its invocations in the code and adds a test for > the change > * [PATCH 2/3] Use correct return codes > The already-acked patch, included for clarity > * [PATCH 3/3] Notify user when deleting nonexistent user or group > Changes tools code to react with appropriate error message to ENOENT > > Jakub Ack to all three. - ------------------------------------------------------------------------ _______________________________________________ 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/ iEYEARECAAYFAkpzFAoACgkQeiVVYja6o6Pc4gCgqbDZNlhp7MmK3rMRtCiV7HLr bugAnRsbGPg6yK2HT2yHKK1LEPnJ1Zor =QX/b -----END PGP SIGNATURE----- From sgallagh at redhat.com Fri Jul 31 16:01:42 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 31 Jul 2009 12:01:42 -0400 Subject: [Freeipa-devel] [PATCH] Correct check for local domain in tools In-Reply-To: <4A71CF48.5030705@redhat.com> References: <4A71CF48.5030705@redhat.com> Message-ID: <4A731566.2030502@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/30/2009 12:50 PM, Jakub Hrozek wrote: > As Stephen noted in a recent post[1], the check for a local non-legacy > domain should be done with checking if provider == local, not by > comparing the domain name. The attached patch fixes this in the tools. > > Jakub > > [1] https://www.redhat.com/archives/freeipa-devel/2009-July/msg00336.html > 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/ iEYEARECAAYFAkpzFWEACgkQeiVVYja6o6N9ywCfTDDPx1xcTlZIslFV8LrZgHod x3sAnjVE1vhX0mVK9fSXtnrZNuEhG3OM =0E+Y -----END PGP SIGNATURE----- From sgallagh at redhat.com Fri Jul 31 16:09:34 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 31 Jul 2009 12:09:34 -0400 Subject: [Freeipa-devel] [PATCH] Improve error messages In-Reply-To: <4A6F0971.1030907@redhat.com> References: <4A6EF5DF.70908@redhat.com> <4A6F0971.1030907@redhat.com> Message-ID: <4A73173E.4020503@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/28/2009 10:21 AM, Stephen Gallagher wrote: > On 07/28/2009 08:58 AM, Jakub Hrozek wrote: >> Jenny found several cases where our error messages were not very >> descriptive. This patch adds a ERROR() call for those cases. > >> The error message for adding a user with existing UID and name is the >> same, since the error code from sysdb is EEXIST in both cases..I hope >> this is OK. > >> Also fixes one typo where useradd would say it cannot "modify user" >> instead of "add user". > >> Jakub > > > Ack. Looks good to me. > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Pushed to master. _______________________________________________ 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/ iEYEARECAAYFAkpzFzkACgkQeiVVYja6o6PLDgCgh3j2RvjUcFk6DcEKGH5vPV3z +AMAoKUKxQWbKQpBVi26Y5dqNxdF2sH+ =XeP+ -----END PGP SIGNATURE----- From sgallagh at redhat.com Fri Jul 31 16:10:03 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 31 Jul 2009 12:10:03 -0400 Subject: [Freeipa-devel] [PATCH] Notify user when deleting nonexistent user or group In-Reply-To: <4A73140D.6090406@redhat.com> References: <4A71CF57.2000007@redhat.com> <4A71DA0C.1010207@redhat.com> <4A71EA3C.7080905@redhat.com> <4A72C119.70801@redhat.com> <4A73140D.6090406@redhat.com> Message-ID: <4A73175B.8000708@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/31/2009 11:55 AM, Stephen Gallagher wrote: > On 07/31/2009 06:02 AM, Jakub Hrozek wrote: >> On 07/30/2009 08:45 PM, Stephen Gallagher wrote: >>> I'm going to nack the user notification patch. I think we need to think >>> some more about this. The sysdb has an interface in place for returning >>> ENOENT when trying to delete, we're just setting it >>> state->ignore_not_found = true; in sysdb_delete_entry_send(). >>> I think the correct thing to do would be to modify that function so that >>> it accepted a boolean value for whether or not to ignore it if it's not >>> found. >>> This way, we aren't doing an extra search. >> I agree, I didn't realize there was this option. Thanks for the review. > >> Attached are three patches: >> * [PATCH 1/3] Add ignore_not_found parameter to sysdb delete functions >> changes the sysdb API, its invocations in the code and adds a test for >> the change >> * [PATCH 2/3] Use correct return codes >> The already-acked patch, included for clarity >> * [PATCH 3/3] Notify user when deleting nonexistent user or group >> Changes tools code to react with appropriate error message to ENOENT > >> Jakub > > Ack to all three. > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Pushed to master. _______________________________________________ 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/ iEYEARECAAYFAkpzF1sACgkQeiVVYja6o6OXNgCeJOL/NqEGHo2CGH52w6JtvDqF Cb4AniNz+VPRX+wpAqFzfSLZN7lSzaBX =Md5I -----END PGP SIGNATURE----- From sgallagh at redhat.com Fri Jul 31 16:10:17 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 31 Jul 2009 12:10:17 -0400 Subject: [Freeipa-devel] [PATCH] Correct check for local domain in tools In-Reply-To: <4A731566.2030502@redhat.com> References: <4A71CF48.5030705@redhat.com> <4A731566.2030502@redhat.com> Message-ID: <4A731769.70602@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/31/2009 12:01 PM, Stephen Gallagher wrote: > On 07/30/2009 12:50 PM, Jakub Hrozek wrote: >> As Stephen noted in a recent post[1], the check for a local non-legacy >> domain should be done with checking if provider == local, not by >> comparing the domain name. The attached patch fixes this in the tools. > >> Jakub > >> [1] https://www.redhat.com/archives/freeipa-devel/2009-July/msg00336.html > > > > Ack > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Pushed to master. _______________________________________________ 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/ iEYEARECAAYFAkpzF2kACgkQeiVVYja6o6MixgCcCXLR5wTGYDIp9+s2erGUOuPt le8An3Ic/XFn5XMmTwfOu8WcTncj7UU9 =pzyn -----END PGP SIGNATURE----- From pzuna at redhat.com Fri Jul 31 16:25:31 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Fri, 31 Jul 2009 18:25:31 +0200 Subject: [Freeipa-devel] [PATCHES] All-around improvements to baseldap.py classes. Message-ID: <4A731AFB.50209@redhat.com> 0001: Enable attribute re-mapping and ordering when printing entries. Also print multiple values on one line separated by commas. ----------------------------------------------------------------------- 0002: Prevent double encoding/decoding when processing compound types. ----------------------------------------------------------------------- 0003: Fix bug in _get_syntax (it was always returning None). Also prevent a few cases of double processing of arguments. ----------------------------------------------------------------------- 0004: All-around improvements to baseldap.py classes. - attribute re-mapping, ordering and hiding (Enables plugins to completely hide LDAP internals from users and full localization of command output.) - translation of member DNs into object names (No more DNs when listing group members etc.) - support for "singleton" LDAP objects (Objects like "pwpolicy"; not accessed by primary key.) - new base classes for commands: LDAPModMember, LDAPAddMember and LDAPRemoveMember (Providing support for objects with 'member'-like attributes.) - LDAPSearch implicit exit code changed to 1 when nothing is found Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-All-around-improvements-to-baseldap.py-classes.patch Type: application/mbox Size: 17765 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Enable-attribute-re-mapping-and-ordering-when-printi.patch Type: application/mbox Size: 2224 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Prevent-double-encoding-decoding-when-processing-com.patch Type: application/mbox Size: 1703 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Fix-bug-in-_get_syntax-it-was-always-returning-None.patch Type: application/mbox Size: 3165 bytes Desc: not available URL: From pzuna at redhat.com Fri Jul 31 16:27:02 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Fri, 31 Jul 2009 18:27:02 +0200 Subject: [Freeipa-devel] [PATCH] Rewrite pwpolicy plugin based on baseldap.py. Message-ID: <4A731B56.7060408@redhat.com> Fix bugs: 510740, 510739, 510735, 510733, 510532 Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Rewrite-pwpolicy-plugin-based-on-baseldap.py.patch Type: application/mbox Size: 5754 bytes Desc: not available URL: From pzuna at redhat.com Fri Jul 31 16:29:06 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Fri, 31 Jul 2009 18:29:06 +0200 Subject: [Freeipa-devel] [PATCH] Replace TYPE_ERROR by ValidationError Message-ID: <4A731BD2.10605@redhat.com> No more tracebacks when an INT parameter is beyond the type limit. Fix bug: 5107333 There will probably be more patches similar to this one in the future. TYPE_ERROR is used in a several places where a better suited exception is available. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Replace-TYPE_ERROR-by-ValidationError.patch Type: application/mbox Size: 1179 bytes Desc: not available URL: From pzuna at redhat.com Fri Jul 31 16:29:58 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Fri, 31 Jul 2009 18:29:58 +0200 Subject: [Freeipa-devel] [PATCH] Fix typo bug in aci.py Message-ID: <4A731C06.4070206@redhat.com> Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-Fix-typo-bug-in-aci.py.patch Type: application/mbox Size: 707 bytes Desc: not available URL: From rcritten at redhat.com Fri Jul 31 18:27:19 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 31 Jul 2009 14:27:19 -0400 Subject: [Freeipa-devel] [PATCHES] All-around improvements to baseldap.py classes. In-Reply-To: <4A731AFB.50209@redhat.com> References: <4A731AFB.50209@redhat.com> Message-ID: <4A733787.5020303@redhat.com> Pavel Z?na wrote: > 0001: Enable attribute re-mapping and ordering when printing entries. > > Also print multiple values on one line separated by commas. Ok, though we'll have to see what that looks like on very large values. One thing I'm thinking is memberOf. In v1 when showing a user you'd also get the list of groups they are a member of. All one one line would be really hard to grok. > ----------------------------------------------------------------------- > 0002: Prevent double encoding/decoding when processing compound types. > ack > ----------------------------------------------------------------------- > 0003: Fix bug in _get_syntax (it was always returning None). > > Also prevent a few cases of double processing of arguments. ack > > ----------------------------------------------------------------------- > 0004: All-around improvements to baseldap.py classes. > > - attribute re-mapping, ordering and hiding > (Enables plugins to completely hide LDAP internals from users > and full localization of command output.) > - translation of member DNs into object names > (No more DNs when listing group members etc.) > - support for "singleton" LDAP objects > (Objects like "pwpolicy"; not accessed by primary key.) > - new base classes for commands: LDAPModMember, LDAPAddMember > and LDAPRemoveMember > (Providing support for objects with 'member'-like attributes.) > - LDAPSearch implicit exit code changed to 1 when nothing is found Why the switch to ONELEVEL as the scope? Otherwise looks ok. 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 Jul 31 18:36:36 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 31 Jul 2009 14:36:36 -0400 Subject: [Freeipa-devel] [PATCH] Rewrite pwpolicy plugin based on baseldap.py. In-Reply-To: <4A731B56.7060408@redhat.com> References: <4A731B56.7060408@redhat.com> Message-ID: <4A7339B4.7090907@redhat.com> Pavel Z?na wrote: > Fix bugs: 510740, 510739, 510735, 510733, 510532 > > Pavel A couple of issues with the max values. I checked DS and I think the maxes should shadow it. krbpwdhistorylength: 24 krbpwdmindiffchars: 6 And I have some further questions for the team. Do we want to limit password validity to 1 year max? Do we need a limit at all other than maxInt? Is 30 big enough for a password? This doesn't seem to enforce that maxlife > minlife. 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 Jul 31 18:37:07 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 31 Jul 2009 14:37:07 -0400 Subject: [Freeipa-devel] [PATCH] Replace TYPE_ERROR by ValidationError In-Reply-To: <4A731BD2.10605@redhat.com> References: <4A731BD2.10605@redhat.com> Message-ID: <4A7339D3.9040006@redhat.com> Pavel Z?na wrote: > No more tracebacks when an INT parameter is beyond the type limit. > > Fix bug: 5107333 > > > There will probably be more patches similar to this one in the future. > TYPE_ERROR is used in a several places where a better suited exception > is available. > 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 rcritten at redhat.com Fri Jul 31 18:38:03 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 31 Jul 2009 14:38:03 -0400 Subject: [Freeipa-devel] [PATCH] Fix typo bug in aci.py In-Reply-To: <4A731C06.4070206@redhat.com> References: <4A731C06.4070206@redhat.com> Message-ID: <4A733A0B.2070602@redhat.com> Pavel Z?na wrote: > > Pavel > > 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 Fri Jul 31 19:04:08 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 31 Jul 2009 15:04:08 -0400 Subject: [Freeipa-devel] [PATCHES] one for INI another for ELAPI In-Reply-To: <4A678E52.1030007@redhat.com> References: <4A678E52.1030007@redhat.com> Message-ID: <4A734028.1050009@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/22/2009 06:10 PM, Dmitri Pal wrote: > Patch 1 (small) > > [PATCH] INI Simple fix to properly process multi value config parameters. > Also fixed a typo in the header file. > Ack > Patch 2 (big) > > [PATCH] ELAPI Next round of functionality - logging part of the interface > > a) Added the main logging interface which > allows creating dispatcher and logging messages or events. > Can't actually log anything yet since the sinks are stubbed out. > b) Made default template be a part of the default > dispatcher. > c) Updated UNIT test. > d) Added preview of the async interface (subject to change > when I actually try to implement it and see what is missing). > e) Some of the calls are stubbed out but they are there > to indicate where next round of work will be. > > Nack. Please squash the patch "ELAPI Adding Core Functionality" into this second patch. Neither one makes sense without the other. I don't like the --with-config-file and --with-config-dir configure parameters. It's usually preferred to keep the filename constant (unless overridden at runtime by a user) and just specify its location. I'd suggest using the following: - --with-config-dir [SYSCONFDIR/elapi] - --with-extra-config-dir [SYSCONFDIR/elapi/apps.d] You can't pass APP_NAME_SIZE as a string and then compare strlen(appname) to it. You're comparing it to the pointer address of the static string. You need to convert it to an integer either in the configure script or in the C code before you can use it that way. - --with-error-file doesn't make sense. There's no reason they should need to change the name of the file. Possibly its location (if they want it somewhere other then CWD) Your ELAPI async interface is incomplete and belongs in a separate patch in any case. I will review this in more detail separately. elapi_event.c: add_host_identity() Please don't use memset on large static character arrays. It's a wasteful operation (in this case, it's 1025 memory writes where one is sufficient). It's much better to set hostname[0] = 0; and then just ensure null termination later if you copy data into it. Memsetting a character array leads to the bad assumption that you are guaranteed a termination. For example, when you use gethostname() later, if the hostname is longer than NI_MAXHOST for some reason, you are not guaranteed null termination. So you should manually insert a null terminator at hostname[NI_MAXHOST]. You do the same thing in several other places in this function, and throughout your code. getnameinfo() guarantees null termination, so memset is completely wasted here. getifaddrs() is not portable. It is implemented only for systems corresponding to BSDi, and even on those systems, it varies widely. If you intend to use this, it needs to be controlled by a configure flag. Please prefer comparisons to EOK or EXIT_SUCCESS instead of 0. Comparison to 0 can imply "false". Similarly, if (!gethostname(hostname, NI_MAXHOST)) hnm = hostname; doesn't read well. Comparing against LOCALHOSTDOMAIN is unnecessary, because it will already have matched LOCALHOST (since you are limiting the search to the length of LOCALHOST). I'd rather see you actually perform a strcasecmp rather than a strncasecmp here, because it's theoretically possible that someone could choose localhost1.example.com for some ridiculous reason, and we'd be throwing it away. It's safe to omit the search limit because strcasecmp() will stop at the end of the shorter string. Why are you doing a string compare of the printable versions of the address vs. LOCALADDRESS[V6]? It would be much faster to do a numeric compare of sockaddr_in->in_addr->s_addr; Similarly, why are we storing the host address as a string instead of as an integer? Seems like a waste of space. add_base_elements(): pass_base = base; is an implicit signed/unsigned conversion on some platforms. It would be best if you defined them both as uint32_t. interprete_key(): For the sake of the sanity of anyone using the code, please spell "interpret" correctly. There's no need to return the length of the strings in the function, since you know they're null-terminated. Returning the length is only useful in arrays without null-termination. convert_bool(): I'd prefer that you use strcasecmp rather than strncasecmp unless you want to allow "Truest" and "Falsely" to match TRUE and FALSE as well. process_arg_list(): strndup() is a GNU extension, it is not portable. Since you control interpret_key(), you know that property will never be unreasonably large and will always be null-terminated, so it's safe to use strdup() here. Use the aforementioned ELAPI_KEY_TYPE_* defines here instead of just if/else. Prefer "elapi_create_event_va" to "with_args". Both elapi_create_event() and elapi_create_event_with_args() take arguments. elapi_internal.c: This is a matter of personal preference, but I prefer _elapi_sink_handler() over elapi_int_sink_handler() to denote an internal function. I am aware that we have an _int suffix in some places in the code, but I'd like to recommend that we move to the underscore prefix. I will send out a coding style change request separately. elapi_log.c: No issues beyond those mentioned above. > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/ iEYEARECAAYFAkpzQCMACgkQeiVVYja6o6NEbgCfaepXzrEgxxk+TNackeJRf5Qv V3kAnjuxlTBVY3EAUFp6wB7GkH9JJBfC =G19K -----END PGP SIGNATURE-----