From jcholast at redhat.com Thu Jan 2 07:40:31 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 02 Jan 2014 08:40:31 +0100 Subject: [Freeipa-devel] [PATCH] chenxiaolong-001 Use /usr/bin/python2 In-Reply-To: <52B45BDB.8000803@redhat.com> References: <52B45BDB.8000803@redhat.com> Message-ID: <52C517EF.5050607@redhat.com> On 20.12.2013 16:01, Petr Viktorin wrote: > On some platforms, "/usr/bin/python" is Python 3. We require Python 2 so > we should explicitly use /usr/bin/python2. > > Xiao-Long, who owns FreeIPA in Arch Linux's AUR [0], wrote a patch for > this issue. I've just updated the patch to current master (so any > breakage this causes is my fault). > > https://fedorahosted.org/freeipa/ticket/3438 > > > [0] https://aur.archlinux.org/packages/freeipa Why not use distutils to fill in the correct interpreter path (http://docs.python.org/2/distutils/setupscript.html#installing-scripts) instead of hardcoding it? -- Jan Cholasta From pviktori at redhat.com Thu Jan 2 08:58:55 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 02 Jan 2014 09:58:55 +0100 Subject: [Freeipa-devel] [PATCH 0027] Add config.h.in~ and rpmbuild to git ignore In-Reply-To: <1387821271.18952.5.camel@localhost.localdomain> References: <1387821271.18952.5.camel@localhost.localdomain> Message-ID: <52C52A4F.7090600@redhat.com> On 12/23/2013 06:54 PM, Nathaniel McCallum wrote: > Attached. config.in.h~ is a product of your specfific editor, right? You should add it to your personal ignore list, e.g. with: $ echo "*~" >> ~/.gitignore $ git config --global core.excludesfile ~/.gitignore As for rpmbuild, how is it generated? I don't think our makefile creates it, does it? If it does, I believe it would appear only in the root directory, in which case it should go in the "Root directory" section of .gitignore, start with a slash. Also it should end with a slash since it's a directory. -- Petr? From pviktori at redhat.com Thu Jan 2 11:37:49 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 02 Jan 2014 12:37:49 +0100 Subject: [Freeipa-devel] [PATCH] chenxiaolong-001 Use /usr/bin/python2 In-Reply-To: <52C517EF.5050607@redhat.com> References: <52B45BDB.8000803@redhat.com> <52C517EF.5050607@redhat.com> Message-ID: <52C54F8D.1050904@redhat.com> On 01/02/2014 08:40 AM, Jan Cholasta wrote: > On 20.12.2013 16:01, Petr Viktorin wrote: >> On some platforms, "/usr/bin/python" is Python 3. We require Python 2 so >> we should explicitly use /usr/bin/python2. >> >> Xiao-Long, who owns FreeIPA in Arch Linux's AUR [0], wrote a patch for >> this issue. I've just updated the patch to current master (so any >> breakage this causes is my fault). >> >> https://fedorahosted.org/freeipa/ticket/3438 >> >> >> [0] https://aur.archlinux.org/packages/freeipa > > Why not use distutils to fill in the correct interpreter path > (http://docs.python.org/2/distutils/setupscript.html#installing-scripts) That could be nice to do, at some time, in addition to this change. Do you want to file a ticket? > instead of hardcoding it? - Not all of FreeIPA uses distutils. Of course client-install should probably start using it, but distutils can't touch Makefiles or the spec file. - Having the proper path already available makes development a lot simpler than having complicated build machinery to call for each change. - To people unfamiliar with this aspect of distutils, it would not be obvious why/how the hashbang is changed on install. We need less magic in our build system, not more. - Relying on distutils makes FreeIPA tied to our build system, which other distros may or may not want to reuse. -- Petr? From jcholast at redhat.com Thu Jan 2 12:41:07 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 02 Jan 2014 13:41:07 +0100 Subject: [Freeipa-devel] [PATCH] chenxiaolong-001 Use /usr/bin/python2 In-Reply-To: <52C54F8D.1050904@redhat.com> References: <52B45BDB.8000803@redhat.com> <52C517EF.5050607@redhat.com> <52C54F8D.1050904@redhat.com> Message-ID: <52C55E63.9080008@redhat.com> On 2.1.2014 12:37, Petr Viktorin wrote: > On 01/02/2014 08:40 AM, Jan Cholasta wrote: >> On 20.12.2013 16:01, Petr Viktorin wrote: >>> On some platforms, "/usr/bin/python" is Python 3. We require Python 2 so >>> we should explicitly use /usr/bin/python2. >>> >>> Xiao-Long, who owns FreeIPA in Arch Linux's AUR [0], wrote a patch for >>> this issue. I've just updated the patch to current master (so any >>> breakage this causes is my fault). >>> >>> https://fedorahosted.org/freeipa/ticket/3438 >>> >>> >>> [0] https://aur.archlinux.org/packages/freeipa >> >> Why not use distutils to fill in the correct interpreter path >> (http://docs.python.org/2/distutils/setupscript.html#installing-scripts) > > That could be nice to do, at some time, in addition to this change. Do > you want to file a ticket? IMHO this should be done as part of the above ticket. > >> instead of hardcoding it? > > - Not all of FreeIPA uses distutils. Of course client-install should > probably start using it, but distutils can't touch Makefiles or the spec > file. That's obvious. We currently run setup.py from the Makefile, not the other way around, and I have no intention of changing that. Some modules are missing setup.py, but that should be easy to fix. > - Having the proper path already available makes development a lot > simpler than having complicated build machinery to call for each change. I'm not against a sane default value. > - To people unfamiliar with this aspect of distutils, it would not be > obvious why/how the hashbang is changed on install. We need less magic > in our build system, not more. This is no more magic than anything else done during build. We already use distutils for some of our script, which means these scripts will have their hashbang changed, while others won't. That's far more confusing than using distutils consistently across all of our scripts. > - Relying on distutils makes FreeIPA tied to our build system, which > other distros may or may not want to reuse. Why would anyone not use our Makefile to build IPA? If there's anything wrong or missing in it, it surely can be fixed. Creating a custom alternative build system does not make sense. -- Jan Cholasta From pviktori at redhat.com Thu Jan 2 13:32:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 02 Jan 2014 14:32:48 +0100 Subject: [Freeipa-devel] [PATCH] chenxiaolong-001 Use /usr/bin/python2 In-Reply-To: <52C55E63.9080008@redhat.com> References: <52B45BDB.8000803@redhat.com> <52C517EF.5050607@redhat.com> <52C54F8D.1050904@redhat.com> <52C55E63.9080008@redhat.com> Message-ID: <52C56A80.4010400@redhat.com> On 01/02/2014 01:41 PM, Jan Cholasta wrote: > On 2.1.2014 12:37, Petr Viktorin wrote: >> On 01/02/2014 08:40 AM, Jan Cholasta wrote: >>> On 20.12.2013 16:01, Petr Viktorin wrote: >>>> On some platforms, "/usr/bin/python" is Python 3. We require Python >>>> 2 so >>>> we should explicitly use /usr/bin/python2. >>>> >>>> Xiao-Long, who owns FreeIPA in Arch Linux's AUR [0], wrote a patch for >>>> this issue. I've just updated the patch to current master (so any >>>> breakage this causes is my fault). >>>> >>>> https://fedorahosted.org/freeipa/ticket/3438 >>>> >>>> >>>> [0] https://aur.archlinux.org/packages/freeipa >>> >>> Why not use distutils to fill in the correct interpreter path >>> (http://docs.python.org/2/distutils/setupscript.html#installing-scripts) >> >> That could be nice to do, at some time, in addition to this change. Do >> you want to file a ticket? > > IMHO this should be done as part of the above ticket. OK, we can keep the ticket open. This patch is then just a part of the work, but one for which we have a contribution from someone not in the regular FreeIPA team (even though it didn't come through the proper channels and needed some cleanup). I believe it's a step in the right direction, and it'll be useful even when the perfect solution is in place. >>> instead of hardcoding it? >> >> - Not all of FreeIPA uses distutils. Of course client-install should >> probably start using it, but distutils can't touch Makefiles or the spec >> file. > > That's obvious. We currently run setup.py from the Makefile, not the > other way around, and I have no intention of changing that. Some modules > are missing setup.py, but that should be easy to fix. > >> - Having the proper path already available makes development a lot >> simpler than having complicated build machinery to call for each change. > > I'm not against a sane default value. > >> - To people unfamiliar with this aspect of distutils, it would not be >> obvious why/how the hashbang is changed on install. We need less magic >> in our build system, not more. > > This is no more magic than anything else done during build. We already > use distutils for some of our script, which means these scripts will > have their hashbang changed, while others won't. That's far more > confusing than using distutils consistently across all of our scripts. > >> - Relying on distutils makes FreeIPA tied to our build system, which >> other distros may or may not want to reuse. > > Why would anyone not use our Makefile to build IPA? If there's anything > wrong or missing in it, it surely can be fixed. Creating a custom > alternative build system does not make sense. Fair points. If we agree this patch is an improvement, let's start building the bikeshed now. We'll get the color right in Beer Exchange. -- Petr? From mkosek at redhat.com Thu Jan 2 14:50:45 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 02 Jan 2014 15:50:45 +0100 Subject: [Freeipa-devel] [PATCH] 231 Prevent garbage from readline on standard output of dogtag-ipa-retrieve-agent In-Reply-To: <52B44749.3010004@redhat.com> References: <52AEF659.8040502@redhat.com> <52B44749.3010004@redhat.com> Message-ID: <52C57CC5.2080904@redhat.com> On 12/20/2013 02:34 PM, Petr Viktorin wrote: > On 12/16/2013 01:47 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> > > Looks good, thanks, ACK, pushed to master: > 1357eade4c5086e6c837a49f3008616317f88e5f > > Also pushed to ipa-3-3: 854dbb8ff9e898b289c9464567f141421880a050 Martin From mkosek at redhat.com Thu Jan 2 15:05:40 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 02 Jan 2014 16:05:40 +0100 Subject: [Freeipa-devel] [PATCH] chenxiaolong-001 Use /usr/bin/python2 In-Reply-To: <52C56A80.4010400@redhat.com> References: <52B45BDB.8000803@redhat.com> <52C517EF.5050607@redhat.com> <52C54F8D.1050904@redhat.com> <52C55E63.9080008@redhat.com> <52C56A80.4010400@redhat.com> Message-ID: <52C58044.5030703@redhat.com> On 01/02/2014 02:32 PM, Petr Viktorin wrote: > On 01/02/2014 01:41 PM, Jan Cholasta wrote: >> On 2.1.2014 12:37, Petr Viktorin wrote: ... >>>> instead of hardcoding it? >>> >>> - Not all of FreeIPA uses distutils. Of course client-install should >>> probably start using it, but distutils can't touch Makefiles or the spec >>> file. >> >> That's obvious. We currently run setup.py from the Makefile, not the >> other way around, and I have no intention of changing that. Some modules >> are missing setup.py, but that should be easy to fix. >> >>> - Having the proper path already available makes development a lot >>> simpler than having complicated build machinery to call for each change. >> >> I'm not against a sane default value. >> >>> - To people unfamiliar with this aspect of distutils, it would not be >>> obvious why/how the hashbang is changed on install. We need less magic >>> in our build system, not more. >> >> This is no more magic than anything else done during build. We already >> use distutils for some of our script, which means these scripts will >> have their hashbang changed, while others won't. That's far more >> confusing than using distutils consistently across all of our scripts. >> >>> - Relying on distutils makes FreeIPA tied to our build system, which >>> other distros may or may not want to reuse. >> >> Why would anyone not use our Makefile to build IPA? If there's anything >> wrong or missing in it, it surely can be fixed. Creating a custom >> alternative build system does not make sense. > > Fair points. > If we agree this patch is an improvement, let's start building the bikeshed > now. We'll get the color right in Beer Exchange. > +1. I would rather like the proposed patch pushed now (as it has immediate benefit) + have the build improvements filed in a separate ticket for the later time (Beer Exchange). Martin From jcholast at redhat.com Fri Jan 3 08:13:22 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 03 Jan 2014 09:13:22 +0100 Subject: [Freeipa-devel] [PATCH] chenxiaolong-001 Use /usr/bin/python2 In-Reply-To: <52C58044.5030703@redhat.com> References: <52B45BDB.8000803@redhat.com> <52C517EF.5050607@redhat.com> <52C54F8D.1050904@redhat.com> <52C55E63.9080008@redhat.com> <52C56A80.4010400@redhat.com> <52C58044.5030703@redhat.com> Message-ID: <52C67122.6090000@redhat.com> On 2.1.2014 16:05, Martin Kosek wrote: > On 01/02/2014 02:32 PM, Petr Viktorin wrote: >> On 01/02/2014 01:41 PM, Jan Cholasta wrote: >>> On 2.1.2014 12:37, Petr Viktorin wrote: > ... > >>>>> instead of hardcoding it? >>>> >>>> - Not all of FreeIPA uses distutils. Of course client-install should >>>> probably start using it, but distutils can't touch Makefiles or the spec >>>> file. >>> >>> That's obvious. We currently run setup.py from the Makefile, not the >>> other way around, and I have no intention of changing that. Some modules >>> are missing setup.py, but that should be easy to fix. >>> >>>> - Having the proper path already available makes development a lot >>>> simpler than having complicated build machinery to call for each change. >>> >>> I'm not against a sane default value. >>> >>>> - To people unfamiliar with this aspect of distutils, it would not be >>>> obvious why/how the hashbang is changed on install. We need less magic >>>> in our build system, not more. >>> >>> This is no more magic than anything else done during build. We already >>> use distutils for some of our script, which means these scripts will >>> have their hashbang changed, while others won't. That's far more >>> confusing than using distutils consistently across all of our scripts. >>> >>>> - Relying on distutils makes FreeIPA tied to our build system, which >>>> other distros may or may not want to reuse. >>> >>> Why would anyone not use our Makefile to build IPA? If there's anything >>> wrong or missing in it, it surely can be fixed. Creating a custom >>> alternative build system does not make sense. >> >> Fair points. >> If we agree this patch is an improvement, let's start building the bikeshed >> now. We'll get the color right in Beer Exchange. >> > > +1. I would rather like the proposed patch pushed now (as it has immediate > benefit) + have the build improvements filed in a separate ticket for the later > time (Beer Exchange). > > Martin > ACK -- Jan Cholasta From mkosek at redhat.com Fri Jan 3 08:50:30 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Jan 2014 09:50:30 +0100 Subject: [Freeipa-devel] [PATCH] chenxiaolong-001 Use /usr/bin/python2 In-Reply-To: <52C67122.6090000@redhat.com> References: <52B45BDB.8000803@redhat.com> <52C517EF.5050607@redhat.com> <52C54F8D.1050904@redhat.com> <52C55E63.9080008@redhat.com> <52C56A80.4010400@redhat.com> <52C58044.5030703@redhat.com> <52C67122.6090000@redhat.com> Message-ID: <52C679D6.8080404@redhat.com> On 01/03/2014 09:13 AM, Jan Cholasta wrote: > On 2.1.2014 16:05, Martin Kosek wrote: >> On 01/02/2014 02:32 PM, Petr Viktorin wrote: >>> On 01/02/2014 01:41 PM, Jan Cholasta wrote: >>>> On 2.1.2014 12:37, Petr Viktorin wrote: >> ... >> >>>>>> instead of hardcoding it? >>>>> >>>>> - Not all of FreeIPA uses distutils. Of course client-install should >>>>> probably start using it, but distutils can't touch Makefiles or the spec >>>>> file. >>>> >>>> That's obvious. We currently run setup.py from the Makefile, not the >>>> other way around, and I have no intention of changing that. Some modules >>>> are missing setup.py, but that should be easy to fix. >>>> >>>>> - Having the proper path already available makes development a lot >>>>> simpler than having complicated build machinery to call for each change. >>>> >>>> I'm not against a sane default value. >>>> >>>>> - To people unfamiliar with this aspect of distutils, it would not be >>>>> obvious why/how the hashbang is changed on install. We need less magic >>>>> in our build system, not more. >>>> >>>> This is no more magic than anything else done during build. We already >>>> use distutils for some of our script, which means these scripts will >>>> have their hashbang changed, while others won't. That's far more >>>> confusing than using distutils consistently across all of our scripts. >>>> >>>>> - Relying on distutils makes FreeIPA tied to our build system, which >>>>> other distros may or may not want to reuse. >>>> >>>> Why would anyone not use our Makefile to build IPA? If there's anything >>>> wrong or missing in it, it surely can be fixed. Creating a custom >>>> alternative build system does not make sense. >>> >>> Fair points. >>> If we agree this patch is an improvement, let's start building the bikeshed >>> now. We'll get the color right in Beer Exchange. >>> >> >> +1. I would rather like the proposed patch pushed now (as it has immediate >> benefit) + have the build improvements filed in a separate ticket for the later >> time (Beer Exchange). >> >> Martin >> > > ACK Pushed to master. Thanks to Xiao-Long for the patch, all work on porting FreeIPA to other platforms is very welcome! Jan, please feel free to file a ticket with build system proposals you stated above. Thanks, Martin From pvoborni at redhat.com Fri Jan 3 11:38:26 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 03 Jan 2014 12:38:26 +0100 Subject: [Freeipa-devel] [PATCH] 463-530 First part of RCUE adoption In-Reply-To: <5298BAB3.4030108@redhat.com> References: <528620F5.3010206@redhat.com> <52937156.6070303@redhat.com> <52989A5D.1030405@redhat.com> <5298BAB3.4030108@redhat.com> Message-ID: <52C6A132.7000701@redhat.com> On 29.11.2013 17:02, Ana Krivokapic wrote: > On 11/29/2013 02:45 PM, Ana Krivokapic wrote: >> >On 11/25/2013 04:48 PM, Ana Krivokapic wrote: >>> >>On 11/15/2013 02:26 PM, Petr Vobornik wrote: >>>> >>>Hello list, >>>> >>> >>>> >>>this is a first part of RCUE adoption effort. Main themes of this patch set are: >>>> >>> >>>> >>>- use RCUE navigation >>>> >>>- new styles for textboxes, textareas, radio/checkbox buttons and buttons- >>>> >>>part of >>>> >>>- new internal form layout (tables replaced by divs) >>>> >>>- layout does not have fixed size >>>> >>>- new dialog styles + removed dependency on jQuery UI dialog >>>> >>>- icons replaced by Font Awesome glyphs >>>> >>> >>>> >>>Example is at: >>>> >>> >>>> >>>Some reasonings and additional info: >>>> >>> >>>> >>>1. RCUE includes Bootstrap which defines o lot of styles for a lot of things. >>>> >>>That messed up the UI and therefore I did the form changes now. >>>> >>> >>>> >>>2. jQuery UI is pretty big lib and we used it only for dialog and buttons. >>>> >>>Buttons were replaced by RCUE buttons so removal of dialog dependency was a >>>> >>>obvious step to get rid of the whole lib. The lib is removed from main UI but >>>> >>>is still present in separate pages - will be removed later. >>>> >>> >>>> >>>3. Dojo and jQuery were upgraded to latest >>>> >>>versions. >>>> >>> >>>> >>>This approach was ACKed by Kyle from a design perspective with a note that we >>>> >>>will review and fixed some styling after second phase. We should not release >>>> >>>until then. >>>> >>> >>>> >>>The second phase, which I'm working on right now, will consist of: >>>> >>> * login screen >>>> >>> * new styles for standalone pages >>>> >>> * necessary responsive enhancement (the ultimate future goal is responsive >>>> >>>layout) >>>> >>> >>>> >>>It's quite a lot of patches so I did not attach them here. You can see the >>>> >>>code in my private repo: branch >>>> >>>'rcue'. >>> >>I tested this phase of RCUE adoption effort, overall it looks and works great. A >>> >>couple of findings: >>> >> >>> >>1) Two ui integration tests are failing, I guess this is due to the re-arranging >>> >>of elements on the automember page. So the tests should be amended to reflect >>> >>that change. > Commit ee4f6540490a16f0fbb5cdd02097a9b3ff354252 works around the navigation > issue which caused tests to fail. ACK. > I've unbundled font files from FreeIPA Web UI - Open Sans will be in new fedora package - open-sans-fonts - Font Awesome as well - fontawesome-fonts - Overpass fonts are no longer used Branch rcue-fonts-unbundled git://fedorapeople.org/home/fedora/pvoborni/public_git/freeipa.git contains the changes. It's 6 additional commits on top of the reviewed rcue branch. 5 commits were squashed in order to reduce size of the final push. Attaching all of the patches for reference. open-sans-fonts and fontawesome-fonts Fedora packages are still on review: - https://bugzilla.redhat.com/show_bug.cgi?id=1035897 - https://bugzilla.redhat.com/show_bug.cgi?id=1026376 Reviewer for open-sans-fonts needed. OTP UI will be rebased on top of this effort. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: fonts-unbundled.tar.xz Type: application/x-xz Size: 1074756 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jan 3 11:51:59 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 03 Jan 2014 12:51:59 +0100 Subject: [Freeipa-devel] FreeIPA OTP End-to-End In-Reply-To: <923551694.401659.1387792475165.JavaMail.root@redhat.com> References: <1386968251.1948.25.camel@localhost.localdomain> <52AB8E08.5000102@redhat.com> <923551694.401659.1387792475165.JavaMail.root@redhat.com> Message-ID: <52C6A45F.5020601@redhat.com> On 23.12.2013 10:54, Alexander Bokovoy wrote: > > > ----- Original Message ----- >> From: "Dmitri Pal" >> To: freeipa-devel at redhat.com >> Sent: Saturday, December 14, 2013 12:45:28 AM >> Subject: Re: [Freeipa-devel] FreeIPA OTP End-to-End >> >> On 12/13/2013 03:57 PM, Nathaniel McCallum wrote: >>> This is an email to track the status of the OTP project as we push >>> toward completion. I'm also attempting to get all the pieces in play so >>> that they are testable. >>> >>> RPMs >>> Available here: http://npmccallum.fedorapeople.org/freeipa-otp/rpms/ >>> These currently contain the CLI and UI patches, but exclude the DS >>> plugin patch. I will merge this last patch in when submitted to the >>> list. >>> >>> OTP CLI >>> All of the patches are merged except npmccallum-0024, which is >>> undergoing active review. >>> https://www.redhat.com/archives/freeipa-devel/2013-December/msg00102.html >>> >>> OTP UI >>> Thanks to Petr Vobornik for his set of patches implementing the UI. They >>> can be found rebased on top of my otp changes here: >>> https://github.com/npmccallum/freeipa/commits/otpui >>> >>> Authentication methods and RADIUS proxy support seems to be fully >>> functional and I have not encountered any bugs. I'm not currently able >>> to get the OTP UI to show up at all (I may well be doing something >>> wrong). >>> >>> I believe Petr plans to clean these up and resubmit them to the list. >>> >>> One additional patch will be required for the token sync extop. >>> >>> DS PLUGIN >>> I am nearing completion on the DS plugin providing support for deletion >>> protection and the token sync extop. This should hit the list next week. >>> >>> OTHER >>> Am I missing anything? >> >> Did you update the wiki page? I think it was one of the outstanding items. >> Any unit tests? >> Any way to include some testes for Continues Integration? >> Anything SELinux related? >> Default configuration of locations and names of sockets and files? >> Things like that. > I've fixed Web UI and have it working now. Patch attached. Thanks for the patch. I'll clean up and rebase the OTP UI patches on top of the RCUE effort. -- Petr Vobornik From pviktori at redhat.com Fri Jan 3 12:13:57 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 03 Jan 2014 13:13:57 +0100 Subject: [Freeipa-devel] [PATCH] 0347 cli.print_attribute: Convert values to strings Message-ID: <52C6A985.4000008@redhat.com> Hello, Recently I've been generating test plans on the wiki from our Declarative tests. This patch allows me to call output_for_cli directly on the `expected` output in tests. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0347-cli.print_attribute-Convert-values-to-strings.patch Type: text/x-patch Size: 1111 bytes Desc: not available URL: From mkosek at redhat.com Fri Jan 3 12:56:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Jan 2014 13:56:53 +0100 Subject: [Freeipa-devel] [PATCH] 443 Increase Java stack size on s390 platforms Message-ID: <52C6B395.9090101@redhat.com> As reported in https://bugzilla.redhat.com/show_bug.cgi?id=1040576, the default stack trace needs to be also increased on s390 platforms to prevent rhino segfault. ---- Pushed as a one-liner (verified in Bugzilla) to master, ipa-3-3. Rawhide and F20 builds were kicked off as well. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-443-increase-java-stack-size-on-s390-platforms.patch Type: text/x-patch Size: 1065 bytes Desc: not available URL: From mkosek at redhat.com Fri Jan 3 13:12:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Jan 2014 14:12:19 +0100 Subject: [Freeipa-devel] [PATCH] 0347 cli.print_attribute: Convert values to strings In-Reply-To: <52C6A985.4000008@redhat.com> References: <52C6A985.4000008@redhat.com> Message-ID: <52C6B733.70409@redhat.com> On 01/03/2014 01:13 PM, Petr Viktorin wrote: > Hello, > Recently I've been generating test plans on the wiki from our Declarative tests. > This patch allows me to call output_for_cli directly on the `expected` output > in tests. Worked fine. ACK. Pushed to master. Martin From mkosek at redhat.com Fri Jan 3 15:44:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Jan 2014 16:44:38 +0100 Subject: [Freeipa-devel] [PATCH] 0344-0345 Allow anonymous and all permissions In-Reply-To: <52AEE828.6010102@redhat.com> References: <52AEE828.6010102@redhat.com> Message-ID: <52C6DAE6.6000002@redhat.com> On 12/16/2013 12:46 PM, Petr Viktorin wrote: > Hello, > The next step in permission effort is small since the groundwork is already done. > > This adds API/CLI for anonymous&all permissions, and disables adding these to > privileges. > > Ticket: https://fedorahosted.org/freeipa/ticket/4032 > Design: http://www.freeipa.org/page/V3/Anonymous_and_All_permissions > This looks strange # ipa permission-add anon --type=user --permissions=read --attrs=description --bindtype=anonymous # ipa privilege-add-permission foo --perm=ipa: ERROR: invalid 'permission': cannot add permission "anon" with bindtype "anonymous" to a privilege (I know, I am nitpicking again). Otherwise I think the patch is OK. Martin From pviktori at redhat.com Mon Jan 6 10:13:05 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 06 Jan 2014 11:13:05 +0100 Subject: [Freeipa-devel] [PATCHES] 0337-0343 YAML test configuration In-Reply-To: <52A9A0A9.9040706@redhat.com> References: <52A9A0A9.9040706@redhat.com> Message-ID: <52CA81B1.4040602@redhat.com> On 12/12/2013 12:40 PM, Petr Viktorin wrote: > Hello Tom??! I'm planning a little Christmas present for you. Instead of > a surprise I'm Releasing early :) > Apply patches or: git pull http://github.com/encukou/freeipa yaml-config > > > These patches add YAML/JSON configuration for tests. > > YAML/JSON is completely optional, the existing envvar style continues to > work. The ipa-test-config tool can convert between the two (which is not > just for show, export will be needed for debugging and unit tests). > If you choose to use YAML, you need PyYAML (python-yaml) installed. > > > Example: > > $ MASTER=master.ipa.test REPLICA=repl.ipa.test > TESTHOST_XYZ_env1=xyz.ipa.test BEAKERMASTER1_IP_env1=1.2.3.4 > BEAKERREPLICA1_IP_env1=1.2.3.5 BEAKERXYZ1_IP_env1=1.2.3.6 > ipa-test-config --global --yaml | tee /tmp/testconf.yaml > ad_admin_name: Administrator > ad_admin_password: Secret123 > admin_name: admin > admin_password: Secret123 > debug: false > dirman_dn: cn=Directory Manager > dirman_password: Secret123 > dns_forwarder: 8.8.8.8 > domains: > - hosts: > master: > external_hostname: master.ipa.test > ip: 1.2.3.4 > role: master > repl: > external_hostname: repl.ipa.test > ip: 1.2.3.5 > role: replica > xyz: > external_hostname: xyz.ipa.test > ip: 1.2.3.6 > role: xyz > name: ipa.test > type: IPA > ipv6: false > nis_domain: ipatest > ntp_server: 2.pool.ntp.org > root_password: null > root_ssh_key_filename: ~/.ssh/id_rsa > test_dir: /root/ipatests > > $ IPATEST_YAML_CONFIG=/tmp/testconf.yaml ipa-run-tests ... > > > > What's left is to update the design and write tests. I'll get to it > eventually, but now I'll probably be busy for a few days. If you'd like > to do them as part of review, tests could be in the format: > > from ipatests.test_integration import config > conf = config.Config.from_env($environment) > assert conf.to_dict() == {$result} > > conf = config.Config.from_dict($inputdict) > assert conf.to_dict() == {$result} > > > https://fedorahosted.org/freeipa/ticket/3938 Tests added, new version attached. As for #4081 (Export dynamic roles properly in ipa-test-config), hosts are exported like static roles are (from the TestComplexConfig case): TESTHOST_EXTRAROLEM_env1="extram1.ipadomain.test extram2.ipadomain.test", TESTHOST_EXTRAROLEM1_env1="extram1.ipadomain.test" TESTHOST_EXTRAROLEM2_env1="extram2.ipadomain.test" For cases where there's just a single host of the role, it'll export it both with the number and without. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0337.2-test_integration.config-Fix-crash-in-to_env-when-no-.patch Type: text/x-patch Size: 2357 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0338.2-test_integration.config-Do-not-save-the-input-enviro.patch Type: text/x-patch Size: 5588 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0339.2-test_integration.config-Use-a-more-declarative-appro.patch Type: text/x-patch Size: 7368 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0340.2-test_integration.config-Do-not-store-the-index-in-Do.patch Type: text/x-patch Size: 8601 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0341.2-test_integration.config-Load-store-from-to-dicts.patch Type: text/x-patch Size: 6299 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0342.2-test_integration.config-Add-environment-variables-fo.patch Type: text/x-patch Size: 1953 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0343.2-ipa-test-config-Add-json-and-yaml-output-options.patch Type: text/x-patch Size: 3905 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0348.2-test_integration.config-Convert-some-text-values-to-.patch Type: text/x-patch Size: 3098 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0349.2-Add-tests-for-integration-test-configuration.patch Type: text/x-patch Size: 17460 bytes Desc: not available URL: From tbabej at redhat.com Mon Jan 6 11:16:18 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 06 Jan 2014 12:16:18 +0100 Subject: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal In-Reply-To: <516BD9D6.6020800@redhat.com> References: <511A72D9.6090506@redhat.com> <511A75F0.7070801@redhat.com> <1360689791.3838.56.camel@willson.li.ssimo.org> <511B8632.7000709@redhat.com> <5159E560.6030603@redhat.com> <5162CC60.8040008@redhat.com> <516BD9D6.6020800@redhat.com> Message-ID: <52CA9082.3000000@redhat.com> On 04/15/2013 12:43 PM, Tomas Babej wrote: > On 04/08/2013 03:55 PM, Martin Kosek wrote: >> On 04/01/2013 09:52 PM, Rob Crittenden wrote: >>> Tomas Babej wrote: >>>> On 02/12/2013 06:23 PM, Simo Sorce wrote: >>>>> On Tue, 2013-02-12 at 18:03 +0100, Tomas Babej wrote: >>>>>> On 02/12/2013 05:50 PM, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> This patch adds a check for krbprincipalexpiration attribute to >>>>>>> pre_bind operation >>>>>>> in ipa-pwd-extop dirsrv plugin. If the principal is expired, >>>>>>> auth is >>>>>>> denied and LDAP_INVALID_CREDENTIALS along with the error message is >>>>>>> sent back to the client. Since krbprincipalexpiration attribute is >>>>>> not >>>>>>> mandatory, if there is no value set, the check is passed. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3305 >>>>> Comments inline. >>>>>> @@ -1166,6 +1173,29 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >>>>>> goto done; >>>>>> } >>>>>> + /* check the krbPrincipalExpiration attribute is present */ >>>>>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>>>>> &attr); >>>>>> + if (!ret) { >>>>> ret is not a boolean so probably better ti use (ret != 0) >>>>> >>>>>> + /* if it is, check whether the principal has not expired */ >>>>>> + >>>>>> + principal_expire = slapi_entry_attr_get_charptr(entry, >>>>>> + "krbprincipalexpiration"); >>>>>> + memset(&expire_tm, 0, sizeof (expire_tm)); >>>>>> + >>>>>> + if (strptime(principal_expire, "%Y%m%d%H%M%SZ", >>>>>> &expire_tm)){ >>>>> style issue missing space between ) and { >>>>> >>>>>> + expire_time = mktime(&expire_tm); >>>>>> + /* this might have overflown on 32-bit system */ >>>>> This comment does not help to point out what you want to put in >>>>> evidence. >>>>> if there is an overflow what is the consequence ? Or does it mean the >>>>> next condition is taking that into account ? >>>> Yeah, this was rather ill-worded. Replaced by a rather verbose >>>> comment that hopefully clears things out. >>>>>> + if (current_time > expire_time && expire_time > 0){ >>>>> style issue missing space between ) and { >>>>> >>>>>> + LOG_FATAL("kerberos principal has expired in user >>>>>> entry: %s\n", >>>>>> + dn); >>>>> I think a better phrasing would be: "The kerberos principal on %s is >>>>> expired\n" >>>>> >>>>>> + errMesg = "Kerberos principal has expired."; >>>>> s/has/is/ >>>>> >>>>> The rest looks good to me. >>>>> >>>>> Simo. >>>> Styling issues fixed and updated patch attached :) >>> Small nit, the expiration error should probably use 'in' not 'on'. >>> >>> I'm not sure LDAP_INVALID_CREDENTIALS is the right return code. This >>> implies >>> that the password is wrong. I think that LDAP_UNWILLING_TO_PERFORM >>> is probably >>> more correct here. It is what we return on other policy failures. >>> >>> rob >>> >> Additional findings: >> >> 1) Lets not try to get current_time every time, but only when its >> needed (i.e. >> krbPrincipalExpiration is set) - AFAIK, it is not so cheap operation: >> >> + /* get current time*/ >> + current_time = time(NULL); >> >> 2) Why using slapi_entry_attr_get_charptr and thus let 389-ds find the >> attribute again when we already have a pointer for the attribute? Would >> slapi_attr_first_value following slapi_entry_attr_find be faster >> approach? >> >> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >> &attr); >> + if (ret != 0) { >> + /* if it is, check whether the principal has not expired */ >> + >> + principal_expire = slapi_entry_attr_get_charptr(entry, >> + "krbprincipalexpiration"); >> >> This way, we would not create a copy of this attribute value - we do >> not need a >> copy, we just do check against it. >> >> >> 3) Shouldn't we return -1 in the end when the auth fails? We do that >> in other >> pre_callbacks. Otherwise we just return 0 (success): >> >> + if (auth_failed){ >> + slapi_send_ldap_result(pb, LDAP_INVALID_CREDENTIALS, NULL, >> errMesg, >> + 0, NULL); >> + } >> + >> return 0; >> >> Martin > > Thank you both for the review. I updated and retested the patch, with > your suggestions incorporated. > > Tomas > I rebased the patch on top of current master. Bumping, since this is planned as part of 3.4 (and there were some requests for this feature). Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0034-5-Deny-LDAP-binds-for-user-accounts-with-expired-princ.patch Type: text/x-patch Size: 4216 bytes Desc: not available URL: From tbabej at redhat.com Mon Jan 6 11:21:37 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 06 Jan 2014 12:21:37 +0100 Subject: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal In-Reply-To: <52CA9082.3000000@redhat.com> References: <511A72D9.6090506@redhat.com> <511A75F0.7070801@redhat.com> <1360689791.3838.56.camel@willson.li.ssimo.org> <511B8632.7000709@redhat.com> <5159E560.6030603@redhat.com> <5162CC60.8040008@redhat.com> <516BD9D6.6020800@redhat.com> <52CA9082.3000000@redhat.com> Message-ID: <52CA91C1.3070804@redhat.com> On 01/06/2014 12:16 PM, Tomas Babej wrote: > On 04/15/2013 12:43 PM, Tomas Babej wrote: >> On 04/08/2013 03:55 PM, Martin Kosek wrote: >>> On 04/01/2013 09:52 PM, Rob Crittenden wrote: >>>> Tomas Babej wrote: >>>>> On 02/12/2013 06:23 PM, Simo Sorce wrote: >>>>>> On Tue, 2013-02-12 at 18:03 +0100, Tomas Babej wrote: >>>>>>> On 02/12/2013 05:50 PM, Tomas Babej wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> This patch adds a check for krbprincipalexpiration attribute to >>>>>>>> pre_bind operation >>>>>>>> in ipa-pwd-extop dirsrv plugin. If the principal is expired, >>>>>>>> auth is >>>>>>>> denied and LDAP_INVALID_CREDENTIALS along with the error message is >>>>>>>> sent back to the client. Since krbprincipalexpiration attribute is >>>>>>> not >>>>>>>> mandatory, if there is no value set, the check is passed. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3305 >>>>>> Comments inline. >>>>>>> @@ -1166,6 +1173,29 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >>>>>>> goto done; >>>>>>> } >>>>>>> + /* check the krbPrincipalExpiration attribute is present */ >>>>>>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>>>>>> &attr); >>>>>>> + if (!ret) { >>>>>> ret is not a boolean so probably better ti use (ret != 0) >>>>>> >>>>>>> + /* if it is, check whether the principal has not expired */ >>>>>>> + >>>>>>> + principal_expire = slapi_entry_attr_get_charptr(entry, >>>>>>> + "krbprincipalexpiration"); >>>>>>> + memset(&expire_tm, 0, sizeof (expire_tm)); >>>>>>> + >>>>>>> + if (strptime(principal_expire, "%Y%m%d%H%M%SZ", >>>>>>> &expire_tm)){ >>>>>> style issue missing space between ) and { >>>>>> >>>>>>> + expire_time = mktime(&expire_tm); >>>>>>> + /* this might have overflown on 32-bit system */ >>>>>> This comment does not help to point out what you want to put in >>>>>> evidence. >>>>>> if there is an overflow what is the consequence ? Or does it mean the >>>>>> next condition is taking that into account ? >>>>> Yeah, this was rather ill-worded. Replaced by a rather verbose >>>>> comment that hopefully clears things out. >>>>>>> + if (current_time > expire_time && expire_time > 0){ >>>>>> style issue missing space between ) and { >>>>>> >>>>>>> + LOG_FATAL("kerberos principal has expired in user >>>>>>> entry: %s\n", >>>>>>> + dn); >>>>>> I think a better phrasing would be: "The kerberos principal on %s is >>>>>> expired\n" >>>>>> >>>>>>> + errMesg = "Kerberos principal has expired."; >>>>>> s/has/is/ >>>>>> >>>>>> The rest looks good to me. >>>>>> >>>>>> Simo. >>>>> Styling issues fixed and updated patch attached :) >>>> Small nit, the expiration error should probably use 'in' not 'on'. >>>> >>>> I'm not sure LDAP_INVALID_CREDENTIALS is the right return code. This >>>> implies >>>> that the password is wrong. I think that LDAP_UNWILLING_TO_PERFORM >>>> is probably >>>> more correct here. It is what we return on other policy failures. >>>> >>>> rob >>>> >>> Additional findings: >>> >>> 1) Lets not try to get current_time every time, but only when its >>> needed (i.e. >>> krbPrincipalExpiration is set) - AFAIK, it is not so cheap operation: >>> >>> + /* get current time*/ >>> + current_time = time(NULL); >>> >>> 2) Why using slapi_entry_attr_get_charptr and thus let 389-ds find the >>> attribute again when we already have a pointer for the attribute? Would >>> slapi_attr_first_value following slapi_entry_attr_find be faster >>> approach? >>> >>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>> &attr); >>> + if (ret != 0) { >>> + /* if it is, check whether the principal has not expired */ >>> + >>> + principal_expire = slapi_entry_attr_get_charptr(entry, >>> + "krbprincipalexpiration"); >>> >>> This way, we would not create a copy of this attribute value - we do >>> not need a >>> copy, we just do check against it. >>> >>> >>> 3) Shouldn't we return -1 in the end when the auth fails? We do that >>> in other >>> pre_callbacks. Otherwise we just return 0 (success): >>> >>> + if (auth_failed){ >>> + slapi_send_ldap_result(pb, LDAP_INVALID_CREDENTIALS, NULL, >>> errMesg, >>> + 0, NULL); >>> + } >>> + >>> return 0; >>> >>> Martin >> Thank you both for the review. I updated and retested the patch, with >> your suggestions incorporated. >> >> Tomas >> > I rebased the patch on top of current master. > > Bumping, since this is planned as part of 3.4 (and there were some > requests for this feature). > > Tomas > I updated the commit message to reflect better what the current version of the patch implements. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0034-6-ipa-pwd-extop-Deny-LDAP-binds-for-user-accounts-with.patch Type: text/x-patch Size: 4233 bytes Desc: not available URL: From pviktori at redhat.com Mon Jan 6 12:26:24 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 06 Jan 2014 13:26:24 +0100 Subject: [Freeipa-devel] [PATCH] 0344-0345 Allow anonymous and all permissions In-Reply-To: <52C6DAE6.6000002@redhat.com> References: <52AEE828.6010102@redhat.com> <52C6DAE6.6000002@redhat.com> Message-ID: <52CAA0F0.7090409@redhat.com> On 01/03/2014 04:44 PM, Martin Kosek wrote: > On 12/16/2013 12:46 PM, Petr Viktorin wrote: >> Hello, >> The next step in permission effort is small since the groundwork is already done. >> >> This adds API/CLI for anonymous&all permissions, and disables adding these to >> privileges. >> >> Ticket: https://fedorahosted.org/freeipa/ticket/4032 >> Design: http://www.freeipa.org/page/V3/Anonymous_and_All_permissions >> > > This looks strange > > # ipa permission-add anon --type=user --permissions=read --attrs=description > --bindtype=anonymous > > # ipa privilege-add-permission foo --perm= > ipa: ERROR: invalid 'permission': > cannot add permission "anon" with bindtype "anonymous" to a privilege > > (I know, I am nitpicking again). > > Otherwise I think the patch is OK. > > Martin Good catch, thanks. Updated patches attached. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0344.2-Use-new-registration-API-in-the-privilege-plugin.patch Type: text/x-patch Size: 2919 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0345.2-Allow-anonymous-and-all-permissions.patch Type: text/x-patch Size: 19016 bytes Desc: not available URL: From abokovoy at redhat.com Tue Jan 7 06:23:28 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 7 Jan 2014 08:23:28 +0200 Subject: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal In-Reply-To: <52CA91C1.3070804@redhat.com> References: <511A72D9.6090506@redhat.com> <511A75F0.7070801@redhat.com> <1360689791.3838.56.camel@willson.li.ssimo.org> <511B8632.7000709@redhat.com> <5159E560.6030603@redhat.com> <5162CC60.8040008@redhat.com> <516BD9D6.6020800@redhat.com> <52CA9082.3000000@redhat.com> <52CA91C1.3070804@redhat.com> Message-ID: <20140107062328.GE12003@redhat.com> On Mon, 06 Jan 2014, Tomas Babej wrote: > >On 01/06/2014 12:16 PM, Tomas Babej wrote: >> On 04/15/2013 12:43 PM, Tomas Babej wrote: >>> On 04/08/2013 03:55 PM, Martin Kosek wrote: >>>> On 04/01/2013 09:52 PM, Rob Crittenden wrote: >>>>> Tomas Babej wrote: >>>>>> On 02/12/2013 06:23 PM, Simo Sorce wrote: >>>>>>> On Tue, 2013-02-12 at 18:03 +0100, Tomas Babej wrote: >>>>>>>> On 02/12/2013 05:50 PM, Tomas Babej wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> This patch adds a check for krbprincipalexpiration attribute to >>>>>>>>> pre_bind operation >>>>>>>>> in ipa-pwd-extop dirsrv plugin. If the principal is expired, >>>>>>>>> auth is >>>>>>>>> denied and LDAP_INVALID_CREDENTIALS along with the error message is >>>>>>>>> sent back to the client. Since krbprincipalexpiration attribute is >>>>>>>> not >>>>>>>>> mandatory, if there is no value set, the check is passed. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3305 >>>>>>> Comments inline. >>>>>>>> @@ -1166,6 +1173,29 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >>>>>>>> goto done; >>>>>>>> } >>>>>>>> + /* check the krbPrincipalExpiration attribute is present */ >>>>>>>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>>>>>>> &attr); >>>>>>>> + if (!ret) { >>>>>>> ret is not a boolean so probably better ti use (ret != 0) >>>>>>> >>>>>>>> + /* if it is, check whether the principal has not expired */ >>>>>>>> + >>>>>>>> + principal_expire = slapi_entry_attr_get_charptr(entry, >>>>>>>> + "krbprincipalexpiration"); >>>>>>>> + memset(&expire_tm, 0, sizeof (expire_tm)); >>>>>>>> + >>>>>>>> + if (strptime(principal_expire, "%Y%m%d%H%M%SZ", >>>>>>>> &expire_tm)){ >>>>>>> style issue missing space between ) and { >>>>>>> >>>>>>>> + expire_time = mktime(&expire_tm); >>>>>>>> + /* this might have overflown on 32-bit system */ >>>>>>> This comment does not help to point out what you want to put in >>>>>>> evidence. >>>>>>> if there is an overflow what is the consequence ? Or does it mean the >>>>>>> next condition is taking that into account ? >>>>>> Yeah, this was rather ill-worded. Replaced by a rather verbose >>>>>> comment that hopefully clears things out. >>>>>>>> + if (current_time > expire_time && expire_time > 0){ >>>>>>> style issue missing space between ) and { >>>>>>> >>>>>>>> + LOG_FATAL("kerberos principal has expired in user >>>>>>>> entry: %s\n", >>>>>>>> + dn); >>>>>>> I think a better phrasing would be: "The kerberos principal on %s is >>>>>>> expired\n" >>>>>>> >>>>>>>> + errMesg = "Kerberos principal has expired."; >>>>>>> s/has/is/ >>>>>>> >>>>>>> The rest looks good to me. >>>>>>> >>>>>>> Simo. >>>>>> Styling issues fixed and updated patch attached :) >>>>> Small nit, the expiration error should probably use 'in' not 'on'. >>>>> >>>>> I'm not sure LDAP_INVALID_CREDENTIALS is the right return code. This >>>>> implies >>>>> that the password is wrong. I think that LDAP_UNWILLING_TO_PERFORM >>>>> is probably >>>>> more correct here. It is what we return on other policy failures. >>>>> >>>>> rob >>>>> >>>> Additional findings: >>>> >>>> 1) Lets not try to get current_time every time, but only when its >>>> needed (i.e. >>>> krbPrincipalExpiration is set) - AFAIK, it is not so cheap operation: >>>> >>>> + /* get current time*/ >>>> + current_time = time(NULL); >>>> >>>> 2) Why using slapi_entry_attr_get_charptr and thus let 389-ds find the >>>> attribute again when we already have a pointer for the attribute? Would >>>> slapi_attr_first_value following slapi_entry_attr_find be faster >>>> approach? >>>> >>>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>>> &attr); >>>> + if (ret != 0) { >>>> + /* if it is, check whether the principal has not expired */ >>>> + >>>> + principal_expire = slapi_entry_attr_get_charptr(entry, >>>> + "krbprincipalexpiration"); >>>> >>>> This way, we would not create a copy of this attribute value - we do >>>> not need a >>>> copy, we just do check against it. >>>> >>>> >>>> 3) Shouldn't we return -1 in the end when the auth fails? We do that >>>> in other >>>> pre_callbacks. Otherwise we just return 0 (success): >>>> >>>> + if (auth_failed){ >>>> + slapi_send_ldap_result(pb, LDAP_INVALID_CREDENTIALS, NULL, >>>> errMesg, >>>> + 0, NULL); >>>> + } >>>> + >>>> return 0; >>>> >>>> Martin >>> Thank you both for the review. I updated and retested the patch, with >>> your suggestions incorporated. >>> >>> Tomas >>> >> I rebased the patch on top of current master. >> >> Bumping, since this is planned as part of 3.4 (and there were some >> requests for this feature). >> >> Tomas >> > >I updated the commit message to reflect better what the current version >of the patch implements. > >Tomas >>From a93d1ec3ca8c7b6e8e754b474257695ba9018e07 Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Mon, 6 Jan 2014 12:11:24 +0100 >Subject: [PATCH] ipa-pwd-extop: Deny LDAP binds for user accounts with expired > principal > >Adds a check for krbprincipalexpiration attribute to pre_bind operation >in ipa-pwd-extop dirsrv plugin. If the principal is expired, auth is >denied and LDAP_UNWILLING_TO_PERFORM along with the error message is >sent back to the client. Since krbprincipalexpiration attribute is not >mandatory, if there is no value set, the check is passed. > >https://fedorahosted.org/freeipa/ticket/3305 >--- > daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 45 ++++++++++++++++++++++- > 1 file changed, 44 insertions(+), 1 deletion(-) > >diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >index ef37b5e173359f9404b241c12d8a6dc6e77da128..568cba7189d1575d030b043daee61f713e9bac5f 100644 >--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >@@ -1389,13 +1389,17 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) > Slapi_Value *value = NULL; > Slapi_Attr *attr = NULL; > struct tm expire_tm; >+ time_t current_time; >+ time_t expire_time; > char *errMesg = "Internal operations error\n"; /* error message */ > char *expire = NULL; /* passwordExpirationTime attribute value */ >+ char *principal_expire = NULL; /* krbPrincipalExpiration attribute value */ > char *dn = NULL; /* bind DN */ > Slapi_Value *objectclass; > int method; /* authentication method */ > int ret = 0; > char *principal = NULL; >+ bool auth_failed = false; > > LOG_TRACE("=>\n"); > >@@ -1422,7 +1426,7 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) > const char *attrs_list[] = {SLAPI_USERPWD_ATTR, "krbprincipalkey", "uid", > "krbprincipalname", "objectclass", > "passwordexpirationtime", "passwordhistory", >- NULL}; >+ "krbprincipalexpiration", NULL}; > > /* retrieve user entry */ > ret = ipapwd_getEntry(dn, &entry, (char **) attrs_list); >@@ -1438,6 +1442,39 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) > goto done; > } > >+ /* check the krbPrincipalExpiration attribute is present */ >+ ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", &attr); >+ if (ret == 0) { >+ ret = slapi_attr_first_value(attr, &value); >+ >+ if (ret == 0) { >+ /* if it is, check whether the principal has not expired */ >+ principal_expire = slapi_value_get_string(value); >+ memset(&expire_tm, 0, sizeof (expire_tm)); >+ >+ if (strptime(principal_expire, "%Y%m%d%H%M%SZ", &expire_tm)) { >+ expire_time = mktime(&expire_tm); >+ >+ /* get current time */ >+ current_time = time(NULL); >+ >+ /* mktime returns -1 if the tm struct cannot be represented as >+ * as calendar time (seconds since the Epoch). This might >+ * happen with tm structs that are ill-formated or on 32-bit >+ * platforms with dates that would cause overflow >+ * (year 2038 and later). >+ * In such cases, skip the expiration check. */ >+ >+ if (current_time > expire_time && expire_time > 0) { >+ LOG_FATAL("kerberos principal in %s is expired\n", dn); >+ errMesg = "Kerberos principal is expired."; >+ auth_failed = true; >+ goto done; >+ } >+ } I think indenting is broken for these two brackets. -- / Alexander Bokovoy From mkosek at redhat.com Tue Jan 7 08:58:23 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 07 Jan 2014 09:58:23 +0100 Subject: [Freeipa-devel] [PATCH] 0344-0345 Allow anonymous and all permissions In-Reply-To: <52CAA0F0.7090409@redhat.com> References: <52AEE828.6010102@redhat.com> <52C6DAE6.6000002@redhat.com> <52CAA0F0.7090409@redhat.com> Message-ID: <52CBC1AF.5030802@redhat.com> On 01/06/2014 01:26 PM, Petr Viktorin wrote: > On 01/03/2014 04:44 PM, Martin Kosek wrote: >> On 12/16/2013 12:46 PM, Petr Viktorin wrote: >>> Hello, >>> The next step in permission effort is small since the groundwork is already >>> done. >>> >>> This adds API/CLI for anonymous&all permissions, and disables adding these to >>> privileges. >>> >>> Ticket: https://fedorahosted.org/freeipa/ticket/4032 >>> Design: http://www.freeipa.org/page/V3/Anonymous_and_All_permissions >>> >> >> This looks strange >> >> # ipa permission-add anon --type=user --permissions=read --attrs=description >> --bindtype=anonymous >> >> # ipa privilege-add-permission foo --perm= >> ipa: ERROR: invalid 'permission': >> cannot add permission "anon" with bindtype "anonymous" to a privilege >> >> (I know, I am nitpicking again). >> >> Otherwise I think the patch is OK. >> >> Martin > > Good catch, thanks. > Updated patches attached. Thanks. ACK, pushed to master. Martin From mkosek at redhat.com Tue Jan 7 12:07:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 07 Jan 2014 13:07:16 +0100 Subject: [Freeipa-devel] [PATCH] 444 PKI service restart after CA renewal failed Message-ID: <52CBEDF4.5020007@redhat.com> Restart scripts tried to call knownservices.pki_cad which did not exist, the script failed and PKI services was not started. Fix both the service restart procedure and registration of old pki-cad well known service name. https://fedorahosted.org/freeipa/ticket/4092 ---- Reproduction instructions are in the ticket. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-444-pki-service-restart-after-ca-renewal-failed.patch Type: text/x-patch Size: 5479 bytes Desc: not available URL: From tbabej at redhat.com Tue Jan 7 12:47:43 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 07 Jan 2014 13:47:43 +0100 Subject: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal In-Reply-To: <20140107062328.GE12003@redhat.com> References: <511A72D9.6090506@redhat.com> <511A75F0.7070801@redhat.com> <1360689791.3838.56.camel@willson.li.ssimo.org> <511B8632.7000709@redhat.com> <5159E560.6030603@redhat.com> <5162CC60.8040008@redhat.com> <516BD9D6.6020800@redhat.com> <52CA9082.3000000@redhat.com> <52CA91C1.3070804@redhat.com> <20140107062328.GE12003@redhat.com> Message-ID: <52CBF76F.5010200@redhat.com> On 01/07/2014 07:23 AM, Alexander Bokovoy wrote: > On Mon, 06 Jan 2014, Tomas Babej wrote: >> >> On 01/06/2014 12:16 PM, Tomas Babej wrote: >>> On 04/15/2013 12:43 PM, Tomas Babej wrote: >>>> On 04/08/2013 03:55 PM, Martin Kosek wrote: >>>>> On 04/01/2013 09:52 PM, Rob Crittenden wrote: >>>>>> Tomas Babej wrote: >>>>>>> On 02/12/2013 06:23 PM, Simo Sorce wrote: >>>>>>>> On Tue, 2013-02-12 at 18:03 +0100, Tomas Babej wrote: >>>>>>>>> On 02/12/2013 05:50 PM, Tomas Babej wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> This patch adds a check for krbprincipalexpiration attribute to >>>>>>>>>> pre_bind operation >>>>>>>>>> in ipa-pwd-extop dirsrv plugin. If the principal is expired, >>>>>>>>>> auth is >>>>>>>>>> denied and LDAP_INVALID_CREDENTIALS along with the error >>>>>>>>>> message is >>>>>>>>>> sent back to the client. Since krbprincipalexpiration >>>>>>>>>> attribute is >>>>>>>>> not >>>>>>>>>> mandatory, if there is no value set, the check is passed. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3305 >>>>>>>> Comments inline. >>>>>>>>> @@ -1166,6 +1173,29 @@ static int ipapwd_pre_bind(Slapi_PBlock >>>>>>>>> *pb) >>>>>>>>> goto done; >>>>>>>>> } >>>>>>>>> + /* check the krbPrincipalExpiration attribute is present */ >>>>>>>>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>>>>>>>> &attr); >>>>>>>>> + if (!ret) { >>>>>>>> ret is not a boolean so probably better ti use (ret != 0) >>>>>>>> >>>>>>>>> + /* if it is, check whether the principal has not >>>>>>>>> expired */ >>>>>>>>> + >>>>>>>>> + principal_expire = slapi_entry_attr_get_charptr(entry, >>>>>>>>> + "krbprincipalexpiration"); >>>>>>>>> + memset(&expire_tm, 0, sizeof (expire_tm)); >>>>>>>>> + >>>>>>>>> + if (strptime(principal_expire, "%Y%m%d%H%M%SZ", >>>>>>>>> &expire_tm)){ >>>>>>>> style issue missing space between ) and { >>>>>>>> >>>>>>>>> + expire_time = mktime(&expire_tm); >>>>>>>>> + /* this might have overflown on 32-bit system */ >>>>>>>> This comment does not help to point out what you want to put in >>>>>>>> evidence. >>>>>>>> if there is an overflow what is the consequence ? Or does it >>>>>>>> mean the >>>>>>>> next condition is taking that into account ? >>>>>>> Yeah, this was rather ill-worded. Replaced by a rather verbose >>>>>>> comment that hopefully clears things out. >>>>>>>>> + if (current_time > expire_time && expire_time > 0){ >>>>>>>> style issue missing space between ) and { >>>>>>>> >>>>>>>>> + LOG_FATAL("kerberos principal has expired in >>>>>>>>> user >>>>>>>>> entry: %s\n", >>>>>>>>> + dn); >>>>>>>> I think a better phrasing would be: "The kerberos principal on >>>>>>>> %s is >>>>>>>> expired\n" >>>>>>>> >>>>>>>>> + errMesg = "Kerberos principal has expired."; >>>>>>>> s/has/is/ >>>>>>>> >>>>>>>> The rest looks good to me. >>>>>>>> >>>>>>>> Simo. >>>>>>> Styling issues fixed and updated patch attached :) >>>>>> Small nit, the expiration error should probably use 'in' not 'on'. >>>>>> >>>>>> I'm not sure LDAP_INVALID_CREDENTIALS is the right return code. This >>>>>> implies >>>>>> that the password is wrong. I think that LDAP_UNWILLING_TO_PERFORM >>>>>> is probably >>>>>> more correct here. It is what we return on other policy failures. >>>>>> >>>>>> rob >>>>>> >>>>> Additional findings: >>>>> >>>>> 1) Lets not try to get current_time every time, but only when its >>>>> needed (i.e. >>>>> krbPrincipalExpiration is set) - AFAIK, it is not so cheap operation: >>>>> >>>>> + /* get current time*/ >>>>> + current_time = time(NULL); >>>>> >>>>> 2) Why using slapi_entry_attr_get_charptr and thus let 389-ds find >>>>> the >>>>> attribute again when we already have a pointer for the attribute? >>>>> Would >>>>> slapi_attr_first_value following slapi_entry_attr_find be faster >>>>> approach? >>>>> >>>>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>>>> &attr); >>>>> + if (ret != 0) { >>>>> + /* if it is, check whether the principal has not expired */ >>>>> + >>>>> + principal_expire = slapi_entry_attr_get_charptr(entry, >>>>> + "krbprincipalexpiration"); >>>>> >>>>> This way, we would not create a copy of this attribute value - we do >>>>> not need a >>>>> copy, we just do check against it. >>>>> >>>>> >>>>> 3) Shouldn't we return -1 in the end when the auth fails? We do that >>>>> in other >>>>> pre_callbacks. Otherwise we just return 0 (success): >>>>> >>>>> + if (auth_failed){ >>>>> + slapi_send_ldap_result(pb, LDAP_INVALID_CREDENTIALS, NULL, >>>>> errMesg, >>>>> + 0, NULL); >>>>> + } >>>>> + >>>>> return 0; >>>>> >>>>> Martin >>>> Thank you both for the review. I updated and retested the patch, with >>>> your suggestions incorporated. >>>> >>>> Tomas >>>> >>> I rebased the patch on top of current master. >>> >>> Bumping, since this is planned as part of 3.4 (and there were some >>> requests for this feature). >>> >>> Tomas >>> >> >> I updated the commit message to reflect better what the current version >> of the patch implements. >> >> Tomas > >>> From a93d1ec3ca8c7b6e8e754b474257695ba9018e07 Mon Sep 17 00:00:00 2001 >> From: Tomas Babej >> Date: Mon, 6 Jan 2014 12:11:24 +0100 >> Subject: [PATCH] ipa-pwd-extop: Deny LDAP binds for user accounts >> with expired >> principal >> >> Adds a check for krbprincipalexpiration attribute to pre_bind operation >> in ipa-pwd-extop dirsrv plugin. If the principal is expired, auth is >> denied and LDAP_UNWILLING_TO_PERFORM along with the error message is >> sent back to the client. Since krbprincipalexpiration attribute is not >> mandatory, if there is no value set, the check is passed. >> >> https://fedorahosted.org/freeipa/ticket/3305 >> --- >> daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 45 >> ++++++++++++++++++++++- >> 1 file changed, 44 insertions(+), 1 deletion(-) >> >> diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >> b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >> index >> ef37b5e173359f9404b241c12d8a6dc6e77da128..568cba7189d1575d030b043daee61f713e9bac5f >> 100644 >> --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >> +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >> @@ -1389,13 +1389,17 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >> Slapi_Value *value = NULL; >> Slapi_Attr *attr = NULL; >> struct tm expire_tm; >> + time_t current_time; >> + time_t expire_time; >> char *errMesg = "Internal operations error\n"; /* error message */ >> char *expire = NULL; /* passwordExpirationTime attribute value */ >> + char *principal_expire = NULL; /* krbPrincipalExpiration >> attribute value */ >> char *dn = NULL; /* bind DN */ >> Slapi_Value *objectclass; >> int method; /* authentication method */ >> int ret = 0; >> char *principal = NULL; >> + bool auth_failed = false; >> >> LOG_TRACE("=>\n"); >> >> @@ -1422,7 +1426,7 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >> const char *attrs_list[] = {SLAPI_USERPWD_ATTR, >> "krbprincipalkey", "uid", >> "krbprincipalname", "objectclass", >> "passwordexpirationtime", >> "passwordhistory", >> - NULL}; >> + "krbprincipalexpiration", NULL}; >> >> /* retrieve user entry */ >> ret = ipapwd_getEntry(dn, &entry, (char **) attrs_list); >> @@ -1438,6 +1442,39 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >> goto done; >> } >> >> + /* check the krbPrincipalExpiration attribute is present */ >> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >> &attr); >> + if (ret == 0) { >> + ret = slapi_attr_first_value(attr, &value); >> + >> + if (ret == 0) { >> + /* if it is, check whether the principal has not expired */ >> + principal_expire = slapi_value_get_string(value); >> + memset(&expire_tm, 0, sizeof (expire_tm)); >> + >> + if (strptime(principal_expire, "%Y%m%d%H%M%SZ", >> &expire_tm)) { >> + expire_time = mktime(&expire_tm); >> + >> + /* get current time */ >> + current_time = time(NULL); >> + >> + /* mktime returns -1 if the tm struct cannot be >> represented as >> + * as calendar time (seconds since the Epoch). This >> might >> + * happen with tm structs that are ill-formated or >> on 32-bit >> + * platforms with dates that would cause overflow >> + * (year 2038 and later). >> + * In such cases, skip the expiration check. */ >> + >> + if (current_time > expire_time && expire_time > 0) { >> + LOG_FATAL("kerberos principal in %s is >> expired\n", dn); >> + errMesg = "Kerberos principal is expired."; >> + auth_failed = true; >> + goto done; >> + } >> + } > I think indenting is broken for these two brackets. > > Thanks Alexander, fixed. Updated version attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0034-7-ipa-pwd-extop-Deny-LDAP-binds-for-user-accounts-with.patch Type: text/x-patch Size: 4225 bytes Desc: not available URL: From jcholast at redhat.com Tue Jan 7 12:54:19 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 07 Jan 2014 13:54:19 +0100 Subject: [Freeipa-devel] [PATCHES] 225-230 Drop support for the legacy LDAP API In-Reply-To: <52AF03F2.2090904@redhat.com> References: <52A72DA8.4090104@redhat.com> <52AB16B8.6050808@redhat.com> <52AEC654.5040602@redhat.com> <52AF03F2.2090904@redhat.com> Message-ID: <52CBF8FB.7090808@redhat.com> On 16.12.2013 14:45, Petr Viktorin wrote: > On 12/16/2013 10:22 AM, Jan Cholasta wrote: >> On 13.12.2013 15:16, Petr Viktorin wrote: >>> On 12/10/2013 04:05 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> I believe the time has come to drop support for the legacy (dn, >>>> entry_attrs) tuple API and move to the new LDAPEntry API exclusively. >>>> The attached patches convert existing code which uses the old API to >>>> the >>>> new API and remove backward compatibility code from the ipaldap module. >>>> >>>> Note that there are still some functions/methods which accept separate >>>> dn and entry_attrs arguments, they will be adapted to LDAPEntry later. >>>> >>>> Honza >>> >>> The first N-1 patches can be tested,acked,pushed independently, right? >> >> Yes. >> >>> If that's the case, ACK for 225 > > Pushed that one to master, 5 more to go. > bc3f3381c6bf0b4941889b775025a60f56318551 > >>> As for dropping the support itself, I think we should think more about >>> backward compatibility. This will affect nearly all third-party plugins, >>> and I'm sure there are a few. >> >> Are there? > > Yes, there are some private plugins in the wild. > >>> I'd recommend something like: >>> 3.4: Warn in release notes that we'll be dropping support; log a warning >>> when __iter__ is used >>> 3.5: Make __iter__ raise an exception (we don't want to silently start >>> returning different data) >>> 3.6: Finally start acting like a dict >> >> Could we raise an exception now instead of waiting for 3.5? Fixing the >> plugins is nothing hard, you know... > > We should discuss this next year, when people come back from holidays. We had an offline discussion and decided to raise an exception in 3.4 and drop support in 3.5. I have created a wiki page with migration guide: (WIP, comments/edits are welcome). Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-226.1-Convert-remaining-frontend-code-to-LDAPEntry-API.patch Type: text/x-patch Size: 100845 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-227.1-Convert-remaining-installer-code-to-LDAPEntry-API.patch Type: text/x-patch Size: 14360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-228.1-Convert-remaining-update-code-to-LDAPEntry-API.patch Type: text/x-patch Size: 10420 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-229.1-Convert-remaining-test-code-to-LDAPEntry-API.patch Type: text/x-patch Size: 3334 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-230.1-Raise-an-exception-when-legacy-LDAP-API-is-used.patch Type: text/x-patch Size: 3802 bytes Desc: not available URL: From pviktori at redhat.com Tue Jan 7 13:26:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 07 Jan 2014 14:26:14 +0100 Subject: [Freeipa-devel] [PATCHES] 225-230 Drop support for the legacy LDAP API In-Reply-To: <52CBF8FB.7090808@redhat.com> References: <52A72DA8.4090104@redhat.com> <52AB16B8.6050808@redhat.com> <52AEC654.5040602@redhat.com> <52AF03F2.2090904@redhat.com> <52CBF8FB.7090808@redhat.com> Message-ID: <52CC0076.1010502@redhat.com> On 01/07/2014 01:54 PM, Jan Cholasta wrote: > On 16.12.2013 14:45, Petr Viktorin wrote: >> On 12/16/2013 10:22 AM, Jan Cholasta wrote: >>> On 13.12.2013 15:16, Petr Viktorin wrote: [...] >>>> I'd recommend something like: >>>> 3.4: Warn in release notes that we'll be dropping support; log a >>>> warning >>>> when __iter__ is used >>>> 3.5: Make __iter__ raise an exception (we don't want to silently start >>>> returning different data) >>>> 3.6: Finally start acting like a dict >>> >>> Could we raise an exception now instead of waiting for 3.5? Fixing the >>> plugins is nothing hard, you know... >> >> We should discuss this next year, when people come back from holidays. > > We had an offline discussion and decided to raise an exception in 3.4 > and drop support in 3.5. > > I have created a wiki page with migration guide: > (WIP, > comments/edits are welcome). I've updated the page with details of our plan. -- Petr? From jcholast at redhat.com Tue Jan 7 14:53:21 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 07 Jan 2014 15:53:21 +0100 Subject: [Freeipa-devel] [PATCH] 444 PKI service restart after CA renewal failed In-Reply-To: <52CBEDF4.5020007@redhat.com> References: <52CBEDF4.5020007@redhat.com> Message-ID: <52CC14E1.2000402@redhat.com> Hi, On 7.1.2014 13:07, Martin Kosek wrote: > Restart scripts tried to call knownservices.pki_cad which did not > exist, the script failed and PKI services was not started. Fix both > the service restart procedure and registration of old pki-cad well > known service name. > > https://fedorahosted.org/freeipa/ticket/4092 ACK on the registration of old pki-cad well known service name. As for the restart procedure, I already fixed that in my patch 178, including some bits you missed in your patch (also, my solution is slightly better IMHO). Honza -- Jan Cholasta From pspacek at redhat.com Tue Jan 7 18:36:39 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 07 Jan 2014 19:36:39 +0100 Subject: [Freeipa-devel] [PATCH 0218] Limit number of unprocessed syncrepl events in queue to 100 Message-ID: <52CC4937.5060309@redhat.com> Hello, Limit number of unprocessed syncrepl events in queue to 100. All syncrepl events are processed sequentialy. This patch limits memory consumption in cases where the LDAP server is sending syncrepl events too quickly. LDAP client library should handle this situation so no events will be lost. This patch should go to the head of future master branch (rbtdb.v22). -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0218-Limit-number-of-unprocessed-syncrepl-events-in-queue.patch Type: text/x-patch Size: 6837 bytes Desc: not available URL: From mkosek at redhat.com Wed Jan 8 08:48:20 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 08 Jan 2014 09:48:20 +0100 Subject: [Freeipa-devel] [PATCH] 444 PKI service restart after CA renewal failed In-Reply-To: <52CC14E1.2000402@redhat.com> References: <52CBEDF4.5020007@redhat.com> <52CC14E1.2000402@redhat.com> Message-ID: <52CD10D4.6020201@redhat.com> On 01/07/2014 03:53 PM, Jan Cholasta wrote: > Hi, > > On 7.1.2014 13:07, Martin Kosek wrote: >> Restart scripts tried to call knownservices.pki_cad which did not >> exist, the script failed and PKI services was not started. Fix both >> the service restart procedure and registration of old pki-cad well >> known service name. >> >> https://fedorahosted.org/freeipa/ticket/4092 > > ACK on the registration of old pki-cad well known service name. As for the > restart procedure, I already fixed that in my patch 178, including some bits > you missed in your patch (also, my solution is slightly better IMHO). > > Honza > True, your solution indeed is better. I squashed the registration fix oneliner to your patch 178 and pushed it to master, ipa-3-3. Martin From tbabej at redhat.com Wed Jan 8 12:42:32 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 08 Jan 2014 13:42:32 +0100 Subject: [Freeipa-devel] Handling of krbPrincpalExpiration in default ACI Message-ID: <52CD47B8.1090302@redhat.com> Hi, I'm working on exposing the krbPrincipalExpiration attribute in the CLI (https://fedorahosted.org/freeipa/ticket/3306). However, this attribute is exempted from the default ACL "Admin can manage any entry" (install/share/default-aci.ldif +8). Now, we have several options: 1.) remove it from blacklisted options in "Admin can manage any entry" ACL 2.) create a new permission that allows writing to this attribute (i.e. Modify Kerberos principal expiration) 3.) add this attribute to a existing permission (Modify users seems like the best candidate, however, the attribute does not really fit even there) I see that the the approach 1.) was taken with the krbTicketFlags attribute in the past (install/updates/60-trusts.update +38). What would be the best approach here? Tomas From simo at redhat.com Wed Jan 8 14:19:40 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 08 Jan 2014 09:19:40 -0500 Subject: [Freeipa-devel] Handling of krbPrincpalExpiration in default ACI In-Reply-To: <52CD47B8.1090302@redhat.com> References: <52CD47B8.1090302@redhat.com> Message-ID: <1389190780.26102.152.camel@willson.li.ssimo.org> On Wed, 2014-01-08 at 13:42 +0100, Tomas Babej wrote: > Hi, > > I'm working on exposing the krbPrincipalExpiration attribute in the CLI > (https://fedorahosted.org/freeipa/ticket/3306). However, this attribute > is exempted from the default ACL "Admin can manage any entry" > (install/share/default-aci.ldif +8). > > Now, we have several options: > 1.) remove it from blacklisted options in "Admin can manage any entry" ACL Nope, it was excluded on purpose, to prevent admins from playing with it. > 2.) create a new permission that allows writing to this attribute (i.e. > Modify Kerberos principal expiration) Yep, this sounds right. > 3.) add this attribute to a existing permission (Modify users seems like > the best candidate, however, the attribute does not really fit even there) Nope, needs to be explicit for auditing purposes that admins are able to violate the password policies of users by changing their expiration date. > I see that the the approach 1.) was taken with the krbTicketFlags > attribute in the past (install/updates/60-trusts.update +38). Yes, however I think this too should be probably explicit and have its own permission with the new permission framework. > What would be the best approach here? I say 2. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Jan 8 14:43:25 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 08 Jan 2014 09:43:25 -0500 Subject: [Freeipa-devel] Handling of krbPrincpalExpiration in default ACI In-Reply-To: <1389190780.26102.152.camel@willson.li.ssimo.org> References: <52CD47B8.1090302@redhat.com> <1389190780.26102.152.camel@willson.li.ssimo.org> Message-ID: <1389192205.26102.162.camel@willson.li.ssimo.org> On Wed, 2014-01-08 at 09:19 -0500, Simo Sorce wrote: > On Wed, 2014-01-08 at 13:42 +0100, Tomas Babej wrote: > > Hi, > > > > I'm working on exposing the krbPrincipalExpiration attribute in the CLI > > (https://fedorahosted.org/freeipa/ticket/3306). However, this attribute > > is exempted from the default ACL "Admin can manage any entry" > > (install/share/default-aci.ldif +8). > > > > Now, we have several options: > > 1.) remove it from blacklisted options in "Admin can manage any entry" ACL > > Nope, it was excluded on purpose, to prevent admins from playing with > it. OOOk and maybe If I stop reading "Password" when I see "Principal" I would make more sense :-( > > 2.) create a new permission that allows writing to this attribute (i.e. > > Modify Kerberos principal expiration) > > Yep, this sounds right. > > > 3.) add this attribute to a existing permission (Modify users seems like > > the best candidate, however, the attribute does not really fit even there) > > Nope, needs to be explicit for auditing purposes that admins are able to > violate the password policies of users by changing their expiration > date. > > > I see that the the approach 1.) was taken with the krbTicketFlags > > attribute in the past (install/updates/60-trusts.update +38). > > Yes, however I think this too should be probably explicit and have its > own permission with the new permission framework. > > > What would be the best approach here? > > I say 2. Given this is "Principal"'s expiration, I amend my suggestion. I say you can choose either 2 or 3. The *Account Expiration* (which is what really this attribute controls) is clearly a user attribute and it is not strictly necessary to have a separate permission. However it is not a bad idea either. I think there may be cases when some administrative process wants to allow admins to modify users, but not let them extend a user account lifetime. The account lifetime may be something that is controlled by an HR department and should not be modifiable by all admins. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Jan 8 14:46:10 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 08 Jan 2014 09:46:10 -0500 Subject: [Freeipa-devel] Handling of krbPrincpalExpiration in default ACI In-Reply-To: <1389192205.26102.162.camel@willson.li.ssimo.org> References: <52CD47B8.1090302@redhat.com> <1389190780.26102.152.camel@willson.li.ssimo.org> <1389192205.26102.162.camel@willson.li.ssimo.org> Message-ID: <52CD64B2.8070708@redhat.com> Simo Sorce wrote: > On Wed, 2014-01-08 at 09:19 -0500, Simo Sorce wrote: >> On Wed, 2014-01-08 at 13:42 +0100, Tomas Babej wrote: >>> Hi, >>> >>> I'm working on exposing the krbPrincipalExpiration attribute in the CLI >>> (https://fedorahosted.org/freeipa/ticket/3306). However, this attribute >>> is exempted from the default ACL "Admin can manage any entry" >>> (install/share/default-aci.ldif +8). >>> >>> Now, we have several options: >>> 1.) remove it from blacklisted options in "Admin can manage any entry" ACL >> >> Nope, it was excluded on purpose, to prevent admins from playing with >> it. > > OOOk and maybe If I stop reading "Password" when I see "Principal" I > would make more sense :-( > >>> 2.) create a new permission that allows writing to this attribute (i.e. >>> Modify Kerberos principal expiration) >> >> Yep, this sounds right. >> >>> 3.) add this attribute to a existing permission (Modify users seems like >>> the best candidate, however, the attribute does not really fit even there) >> >> Nope, needs to be explicit for auditing purposes that admins are able to >> violate the password policies of users by changing their expiration >> date. >> >>> I see that the the approach 1.) was taken with the krbTicketFlags >>> attribute in the past (install/updates/60-trusts.update +38). >> >> Yes, however I think this too should be probably explicit and have its >> own permission with the new permission framework. >> >>> What would be the best approach here? >> >> I say 2. > > Given this is "Principal"'s expiration, I amend my suggestion. > > I say you can choose either 2 or 3. The *Account Expiration* (which is > what really this attribute controls) is clearly a user attribute and it > is not strictly necessary to have a separate permission. > However it is not a bad idea either. I think there may be cases when > some administrative process wants to allow admins to modify users, but > not let them extend a user account lifetime. The account lifetime may be > something that is controlled by an HR department and should not be > modifiable by all admins. > > Simo. > I was wondering about your initial logic but you came to the same conclusion I did so I didn't say anything :-) I think I prefer #2 so that there is explicit permission to modify this policy-related attribute. rob From pviktori at redhat.com Wed Jan 8 14:49:32 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 08 Jan 2014 15:49:32 +0100 Subject: [Freeipa-devel] Handling of krbPrincpalExpiration in default ACI In-Reply-To: <1389192205.26102.162.camel@willson.li.ssimo.org> References: <52CD47B8.1090302@redhat.com> <1389190780.26102.152.camel@willson.li.ssimo.org> <1389192205.26102.162.camel@willson.li.ssimo.org> Message-ID: <52CD657C.5080800@redhat.com> On 01/08/2014 03:43 PM, Simo Sorce wrote: > On Wed, 2014-01-08 at 09:19 -0500, Simo Sorce wrote: >> On Wed, 2014-01-08 at 13:42 +0100, Tomas Babej wrote: >>> Hi, >>> >>> I'm working on exposing the krbPrincipalExpiration attribute in the CLI >>> (https://fedorahosted.org/freeipa/ticket/3306). However, this attribute >>> is exempted from the default ACL "Admin can manage any entry" >>> (install/share/default-aci.ldif +8). >>> >>> Now, we have several options: >>> 1.) remove it from blacklisted options in "Admin can manage any entry" ACL >> >> Nope, it was excluded on purpose, to prevent admins from playing with >> it. > > OOOk and maybe If I stop reading "Password" when I see "Principal" I > would make more sense :-( > >>> 2.) create a new permission that allows writing to this attribute (i.e. >>> Modify Kerberos principal expiration) >> >> Yep, this sounds right. >> >>> 3.) add this attribute to a existing permission (Modify users seems like >>> the best candidate, however, the attribute does not really fit even there) >> >> Nope, needs to be explicit for auditing purposes that admins are able to >> violate the password policies of users by changing their expiration >> date. >> >>> I see that the the approach 1.) was taken with the krbTicketFlags >>> attribute in the past (install/updates/60-trusts.update +38). >> >> Yes, however I think this too should be probably explicit and have its >> own permission with the new permission framework. >> >>> What would be the best approach here? >> >> I say 2. > > Given this is "Principal"'s expiration, I amend my suggestion. > > I say you can choose either 2 or 3. The *Account Expiration* (which is > what really this attribute controls) is clearly a user attribute and it > is not strictly necessary to have a separate permission. > However it is not a bad idea either. I think there may be cases when > some administrative process wants to allow admins to modify users, but > not let them extend a user account lifetime. The account lifetime may be > something that is controlled by an HR department and should not be > modifiable by all admins. How rare would this case be? We'll have manageable permissions, it should be easy to exclude the attribute and add a separate permission for it. -- Petr? From tbabej at redhat.com Wed Jan 8 14:54:26 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 08 Jan 2014 15:54:26 +0100 Subject: [Freeipa-devel] Handling of krbPrincpalExpiration in default ACI In-Reply-To: <52CD64B2.8070708@redhat.com> References: <52CD47B8.1090302@redhat.com> <1389190780.26102.152.camel@willson.li.ssimo.org> <1389192205.26102.162.camel@willson.li.ssimo.org> <52CD64B2.8070708@redhat.com> Message-ID: <52CD66A2.5020405@redhat.com> On 01/08/2014 03:46 PM, Rob Crittenden wrote: > Simo Sorce wrote: >> On Wed, 2014-01-08 at 09:19 -0500, Simo Sorce wrote: >>> On Wed, 2014-01-08 at 13:42 +0100, Tomas Babej wrote: >>>> Hi, >>>> >>>> I'm working on exposing the krbPrincipalExpiration attribute in the >>>> CLI >>>> (https://fedorahosted.org/freeipa/ticket/3306). However, this >>>> attribute >>>> is exempted from the default ACL "Admin can manage any entry" >>>> (install/share/default-aci.ldif +8). >>>> >>>> Now, we have several options: >>>> 1.) remove it from blacklisted options in "Admin can manage any >>>> entry" ACL >>> >>> Nope, it was excluded on purpose, to prevent admins from playing with >>> it. >> >> OOOk and maybe If I stop reading "Password" when I see "Principal" I >> would make more sense :-( >> >>>> 2.) create a new permission that allows writing to this attribute >>>> (i.e. >>>> Modify Kerberos principal expiration) >>> >>> Yep, this sounds right. >>> >>>> 3.) add this attribute to a existing permission (Modify users seems >>>> like >>>> the best candidate, however, the attribute does not really fit even >>>> there) >>> >>> Nope, needs to be explicit for auditing purposes that admins are >>> able to >>> violate the password policies of users by changing their expiration >>> date. >>> >>>> I see that the the approach 1.) was taken with the krbTicketFlags >>>> attribute in the past (install/updates/60-trusts.update +38). >>> >>> Yes, however I think this too should be probably explicit and have its >>> own permission with the new permission framework. >>> >>>> What would be the best approach here? >>> >>> I say 2. >> >> Given this is "Principal"'s expiration, I amend my suggestion. >> >> I say you can choose either 2 or 3. The *Account Expiration* (which is >> what really this attribute controls) is clearly a user attribute and it >> is not strictly necessary to have a separate permission. >> However it is not a bad idea either. I think there may be cases when >> some administrative process wants to allow admins to modify users, but >> not let them extend a user account lifetime. The account lifetime may be >> something that is controlled by an HR department and should not be >> modifiable by all admins. >> >> Simo. >> > > I was wondering about your initial logic but you came to the same > conclusion I did so I didn't say anything :-) > > I think I prefer #2 so that there is explicit permission to modify > this policy-related attribute. > > rob Yes, I wouldn't personally go with #3 since the rest of the attributes in the permission seem more benign. What puzzles me though: going with #2 and not with #1 will create the situation where we have an attribute that is exposed by Web UI / CLI, but members of the admins group do not have this permission to edit this attribute. Or should we make assign this permission to admins group by default? They still can, in default configuration, change the roles/privileges/permissions anyway. From mkosek at redhat.com Wed Jan 8 14:55:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 08 Jan 2014 15:55:01 +0100 Subject: [Freeipa-devel] Handling of krbPrincpalExpiration in default ACI In-Reply-To: <52CD64B2.8070708@redhat.com> References: <52CD47B8.1090302@redhat.com> <1389190780.26102.152.camel@willson.li.ssimo.org> <1389192205.26102.162.camel@willson.li.ssimo.org> <52CD64B2.8070708@redhat.com> Message-ID: <52CD66C5.5090101@redhat.com> On 01/08/2014 03:46 PM, Rob Crittenden wrote: > Simo Sorce wrote: >> On Wed, 2014-01-08 at 09:19 -0500, Simo Sorce wrote: >>> On Wed, 2014-01-08 at 13:42 +0100, Tomas Babej wrote: >>>> Hi, >>>> >>>> I'm working on exposing the krbPrincipalExpiration attribute in the CLI >>>> (https://fedorahosted.org/freeipa/ticket/3306). However, this attribute >>>> is exempted from the default ACL "Admin can manage any entry" >>>> (install/share/default-aci.ldif +8). >>>> >>>> Now, we have several options: >>>> 1.) remove it from blacklisted options in "Admin can manage any entry" ACL >>> >>> Nope, it was excluded on purpose, to prevent admins from playing with >>> it. >> >> OOOk and maybe If I stop reading "Password" when I see "Principal" I >> would make more sense :-( >> >>>> 2.) create a new permission that allows writing to this attribute (i.e. >>>> Modify Kerberos principal expiration) >>> >>> Yep, this sounds right. >>> >>>> 3.) add this attribute to a existing permission (Modify users seems like >>>> the best candidate, however, the attribute does not really fit even there) >>> >>> Nope, needs to be explicit for auditing purposes that admins are able to >>> violate the password policies of users by changing their expiration >>> date. >>> >>>> I see that the the approach 1.) was taken with the krbTicketFlags >>>> attribute in the past (install/updates/60-trusts.update +38). >>> >>> Yes, however I think this too should be probably explicit and have its >>> own permission with the new permission framework. >>> >>>> What would be the best approach here? >>> >>> I say 2. >> >> Given this is "Principal"'s expiration, I amend my suggestion. >> >> I say you can choose either 2 or 3. The *Account Expiration* (which is >> what really this attribute controls) is clearly a user attribute and it >> is not strictly necessary to have a separate permission. >> However it is not a bad idea either. I think there may be cases when >> some administrative process wants to allow admins to modify users, but >> not let them extend a user account lifetime. The account lifetime may be >> something that is controlled by an HR department and should not be >> modifiable by all admins. >> >> Simo. >> > > I was wondering about your initial logic but you came to the same conclusion I > did so I didn't say anything :-) > > I think I prefer #2 so that there is explicit permission to modify this > policy-related attribute. > > rob I would personally do #1, for simplicity. krbPrincipalExpiration is not something controlled by ipa-kdb or custom policy to warrant excluding it from admin's permissions. It is basically just disabling an account in a future, something that admin can already do with cron+"ipa user-disable $user" - i.e. I did not see why this attribute needs to be protected from admins. I am also not sure if the HR example is the right one. We are talking about permission for admins group, i.e. the "ultimate admins group" that only few members in the organization should have. Normal admins should be controlled via RBAC which does not allow krbPrincipalExpiration (but can be added). Martin From mkosek at redhat.com Wed Jan 8 14:58:25 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 08 Jan 2014 15:58:25 +0100 Subject: [Freeipa-devel] Handling of krbPrincpalExpiration in default ACI In-Reply-To: <52CD66A2.5020405@redhat.com> References: <52CD47B8.1090302@redhat.com> <1389190780.26102.152.camel@willson.li.ssimo.org> <1389192205.26102.162.camel@willson.li.ssimo.org> <52CD64B2.8070708@redhat.com> <52CD66A2.5020405@redhat.com> Message-ID: <52CD6791.4090403@redhat.com> On 01/08/2014 03:54 PM, Tomas Babej wrote: > > On 01/08/2014 03:46 PM, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Wed, 2014-01-08 at 09:19 -0500, Simo Sorce wrote: >>>> On Wed, 2014-01-08 at 13:42 +0100, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> I'm working on exposing the krbPrincipalExpiration attribute in the >>>>> CLI >>>>> (https://fedorahosted.org/freeipa/ticket/3306). However, this >>>>> attribute >>>>> is exempted from the default ACL "Admin can manage any entry" >>>>> (install/share/default-aci.ldif +8). >>>>> >>>>> Now, we have several options: >>>>> 1.) remove it from blacklisted options in "Admin can manage any >>>>> entry" ACL >>>> >>>> Nope, it was excluded on purpose, to prevent admins from playing with >>>> it. >>> >>> OOOk and maybe If I stop reading "Password" when I see "Principal" I >>> would make more sense :-( >>> >>>>> 2.) create a new permission that allows writing to this attribute >>>>> (i.e. >>>>> Modify Kerberos principal expiration) >>>> >>>> Yep, this sounds right. >>>> >>>>> 3.) add this attribute to a existing permission (Modify users seems >>>>> like >>>>> the best candidate, however, the attribute does not really fit even >>>>> there) >>>> >>>> Nope, needs to be explicit for auditing purposes that admins are >>>> able to >>>> violate the password policies of users by changing their expiration >>>> date. >>>> >>>>> I see that the the approach 1.) was taken with the krbTicketFlags >>>>> attribute in the past (install/updates/60-trusts.update +38). >>>> >>>> Yes, however I think this too should be probably explicit and have its >>>> own permission with the new permission framework. >>>> >>>>> What would be the best approach here? >>>> >>>> I say 2. >>> >>> Given this is "Principal"'s expiration, I amend my suggestion. >>> >>> I say you can choose either 2 or 3. The *Account Expiration* (which is >>> what really this attribute controls) is clearly a user attribute and it >>> is not strictly necessary to have a separate permission. >>> However it is not a bad idea either. I think there may be cases when >>> some administrative process wants to allow admins to modify users, but >>> not let them extend a user account lifetime. The account lifetime may be >>> something that is controlled by an HR department and should not be >>> modifiable by all admins. >>> >>> Simo. >>> >> >> I was wondering about your initial logic but you came to the same >> conclusion I did so I didn't say anything :-) >> >> I think I prefer #2 so that there is explicit permission to modify >> this policy-related attribute. >> >> rob > > Yes, I wouldn't personally go with #3 since the rest of the attributes > in the permission seem more benign. > > What puzzles me though: going with #2 and not with #1 will create the > situation where we have an attribute that is exposed by Web UI / CLI, > but members of the admins group do not have this permission to edit this > attribute. > > Or should we make assign this permission to admins group by default? > They still can, in default configuration, change the > roles/privileges/permissions anyway. admins have no default permission so far, I would not start with it now. You would need to add special privilege, roles... Doing just #1 is IMO much easier for us to do. I also did not see the main concern why the super admins cannot modify it. Martin From simo at redhat.com Wed Jan 8 15:19:31 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 08 Jan 2014 10:19:31 -0500 Subject: [Freeipa-devel] Handling of krbPrincpalExpiration in default ACI In-Reply-To: <52CD657C.5080800@redhat.com> References: <52CD47B8.1090302@redhat.com> <1389190780.26102.152.camel@willson.li.ssimo.org> <1389192205.26102.162.camel@willson.li.ssimo.org> <52CD657C.5080800@redhat.com> Message-ID: <1389194371.26102.163.camel@willson.li.ssimo.org> On Wed, 2014-01-08 at 15:49 +0100, Petr Viktorin wrote: > On 01/08/2014 03:43 PM, Simo Sorce wrote: > > On Wed, 2014-01-08 at 09:19 -0500, Simo Sorce wrote: > >> On Wed, 2014-01-08 at 13:42 +0100, Tomas Babej wrote: > >>> Hi, > >>> > >>> I'm working on exposing the krbPrincipalExpiration attribute in the CLI > >>> (https://fedorahosted.org/freeipa/ticket/3306). However, this attribute > >>> is exempted from the default ACL "Admin can manage any entry" > >>> (install/share/default-aci.ldif +8). > >>> > >>> Now, we have several options: > >>> 1.) remove it from blacklisted options in "Admin can manage any entry" ACL > >> > >> Nope, it was excluded on purpose, to prevent admins from playing with > >> it. > > > > OOOk and maybe If I stop reading "Password" when I see "Principal" I > > would make more sense :-( > > > >>> 2.) create a new permission that allows writing to this attribute (i.e. > >>> Modify Kerberos principal expiration) > >> > >> Yep, this sounds right. > >> > >>> 3.) add this attribute to a existing permission (Modify users seems like > >>> the best candidate, however, the attribute does not really fit even there) > >> > >> Nope, needs to be explicit for auditing purposes that admins are able to > >> violate the password policies of users by changing their expiration > >> date. > >> > >>> I see that the the approach 1.) was taken with the krbTicketFlags > >>> attribute in the past (install/updates/60-trusts.update +38). > >> > >> Yes, however I think this too should be probably explicit and have its > >> own permission with the new permission framework. > >> > >>> What would be the best approach here? > >> > >> I say 2. > > > > Given this is "Principal"'s expiration, I amend my suggestion. > > > > I say you can choose either 2 or 3. The *Account Expiration* (which is > > what really this attribute controls) is clearly a user attribute and it > > is not strictly necessary to have a separate permission. > > However it is not a bad idea either. I think there may be cases when > > some administrative process wants to allow admins to modify users, but > > not let them extend a user account lifetime. The account lifetime may be > > something that is controlled by an HR department and should not be > > modifiable by all admins. > > How rare would this case be? We'll have manageable permissions, it > should be easy to exclude the attribute and add a separate permission > for it. Right which is why I say 2 or 3, I do not have a strong preference, if it is a hassle to create a new permission now, feel free to fold into the std modify users permission for now. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed Jan 8 15:33:27 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 08 Jan 2014 16:33:27 +0100 Subject: [Freeipa-devel] Handling of krbPrincpalExpiration in default ACI In-Reply-To: <1389194371.26102.163.camel@willson.li.ssimo.org> References: <52CD47B8.1090302@redhat.com> <1389190780.26102.152.camel@willson.li.ssimo.org> <1389192205.26102.162.camel@willson.li.ssimo.org> <52CD657C.5080800@redhat.com> <1389194371.26102.163.camel@willson.li.ssimo.org> Message-ID: <52CD6FC7.3020208@redhat.com> On 01/08/2014 04:19 PM, Simo Sorce wrote: > On Wed, 2014-01-08 at 15:49 +0100, Petr Viktorin wrote: >> On 01/08/2014 03:43 PM, Simo Sorce wrote: >>> On Wed, 2014-01-08 at 09:19 -0500, Simo Sorce wrote: >>>> On Wed, 2014-01-08 at 13:42 +0100, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> I'm working on exposing the krbPrincipalExpiration attribute in the CLI >>>>> (https://fedorahosted.org/freeipa/ticket/3306). However, this attribute >>>>> is exempted from the default ACL "Admin can manage any entry" >>>>> (install/share/default-aci.ldif +8). >>>>> >>>>> Now, we have several options: >>>>> 1.) remove it from blacklisted options in "Admin can manage any entry" ACL >>>> >>>> Nope, it was excluded on purpose, to prevent admins from playing with >>>> it. >>> >>> OOOk and maybe If I stop reading "Password" when I see "Principal" I >>> would make more sense :-( >>> >>>>> 2.) create a new permission that allows writing to this attribute (i.e. >>>>> Modify Kerberos principal expiration) >>>> >>>> Yep, this sounds right. >>>> >>>>> 3.) add this attribute to a existing permission (Modify users seems like >>>>> the best candidate, however, the attribute does not really fit even there) >>>> >>>> Nope, needs to be explicit for auditing purposes that admins are able to >>>> violate the password policies of users by changing their expiration >>>> date. >>>> >>>>> I see that the the approach 1.) was taken with the krbTicketFlags >>>>> attribute in the past (install/updates/60-trusts.update +38). >>>> >>>> Yes, however I think this too should be probably explicit and have its >>>> own permission with the new permission framework. >>>> >>>>> What would be the best approach here? >>>> >>>> I say 2. >>> >>> Given this is "Principal"'s expiration, I amend my suggestion. >>> >>> I say you can choose either 2 or 3. The *Account Expiration* (which is >>> what really this attribute controls) is clearly a user attribute and it >>> is not strictly necessary to have a separate permission. >>> However it is not a bad idea either. I think there may be cases when >>> some administrative process wants to allow admins to modify users, but >>> not let them extend a user account lifetime. The account lifetime may be >>> something that is controlled by an HR department and should not be >>> modifiable by all admins. >> >> How rare would this case be? We'll have manageable permissions, it >> should be easy to exclude the attribute and add a separate permission >> for it. > > Right which is why I say 2 or 3, I do not have a strong preference, if > it is a hassle to create a new permission now, feel free to fold into > the std modify users permission for now. > > Simo. I still do not understand why we should do #2 or #3 only. Then lower level admins with the permission assigned could do the job, but the super admin still couldn't. IMO doing #1 (and #2 or #3) would make more sense. Martin From tbabej at redhat.com Wed Jan 8 15:41:38 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 08 Jan 2014 16:41:38 +0100 Subject: [Freeipa-devel] Handling of krbPrincpalExpiration in default ACI In-Reply-To: <1389194371.26102.163.camel@willson.li.ssimo.org> References: <52CD47B8.1090302@redhat.com> <1389190780.26102.152.camel@willson.li.ssimo.org> <1389192205.26102.162.camel@willson.li.ssimo.org> <52CD657C.5080800@redhat.com> <1389194371.26102.163.camel@willson.li.ssimo.org> Message-ID: <52CD71B2.3080301@redhat.com> On 01/08/2014 04:19 PM, Simo Sorce wrote: > On Wed, 2014-01-08 at 15:49 +0100, Petr Viktorin wrote: >> On 01/08/2014 03:43 PM, Simo Sorce wrote: >>> On Wed, 2014-01-08 at 09:19 -0500, Simo Sorce wrote: >>>> On Wed, 2014-01-08 at 13:42 +0100, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> I'm working on exposing the krbPrincipalExpiration attribute in the CLI >>>>> (https://fedorahosted.org/freeipa/ticket/3306). However, this attribute >>>>> is exempted from the default ACL "Admin can manage any entry" >>>>> (install/share/default-aci.ldif +8). >>>>> >>>>> Now, we have several options: >>>>> 1.) remove it from blacklisted options in "Admin can manage any entry" ACL >>>> Nope, it was excluded on purpose, to prevent admins from playing with >>>> it. >>> OOOk and maybe If I stop reading "Password" when I see "Principal" I >>> would make more sense :-( >>> >>>>> 2.) create a new permission that allows writing to this attribute (i.e. >>>>> Modify Kerberos principal expiration) >>>> Yep, this sounds right. >>>> >>>>> 3.) add this attribute to a existing permission (Modify users seems like >>>>> the best candidate, however, the attribute does not really fit even there) >>>> Nope, needs to be explicit for auditing purposes that admins are able to >>>> violate the password policies of users by changing their expiration >>>> date. >>>> >>>>> I see that the the approach 1.) was taken with the krbTicketFlags >>>>> attribute in the past (install/updates/60-trusts.update +38). >>>> Yes, however I think this too should be probably explicit and have its >>>> own permission with the new permission framework. >>>> >>>>> What would be the best approach here? >>>> I say 2. >>> Given this is "Principal"'s expiration, I amend my suggestion. >>> >>> I say you can choose either 2 or 3. The *Account Expiration* (which is >>> what really this attribute controls) is clearly a user attribute and it >>> is not strictly necessary to have a separate permission. >>> However it is not a bad idea either. I think there may be cases when >>> some administrative process wants to allow admins to modify users, but >>> not let them extend a user account lifetime. The account lifetime may be >>> something that is controlled by an HR department and should not be >>> modifiable by all admins. >> How rare would this case be? We'll have manageable permissions, it >> should be easy to exclude the attribute and add a separate permission >> for it. > Right which is why I say 2 or 3, I do not have a strong preference, if > it is a hassle to create a new permission now, feel free to fold into > the std modify users permission for now. > > Simo. > Maybe the approach we should take is both #1 and #2. Not taking the #1 doesn't make sense for consistency's sake and reasons Martin mentioned (we do not prevent admin user for doing this anyway, just make it more complicated). For fine-grained permission management, we can create new permission/privilege/role, and that's #2. This can be part of the current permission work, right? Tomas From pviktori at redhat.com Wed Jan 8 15:49:30 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 08 Jan 2014 16:49:30 +0100 Subject: [Freeipa-devel] [PATCHES] 0447-0449 Add support for managed permissions Message-ID: <52CD738A.40105@redhat.com> Hello, This adds "managed" permissions, the framework that will make our default permissions merge IPA updates and user changes sanely. There is no updater yet, nor does this add any actual managed permissions, so there's no user-visible change (beyond help text and a disabled option). To test the patch you might need to touch LDAP directly. Ticket: https://fedorahosted.org/freeipa/ticket/4033 Design (no updater & plugin changes yet): http://www.freeipa.org/page/V3/Managed_Read_permissions 0447 - Minor fixes. 0448 - Since you can't create managed permissions through the API, I needed to get creative with the declarative tests. The tests will need a custom function that adds a managed perm. 0449 - The change itself. FYI, my roadmap: I'll now concentrate on #4074 (Use targetfilter & targetattrfilter in permissions) since it looks like we'll want most of the default permissions to use location + objectclass targetfilter. (The ticket turned out to be trickier than it seems, stay tuned). http://www.redhat.com/archives/freeipa-devel/2013-December/msg00063.html I'm planning to add the updater, and design how plugins will advertise their default permissions, after we decide how most of the default permissions will look. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0447-Permission-plugin-fixes.patch Type: text/x-patch Size: 3959 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0448-Make-it-possible-to-call-custom-functions-in-Declara.patch Type: text/x-patch Size: 1798 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0449-Add-support-for-managed-permissions.patch Type: text/x-patch Size: 27500 bytes Desc: not available URL: From simo at redhat.com Wed Jan 8 16:28:30 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 08 Jan 2014 11:28:30 -0500 Subject: [Freeipa-devel] Handling of krbPrincpalExpiration in default ACI In-Reply-To: <52CD71B2.3080301@redhat.com> References: <52CD47B8.1090302@redhat.com> <1389190780.26102.152.camel@willson.li.ssimo.org> <1389192205.26102.162.camel@willson.li.ssimo.org> <52CD657C.5080800@redhat.com> <1389194371.26102.163.camel@willson.li.ssimo.org> <52CD71B2.3080301@redhat.com> Message-ID: <1389198510.26102.166.camel@willson.li.ssimo.org> On Wed, 2014-01-08 at 16:41 +0100, Tomas Babej wrote: > On 01/08/2014 04:19 PM, Simo Sorce wrote: > > On Wed, 2014-01-08 at 15:49 +0100, Petr Viktorin wrote: > >> On 01/08/2014 03:43 PM, Simo Sorce wrote: > >>> On Wed, 2014-01-08 at 09:19 -0500, Simo Sorce wrote: > >>>> On Wed, 2014-01-08 at 13:42 +0100, Tomas Babej wrote: > >>>>> Hi, > >>>>> > >>>>> I'm working on exposing the krbPrincipalExpiration attribute in the CLI > >>>>> (https://fedorahosted.org/freeipa/ticket/3306). However, this attribute > >>>>> is exempted from the default ACL "Admin can manage any entry" > >>>>> (install/share/default-aci.ldif +8). > >>>>> > >>>>> Now, we have several options: > >>>>> 1.) remove it from blacklisted options in "Admin can manage any entry" ACL > >>>> Nope, it was excluded on purpose, to prevent admins from playing with > >>>> it. > >>> OOOk and maybe If I stop reading "Password" when I see "Principal" I > >>> would make more sense :-( > >>> > >>>>> 2.) create a new permission that allows writing to this attribute (i.e. > >>>>> Modify Kerberos principal expiration) > >>>> Yep, this sounds right. > >>>> > >>>>> 3.) add this attribute to a existing permission (Modify users seems like > >>>>> the best candidate, however, the attribute does not really fit even there) > >>>> Nope, needs to be explicit for auditing purposes that admins are able to > >>>> violate the password policies of users by changing their expiration > >>>> date. > >>>> > >>>>> I see that the the approach 1.) was taken with the krbTicketFlags > >>>>> attribute in the past (install/updates/60-trusts.update +38). > >>>> Yes, however I think this too should be probably explicit and have its > >>>> own permission with the new permission framework. > >>>> > >>>>> What would be the best approach here? > >>>> I say 2. > >>> Given this is "Principal"'s expiration, I amend my suggestion. > >>> > >>> I say you can choose either 2 or 3. The *Account Expiration* (which is > >>> what really this attribute controls) is clearly a user attribute and it > >>> is not strictly necessary to have a separate permission. > >>> However it is not a bad idea either. I think there may be cases when > >>> some administrative process wants to allow admins to modify users, but > >>> not let them extend a user account lifetime. The account lifetime may be > >>> something that is controlled by an HR department and should not be > >>> modifiable by all admins. > >> How rare would this case be? We'll have manageable permissions, it > >> should be easy to exclude the attribute and add a separate permission > >> for it. > > Right which is why I say 2 or 3, I do not have a strong preference, if > > it is a hassle to create a new permission now, feel free to fold into > > the std modify users permission for now. > > > > Simo. > > > Maybe the approach we should take is both #1 and #2. Not taking the #1 > doesn't make sense for consistency's sake and reasons Martin mentioned > (we do not prevent admin user for doing this anyway, just make it more > complicated). > > For fine-grained permission management, we can create new > permission/privilege/role, and that's #2. This can be part of the > current permission work, right? Works for me, having 2 is important for when we rework the current default ACI system and make admins also use permissions. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Wed Jan 8 17:46:27 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 08 Jan 2014 18:46:27 +0100 Subject: [Freeipa-devel] [PATCHES] 0447-0449 Add support for managed permissions In-Reply-To: <52CD738A.40105@redhat.com> References: <52CD738A.40105@redhat.com> Message-ID: <52CD8EF3.4010109@redhat.com> On 01/08/2014 04:49 PM, Petr Viktorin wrote: > Hello, > This adds "managed" permissions, the framework that will make our > default permissions merge IPA updates and user changes sanely. > > There is no updater yet, nor does this add any actual managed > permissions, so there's no user-visible change (beyond help text and a > disabled option). To test the patch you might need to touch LDAP directly. > > Ticket: https://fedorahosted.org/freeipa/ticket/4033 > Design (no updater & plugin changes yet): > http://www.freeipa.org/page/V3/Managed_Read_permissions > > 0447 - Minor fixes. > 0448 - Since you can't create managed permissions through the API, I > needed to get creative with the declarative tests. The tests will need a > custom function that adds a managed perm. > 0449 - The change itself. One thing I meant to write in this mail but forgot: I added a comment to the end of VERSION. There was a patch/thread about this, but it hasn't really reached a conclusion: https://www.redhat.com/archives/freeipa-devel/2013-December/msg00084.html If anyone is still opposed to the comment speak up and I can remove it. > FYI, my roadmap: > I'll now concentrate on #4074 (Use targetfilter & targetattrfilter in > permissions) since it looks like we'll want most of the default > permissions to use location + objectclass targetfilter. (The ticket > turned out to be trickier than it seems, stay tuned). > http://www.redhat.com/archives/freeipa-devel/2013-December/msg00063.html > > I'm planning to add the updater, and design how plugins will advertise > their default permissions, after we decide how most of the default > permissions will look. > -- Petr? From simo at redhat.com Wed Jan 8 23:26:23 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 08 Jan 2014 18:26:23 -0500 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <52A0817E.2080002@redhat.com> References: <52A0817E.2080002@redhat.com> Message-ID: <1389223583.26102.187.camel@willson.li.ssimo.org> On Thu, 2013-12-05 at 14:37 +0100, Jan Cholasta wrote: > Hi, > > the attached patch fixes . See the additional comments on 3977, I think this patch should be NACKed with extreme prejudice if it allows setting arbitrary subjectAltNames. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Jan 9 07:28:39 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 Jan 2014 08:28:39 +0100 Subject: [Freeipa-devel] [PATCHES] 0447-0449 Add support for managed permissions In-Reply-To: <52CD8EF3.4010109@redhat.com> References: <52CD738A.40105@redhat.com> <52CD8EF3.4010109@redhat.com> Message-ID: <52CE4FA7.3040400@redhat.com> On 01/08/2014 06:46 PM, Petr Viktorin wrote: > On 01/08/2014 04:49 PM, Petr Viktorin wrote: >> Hello, >> This adds "managed" permissions, the framework that will make our >> default permissions merge IPA updates and user changes sanely. >> >> There is no updater yet, nor does this add any actual managed >> permissions, so there's no user-visible change (beyond help text and a >> disabled option). To test the patch you might need to touch LDAP directly. >> >> Ticket: https://fedorahosted.org/freeipa/ticket/4033 >> Design (no updater & plugin changes yet): >> http://www.freeipa.org/page/V3/Managed_Read_permissions >> >> 0447 - Minor fixes. >> 0448 - Since you can't create managed permissions through the API, I >> needed to get creative with the declarative tests. The tests will need a >> custom function that adds a managed perm. >> 0449 - The change itself. > > One thing I meant to write in this mail but forgot: I added a comment to the > end of VERSION. > There was a patch/thread about this, but it hasn't really reached a conclusion: > https://www.redhat.com/archives/freeipa-devel/2013-December/msg00084.html > If anyone is still opposed to the comment speak up and I can remove it. +1 for using the comment from me, if some server side setting is not an option. The format you used -IPA_API_VERSION_MINOR=72 +IPA_API_VERSION_MINOR=73 +# Last change: pviktori - Managed permissions is quite lightweight and not a burden to write. Martin From abokovoy at redhat.com Thu Jan 9 07:41:16 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 9 Jan 2014 09:41:16 +0200 Subject: [Freeipa-devel] [PATCHES] 0447-0449 Add support for managed permissions In-Reply-To: <52CE4FA7.3040400@redhat.com> References: <52CD738A.40105@redhat.com> <52CD8EF3.4010109@redhat.com> <52CE4FA7.3040400@redhat.com> Message-ID: <20140109074116.GR12003@redhat.com> On Thu, 09 Jan 2014, Martin Kosek wrote: >On 01/08/2014 06:46 PM, Petr Viktorin wrote: >> On 01/08/2014 04:49 PM, Petr Viktorin wrote: >>> Hello, >>> This adds "managed" permissions, the framework that will make our >>> default permissions merge IPA updates and user changes sanely. >>> >>> There is no updater yet, nor does this add any actual managed >>> permissions, so there's no user-visible change (beyond help text and a >>> disabled option). To test the patch you might need to touch LDAP directly. >>> >>> Ticket: https://fedorahosted.org/freeipa/ticket/4033 >>> Design (no updater & plugin changes yet): >>> http://www.freeipa.org/page/V3/Managed_Read_permissions >>> >>> 0447 - Minor fixes. >>> 0448 - Since you can't create managed permissions through the API, I >>> needed to get creative with the declarative tests. The tests will need a >>> custom function that adds a managed perm. >>> 0449 - The change itself. >> >> One thing I meant to write in this mail but forgot: I added a comment to the >> end of VERSION. >> There was a patch/thread about this, but it hasn't really reached a conclusion: >> https://www.redhat.com/archives/freeipa-devel/2013-December/msg00084.html >> If anyone is still opposed to the comment speak up and I can remove it. > >+1 for using the comment from me, if some server side setting is not an option. >The format you used > >-IPA_API_VERSION_MINOR=72 >+IPA_API_VERSION_MINOR=73 >+# Last change: pviktori - Managed permissions > >is quite lightweight and not a burden to write. I agree, it is simple and clear. -- / Alexander Bokovoy From mkosek at redhat.com Thu Jan 9 08:51:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 Jan 2014 09:51:28 +0100 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <1389223583.26102.187.camel@willson.li.ssimo.org> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> Message-ID: <52CE6310.6030009@redhat.com> On 01/09/2014 12:26 AM, Simo Sorce wrote: > On Thu, 2013-12-05 at 14:37 +0100, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . > > See the additional comments on 3977, I think this patch should be NACKed > with extreme prejudice if it allows setting arbitrary subjectAltNames. > > Simo. > It does not allow them - SANs are being authorized by using the managedBy attribute on the SAN-ed host/service (i.e. host-add-managedby/service-add-host commands). But you are right that the authorization part should not be taken lightly and should be verified before we allow SANs in default profile. I added a comment in the Trac as well. Martin From pviktori at redhat.com Thu Jan 9 12:15:54 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 09 Jan 2014 13:15:54 +0100 Subject: [Freeipa-devel] Objectclasses for target filters in default permissions Message-ID: <52CE92FA.3090908@redhat.com> Hello, When I'm done with [#4074], the "type" permissions will use a target filter, e.g.: ipa permission-add \ 'Modify Account Expiration' \ --attr=krbPrincipalExpiration \ --type=user --perm=write should result in this ACI at cn=users,...: (targetattr = "krbPrincipalExpiration") (targetfilter = "(objectclass=ipauser)") (version 3.0; acl "permission:Modify Account Expiration"; allow (write) groupdn = "ldap:///cn=Modify Account Expiration,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com";) The probjem is matching the "user" type with the "ipauser" objectclass. I've looked, but I don't think we have such "canonical objectclasses" defined anywhere in the code. There is object_class and possible_objectclasses for each object type in the plugins, but these aren't adequate: user has "posixaccount"; some have multiple objectclasses listed (even `top` in one case). (Of course it's not a problem to add multiple classes to the filter, it just seems superfluous.) I'd like to add a new attribute to LDAPObject that lists the objectclass(es) for permission filters. This would also mean the list of allowed `type`s for permissions can be pulled from the plugins, rather than being hardcoded in the aci/permission plugin. Here's a list of proposed classes, and the existing lists for reference: user: proposed for filter: ipauser object_class: posixaccount possible_objectclasses: meporiginentry, ipauserauthtypeclass, ipauser, ipatokenradiusproxyuser group: proposed for filter: ipausergroup object_class: ipausergroup possible_objectclasses: posixGroup, mepManagedEntry, ipaExternalGroup host: proposed for filter: ipahost object_class: ipaobject, nshost, ipahost, pkiuser, ipaservice possible_objectclasses: (none) service: proposed for filter: ipaservice object_class: krbprincipal, krbprincipalaux, krbticketpolicyaux, ipaobject, ipaservice, pkiuser possible_objectclasses: ipakrbprincipal hostgroup: proposed for filter: ipahostgroup object_class: ipaobject, ipahostgroup possible_objectclasses: (none) netgroup: proposed for filter: ipanisnetgroup object_class: ipaobject, ipaassociation, ipanisnetgroup possible_objectclasses: (none) dnsrecord: proposed for filter: idnsrecord object_class: top, idnsrecord possible_objectclasses: (none) [#4074]: https://fedorahosted.org/freeipa/ticket/4074 -- Petr? From mkosek at redhat.com Thu Jan 9 13:02:11 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 Jan 2014 14:02:11 +0100 Subject: [Freeipa-devel] Objectclasses for target filters in default permissions In-Reply-To: <52CE92FA.3090908@redhat.com> References: <52CE92FA.3090908@redhat.com> Message-ID: <52CE9DD3.2030301@redhat.com> On 01/09/2014 01:15 PM, Petr Viktorin wrote: > Hello, > When I'm done with [#4074], the "type" permissions will use a target filter, e.g.: > > ipa permission-add \ > 'Modify Account Expiration' \ > --attr=krbPrincipalExpiration \ > --type=user --perm=write > > should result in this ACI at cn=users,...: > > (targetattr = "krbPrincipalExpiration") > (targetfilter = "(objectclass=ipauser)") > (version 3.0; > acl "permission:Modify Account Expiration"; > allow (write) groupdn = "ldap:///cn=Modify Account > Expiration,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com";) > > The probjem is matching the "user" type with the "ipauser" objectclass. > I've looked, but I don't think we have such "canonical objectclasses" defined > anywhere in the code. There is object_class and possible_objectclasses for each > object type in the plugins, but these aren't adequate: user has "posixaccount"; > some have multiple objectclasses listed (even `top` in one case). (Of course > it's not a problem to add multiple classes to the filter, it just seems > superfluous.) > I'd like to add a new attribute to LDAPObject that lists the objectclass(es) > for permission filters. This would also mean the list of allowed `type`s for > permissions can be pulled from the plugins, rather than being hardcoded in the > aci/permission plugin. Sounds like a good idea. > > Here's a list of proposed classes, and the existing lists for reference: > > > user: > proposed for filter: ipauser > object_class: posixaccount > possible_objectclasses: meporiginentry, ipauserauthtypeclass, ipauser, > ipatokenradiusproxyuser Not sure about this one. ipauser is only given to the new users, after ipausers was introduced, right? In this case, posixaccount may be a better choice. > > group: > proposed for filter: ipausergroup > object_class: ipausergroup > possible_objectclasses: posixGroup, mepManagedEntry, ipaExternalGroup > > host: > proposed for filter: ipahost > object_class: ipaobject, nshost, ipahost, pkiuser, ipaservice > possible_objectclasses: (none) > > service: > proposed for filter: ipaservice > object_class: krbprincipal, krbprincipalaux, krbticketpolicyaux, ipaobject, > ipaservice, pkiuser > possible_objectclasses: ipakrbprincipal > > hostgroup: > proposed for filter: ipahostgroup > object_class: ipaobject, ipahostgroup > possible_objectclasses: (none) > > netgroup: > proposed for filter: ipanisnetgroup > object_class: ipaobject, ipaassociation, ipanisnetgroup > possible_objectclasses: (none) > > dnsrecord: > proposed for filter: idnsrecord > object_class: top, idnsrecord > possible_objectclasses: (none) Looks good to me. You also missed some other non-account object like SUDO or HBAC, but it should be easy there as they usually have a ipa* canonical base objectclass, i.e. ipahbacrule, ipahbacservice, ipahbacservicegroup, ipaselinuxusermap, ipasudocmd, ipasudocmdgrp, ipasudorule, ipaNTTrustedDomain. Just the pwpolicy object do now have our own objectclass, but I think we could work with costemplate and krbpwdpolicy objectclasses. Martin From pviktori at redhat.com Thu Jan 9 13:05:47 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 09 Jan 2014 14:05:47 +0100 Subject: [Freeipa-devel] Objectclasses for target filters in default permissions In-Reply-To: <52CE9DD3.2030301@redhat.com> References: <52CE92FA.3090908@redhat.com> <52CE9DD3.2030301@redhat.com> Message-ID: <52CE9EAB.9050605@redhat.com> On 01/09/2014 02:02 PM, Martin Kosek wrote: > On 01/09/2014 01:15 PM, Petr Viktorin wrote: >> Hello, >> When I'm done with [#4074], the "type" permissions will use a target filter, e.g.: >> >> ipa permission-add \ >> 'Modify Account Expiration' \ >> --attr=krbPrincipalExpiration \ >> --type=user --perm=write >> >> should result in this ACI at cn=users,...: >> >> (targetattr = "krbPrincipalExpiration") >> (targetfilter = "(objectclass=ipauser)") >> (version 3.0; >> acl "permission:Modify Account Expiration"; >> allow (write) groupdn = "ldap:///cn=Modify Account >> Expiration,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com";) >> >> The probjem is matching the "user" type with the "ipauser" objectclass. >> I've looked, but I don't think we have such "canonical objectclasses" defined >> anywhere in the code. There is object_class and possible_objectclasses for each >> object type in the plugins, but these aren't adequate: user has "posixaccount"; >> some have multiple objectclasses listed (even `top` in one case). (Of course >> it's not a problem to add multiple classes to the filter, it just seems >> superfluous.) >> I'd like to add a new attribute to LDAPObject that lists the objectclass(es) >> for permission filters. This would also mean the list of allowed `type`s for >> permissions can be pulled from the plugins, rather than being hardcoded in the >> aci/permission plugin. > > Sounds like a good idea. > >> >> Here's a list of proposed classes, and the existing lists for reference: >> >> >> user: >> proposed for filter: ipauser >> object_class: posixaccount >> possible_objectclasses: meporiginentry, ipauserauthtypeclass, ipauser, >> ipatokenradiusproxyuser > > Not sure about this one. ipauser is only given to the new users, after ipausers > was introduced, right? > > In this case, posixaccount may be a better choice. OK >> group: >> proposed for filter: ipausergroup >> object_class: ipausergroup >> possible_objectclasses: posixGroup, mepManagedEntry, ipaExternalGroup >> >> host: >> proposed for filter: ipahost >> object_class: ipaobject, nshost, ipahost, pkiuser, ipaservice >> possible_objectclasses: (none) >> >> service: >> proposed for filter: ipaservice >> object_class: krbprincipal, krbprincipalaux, krbticketpolicyaux, ipaobject, >> ipaservice, pkiuser >> possible_objectclasses: ipakrbprincipal >> >> hostgroup: >> proposed for filter: ipahostgroup >> object_class: ipaobject, ipahostgroup >> possible_objectclasses: (none) >> >> netgroup: >> proposed for filter: ipanisnetgroup >> object_class: ipaobject, ipaassociation, ipanisnetgroup >> possible_objectclasses: (none) >> >> dnsrecord: >> proposed for filter: idnsrecord >> object_class: top, idnsrecord >> possible_objectclasses: (none) > > Looks good to me. You also missed some other non-account object like SUDO or > HBAC, but it should be easy there as they usually have a ipa* canonical base > objectclass, i.e. ipahbacrule, ipahbacservice, > ipahbacservicegroup, ipaselinuxusermap, ipasudocmd, ipasudocmdgrp, ipasudorule, > ipaNTTrustedDomain. Well, I've only listed what is allowed in permissions' --type option now. We can add others as we design read permissions for them. > Just the pwpolicy object do now have our own objectclass, but I think we could > work with costemplate and krbpwdpolicy objectclasses. -- Petr? From simo at redhat.com Thu Jan 9 14:04:16 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 09 Jan 2014 09:04:16 -0500 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <52CE6310.6030009@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> Message-ID: <1389276256.26102.211.camel@willson.li.ssimo.org> On Thu, 2014-01-09 at 09:51 +0100, Martin Kosek wrote: > On 01/09/2014 12:26 AM, Simo Sorce wrote: > > On Thu, 2013-12-05 at 14:37 +0100, Jan Cholasta wrote: > >> Hi, > >> > >> the attached patch fixes . > > > > See the additional comments on 3977, I think this patch should be NACKed > > with extreme prejudice if it allows setting arbitrary subjectAltNames. > > > > Simo. > > > > It does not allow them - SANs are being authorized by using the managedBy > attribute on the SAN-ed host/service (i.e. host-add-managedby/service-add-host > commands). This means that in order to add a subjectAltName you have to register a Host with that name ? That is not really convenient, but if it works at least it properly constrains potential hijacking. > But you are right that the authorization part should not be taken lightly and > should be verified before we allow SANs in default profile. I added a comment > in the Trac as well. Yes we definitely need a test to make 100% sure this cannot be worked around, the security consequences would be disastrous. Also maybe we should allow admins to bypass the need to have an actual object to represent the alt name ? We will need this type of functionality if we want to allow admins to create wildcard certificates anyway, which is another important use case for hosting/cloud-like services. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Jan 9 14:07:55 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 09 Jan 2014 09:07:55 -0500 Subject: [Freeipa-devel] Objectclasses for target filters in default permissions In-Reply-To: <52CE92FA.3090908@redhat.com> References: <52CE92FA.3090908@redhat.com> Message-ID: <1389276475.26102.212.camel@willson.li.ssimo.org> On Thu, 2014-01-09 at 13:15 +0100, Petr Viktorin wrote: > Hello, > When I'm done with [#4074], the "type" permissions will use a target > filter, e.g.: > > ipa permission-add \ > 'Modify Account Expiration' \ > --attr=krbPrincipalExpiration \ > --type=user --perm=write > > should result in this ACI at cn=users,...: > > (targetattr = "krbPrincipalExpiration") > (targetfilter = "(objectclass=ipauser)") > (version 3.0; > acl "permission:Modify Account Expiration"; > allow (write) groupdn = "ldap:///cn=Modify Account > Expiration,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com";) > > The probjem is matching the "user" type with the "ipauser" objectclass. > I've looked, but I don't think we have such "canonical objectclasses" > defined anywhere in the code. There is object_class and > possible_objectclasses for each object type in the plugins, but these > aren't adequate: user has "posixaccount"; some have multiple > objectclasses listed (even `top` in one case). (Of course it's not a > problem to add multiple classes to the filter, it just seems superfluous.) > I'd like to add a new attribute to LDAPObject that lists the > objectclass(es) for permission filters. This would also mean the list of > allowed `type`s for permissions can be pulled from the plugins, rather > than being hardcoded in the aci/permission plugin. Sounds reasonable, I trust the objetclass can be manually changed anyway if an admin needs to do so ? Simo. > Here's a list of proposed classes, and the existing lists for reference: > > > user: > proposed for filter: ipauser > object_class: posixaccount > possible_objectclasses: meporiginentry, ipauserauthtypeclass, > ipauser, ipatokenradiusproxyuser > > group: > proposed for filter: ipausergroup > object_class: ipausergroup > possible_objectclasses: posixGroup, mepManagedEntry, ipaExternalGroup > > host: > proposed for filter: ipahost > object_class: ipaobject, nshost, ipahost, pkiuser, ipaservice > possible_objectclasses: (none) > > service: > proposed for filter: ipaservice > object_class: krbprincipal, krbprincipalaux, krbticketpolicyaux, > ipaobject, ipaservice, pkiuser > possible_objectclasses: ipakrbprincipal > > hostgroup: > proposed for filter: ipahostgroup > object_class: ipaobject, ipahostgroup > possible_objectclasses: (none) > > netgroup: > proposed for filter: ipanisnetgroup > object_class: ipaobject, ipaassociation, ipanisnetgroup > possible_objectclasses: (none) > > dnsrecord: > proposed for filter: idnsrecord > object_class: top, idnsrecord > possible_objectclasses: (none) > > > [#4074]: https://fedorahosted.org/freeipa/ticket/4074 > -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Jan 9 14:12:19 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 09 Jan 2014 09:12:19 -0500 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <1389276256.26102.211.camel@willson.li.ssimo.org> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> Message-ID: <1389276739.26102.215.camel@willson.li.ssimo.org> On Thu, 2014-01-09 at 09:04 -0500, Simo Sorce wrote: > On Thu, 2014-01-09 at 09:51 +0100, Martin Kosek wrote: > > On 01/09/2014 12:26 AM, Simo Sorce wrote: > > > On Thu, 2013-12-05 at 14:37 +0100, Jan Cholasta wrote: > > >> Hi, > > >> > > >> the attached patch fixes . > > > > > > See the additional comments on 3977, I think this patch should be NACKed > > > with extreme prejudice if it allows setting arbitrary subjectAltNames. > > > > > > Simo. > > > > > > > It does not allow them - SANs are being authorized by using the managedBy > > attribute on the SAN-ed host/service (i.e. host-add-managedby/service-add-host > > commands). > > This means that in order to add a subjectAltName you have to register a > Host with that name ? That is not really convenient, but if it works at > least it properly constrains potential hijacking. > > > But you are right that the authorization part should not be taken lightly and > > should be verified before we allow SANs in default profile. I added a comment > > in the Trac as well. > > Yes we definitely need a test to make 100% sure this cannot be worked > around, the security consequences would be disastrous. > > Also maybe we should allow admins to bypass the need to have an actual > object to represent the alt name ? > > We will need this type of functionality if we want to allow admins to > create wildcard certificates anyway, which is another important use case > for hosting/cloud-like services. I was also thinking admins may want to allow a lower privileged admin to manage a host, but not allow them to add a special subjectaltname to random other hosts he manages. In this case again we need the ability for an admin to be able to provide the cert to the host. Also then a special case arises on automatic renew from certmonger, all names need to be checked against the old certificate being renewed, so authorization in that case would have to be based on the previous cert names and not on managedby, right ? If not automatic renewal would fail ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Thu Jan 9 14:14:42 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 09 Jan 2014 15:14:42 +0100 Subject: [Freeipa-devel] Objectclasses for target filters in default permissions In-Reply-To: <1389276475.26102.212.camel@willson.li.ssimo.org> References: <52CE92FA.3090908@redhat.com> <1389276475.26102.212.camel@willson.li.ssimo.org> Message-ID: <52CEAED2.8030905@redhat.com> On 01/09/2014 03:07 PM, Simo Sorce wrote: > On Thu, 2014-01-09 at 13:15 +0100, Petr Viktorin wrote: >> Hello, >> When I'm done with [#4074], the "type" permissions will use a target >> filter, e.g.: >> >> ipa permission-add \ >> 'Modify Account Expiration' \ >> --attr=krbPrincipalExpiration \ >> --type=user --perm=write >> >> should result in this ACI at cn=users,...: >> >> (targetattr = "krbPrincipalExpiration") >> (targetfilter = "(objectclass=ipauser)") >> (version 3.0; >> acl "permission:Modify Account Expiration"; >> allow (write) groupdn = "ldap:///cn=Modify Account >> Expiration,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com";) >> >> The probjem is matching the "user" type with the "ipauser" objectclass. >> I've looked, but I don't think we have such "canonical objectclasses" >> defined anywhere in the code. There is object_class and >> possible_objectclasses for each object type in the plugins, but these >> aren't adequate: user has "posixaccount"; some have multiple >> objectclasses listed (even `top` in one case). (Of course it's not a >> problem to add multiple classes to the filter, it just seems superfluous.) >> I'd like to add a new attribute to LDAPObject that lists the >> objectclass(es) for permission filters. This would also mean the list of >> allowed `type`s for permissions can be pulled from the plugins, rather >> than being hardcoded in the aci/permission plugin. > > Sounds reasonable, I trust the objetclass can be manually changed anyway > if an admin needs to do so ? > > Simo. Yes, `type` is just a convenience shortcut to set the location + filter, which can be manipulated individually. Removing the objectclass filter would make the permission no longer show up as that `type`. -- Petr? From simo at redhat.com Thu Jan 9 14:20:28 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 09 Jan 2014 09:20:28 -0500 Subject: [Freeipa-devel] Objectclasses for target filters in default permissions In-Reply-To: <52CEAED2.8030905@redhat.com> References: <52CE92FA.3090908@redhat.com> <1389276475.26102.212.camel@willson.li.ssimo.org> <52CEAED2.8030905@redhat.com> Message-ID: <1389277228.26102.219.camel@willson.li.ssimo.org> On Thu, 2014-01-09 at 15:14 +0100, Petr Viktorin wrote: > On 01/09/2014 03:07 PM, Simo Sorce wrote: > > On Thu, 2014-01-09 at 13:15 +0100, Petr Viktorin wrote: > >> Hello, > >> When I'm done with [#4074], the "type" permissions will use a target > >> filter, e.g.: > >> > >> ipa permission-add \ > >> 'Modify Account Expiration' \ > >> --attr=krbPrincipalExpiration \ > >> --type=user --perm=write > >> > >> should result in this ACI at cn=users,...: > >> > >> (targetattr = "krbPrincipalExpiration") > >> (targetfilter = "(objectclass=ipauser)") > >> (version 3.0; > >> acl "permission:Modify Account Expiration"; > >> allow (write) groupdn = "ldap:///cn=Modify Account > >> Expiration,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com";) > >> > >> The probjem is matching the "user" type with the "ipauser" objectclass. > >> I've looked, but I don't think we have such "canonical objectclasses" > >> defined anywhere in the code. There is object_class and > >> possible_objectclasses for each object type in the plugins, but these > >> aren't adequate: user has "posixaccount"; some have multiple > >> objectclasses listed (even `top` in one case). (Of course it's not a > >> problem to add multiple classes to the filter, it just seems superfluous.) > >> I'd like to add a new attribute to LDAPObject that lists the > >> objectclass(es) for permission filters. This would also mean the list of > >> allowed `type`s for permissions can be pulled from the plugins, rather > >> than being hardcoded in the aci/permission plugin. > > > > Sounds reasonable, I trust the objetclass can be manually changed anyway > > if an admin needs to do so ? > > > > Simo. > > Yes, `type` is just a convenience shortcut to set the location + filter, > which can be manipulated individually. > Removing the objectclass filter would make the permission no longer show > up as that `type`. The question I think was more nuanced. Will we allow the creation of custom permissions for UI/CLI ? In that case will the admin be able to just provide a custom objectclass name ? I guess the answer is yes, but just checking. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Thu Jan 9 14:24:06 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 09 Jan 2014 15:24:06 +0100 Subject: [Freeipa-devel] Objectclasses for target filters in default permissions In-Reply-To: <1389277228.26102.219.camel@willson.li.ssimo.org> References: <52CE92FA.3090908@redhat.com> <1389276475.26102.212.camel@willson.li.ssimo.org> <52CEAED2.8030905@redhat.com> <1389277228.26102.219.camel@willson.li.ssimo.org> Message-ID: <52CEB106.8070800@redhat.com> On 01/09/2014 03:20 PM, Simo Sorce wrote: > On Thu, 2014-01-09 at 15:14 +0100, Petr Viktorin wrote: >> On 01/09/2014 03:07 PM, Simo Sorce wrote: >>> On Thu, 2014-01-09 at 13:15 +0100, Petr Viktorin wrote: >>>> Hello, >>>> When I'm done with [#4074], the "type" permissions will use a target >>>> filter, e.g.: >>>> >>>> ipa permission-add \ >>>> 'Modify Account Expiration' \ >>>> --attr=krbPrincipalExpiration \ >>>> --type=user --perm=write >>>> >>>> should result in this ACI at cn=users,...: >>>> >>>> (targetattr = "krbPrincipalExpiration") >>>> (targetfilter = "(objectclass=ipauser)") >>>> (version 3.0; >>>> acl "permission:Modify Account Expiration"; >>>> allow (write) groupdn = "ldap:///cn=Modify Account >>>> Expiration,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com";) >>>> >>>> The probjem is matching the "user" type with the "ipauser" objectclass. >>>> I've looked, but I don't think we have such "canonical objectclasses" >>>> defined anywhere in the code. There is object_class and >>>> possible_objectclasses for each object type in the plugins, but these >>>> aren't adequate: user has "posixaccount"; some have multiple >>>> objectclasses listed (even `top` in one case). (Of course it's not a >>>> problem to add multiple classes to the filter, it just seems superfluous.) >>>> I'd like to add a new attribute to LDAPObject that lists the >>>> objectclass(es) for permission filters. This would also mean the list of >>>> allowed `type`s for permissions can be pulled from the plugins, rather >>>> than being hardcoded in the aci/permission plugin. >>> >>> Sounds reasonable, I trust the objetclass can be manually changed anyway >>> if an admin needs to do so ? >>> >>> Simo. >> >> Yes, `type` is just a convenience shortcut to set the location + filter, >> which can be manipulated individually. >> Removing the objectclass filter would make the permission no longer show >> up as that `type`. Ah I forgot to mention this, sorry: For the default permissions (the ones that come with IPA), the admin won't be able to change the target at all. But any custom ones can be changed. > The question I think was more nuanced. Will we allow the creation of > custom permissions for UI/CLI ? In that case will the admin be able to > just provide a custom objectclass name ? I guess the answer is yes, but > just checking. Yes. -- Petr? From mkosek at redhat.com Thu Jan 9 14:27:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 Jan 2014 15:27:03 +0100 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <1389276739.26102.215.camel@willson.li.ssimo.org> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> Message-ID: <52CEB1B7.8050306@redhat.com> On 01/09/2014 03:12 PM, Simo Sorce wrote: > On Thu, 2014-01-09 at 09:04 -0500, Simo Sorce wrote: >> On Thu, 2014-01-09 at 09:51 +0100, Martin Kosek wrote: >>> On 01/09/2014 12:26 AM, Simo Sorce wrote: >>>> On Thu, 2013-12-05 at 14:37 +0100, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patch fixes . >>>> >>>> See the additional comments on 3977, I think this patch should be NACKed >>>> with extreme prejudice if it allows setting arbitrary subjectAltNames. >>>> >>>> Simo. >>>> >>> >>> It does not allow them - SANs are being authorized by using the managedBy >>> attribute on the SAN-ed host/service (i.e. host-add-managedby/service-add-host >>> commands). >> >> This means that in order to add a subjectAltName you have to register a >> Host with that name ? That is not really convenient, but if it works at >> least it properly constrains potential hijacking. Right. The host does not need to even be enrolled to make this work. But it is still better to make it this way that to allow hosts to request SANs. >> >>> But you are right that the authorization part should not be taken lightly and >>> should be verified before we allow SANs in default profile. I added a comment >>> in the Trac as well. >> >> Yes we definitely need a test to make 100% sure this cannot be worked >> around, the security consequences would be disastrous. +1 >> Also maybe we should allow admins to bypass the need to have an actual >> object to represent the alt name ? cert requests issued by admin can bypass this check, it is only applied to principals starting with "host/", i.e. for example to certs renewed by certmonger. Other requests are authorized differently. cert-request is a VirtualCommand and people are authorized by checking if they have a write access to the appropriate virtual operation LDAP entry, living in cn=virtual operations,cn=etc,SUFFIX... Which is by default only the admins group members which have the god-like special ACI we discussed yesterday. Rob is that correct? You also participated in the VirtualCommand coding... >> >> We will need this type of functionality if we want to allow admins to >> create wildcard certificates anyway, which is another important use case >> for hosting/cloud-like services. > > > I was also thinking admins may want to allow a lower privileged admin to > manage a host, but not allow them to add a special subjectaltname to > random other hosts he manages. In this case again we need the ability > for an admin to be able to provide the cert to the host. Also then a > special case arises on automatic renew from certmonger, all names need > to be checked against the old certificate being renewed, so > authorization in that case would have to be based on the previous cert > names and not on managedby, right ? > If not automatic renewal would fail ? Hmm, the renewal would fail in this case. admin would have to request new certificate manually in this case (when mangedby attribute is not set properly). Previous certificate is not checked by the cert-request authorization code. Martin From simo at redhat.com Thu Jan 9 14:37:23 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 09 Jan 2014 09:37:23 -0500 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <52CEB1B7.8050306@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> Message-ID: <1389278243.26102.227.camel@willson.li.ssimo.org> On Thu, 2014-01-09 at 15:27 +0100, Martin Kosek wrote: > On 01/09/2014 03:12 PM, Simo Sorce wrote: > > On Thu, 2014-01-09 at 09:04 -0500, Simo Sorce wrote: > >> On Thu, 2014-01-09 at 09:51 +0100, Martin Kosek wrote: > >>> On 01/09/2014 12:26 AM, Simo Sorce wrote: > >>>> On Thu, 2013-12-05 at 14:37 +0100, Jan Cholasta wrote: > >>>>> Hi, > >>>>> > >>>>> the attached patch fixes . > >>>> > >>>> See the additional comments on 3977, I think this patch should be NACKed > >>>> with extreme prejudice if it allows setting arbitrary subjectAltNames. > >>>> > >>>> Simo. > >>>> > >>> > >>> It does not allow them - SANs are being authorized by using the managedBy > >>> attribute on the SAN-ed host/service (i.e. host-add-managedby/service-add-host > >>> commands). > >> > >> This means that in order to add a subjectAltName you have to register a > >> Host with that name ? That is not really convenient, but if it works at > >> least it properly constrains potential hijacking. > > Right. The host does not need to even be enrolled to make this work. But it is > still better to make it this way that to allow hosts to request SANs. > > >> > >>> But you are right that the authorization part should not be taken lightly and > >>> should be verified before we allow SANs in default profile. I added a comment > >>> in the Trac as well. > >> > >> Yes we definitely need a test to make 100% sure this cannot be worked > >> around, the security consequences would be disastrous. > > +1 > > >> Also maybe we should allow admins to bypass the need to have an actual > >> object to represent the alt name ? > > cert requests issued by admin can bypass this check, it is only applied to > principals starting with "host/", i.e. for example to certs renewed by certmonger. > > Other requests are authorized differently. cert-request is a VirtualCommand and > people are authorized by checking if they have a write access to the > appropriate virtual operation LDAP entry, living in cn=virtual > operations,cn=etc,SUFFIX... Which is by default only the admins group members > which have the god-like special ACI we discussed yesterday. Rob is that > correct? You also participated in the VirtualCommand coding... The situation sounds sub-optimal, I would think that giving managedby to a 'junior-admin' user would allow him to also fetch certs but only for the machines they manage. Is the Virtual Permission an all or nothing thing ? or can it be scoped to group of machines ? If the latter, fine, if not, not so much. Although, if the junior-admin can gain root on the host, he can still get certs using the host/ key so maybe that is not fundamental, but it would need clear documentation on how to allow a less privileged admin to perform these functions. > >> We will need this type of functionality if we want to allow admins to > >> create wildcard certificates anyway, which is another important use case > >> for hosting/cloud-like services. > > > > > > I was also thinking admins may want to allow a lower privileged admin to > > manage a host, but not allow them to add a special subjectaltname to > > random other hosts he manages. In this case again we need the ability > > for an admin to be able to provide the cert to the host. Also then a > > special case arises on automatic renew from certmonger, all names need > > to be checked against the old certificate being renewed, so > > authorization in that case would have to be based on the previous cert > > names and not on managedby, right ? > > If not automatic renewal would fail ? > > Hmm, the renewal would fail in this case. admin would have to request new > certificate manually in this case (when mangedby attribute is not set > properly). Previous certificate is not checked by the cert-request > authorization code. I think the renewal problem is more important. Failing renewals cripples one of the most important features of using FreeIPA as your CA for enrolled hosts. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbabej at redhat.com Thu Jan 9 15:30:54 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 09 Jan 2014 16:30:54 +0100 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter Message-ID: <52CEC0AE.9040502@redhat.com> Hi, Adds a parameter that represents a DateTime format using datetime.datetime object from python's native datetime library. In the CLI, accepts one of the following formats: Accepts subset of values defined by ISO 8601: %Y-%m-%dT%H:%M:%S %Y-%m-%dT%H:%M '%Y%m%dT%H:%M:%S' '%Y%m%dT%H:%M' Also accepts LDAP Generalized time in the following format: '%Y%m%d%H%M%SZ' As a simplification, it does not deal with timezone info and ISO 8601 values with timezone info (+-hhmm) are rejected. Values are expected to be in the UTC timezone. Values are saved to LDAP as LDAP Generalized time values in the format '%Y%m%d%H%SZ' (no time fractions and UTC timezone is assumed). To avoid confusion, in addition to subset of ISO 8601 values, the LDAP generalized time in the format '%Y%m%d%H%M%SZ' is also accepted as an input (as this is the format user will see on the output). Part of: https://fedorahosted.org/freeipa/ticket/3306 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0137-ipalib-Add-DateTime-parameter.patch Type: text/x-patch Size: 6695 bytes Desc: not available URL: From tbabej at redhat.com Thu Jan 9 15:31:21 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 09 Jan 2014 16:31:21 +0100 Subject: [Freeipa-devel] [PATCH 0138] ipalib: Expose krbPrincipalExpiration in CLI Message-ID: <52CEC0C9.70905@redhat.com> Hi, Adds a krbPrincipalExpiration attribute to the user class in user.py ipalib plugin as a DateTime parameter. Part of: https://fedorahosted.org/freeipa/ticket/3306 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0138-ipalib-Expose-krbPrincipalExpiration-in-CLI.patch Type: text/x-patch Size: 7330 bytes Desc: not available URL: From tbabej at redhat.com Thu Jan 9 15:31:50 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 09 Jan 2014 16:31:50 +0100 Subject: [Freeipa-devel] [PATCH 0139] acl: Remove krbPrincipalExpiration from list of excluded attrs Message-ID: <52CEC0E6.6030706@redhat.com> Hi, Since we're exposing the krbPrincipalExpiration attribute for direct editing in the CLI, remove it from the list of attributes that admin cannot edit by default. Part of: https://fedorahosted.org/freeipa/ticket/3306 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0139-acl-Remove-krbPrincipalExpiration-from-list-of-admin.patch Type: text/x-patch Size: 8893 bytes Desc: not available URL: From tbabej at redhat.com Thu Jan 9 15:32:34 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 09 Jan 2014 16:32:34 +0100 Subject: [Freeipa-devel] [PATCH 0140] [PATCH 140/140] ipalib: Use DateTime parameter class for OTP token Message-ID: <52CEC112.9010802@redhat.com> Hi, For ipatokennotbefore and ipatokennotafter attributes use DateTime parameter class instead of Str, since these are represented as LDAP Generalized Time in LDAP. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0140-ipalib-Use-DateTime-parameter-class-for-OTP-token-ti.patch Type: text/x-patch Size: 6642 bytes Desc: not available URL: From rcritten at redhat.com Thu Jan 9 15:44:42 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 09 Jan 2014 10:44:42 -0500 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <52CEB1B7.8050306@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> Message-ID: <52CEC3EA.7040401@redhat.com> Martin Kosek wrote: > On 01/09/2014 03:12 PM, Simo Sorce wrote: >> On Thu, 2014-01-09 at 09:04 -0500, Simo Sorce wrote: >>> On Thu, 2014-01-09 at 09:51 +0100, Martin Kosek wrote: >>>> On 01/09/2014 12:26 AM, Simo Sorce wrote: >>>>> On Thu, 2013-12-05 at 14:37 +0100, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> the attached patch fixes . >>>>> >>>>> See the additional comments on 3977, I think this patch should be NACKed >>>>> with extreme prejudice if it allows setting arbitrary subjectAltNames. >>>>> >>>>> Simo. >>>>> >>>> >>>> It does not allow them - SANs are being authorized by using the managedBy >>>> attribute on the SAN-ed host/service (i.e. host-add-managedby/service-add-host >>>> commands). >>> >>> This means that in order to add a subjectAltName you have to register a >>> Host with that name ? That is not really convenient, but if it works at >>> least it properly constrains potential hijacking. > > Right. The host does not need to even be enrolled to make this work. But it is > still better to make it this way that to allow hosts to request SANs. > >>> >>>> But you are right that the authorization part should not be taken lightly and >>>> should be verified before we allow SANs in default profile. I added a comment >>>> in the Trac as well. >>> >>> Yes we definitely need a test to make 100% sure this cannot be worked >>> around, the security consequences would be disastrous. > > +1 > >>> Also maybe we should allow admins to bypass the need to have an actual >>> object to represent the alt name ? I'd rather not. This would allow a rogue admin to create a cert for www.google.com. Sure, they could also create a host for that but forcing them to add more entries increases the chances of them getting caught doing it. > > cert requests issued by admin can bypass this check, it is only applied to > principals starting with "host/", i.e. for example to certs renewed by certmonger. > > Other requests are authorized differently. cert-request is a VirtualCommand and > people are authorized by checking if they have a write access to the > appropriate virtual operation LDAP entry, living in cn=virtual > operations,cn=etc,SUFFIX... Which is by default only the admins group members > which have the god-like special ACI we discussed yesterday. Rob is that > correct? You also participated in the VirtualCommand coding... Right. I think I mentioned yesterday that there is currently no special permission for issuing SAN certs (at least partly because we don't actually do it). Adding a rule for this should be fairly straightforward and I think should be part of any effort to enable SAN certs. Doing the ACI will require a bit of work since currently there is a 1-1 relationship between a command and an ACI right now (via self.check_access()). It shouldn't be too much work to be able to pass in another ACI to check though. > >>> >>> We will need this type of functionality if we want to allow admins to >>> create wildcard certificates anyway, which is another important use case >>> for hosting/cloud-like services. >> >> >> I was also thinking admins may want to allow a lower privileged admin to >> manage a host, but not allow them to add a special subjectaltname to >> random other hosts he manages. In this case again we need the ability >> for an admin to be able to provide the cert to the host. Also then a >> special case arises on automatic renew from certmonger, all names need >> to be checked against the old certificate being renewed, so >> authorization in that case would have to be based on the previous cert >> names and not on managedby, right ? >> If not automatic renewal would fail ? > > Hmm, the renewal would fail in this case. admin would have to request new > certificate manually in this case (when mangedby attribute is not set > properly). Previous certificate is not checked by the cert-request > authorization code. Yup. If the host can't manage all the hosts in the SAN then renewal will be rejected. rob From simo at redhat.com Thu Jan 9 15:49:58 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 09 Jan 2014 10:49:58 -0500 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <52CEC3EA.7040401@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> Message-ID: <1389282598.26102.230.camel@willson.li.ssimo.org> On Thu, 2014-01-09 at 10:44 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On 01/09/2014 03:12 PM, Simo Sorce wrote: > >>> Also maybe we should allow admins to bypass the need to have an actual > >>> object to represent the alt name ? > > I'd rather not. This would allow a rogue admin to create a cert for > www.google.com. Sure, they could also create a host for that but forcing > them to add more entries increases the chances of them getting caught > doing it. They can remove the host right after they create a cert, I honestly do not think this is a valid concern. If your admin is rouge he can already take full ownership of your infrastructure in many ways, preventing setting a name in a cert doesn't really make a difference IMO. However I would be ok to limit this to some new "Security Admin/CA Admin" role that is not assigned by default. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Thu Jan 9 21:25:08 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 09 Jan 2014 16:25:08 -0500 Subject: [Freeipa-devel] [PATCH 0027] Add config.h.in~ and rpmbuild to git ignore In-Reply-To: <52C52A4F.7090600@redhat.com> References: <1387821271.18952.5.camel@localhost.localdomain> <52C52A4F.7090600@redhat.com> Message-ID: <1389302708.1962.3.camel@localhost.localdomain> On Thu, 2014-01-02 at 09:58 +0100, Petr Viktorin wrote: > On 12/23/2013 06:54 PM, Nathaniel McCallum wrote: > > Attached. > > config.in.h~ is a product of your specfific editor, right? You should > add it to your personal ignore list, e.g. with: > > $ echo "*~" >> ~/.gitignore > $ git config --global core.excludesfile ~/.gitignore I don't remember editing config.in.h, but I've removed it from this version. > As for rpmbuild, how is it generated? I don't think our makefile creates > it, does it? make rpms > If it does, I believe it would appear only in the root directory, in > which case it should go in the "Root directory" section of .gitignore, > start with a slash. > Also it should end with a slash since it's a directory. Fixed. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0027-2-Add-rpmbuild-to-.gitignore.patch Type: text/x-patch Size: 565 bytes Desc: not available URL: From npmccallum at redhat.com Thu Jan 9 21:26:29 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 09 Jan 2014 16:26:29 -0500 Subject: [Freeipa-devel] [PATCH 0029] Add libotp internal library for slapi plugins Message-ID: <1389302789.1962.4.camel@localhost.localdomain> Attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0029-Add-libotp-internal-library-for-slapi-plugins.patch Type: text/x-patch Size: 35640 bytes Desc: not available URL: From npmccallum at redhat.com Thu Jan 9 21:27:28 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 09 Jan 2014 16:27:28 -0500 Subject: [Freeipa-devel] [PATCH 0028] Add OTP last token plugin In-Reply-To: <1387821395.18952.7.camel@localhost.localdomain> References: <1387821395.18952.7.camel@localhost.localdomain> Message-ID: <1389302848.1962.5.camel@localhost.localdomain> This new version now depends on my patch 0029. Sorry for the reverse ordering. On Mon, 2013-12-23 at 12:56 -0500, Nathaniel McCallum wrote: > This plugin prevents the deletion or deactivation of the last valid > token for a user. This prevents the user from migrating back to single > factor authentication once OTP has been enabled. > > Thanks to Mark Reynolds for helping me with this patch. > _______________________________________________ > 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: freeipa-npmccallum-0028-2-Add-OTP-last-token-plugin.patch Type: text/x-patch Size: 13791 bytes Desc: not available URL: From npmccallum at redhat.com Thu Jan 9 21:28:16 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 09 Jan 2014 16:28:16 -0500 Subject: [Freeipa-devel] [PATCH 0030] Add OTP sync plugin Message-ID: <1389302896.1962.6.camel@localhost.localdomain> This plugin adds an extended operation for synchronizing tokens. This operation is availalbe both with and without bind. In the latter case, the first factor is required. This operation can also be performed on a per-token or per-user level. In the latter case, we will attempt to find the token automatically. Thanks to Mark Reynolds for helping me with this patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0030-Add-OTP-sync-plugin.patch Type: text/x-patch Size: 24131 bytes Desc: not available URL: From npmccallum at redhat.com Thu Jan 9 21:29:05 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 09 Jan 2014 16:29:05 -0500 Subject: [Freeipa-devel] [PATCH 0031] Migrate ipa-pwd-extop to use libotp Message-ID: <1389302945.1962.7.camel@localhost.localdomain> Attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0031-Migrate-ipa-pwd-extop-to-use-libotp.patch Type: text/x-patch Size: 42995 bytes Desc: not available URL: From npmccallum at redhat.com Thu Jan 9 21:32:53 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 09 Jan 2014 16:32:53 -0500 Subject: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens Message-ID: <1389303173.1962.11.camel@localhost.localdomain> This patch is independent from my patches 0028-0031 and can be merged in any order. This patch has a bug, but I can't figure it out. We need to set nsslapd-access-userattr-strict on cn=config to "off". However, during the rpm installation, I get this error: DEBUG Unhandled LDAPError: UNWILLING_TO_PERFORM: {'info': 'Deleting attributes is not allowed', 'desc': 'Server is unwilling to perform'} ERROR Update failed: Server is unwilling to perform: Deleting attributes is not allowed I'm not sure what is causing this. Does anyone have any suggestions? Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0032-Update-ACIs-to-permit-users-to-add-delete-their-own-.patch Type: text/x-patch Size: 5335 bytes Desc: not available URL: From npmccallum at redhat.com Thu Jan 9 21:36:34 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 09 Jan 2014 16:36:34 -0500 Subject: [Freeipa-devel] [PATCH 0033] Add HOTP token support Message-ID: <1389303394.1962.15.camel@localhost.localdomain> This patch depends on my patch 0029. In the past we have talked about not adding HOTP support due to the inability to guarantee timely updates to the counter across replication. I went ahead and implemented HOTP support for two reasons: 1. Testing the OTP stack with TOTP tokens can be a bit frustrating waiting for the tokens to generate. 2. Since we aren't implementing watermark support for TOTP, the HOTP security guarantee seems very similar to me. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0033-Add-HOTP-token-support.patch Type: text/x-patch Size: 21211 bytes Desc: not available URL: From rmeggins at redhat.com Thu Jan 9 21:56:00 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 09 Jan 2014 14:56:00 -0700 Subject: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens In-Reply-To: <1389303173.1962.11.camel@localhost.localdomain> References: <1389303173.1962.11.camel@localhost.localdomain> Message-ID: <52CF1AF0.6020808@redhat.com> On 01/09/2014 02:32 PM, Nathaniel McCallum wrote: > This patch is independent from my patches 0028-0031 and can be merged in > any order. > > This patch has a bug, but I can't figure it out. We need to set > nsslapd-access-userattr-strict on cn=config to "off". However, during > the rpm installation, I get this error: > > DEBUG Unhandled LDAPError: UNWILLING_TO_PERFORM: {'info': 'Deleting > attributes is not allowed', 'desc': 'Server is unwilling to perform'} > ERROR Update failed: Server is unwilling to perform: Deleting attributes > is not allowed > > I'm not sure what is causing this. Does anyone have any suggestions? I believe the IPA update mechanism works by doing a modify/del of the attribute followed by a modify/add. By default, cn=config restricts the attributes which can be deleted. You can add nsslapd-access-userattr-strict to this list. Unfortunately, it is rather painful to do so. Method one: Don't use the ipa update mechanism to update this attribute. Instead, just use an ldap modify directly e.g. using ldapmodify: ldapmodify .... dn: cn=config changetype: modify replace: nsslapd-access-userattr-strict nsslapd-access-userattr-strict: off or in python-ldap: conn = ldap.connection(my ldap url) conn.simple_bind_s("cn=directory manager", "password") mod = [(ldap.MOD_REPLACE, "nsslapd-access-userattr-strict", ['off'])] conn.modify_s("cn=config", mod) Method two: allow deletion of nsslapd-access-userattr-strict in order to use ipa update method This will unfortunately require the use of something other than the ipa update method, again. 1) do a search to get the current value in cn=config nsslapd-allowed-to-delete-attrs - it is a single space delimited list 2) add nsslapd-access-userattr-strict to the list 3) mod/replace the value > > Nathaniel > > > _______________________________________________ > 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 npmccallum at redhat.com Thu Jan 9 22:26:08 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 09 Jan 2014 17:26:08 -0500 Subject: [Freeipa-devel] FreeIPA OTP End-to-End In-Reply-To: <1386968251.1948.25.camel@localhost.localdomain> References: <1386968251.1948.25.camel@localhost.localdomain> Message-ID: <1389306368.1962.31.camel@localhost.localdomain> New RPMs are up: http://npmccallum.fedorapeople.org/freeipa-otp/rpms/ WHAT'S NEW IN THE RPMS? * 389ds OTP Last Token Plugin * 389ds OTP Sync Plugin * HOTP token support * OTP UI is now working All of the non-UI code is currently on the list. Petr is working on UI cleanup. You can see all the patches here: https://github.com/npmccallum/freeipa/tree/otp https://github.com/npmccallum/freeipa/tree/otpui KNOWN ISSUES Setting User Auth Type globally doesn't work: https://fedorahosted.org/freeipa/ticket/4105 SELinux is broken on F20 (should be fixed in rawhide): https://bugzilla.redhat.com/show_bug.cgi?id=970163 User's can't add their own tokens. A patch to fix this is in the RPMs, but currently has a bug. A workaround exists. Details are here: https://www.redhat.com/archives/freeipa-devel/2014-January/msg00068.html Alexander Bokovoy (I think) found some issues when interacting with pkinit. I don't know the state of this. Alexander Bokovoy found a bug with SSSD that has (a few minutes ago) been patched. Details are here: https://lists.fedorahosted.org/pipermail/sssd-devel/2014-January/017934.html STILL NEEDED * UI patches polished and sent to the list. * OTP Sync Client (both CLI and UI). Nathaniel On Fri, 2013-12-13 at 15:57 -0500, Nathaniel McCallum wrote: > This is an email to track the status of the OTP project as we push > toward completion. I'm also attempting to get all the pieces in play so > that they are testable. > > RPMs > Available here: http://npmccallum.fedorapeople.org/freeipa-otp/rpms/ > These currently contain the CLI and UI patches, but exclude the DS > plugin patch. I will merge this last patch in when submitted to the > list. > > OTP CLI > All of the patches are merged except npmccallum-0024, which is > undergoing active review. > https://www.redhat.com/archives/freeipa-devel/2013-December/msg00102.html > > OTP UI > Thanks to Petr Vobornik for his set of patches implementing the UI. They > can be found rebased on top of my otp changes here: > https://github.com/npmccallum/freeipa/commits/otpui > > Authentication methods and RADIUS proxy support seems to be fully > functional and I have not encountered any bugs. I'm not currently able > to get the OTP UI to show up at all (I may well be doing something > wrong). > > I believe Petr plans to clean these up and resubmit them to the list. > > One additional patch will be required for the token sync extop. > > DS PLUGIN > I am nearing completion on the DS plugin providing support for deletion > protection and the token sync extop. This should hit the list next week. > > OTHER > Am I missing anything? > > Nathaniel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From simo at redhat.com Thu Jan 9 22:37:23 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 09 Jan 2014 17:37:23 -0500 Subject: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens In-Reply-To: <1389303173.1962.11.camel@localhost.localdomain> References: <1389303173.1962.11.camel@localhost.localdomain> Message-ID: <1389307043.26102.253.camel@willson.li.ssimo.org> On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: > This patch is independent from my patches 0028-0031 and can be merged in > any order. > > This patch has a bug, but I can't figure it out. We need to set > nsslapd-access-userattr-strict on cn=config to "off". Uhmm what is the effect on ACL evaluation of changing this boolean ? I can;t figure out from your commit not from 389ds commit what exactly changes and how it impacts the security of the directory. I ask because I was planning on using userattr to protect some operations in the password plugin but was waiting due to bug: https://fedorahosted.org/389/ticket/47571 which is beeing resolved. I want to make sure your change won't change what this ACIs would allow. Is this option simply allowing the use of add/delete ACIs to be specified in conjunction with userattr, so that a user can add an attr only if it contains its own DN ? Will it allow the user to add multiple values to the same attr as long as one of the is the userDN ? O will it restrict that case ? (I know that ipaTokenOwner is a single-value attribute, but the mechanism you are enabling here is general, and I want to be sure of what the semantics are) Simo. -- Simo Sorce * Red Hat, Inc * New York From nhosoi at redhat.com Thu Jan 9 23:15:55 2014 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 09 Jan 2014 15:15:55 -0800 Subject: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens In-Reply-To: <1389307043.26102.253.camel@willson.li.ssimo.org> References: <1389303173.1962.11.camel@localhost.localdomain> <1389307043.26102.253.camel@willson.li.ssimo.org> Message-ID: <52CF2DAB.8050508@redhat.com> Simo Sorce wrote: > On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: >> This patch is independent from my patches 0028-0031 and can be merged in >> any order. >> >> This patch has a bug, but I can't figure it out. We need to set >> nsslapd-access-userattr-strict on cn=config to "off". > Uhmm what is the effect on ACL evaluation of changing this boolean ? Ticket 47653 - Need a way to allow users to create entries assigned to themselves Bug Description: There are cases where users need to be able to create, edit and delete their own entries. Using an ACI with the "userattr" keyword does not work with ADD operations(to prevent a security hole). This prevents IPA's OTP plugin from performing some necessary operations. Fix Description: Added a new config attribute "nsslapd-access-userattr-strict". The default is "on" or strict. For the IPA case, it would need to be set to "off" in order to allow the desired behavior. https://fedorahosted.org/389/ticket/47653 This patch is included in 389-ds-base-1.3.2.10 and newer. > I can;t figure out from your commit not from 389ds commit what exactly > changes and how it impacts the security of the directory. > > I ask because I was planning on using userattr to protect some > operations in the password plugin but was waiting due to bug: > https://fedorahosted.org/389/ticket/47571 which is beeing resolved. Thank you for waiting. We are going to add the fix to the next release (1.3.2.11). Thanks! --noriko > > I want to make sure your change won't change what this ACIs would allow. > > Is this option simply allowing the use of add/delete ACIs to be > specified in conjunction with userattr, so that a user can add an attr > only if it contains its own DN ? > > Will it allow the user to add multiple values to the same attr as long > as one of the is the userDN ? O will it restrict that case ? > > (I know that ipaTokenOwner is a single-value attribute, but the > mechanism you are enabling here is general, and I want to be sure of > what the semantics are) > > Simo. > From simo at redhat.com Fri Jan 10 03:28:44 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 09 Jan 2014 22:28:44 -0500 Subject: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens In-Reply-To: <52CF2DAB.8050508@redhat.com> References: <1389303173.1962.11.camel@localhost.localdomain> <1389307043.26102.253.camel@willson.li.ssimo.org> <52CF2DAB.8050508@redhat.com> Message-ID: <1389324524.26102.263.camel@willson.li.ssimo.org> On Thu, 2014-01-09 at 15:15 -0800, Noriko Hosoi wrote: > Simo Sorce wrote: > > On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: > >> This patch is independent from my patches 0028-0031 and can be merged in > >> any order. > >> > >> This patch has a bug, but I can't figure it out. We need to set > >> nsslapd-access-userattr-strict on cn=config to "off". > > Uhmm what is the effect on ACL evaluation of changing this boolean ? > Ticket 47653 - Need a way to allow users to create entries assigned > to themselves > > Bug Description: There are cases where users need to be able to > create, edit and delete > their own entries. Using an ACI with the > "userattr" keyword does not > work with ADD operations(to prevent a security > hole). This prevents IPA's > OTP plugin from performing some necessary operations. > > Fix Description: Added a new config attribute > "nsslapd-access-userattr-strict". The default > is "on" or strict. For the IPA case, it would > need to be set to "off" in > order to allow the desired behavior. > > https://fedorahosted.org/389/ticket/47653 > > This patch is included in 389-ds-base-1.3.2.10 and newer. Thank you Noriko, but as I mentioned, I already read through the 389ds patch and it doesn't help me. Below I have a few more questions, I will add one that is more clear. > > Is this option simply allowing the use of add/delete ACIs to be > > specified in conjunction with userattr, so that a user can add an attr > > only if it contains its own DN ? So the entry in this case does not exist yet, so my question is whether the (userattr=attrFoo#userDN) part will actually match that attrFoo is set to contain the DN of the user that is performing the operation ? > > Will it allow the user to add multiple values to the same attr as long > > as one of the is the userDN ? O will it restrict that case ? This is also important, if attrFoo is a multivalued attribute, does this option allow any values to be set as long as one of them is userDN ? Or will it enforce that *only* userDN is add in the add operation ? Simo. -- Simo Sorce * Red Hat, Inc * New York From nhosoi at redhat.com Fri Jan 10 05:30:14 2014 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 09 Jan 2014 21:30:14 -0800 Subject: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens In-Reply-To: <1389324524.26102.263.camel@willson.li.ssimo.org> References: <1389303173.1962.11.camel@localhost.localdomain> <1389307043.26102.253.camel@willson.li.ssimo.org> <52CF2DAB.8050508@redhat.com> <1389324524.26102.263.camel@willson.li.ssimo.org> Message-ID: <52CF8566.6030803@redhat.com> Simo Sorce wrote: > On Thu, 2014-01-09 at 15:15 -0800, Noriko Hosoi wrote: >> Simo Sorce wrote: >>> On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: >>>> This patch is independent from my patches 0028-0031 and can be merged in >>>> any order. >>>> >>>> This patch has a bug, but I can't figure it out. We need to set >>>> nsslapd-access-userattr-strict on cn=config to "off". >>> Uhmm what is the effect on ACL evaluation of changing this boolean ? >> Ticket 47653 - Need a way to allow users to create entries assigned >> to themselves >> >> Bug Description: There are cases where users need to be able to >> create, edit and delete >> their own entries. Using an ACI with the >> "userattr" keyword does not >> work with ADD operations(to prevent a security >> hole). This prevents IPA's >> OTP plugin from performing some necessary operations. >> >> Fix Description: Added a new config attribute >> "nsslapd-access-userattr-strict". The default >> is "on" or strict. For the IPA case, it would >> need to be set to "off" in >> order to allow the desired behavior. >> >> https://fedorahosted.org/389/ticket/47653 >> >> This patch is included in 389-ds-base-1.3.2.10 and newer. > Thank you Noriko, but as I mentioned, I already read through the 389ds > patch and it doesn't help me. Below I have a few more questions, I will > add one that is more clear. > >>> Is this option simply allowing the use of add/delete ACIs to be >>> specified in conjunction with userattr, so that a user can add an attr >>> only if it contains its own DN ? > So the entry in this case does not exist yet, so my question is whether > the (userattr=attrFoo#userDN) part will actually match that attrFoo is > set to contain the DN of the user that is performing the operation ? I uesd this ACI: aci: (target=ldap:///o=my.com)(targetattr=*) (version 3.0; acl "userattr test"; allow (add,write,delete,read,search,compare) userattr = "description#USERDN";) Please note uid=nuser does not exist yet. Does your question mean by this add? Before coming to the ACL code, bind fails... $ ldapmodify ... -D 'uid=nuser,o=my.com' -w Nuser -a << EOF dn: uid=Nuser, o=my.com objectClass: top [...] uid: Nuser description: uid=nuser,o=my.com userPassword: {CLEAR}Nuser EOF ldap_simple_bind: No such object ldap_simple_bind: matched: o=my.com >>> Will it allow the user to add multiple values to the same attr as long >>> as one of the is the userDN ? O will it restrict that case ? > This is also important, if attrFoo is a multivalued attribute, does this > option allow any values to be set as long as one of them is userDN ? > Or will it enforce that *only* userDN is add in the add operation ? As long as the type of the attribute is not restricted as DN syntax, it takes any value including DN. I tested with 'description' (e.g., userattr = "description#USERDN") and verified it takes userDN as well as any other values. $ ldapmodify ... -D 'cn=directory manager' -w dn: uid=nuser4,o=my.com changetype: modify add: description description: uid=nuser4,o=my.com $ ldapmodify ... -D 'uid=nuser4,o=my.com' -w Nuser4 dn: uid=nuser4,o=my.com changetype: modify add: description description: uid=nuser0,o=my.com modifying entry uid=nuser4,o=my.com $ ldapmodify ... -D 'uid=nuser0,o=my.com' -w Nuser0 dn: uid=nuser4,o=my.com changetype: modify add: description description: uid=nuser1,o=my.com modifying entry uid=nuser4,o=my.com $ ldapmodify ... -D 'uid=nuser1,o=my.com' -w Nuser1 dn: uid=nuser4,o=my.com changetype: modify add: description description: value $ ldapsearch ... -D 'cn=directory manager' -w -b "uid=nuser4,o=my.com" description dn: uid=Nuser4,o=my.com description: uid=nuser4,o=my.com description: uid=nuser0,o=my.com description: uid=nuser1,o=my.com description: value --noriko From jcholast at redhat.com Fri Jan 10 11:43:00 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 10 Jan 2014 12:43:00 +0100 Subject: [Freeipa-devel] [PATCHES] 213-224 Use old entry state in LDAP mods In-Reply-To: <52B432D4.3090804@redhat.com> References: <52A712BC.2090109@redhat.com> <52A88D45.60706@redhat.com> <52A8A0C0.2050404@redhat.com> <52B18C1D.9020902@redhat.com> <52B432D4.3090804@redhat.com> Message-ID: <52CFDCC4.4080806@redhat.com> On 20.12.2013 13:06, Petr Viktorin wrote: > I now have a failing test in test_permission_rollback. Let's think about > this case for a moment: > > The permission system has "rollback": if an ACI update fails, the entry > is rolled back. Currently it works (for ipapermlocation changes) like this: > > - The old entry is retreived > - A new entry is populated (NB, the framework's mod operation does not > retrieve the entry it modifies; rather it builds an entirely new entry > with *only* the data that's changed, and relies on generate_modlist > doing MOD_REPLACE when orig data is missing). > - update is called on the new entry > - The ACI is updated, and this fails (e.g. with SyntaxError) > - update is called on the *old* entry retreived in the first step. Up to > now this had restored the entry (since existing state was looked up > before each mod), but with these patches it raises EmptyModlist since > the object has not changed relative to its orig data. > > Obviously this approach is wrong given how entry is supposed to work > now, and I'll be happy to change it it. But it's not clear what's the > right way to do such rollback. I have added an optional argument to reset_modlist, which you can use to specify on which entry to base the modlist, see patch 214. Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-213.2-Rename-LDAPEntry-method-commit-to-reset_modlist.patch Type: text/x-patch Size: 1237 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-214.2-Use-old-entry-state-in-LDAPClient.update_entry.patch Type: text/x-patch Size: 5896 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-215.2-Move-LDAPClient-method-get_single_value-to-IPASimple.patch Type: text/x-patch Size: 3089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-216.2-Make-IPASimpleLDAPObject.get_single_value-result-ove.patch Type: text/x-patch Size: 1969 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-217.2-Use-LDAPClient.update_entry-for-LDAP-mods-in-ldapupd.patch Type: text/x-patch Size: 4389 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-218.2-Reduce-amount-of-LDAPEntry.reset_modlist-calls-in-ld.patch Type: text/x-patch Size: 1976 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-219.2-Add-LDAPEntry-method-generate_modlist.patch Type: text/x-patch Size: 5983 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-220.2-Remove-unused-LDAPClient-methods-get_syntax-and-get_.patch Type: text/x-patch Size: 1415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-221.2-Remove-legacy-LDAPEntry-properties-data-and-orig_dat.patch Type: text/x-patch Size: 4015 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-222.2-Store-old-entry-state-in-dict-rather-than-LDAPEntry.patch Type: text/x-patch Size: 4731 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-223.2-Do-not-crash-on-bad-LDAP-data-when-formatting-decode.patch Type: text/x-patch Size: 1003 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-224.2-Use-raw-LDAP-data-in-ldapupdate.patch Type: text/x-patch Size: 3242 bytes Desc: not available URL: From mkosek at redhat.com Fri Jan 10 11:45:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 10 Jan 2014 12:45:32 +0100 Subject: [Freeipa-devel] [PATCH] 445 hbactest does not work for external users Message-ID: <52CFDD5C.4060905@redhat.com> Original patch for ticket #3803 implemented support to resolve SIDs through SSSD. However, it also broke hbactest for external users. The result of the updated external member group search must be local non-external groups, not the external ones. Otherwise the rule is not matched. https://fedorahosted.org/freeipa/ticket/3803 ---- This is a follow up to failed verification in https://bugzilla.redhat.com/show_bug.cgi?id=1032668 Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-445-hbactest-does-not-work-for-external-users.patch Type: text/x-patch Size: 1990 bytes Desc: not available URL: From abokovoy at redhat.com Fri Jan 10 11:54:37 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 10 Jan 2014 13:54:37 +0200 Subject: [Freeipa-devel] [PATCH] 445 hbactest does not work for external users In-Reply-To: <52CFDD5C.4060905@redhat.com> References: <52CFDD5C.4060905@redhat.com> Message-ID: <20140110115437.GY12003@redhat.com> On Fri, 10 Jan 2014, Martin Kosek wrote: >Original patch for ticket #3803 implemented support to resolve SIDs >through SSSD. However, it also broke hbactest for external users. The >result of the updated external member group search must be local >non-external groups, not the external ones. Otherwise the rule is not >matched. > >https://fedorahosted.org/freeipa/ticket/3803 > >---- > >This is a follow up to failed verification in >https://bugzilla.redhat.com/show_bug.cgi?id=1032668 > >Martin >From 829e1359e6868af51156da00b0e8e3861828c7be Mon Sep 17 00:00:00 2001 >From: Martin Kosek >Date: Fri, 10 Jan 2014 12:41:29 +0100 >Subject: [PATCH] hbactest does not work for external users > >Original patch for ticket #3803 implemented support to resolve SIDs >through SSSD. However, it also broke hbactest for external users. The >result of the updated external member group search must be local >non-external groups, not the external ones. Otherwise the rule is not >matched. > >https://fedorahosted.org/freeipa/ticket/3803 >--- > ipalib/plugins/hbactest.py | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > >diff --git a/ipalib/plugins/hbactest.py b/ipalib/plugins/hbactest.py >index fed39b05d8ac75254575cf211d338ab85b093cb8..cc18890ce3ca589a0d086aa263795f9c4ff61cb6 100644 >--- a/ipalib/plugins/hbactest.py >+++ b/ipalib/plugins/hbactest.py >@@ -400,14 +400,16 @@ def execute(self, *args, **options): > ldap = self.api.Backend.ldap2 > group_container = DN(api.env.container_group, api.env.basedn) > try: >- entries, truncated = ldap.find_entries(filter_sids, ['cn'], group_container) >+ entries, truncated = ldap.find_entries(filter_sids, ['memberof'], group_container) > except errors.NotFound: > request.user.groups = [] > else: > groups = [] > for dn, entry in entries: >- if dn.endswith(group_container): >- groups.append(dn[0][0].value) >+ memberof_dns = entry.get('memberof', []) >+ for memberof_dn in memberof_dns: >+ if memberof_dn.endswith(group_container): >+ groups.append(memberof_dn[0][0].value) > request.user.groups = sorted(set(groups)) > else: > # try searching for a local user ACK. Indeed, when verifying groups we need to take their nestedness into account because AD users and groups are mapped through two-tier groups. -- / Alexander Bokovoy From mkosek at redhat.com Fri Jan 10 11:57:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 10 Jan 2014 12:57:37 +0100 Subject: [Freeipa-devel] [PATCH] 445 hbactest does not work for external users In-Reply-To: <20140110115437.GY12003@redhat.com> References: <52CFDD5C.4060905@redhat.com> <20140110115437.GY12003@redhat.com> Message-ID: <52CFE031.90305@redhat.com> On 01/10/2014 12:54 PM, Alexander Bokovoy wrote: > On Fri, 10 Jan 2014, Martin Kosek wrote: >> Original patch for ticket #3803 implemented support to resolve SIDs >> through SSSD. However, it also broke hbactest for external users. The >> result of the updated external member group search must be local >> non-external groups, not the external ones. Otherwise the rule is not >> matched. >> >> https://fedorahosted.org/freeipa/ticket/3803 >> >> ---- >> >> This is a follow up to failed verification in >> https://bugzilla.redhat.com/show_bug.cgi?id=1032668 >> >> Martin > >> From 829e1359e6868af51156da00b0e8e3861828c7be Mon Sep 17 00:00:00 2001 >> From: Martin Kosek >> Date: Fri, 10 Jan 2014 12:41:29 +0100 >> Subject: [PATCH] hbactest does not work for external users >> >> Original patch for ticket #3803 implemented support to resolve SIDs >> through SSSD. However, it also broke hbactest for external users. The >> result of the updated external member group search must be local >> non-external groups, not the external ones. Otherwise the rule is not >> matched. >> >> https://fedorahosted.org/freeipa/ticket/3803 >> --- >> ipalib/plugins/hbactest.py | 8 +++++--- >> 1 file changed, 5 insertions(+), 3 deletions(-) >> >> diff --git a/ipalib/plugins/hbactest.py b/ipalib/plugins/hbactest.py >> index >> fed39b05d8ac75254575cf211d338ab85b093cb8..cc18890ce3ca589a0d086aa263795f9c4ff61cb6 >> 100644 >> --- a/ipalib/plugins/hbactest.py >> +++ b/ipalib/plugins/hbactest.py >> @@ -400,14 +400,16 @@ def execute(self, *args, **options): >> ldap = self.api.Backend.ldap2 >> group_container = DN(api.env.container_group, api.env.basedn) >> try: >> - entries, truncated = ldap.find_entries(filter_sids, >> ['cn'], group_container) >> + entries, truncated = ldap.find_entries(filter_sids, >> ['memberof'], group_container) >> except errors.NotFound: >> request.user.groups = [] >> else: >> groups = [] >> for dn, entry in entries: >> - if dn.endswith(group_container): >> - groups.append(dn[0][0].value) >> + memberof_dns = entry.get('memberof', []) >> + for memberof_dn in memberof_dns: >> + if memberof_dn.endswith(group_container): >> + groups.append(memberof_dn[0][0].value) >> request.user.groups = sorted(set(groups)) >> else: >> # try searching for a local user > ACK. > > Indeed, when verifying groups we need to take their nestedness into > account because AD users and groups are mapped through two-tier groups. > Pushed to master, ipa-3-3. Martin From pviktori at redhat.com Fri Jan 10 12:08:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 10 Jan 2014 13:08:14 +0100 Subject: [Freeipa-devel] [PATCH 0027] Add config.h.in~ and rpmbuild to git ignore In-Reply-To: <1389302708.1962.3.camel@localhost.localdomain> References: <1387821271.18952.5.camel@localhost.localdomain> <52C52A4F.7090600@redhat.com> <1389302708.1962.3.camel@localhost.localdomain> Message-ID: <52CFE2AE.4040100@redhat.com> On 01/09/2014 10:25 PM, Nathaniel McCallum wrote: > On Thu, 2014-01-02 at 09:58 +0100, Petr Viktorin wrote: >> On 12/23/2013 06:54 PM, Nathaniel McCallum wrote: >>> Attached. >> >> config.in.h~ is a product of your specfific editor, right? You should >> add it to your personal ignore list, e.g. with: >> >> $ echo "*~" >> ~/.gitignore >> $ git config --global core.excludesfile ~/.gitignore > > I don't remember editing config.in.h, but I've removed it from this > version. > >> As for rpmbuild, how is it generated? I don't think our makefile creates >> it, does it? > > make rpms Ah, right, it's there but deleted at the end of the build. >> If it does, I believe it would appear only in the root directory, in >> which case it should go in the "Root directory" section of .gitignore, >> start with a slash. >> Also it should end with a slash since it's a directory. > > Fixed. > ACK, pushed to master: d1873a5a1324e265360f1cc30eb288db9f0ad91a -- Petr? From mkosek at redhat.com Fri Jan 10 12:29:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 10 Jan 2014 13:29:54 +0100 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <1389278243.26102.227.camel@willson.li.ssimo.org> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <1389278243.26102.227.camel@willson.li.ssimo.org> Message-ID: <52CFE7C2.4030405@redhat.com> On 01/09/2014 03:37 PM, Simo Sorce wrote: > On Thu, 2014-01-09 at 15:27 +0100, Martin Kosek wrote: >> On 01/09/2014 03:12 PM, Simo Sorce wrote: >>> On Thu, 2014-01-09 at 09:04 -0500, Simo Sorce wrote: >>>> On Thu, 2014-01-09 at 09:51 +0100, Martin Kosek wrote: >>>>> On 01/09/2014 12:26 AM, Simo Sorce wrote: >>>>>> On Thu, 2013-12-05 at 14:37 +0100, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> the attached patch fixes . >>>>>> >>>>>> See the additional comments on 3977, I think this patch should be NACKed >>>>>> with extreme prejudice if it allows setting arbitrary subjectAltNames. >>>>>> >>>>>> Simo. >>>>>> >>>>> >>>>> It does not allow them - SANs are being authorized by using the managedBy >>>>> attribute on the SAN-ed host/service (i.e. host-add-managedby/service-add-host >>>>> commands). >>>> >>>> This means that in order to add a subjectAltName you have to register a >>>> Host with that name ? That is not really convenient, but if it works at >>>> least it properly constrains potential hijacking. >> >> Right. The host does not need to even be enrolled to make this work. But it is >> still better to make it this way that to allow hosts to request SANs. >> >>>> >>>>> But you are right that the authorization part should not be taken lightly and >>>>> should be verified before we allow SANs in default profile. I added a comment >>>>> in the Trac as well. >>>> >>>> Yes we definitely need a test to make 100% sure this cannot be worked >>>> around, the security consequences would be disastrous. >> >> +1 >> >>>> Also maybe we should allow admins to bypass the need to have an actual >>>> object to represent the alt name ? >> >> cert requests issued by admin can bypass this check, it is only applied to >> principals starting with "host/", i.e. for example to certs renewed by certmonger. >> >> Other requests are authorized differently. cert-request is a VirtualCommand and >> people are authorized by checking if they have a write access to the >> appropriate virtual operation LDAP entry, living in cn=virtual >> operations,cn=etc,SUFFIX... Which is by default only the admins group members >> which have the god-like special ACI we discussed yesterday. Rob is that >> correct? You also participated in the VirtualCommand coding... > > The situation sounds sub-optimal, I would think that giving managedby to > a 'junior-admin' user would allow him to also fetch certs but only for > the machines they manage. I sense some confusion here. You do not give managedby to a junior admin. You set managedby to a host or service. Example: ipa host-add lowsecure.example.com ipa host-add highsecure.example.com ipa host-add-managedby highsecure.example.com --hosts lowsecure.example.com Then host/lowsecure.example.com at REALM can request cert with SAN highsecure.example.com. > > Is the Virtual Permission an all or nothing thing ? or can it be scoped > to group of machines ? If the latter, fine, if not, not so much. Not really. But this pain is shared also in the standard permissions. "Modify hosts" permission also means all or nothing. > Although, if the junior-admin can gain root on the host, he can still > get certs using the host/ key so maybe that is not fundamental, but it > would need clear documentation on how to allow a less privileged admin > to perform these functions. > >>>> We will need this type of functionality if we want to allow admins to >>>> create wildcard certificates anyway, which is another important use case >>>> for hosting/cloud-like services. >>> >>> >>> I was also thinking admins may want to allow a lower privileged admin to >>> manage a host, but not allow them to add a special subjectaltname to >>> random other hosts he manages. In this case again we need the ability >>> for an admin to be able to provide the cert to the host. Also then a >>> special case arises on automatic renew from certmonger, all names need >>> to be checked against the old certificate being renewed, so >>> authorization in that case would have to be based on the previous cert >>> names and not on managedby, right ? >>> If not automatic renewal would fail ? >> >> Hmm, the renewal would fail in this case. admin would have to request new >> certificate manually in this case (when mangedby attribute is not set >> properly). Previous certificate is not checked by the cert-request >> authorization code. > > I think the renewal problem is more important. Failing renewals cripples > one of the most important features of using FreeIPA as your CA for > enrolled hosts. > > Simo. > I am still not sure if there is not a confusion about the managedby attribute. If you have an admin of lowsecure.example.com + have the managedby attributes on other hosts correctly, local admin/certmonger on lowsecure.example.com can still happily request or renew cert with the approved SANs. Martin From mkosek at redhat.com Fri Jan 10 12:34:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 10 Jan 2014 13:34:04 +0100 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <1389282598.26102.230.camel@willson.li.ssimo.org> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> Message-ID: <52CFE8BC.8010201@redhat.com> On 01/09/2014 04:49 PM, Simo Sorce wrote: > On Thu, 2014-01-09 at 10:44 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 01/09/2014 03:12 PM, Simo Sorce wrote: > >>>>> Also maybe we should allow admins to bypass the need to have an actual >>>>> object to represent the alt name ? >> >> I'd rather not. This would allow a rogue admin to create a cert for >> www.google.com. Sure, they could also create a host for that but forcing >> them to add more entries increases the chances of them getting caught >> doing it. > > They can remove the host right after they create a cert, I honestly do > not think this is a valid concern. If your admin is rouge he can already > take full ownership of your infrastructure in many ways, preventing > setting a name in a cert doesn't really make a difference IMO. > > However I would be ok to limit this to some new "Security Admin/CA > Admin" role that is not assigned by default. > > Simo. > Ok, let's reach some conclusion here. I would really like to not defer this feature for too long, it is quite wanted. Would creating new virtual operation "Request certificate with SAN" make the situation better? It would not be so difficult to do, the check_access function can already access virtual operation name as a parameter, we just need to call it. Martin From pviktori at redhat.com Fri Jan 10 13:38:56 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 10 Jan 2014 14:38:56 +0100 Subject: [Freeipa-devel] [PATCHES] 213-224 Use old entry state in LDAP mods In-Reply-To: <52CFDCC4.4080806@redhat.com> References: <52A712BC.2090109@redhat.com> <52A88D45.60706@redhat.com> <52A8A0C0.2050404@redhat.com> <52B18C1D.9020902@redhat.com> <52B432D4.3090804@redhat.com> <52CFDCC4.4080806@redhat.com> Message-ID: <52CFF7F0.3050402@redhat.com> On 01/10/2014 12:43 PM, Jan Cholasta wrote: > On 20.12.2013 13:06, Petr Viktorin wrote: >> I now have a failing test in test_permission_rollback. Let's think about >> this case for a moment: >> >> The permission system has "rollback": if an ACI update fails, the entry >> is rolled back. Currently it works (for ipapermlocation changes) like >> this: >> >> - The old entry is retreived >> - A new entry is populated (NB, the framework's mod operation does not >> retrieve the entry it modifies; rather it builds an entirely new entry >> with *only* the data that's changed, and relies on generate_modlist >> doing MOD_REPLACE when orig data is missing). >> - update is called on the new entry >> - The ACI is updated, and this fails (e.g. with SyntaxError) >> - update is called on the *old* entry retreived in the first step. Up to >> now this had restored the entry (since existing state was looked up >> before each mod), but with these patches it raises EmptyModlist since >> the object has not changed relative to its orig data. >> >> Obviously this approach is wrong given how entry is supposed to work >> now, and I'll be happy to change it it. But it's not clear what's the >> right way to do such rollback. > > I have added an optional argument to reset_modlist, which you can use to > specify on which entry to base the modlist, see patch 214. > > Updated patches attached. > Thanks! Looks good, test pass, upgrade works too. ACK, pushed to master: 7b3d9be388f8e3da3959912061513e40b31926c5 -- Petr? From rcritten at redhat.com Fri Jan 10 14:44:56 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 Jan 2014 09:44:56 -0500 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <1389282598.26102.230.camel@willson.li.ssimo.org> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> Message-ID: <52D00768.2040700@redhat.com> Simo Sorce wrote: > On Thu, 2014-01-09 at 10:44 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 01/09/2014 03:12 PM, Simo Sorce wrote: > >>>>> Also maybe we should allow admins to bypass the need to have an actual >>>>> object to represent the alt name ? >> >> I'd rather not. This would allow a rogue admin to create a cert for >> www.google.com. Sure, they could also create a host for that but forcing >> them to add more entries increases the chances of them getting caught >> doing it. > > They can remove the host right after they create a cert, I honestly do > not think this is a valid concern. If your admin is rouge he can already > take full ownership of your infrastructure in many ways, preventing > setting a name in a cert doesn't really make a difference IMO. > > However I would be ok to limit this to some new "Security Admin/CA > Admin" role that is not assigned by default. That's an interesting point. So right now if you remove a host we delete its services and revoke its certificates. This wouldn't apply to a SAN though, it probably should. rob From pviktori at redhat.com Fri Jan 10 15:02:28 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 10 Jan 2014 16:02:28 +0100 Subject: [Freeipa-devel] [PATCHES] 225-230 Drop support for the legacy LDAP API In-Reply-To: <52CBF8FB.7090808@redhat.com> References: <52A72DA8.4090104@redhat.com> <52AB16B8.6050808@redhat.com> <52AEC654.5040602@redhat.com> <52AF03F2.2090904@redhat.com> <52CBF8FB.7090808@redhat.com> Message-ID: <52D00B84.1090804@redhat.com> On 01/07/2014 01:54 PM, Jan Cholasta wrote: > On 16.12.2013 14:45, Petr Viktorin wrote: >> On 12/16/2013 10:22 AM, Jan Cholasta wrote: >>> On 13.12.2013 15:16, Petr Viktorin wrote: >>>> On 12/10/2013 04:05 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> I believe the time has come to drop support for the legacy (dn, >>>>> entry_attrs) tuple API and move to the new LDAPEntry API exclusively. >>>>> The attached patches convert existing code which uses the old API to >>>>> the >>>>> new API and remove backward compatibility code from the ipaldap >>>>> module. >>>>> >>>>> Note that there are still some functions/methods which accept separate >>>>> dn and entry_attrs arguments, they will be adapted to LDAPEntry later. >>>>> >>>>> Honza >>>> >>>> The first N-1 patches can be tested,acked,pushed independently, right? >>> >>> Yes. >>> >>>> If that's the case, ACK for 225 >> >> Pushed that one to master, 5 more to go. >> bc3f3381c6bf0b4941889b775025a60f56318551 >> 226 needs a rebase. 227: in install/tools/ipa-adtrust-install: + entry_attrs = conn.make_entry( + dn, + objectclass=['top', 'pkiuser', 'nscontainer'], + usercertificate=cert) + conn.add_entry(entry_attrs) Shouldn't it be `usercertificate=[cert]` now? Similarly in ra_cert, and in ipa-server-install with ipacertificatesubjectbase Otherwise this looks good. 228: in ipaserver/install/plugins/update_idranges.py, again we should use lists Otherwise it looks good 229: ACK -- Petr? From pviktori at redhat.com Fri Jan 10 16:49:10 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 10 Jan 2014 17:49:10 +0100 Subject: [Freeipa-devel] [RFE] Multivalued target filters in permissions Message-ID: <52D02486.3090106@redhat.com> Another permission design page coming up: http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions related thread: http://www.redhat.com/archives/freeipa-devel/2013-December/msg00063.html ticket: https://fedorahosted.org/freeipa/ticket/4074 Originally the ticket also included adding targetattrfilters (#4106), but they're a very different kind of effort, and it turns out neither is trivial, so I've split them up. -- Petr? From simo at redhat.com Fri Jan 10 16:51:07 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 10 Jan 2014 11:51:07 -0500 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <52CFE7C2.4030405@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <1389278243.26102.227.camel@willson.li.ssimo.org> <52CFE7C2.4030405@redhat.com> Message-ID: <1389372667.26102.278.camel@willson.li.ssimo.org> On Fri, 2014-01-10 at 13:29 +0100, Martin Kosek wrote: > On 01/09/2014 03:37 PM, Simo Sorce wrote: > > On Thu, 2014-01-09 at 15:27 +0100, Martin Kosek wrote: > >> On 01/09/2014 03:12 PM, Simo Sorce wrote: > >>> On Thu, 2014-01-09 at 09:04 -0500, Simo Sorce wrote: > >>>> On Thu, 2014-01-09 at 09:51 +0100, Martin Kosek wrote: > >>>>> On 01/09/2014 12:26 AM, Simo Sorce wrote: > >>>>>> On Thu, 2013-12-05 at 14:37 +0100, Jan Cholasta wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> the attached patch fixes . > >>>>>> > >>>>>> See the additional comments on 3977, I think this patch should be NACKed > >>>>>> with extreme prejudice if it allows setting arbitrary subjectAltNames. > >>>>>> > >>>>>> Simo. > >>>>>> > >>>>> > >>>>> It does not allow them - SANs are being authorized by using the managedBy > >>>>> attribute on the SAN-ed host/service (i.e. host-add-managedby/service-add-host > >>>>> commands). > >>>> > >>>> This means that in order to add a subjectAltName you have to register a > >>>> Host with that name ? That is not really convenient, but if it works at > >>>> least it properly constrains potential hijacking. > >> > >> Right. The host does not need to even be enrolled to make this work. But it is > >> still better to make it this way that to allow hosts to request SANs. > >> > >>>> > >>>>> But you are right that the authorization part should not be taken lightly and > >>>>> should be verified before we allow SANs in default profile. I added a comment > >>>>> in the Trac as well. > >>>> > >>>> Yes we definitely need a test to make 100% sure this cannot be worked > >>>> around, the security consequences would be disastrous. > >> > >> +1 > >> > >>>> Also maybe we should allow admins to bypass the need to have an actual > >>>> object to represent the alt name ? > >> > >> cert requests issued by admin can bypass this check, it is only applied to > >> principals starting with "host/", i.e. for example to certs renewed by certmonger. > >> > >> Other requests are authorized differently. cert-request is a VirtualCommand and > >> people are authorized by checking if they have a write access to the > >> appropriate virtual operation LDAP entry, living in cn=virtual > >> operations,cn=etc,SUFFIX... Which is by default only the admins group members > >> which have the god-like special ACI we discussed yesterday. Rob is that > >> correct? You also participated in the VirtualCommand coding... > > > > The situation sounds sub-optimal, I would think that giving managedby to > > a 'junior-admin' user would allow him to also fetch certs but only for > > the machines they manage. > > I sense some confusion here. You do not give managedby to a junior admin. You > set managedby to a host or service. Example: > > ipa host-add lowsecure.example.com > ipa host-add highsecure.example.com > ipa host-add-managedby highsecure.example.com --hosts lowsecure.example.com > > Then host/lowsecure.example.com at REALM can request cert with SAN > highsecure.example.com. Yes technically it works like this, but if the junior admin has root privs on the host listed in managedby then it is just like you gave managedby to the junior admin. > > > > Is the Virtual Permission an all or nothing thing ? or can it be scoped > > to group of machines ? If the latter, fine, if not, not so much. > > Not really. But this pain is shared also in the standard permissions. "Modify > hosts" permission also means all or nothing. Right, which is limiting, already, we can start with an all or nothing thing for now, but it must not prevent us extending this functionality so that an admin can be granted permission only for a restricted set of hosts. > > Although, if the junior-admin can gain root on the host, he can still > > get certs using the host/ key so maybe that is not fundamental, but it > > would need clear documentation on how to allow a less privileged admin > > to perform these functions. > > > >>>> We will need this type of functionality if we want to allow admins to > >>>> create wildcard certificates anyway, which is another important use case > >>>> for hosting/cloud-like services. > >>> > >>> > >>> I was also thinking admins may want to allow a lower privileged admin to > >>> manage a host, but not allow them to add a special subjectaltname to > >>> random other hosts he manages. In this case again we need the ability > >>> for an admin to be able to provide the cert to the host. Also then a > >>> special case arises on automatic renew from certmonger, all names need > >>> to be checked against the old certificate being renewed, so > >>> authorization in that case would have to be based on the previous cert > >>> names and not on managedby, right ? > >>> If not automatic renewal would fail ? > >> > >> Hmm, the renewal would fail in this case. admin would have to request new > >> certificate manually in this case (when mangedby attribute is not set > >> properly). Previous certificate is not checked by the cert-request > >> authorization code. > > > > I think the renewal problem is more important. Failing renewals cripples > > one of the most important features of using FreeIPA as your CA for > > enrolled hosts. > > > > Simo. > > > > I am still not sure if there is not a confusion about the managedby attribute. > If you have an admin of lowsecure.example.com + have the managedby attributes > on other hosts correctly, local admin/certmonger on lowsecure.example.com can > still happily request or renew cert with the approved SANs. Sure. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Jan 10 17:15:51 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 10 Jan 2014 12:15:51 -0500 Subject: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens In-Reply-To: <52CF8566.6030803@redhat.com> References: <1389303173.1962.11.camel@localhost.localdomain> <1389307043.26102.253.camel@willson.li.ssimo.org> <52CF2DAB.8050508@redhat.com> <1389324524.26102.263.camel@willson.li.ssimo.org> <52CF8566.6030803@redhat.com> Message-ID: <1389374151.26102.283.camel@willson.li.ssimo.org> On Thu, 2014-01-09 at 21:30 -0800, Noriko Hosoi wrote: > Simo Sorce wrote: > > On Thu, 2014-01-09 at 15:15 -0800, Noriko Hosoi wrote: > >> Simo Sorce wrote: > >>> On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: > >>>> This patch is independent from my patches 0028-0031 and can be merged in > >>>> any order. > >>>> > >>>> This patch has a bug, but I can't figure it out. We need to set > >>>> nsslapd-access-userattr-strict on cn=config to "off". > >>> Uhmm what is the effect on ACL evaluation of changing this boolean ? > >> Ticket 47653 - Need a way to allow users to create entries assigned > >> to themselves > >> > >> Bug Description: There are cases where users need to be able to > >> create, edit and delete > >> their own entries. Using an ACI with the > >> "userattr" keyword does not > >> work with ADD operations(to prevent a security > >> hole). This prevents IPA's > >> OTP plugin from performing some necessary operations. > >> > >> Fix Description: Added a new config attribute > >> "nsslapd-access-userattr-strict". The default > >> is "on" or strict. For the IPA case, it would > >> need to be set to "off" in > >> order to allow the desired behavior. > >> > >> https://fedorahosted.org/389/ticket/47653 > >> > >> This patch is included in 389-ds-base-1.3.2.10 and newer. > > Thank you Noriko, but as I mentioned, I already read through the 389ds > > patch and it doesn't help me. Below I have a few more questions, I will > > add one that is more clear. > > > >>> Is this option simply allowing the use of add/delete ACIs to be > >>> specified in conjunction with userattr, so that a user can add an attr > >>> only if it contains its own DN ? > > So the entry in this case does not exist yet, so my question is whether > > the (userattr=attrFoo#userDN) part will actually match that attrFoo is > > set to contain the DN of the user that is performing the operation ? > I uesd this ACI: > aci: (target=ldap:///o=my.com)(targetattr=*) (version 3.0; acl "userattr > test"; allow (add,write,delete,read,search,compare) userattr = > "description#USERDN";) > > Please note uid=nuser does not exist yet. Does your question mean by > this add? Before coming to the ACL code, bind fails... > $ ldapmodify ... -D 'uid=nuser,o=my.com' -w Nuser -a << EOF > dn: uid=Nuser, o=my.com > objectClass: top > [...] > uid: Nuser > description: uid=nuser,o=my.com > userPassword: {CLEAR}Nuser > EOF > ldap_simple_bind: No such object > ldap_simple_bind: matched: o=my.com This is not what I had in mind, our use cases is something like this: aci: (target=ldap:///dc=bar)(targetattr=*) (version 3.0; acl "userattr test"; allow (add) userattr = "managedby#USERDN";) ldapmodify -D uid=user,dc=bar ... < >>> Will it allow the user to add multiple values to the same attr as long > >>> as one of the is the userDN ? O will it restrict that case ? > > This is also important, if attrFoo is a multivalued attribute, does this > > option allow any values to be set as long as one of them is userDN ? > > Or will it enforce that *only* userDN is add in the add operation ? > As long as the type of the attribute is not restricted as DN syntax, it > takes any value including DN. I tested with 'description' (e.g., > userattr = "description#USERDN") and verified it takes userDN as well as > any other values. > > $ ldapmodify ... -D 'cn=directory manager' -w > dn: uid=nuser4,o=my.com > changetype: modify > add: description > description: uid=nuser4,o=my.com > > $ ldapmodify ... -D 'uid=nuser4,o=my.com' -w Nuser4 > dn: uid=nuser4,o=my.com > changetype: modify > add: description > description: uid=nuser0,o=my.com > > modifying entry uid=nuser4,o=my.com > > $ ldapmodify ... -D 'uid=nuser0,o=my.com' -w Nuser0 > dn: uid=nuser4,o=my.com > changetype: modify > add: description > description: uid=nuser1,o=my.com > > modifying entry uid=nuser4,o=my.com > > $ ldapmodify ... -D 'uid=nuser1,o=my.com' -w Nuser1 > dn: uid=nuser4,o=my.com > changetype: modify > add: description > description: value > > $ ldapsearch ... -D 'cn=directory manager' -w -b > "uid=nuser4,o=my.com" description > dn: uid=Nuser4,o=my.com > description: uid=nuser4,o=my.com > description: uid=nuser0,o=my.com > description: uid=nuser1,o=my.com > description: value If I read this correctly, and I am not 100% sure yet, it seem to me this is exactly the opposite of what IPA needs. Our need is that uid=userX,... can only write its own DN as value or the attributes we are allowing through userattr. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Jan 10 17:18:03 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 10 Jan 2014 12:18:03 -0500 Subject: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens In-Reply-To: <1389374151.26102.283.camel@willson.li.ssimo.org> References: <1389303173.1962.11.camel@localhost.localdomain> <1389307043.26102.253.camel@willson.li.ssimo.org> <52CF2DAB.8050508@redhat.com> <1389324524.26102.263.camel@willson.li.ssimo.org> <52CF8566.6030803@redhat.com> <1389374151.26102.283.camel@willson.li.ssimo.org> Message-ID: <1389374283.26102.284.camel@willson.li.ssimo.org> On Fri, 2014-01-10 at 12:15 -0500, Simo Sorce wrote: > On Thu, 2014-01-09 at 21:30 -0800, Noriko Hosoi wrote: > > Simo Sorce wrote: > > > On Thu, 2014-01-09 at 15:15 -0800, Noriko Hosoi wrote: > > >> Simo Sorce wrote: > > >>> On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: > > >>>> This patch is independent from my patches 0028-0031 and can be merged in > > >>>> any order. > > >>>> > > >>>> This patch has a bug, but I can't figure it out. We need to set > > >>>> nsslapd-access-userattr-strict on cn=config to "off". > > >>> Uhmm what is the effect on ACL evaluation of changing this boolean ? > > >> Ticket 47653 - Need a way to allow users to create entries assigned > > >> to themselves > > >> > > >> Bug Description: There are cases where users need to be able to > > >> create, edit and delete > > >> their own entries. Using an ACI with the > > >> "userattr" keyword does not > > >> work with ADD operations(to prevent a security > > >> hole). This prevents IPA's > > >> OTP plugin from performing some necessary operations. > > >> > > >> Fix Description: Added a new config attribute > > >> "nsslapd-access-userattr-strict". The default > > >> is "on" or strict. For the IPA case, it would > > >> need to be set to "off" in > > >> order to allow the desired behavior. > > >> > > >> https://fedorahosted.org/389/ticket/47653 > > >> > > >> This patch is included in 389-ds-base-1.3.2.10 and newer. > > > Thank you Noriko, but as I mentioned, I already read through the 389ds > > > patch and it doesn't help me. Below I have a few more questions, I will > > > add one that is more clear. > > > > > >>> Is this option simply allowing the use of add/delete ACIs to be > > >>> specified in conjunction with userattr, so that a user can add an attr > > >>> only if it contains its own DN ? > > > So the entry in this case does not exist yet, so my question is whether > > > the (userattr=attrFoo#userDN) part will actually match that attrFoo is > > > set to contain the DN of the user that is performing the operation ? > > I uesd this ACI: > > aci: (target=ldap:///o=my.com)(targetattr=*) (version 3.0; acl "userattr > > test"; allow (add,write,delete,read,search,compare) userattr = > > "description#USERDN";) > > > > Please note uid=nuser does not exist yet. Does your question mean by > > this add? Before coming to the ACL code, bind fails... > > $ ldapmodify ... -D 'uid=nuser,o=my.com' -w Nuser -a << EOF > > dn: uid=Nuser, o=my.com > > objectClass: top > > [...] > > uid: Nuser > > description: uid=nuser,o=my.com > > userPassword: {CLEAR}Nuser > > EOF > > ldap_simple_bind: No such object > > ldap_simple_bind: matched: o=my.com > > This is not what I had in mind, our use cases is something like this: > aci: (target=ldap:///dc=bar)(targetattr=*) (version 3.0; acl "userattr > test"; allow (add) userattr = "managedby#USERDN";) > > ldapmodify -D uid=user,dc=bar ... < dn: cn=somobj,dc=bar > ... > managedby: uid=user,dc=bar > > > This should succeed, however if managedby includes anything but > "uid=user,dc=bar" it should fail. > > > >>> Will it allow the user to add multiple values to the same attr as long > > >>> as one of the is the userDN ? O will it restrict that case ? > > > This is also important, if attrFoo is a multivalued attribute, does this > > > option allow any values to be set as long as one of them is userDN ? > > > Or will it enforce that *only* userDN is add in the add operation ? > > As long as the type of the attribute is not restricted as DN syntax, it > > takes any value including DN. I tested with 'description' (e.g., > > userattr = "description#USERDN") and verified it takes userDN as well as > > any other values. > > > > $ ldapmodify ... -D 'cn=directory manager' -w > > dn: uid=nuser4,o=my.com > > changetype: modify > > add: description > > description: uid=nuser4,o=my.com > > > > $ ldapmodify ... -D 'uid=nuser4,o=my.com' -w Nuser4 > > dn: uid=nuser4,o=my.com > > changetype: modify > > add: description > > description: uid=nuser0,o=my.com > > > > modifying entry uid=nuser4,o=my.com > > > > $ ldapmodify ... -D 'uid=nuser0,o=my.com' -w Nuser0 > > dn: uid=nuser4,o=my.com > > changetype: modify > > add: description > > description: uid=nuser1,o=my.com > > > > modifying entry uid=nuser4,o=my.com > > > > $ ldapmodify ... -D 'uid=nuser1,o=my.com' -w Nuser1 > > dn: uid=nuser4,o=my.com > > changetype: modify > > add: description > > description: value > > > > $ ldapsearch ... -D 'cn=directory manager' -w -b > > "uid=nuser4,o=my.com" description > > dn: uid=Nuser4,o=my.com > > description: uid=nuser4,o=my.com > > description: uid=nuser0,o=my.com > > description: uid=nuser1,o=my.com > > description: value > > If I read this correctly, and I am not 100% sure yet, it seem to me this > is exactly the opposite of what IPA needs. > > Our need is that uid=userX,... can only write its own DN as value or the > attributes we are allowing through userattr. > > Simo. > -- Simo Sorce * Red Hat, Inc * New York From nhosoi at redhat.com Fri Jan 10 18:49:14 2014 From: nhosoi at redhat.com (Noriko Hosoi) Date: Fri, 10 Jan 2014 10:49:14 -0800 Subject: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens In-Reply-To: <1389374283.26102.284.camel@willson.li.ssimo.org> References: <1389303173.1962.11.camel@localhost.localdomain> <1389307043.26102.253.camel@willson.li.ssimo.org> <52CF2DAB.8050508@redhat.com> <1389324524.26102.263.camel@willson.li.ssimo.org> <52CF8566.6030803@redhat.com> <1389374151.26102.283.camel@willson.li.ssimo.org> <1389374283.26102.284.camel@willson.li.ssimo.org> Message-ID: <52D040AA.7080601@redhat.com> Hi Simo, Simo Sorce wrote: > On Fri, 2014-01-10 at 12:15 -0500, Simo Sorce wrote: >> This is not what I had in mind, our use cases is something like this: >> aci: (target=ldap:///dc=bar)(targetattr=*) (version 3.0; acl "userattr >> test"; allow (add) userattr = "managedby#USERDN";) >> >> ldapmodify -D uid=user,dc=bar ... < ^^^^^^^^ Sorry this should have been ldapadd. > Simo. Yes, it works. aci: (target=ldap:///o=my.com)(targetattr=*) (version 3.0; acl "userattr test" ; allow (add,write,delete,read,search,compare) userattr = "description#USERDN";) $ ldapmodify ... -D 'uid=nuser0,o=my.com' -w Nuser0 -a << EOF dn: uid=Nuser6, o=my.com ... description: uid=nuser0,o=my.com EOF $ ldapsearch... -b "o=my.com" "(uid=nuser6)" description dn: uid=Nuser6,o=my.com description: uid=nuser0,o=my.com # delete uid=nuser6 # attempt to add the entry by other user fails: $ ldapmodify ... -D 'uid=nuser1,o=my.com' -w Nuser1 -a << EOF dn: uid=Nuser6, o=my.com ... description: uid=nuser0,o=my.com EOF ldap_add: Insufficient access ldap_add: additional info: Insufficient 'add' privilege to the 'userPassword' attribute > >> dn: cn=somobj,dc=bar >> ... >> managedby: uid=user,dc=bar >> >> >> This should succeed, however if managedby includes anything but >> "uid=user,dc=bar" it should fail. >> >>>>>> Will it allow the user to add multiple values to the same attr as long >>>>>> as one of the is the userDN ? O will it restrict that case ? >>>> This is also important, if attrFoo is a multivalued attribute, does this >>>> option allow any values to be set as long as one of them is userDN ? >>>> Or will it enforce that *only* userDN is add in the add operation ? >>> As long as the type of the attribute is not restricted as DN syntax, it >>> takes any value including DN. I tested with 'description' (e.g., >>> userattr = "description#USERDN") and verified it takes userDN as well as >>> any other values. >>> >>> $ ldapmodify ... -D 'cn=directory manager' -w >>> dn: uid=nuser4,o=my.com >>> changetype: modify >>> add: description >>> description: uid=nuser4,o=my.com >>> >>> $ ldapmodify ... -D 'uid=nuser4,o=my.com' -w Nuser4 >>> dn: uid=nuser4,o=my.com >>> changetype: modify >>> add: description >>> description: uid=nuser0,o=my.com >>> >>> modifying entry uid=nuser4,o=my.com >>> >>> $ ldapmodify ... -D 'uid=nuser0,o=my.com' -w Nuser0 >>> dn: uid=nuser4,o=my.com >>> changetype: modify >>> add: description >>> description: uid=nuser1,o=my.com >>> >>> modifying entry uid=nuser4,o=my.com >>> >>> $ ldapmodify ... -D 'uid=nuser1,o=my.com' -w Nuser1 >>> dn: uid=nuser4,o=my.com >>> changetype: modify >>> add: description >>> description: value >>> >>> $ ldapsearch ... -D 'cn=directory manager' -w -b >>> "uid=nuser4,o=my.com" description >>> dn: uid=Nuser4,o=my.com >>> description: uid=nuser4,o=my.com >>> description: uid=nuser0,o=my.com >>> description: uid=nuser1,o=my.com >>> description: value >> If I read this correctly, and I am not 100% sure yet, it seem to me this >> is exactly the opposite of what IPA needs. >> >> Our need is that uid=userX,... can only write its own DN as value or the >> attributes we are allowing through userattr. You want to allow this $ ldapmodify ... -D 'uid=*userX*,o=my.com' -w userX << EOF dn: uid=userY,o=my.com changetype: modify replace: managedby managedby: uid=*userX*,o=my.com EOF But NOT allow this? $ ldapmodify ... -D 'uid=*userX*,o=my.com' -w userX << EOF dn: uid=userY,o=my.com changetype: modify replace: managedby managedby: uid=*userZ*,o=my.com EOF I don't think we have the control there... --noriko -------------- next part -------------- An HTML attachment was scrubbed... URL: From npmccallum at redhat.com Fri Jan 10 20:14:16 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 10 Jan 2014 15:14:16 -0500 Subject: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens In-Reply-To: <1389307043.26102.253.camel@willson.li.ssimo.org> References: <1389303173.1962.11.camel@localhost.localdomain> <1389307043.26102.253.camel@willson.li.ssimo.org> Message-ID: <1389384856.2072.6.camel@localhost.localdomain> On Thu, 2014-01-09 at 17:37 -0500, Simo Sorce wrote: > On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: > > This patch is independent from my patches 0028-0031 and can be merged in > > any order. > > > > This patch has a bug, but I can't figure it out. We need to set > > nsslapd-access-userattr-strict on cn=config to "off". > > Uhmm what is the effect on ACL evaluation of changing this boolean ? > I can;t figure out from your commit not from 389ds commit what exactly > changes and how it impacts the security of the directory. > > I ask because I was planning on using userattr to protect some > operations in the password plugin but was waiting due to bug: > https://fedorahosted.org/389/ticket/47571 which is beeing resolved. > > I want to make sure your change won't change what this ACIs would allow. > > Is this option simply allowing the use of add/delete ACIs to be > specified in conjunction with userattr, so that a user can add an attr > only if it contains its own DN ? > > Will it allow the user to add multiple values to the same attr as long > as one of the is the userDN ? O will it restrict that case ? > > (I know that ipaTokenOwner is a single-value attribute, but the > mechanism you are enabling here is general, and I want to be sure of > what the semantics are) After testing, it was determined that the 389DS patch #47653 does in fact permit addition if any of the multi-valued attributes match the condition. This is definitely problematic. After discussion today with nkinder, simo, nhosoi, we agreed to roll-back patch #47653 and find an alternate approach. This also invalidates patch freeipa-npmccallum-0032. Simo will follow up this email with an alternate proposal. Nathaniel From npmccallum at redhat.com Fri Jan 10 20:21:49 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 10 Jan 2014 15:21:49 -0500 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <52CEC0AE.9040502@redhat.com> References: <52CEC0AE.9040502@redhat.com> Message-ID: <1389385309.2072.12.camel@localhost.localdomain> On Thu, 2014-01-09 at 16:30 +0100, Tomas Babej wrote: > Hi, > > Adds a parameter that represents a DateTime format using datetime.datetime > object from python's native datetime library. > > In the CLI, accepts one of the following formats: > Accepts subset of values defined by ISO 8601: > %Y-%m-%dT%H:%M:%S > %Y-%m-%dT%H:%M > '%Y%m%dT%H:%M:%S' > '%Y%m%dT%H:%M' > > Also accepts LDAP Generalized time in the following format: > '%Y%m%d%H%M%SZ' > > As a simplification, it does not deal with timezone info and ISO 8601 > values with timezone info (+-hhmm) are rejected. Values are expected > to be in the UTC timezone. > > Values are saved to LDAP as LDAP Generalized time values in the format > '%Y%m%d%H%SZ' (no time fractions and UTC timezone is assumed). To avoid > confusion, in addition to subset of ISO 8601 values, the LDAP generalized > time in the format '%Y%m%d%H%M%SZ' is also accepted as an input (as this > is the > format user will see on the output). > > Part of: https://fedorahosted.org/freeipa/ticket/3306 The date/time syntax formats are not compliant with ISO 8601. You stated they are expected to be in UTC timezone, but no 'Z' is expected in most of them. This is not only non-standard, but would prevent you from every supporting local time in the future. Nathaniel From abokovoy at redhat.com Fri Jan 10 23:20:59 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 11 Jan 2014 01:20:59 +0200 Subject: [Freeipa-devel] FreeIPA OTP End-to-End In-Reply-To: <1389306368.1962.31.camel@localhost.localdomain> References: <1386968251.1948.25.camel@localhost.localdomain> <1389306368.1962.31.camel@localhost.localdomain> Message-ID: <20140110232059.GA22677@redhat.com> On Thu, 09 Jan 2014, Nathaniel McCallum wrote: >New RPMs are up: http://npmccallum.fedorapeople.org/freeipa-otp/rpms/ Just as a note -- we can use copr service to provide a better experience for testing. I made a copr repo with previous patchset last year: http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ Any Fedora contributor can make own copr repositories. >WHAT'S NEW IN THE RPMS? >* 389ds OTP Last Token Plugin >* 389ds OTP Sync Plugin >* HOTP token support >* OTP UI is now working > >All of the non-UI code is currently on the list. Petr is working on UI >cleanup. You can see all the patches here: >https://github.com/npmccallum/freeipa/tree/otp >https://github.com/npmccallum/freeipa/tree/otpui > >KNOWN ISSUES >Setting User Auth Type globally doesn't work: >https://fedorahosted.org/freeipa/ticket/4105 > >SELinux is broken on F20 (should be fixed in rawhide): >https://bugzilla.redhat.com/show_bug.cgi?id=970163 There seem to be two parts, one is covered by this bug and another one is related to SSSD/logind communication: allow sssd_t systemd_logind_var_run_t:dir search; allow sssd_t systemd_logind_var_run_t:file { read getattr open }; >User's can't add their own tokens. A patch to fix this is in the RPMs, >but currently has a bug. A workaround exists. Details are here: >https://www.redhat.com/archives/freeipa-devel/2014-January/msg00068.html > >Alexander Bokovoy (I think) found some issues when interacting with >pkinit. I don't know the state of this. It is unclear what exactly happens but from Jakub Hrozek's testing we saw that on client side (preauth2.c) in tryagain() code 'pkinit' module gets control despite 'otp' module returns success and modified pa_data. 'pkinit' cannot process pa_data afterwards and therefore returns error which is interpreted by the libkrb5 as a failure of preauth processing. >Alexander Bokovoy found a bug with SSSD that has (a few minutes ago) >been patched. Details are here: >https://lists.fedorahosted.org/pipermail/sssd-devel/2014-January/017934.html > >STILL NEEDED >* UI patches polished and sent to the list. >* OTP Sync Client (both CLI and UI). I'll get through the otp patch reviews next week. > >Nathaniel > >On Fri, 2013-12-13 at 15:57 -0500, Nathaniel McCallum wrote: >> This is an email to track the status of the OTP project as we push >> toward completion. I'm also attempting to get all the pieces in play so >> that they are testable. >> >> RPMs >> Available here: http://npmccallum.fedorapeople.org/freeipa-otp/rpms/ >> These currently contain the CLI and UI patches, but exclude the DS >> plugin patch. I will merge this last patch in when submitted to the >> list. >> >> OTP CLI >> All of the patches are merged except npmccallum-0024, which is >> undergoing active review. >> https://www.redhat.com/archives/freeipa-devel/2013-December/msg00102.html >> >> OTP UI >> Thanks to Petr Vobornik for his set of patches implementing the UI. They >> can be found rebased on top of my otp changes here: >> https://github.com/npmccallum/freeipa/commits/otpui >> >> Authentication methods and RADIUS proxy support seems to be fully >> functional and I have not encountered any bugs. I'm not currently able >> to get the OTP UI to show up at all (I may well be doing something >> wrong). >> >> I believe Petr plans to clean these up and resubmit them to the list. >> >> One additional patch will be required for the token sync extop. >> >> DS PLUGIN >> I am nearing completion on the DS plugin providing support for deletion >> protection and the token sync extop. This should hit the list next week. >> >> OTHER >> Am I missing anything? >> >> Nathaniel >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > >_______________________________________________ >Freeipa-devel mailing list >Freeipa-devel at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-devel -- / Alexander Bokovoy From simo at redhat.com Sat Jan 11 23:59:40 2014 From: simo at redhat.com (Simo Sorce) Date: Sat, 11 Jan 2014 18:59:40 -0500 Subject: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens In-Reply-To: <1389384856.2072.6.camel@localhost.localdomain> References: <1389303173.1962.11.camel@localhost.localdomain> <1389307043.26102.253.camel@willson.li.ssimo.org> <1389384856.2072.6.camel@localhost.localdomain> Message-ID: <1389484780.26102.365.camel@willson.li.ssimo.org> On Fri, 2014-01-10 at 15:14 -0500, Nathaniel McCallum wrote: > On Thu, 2014-01-09 at 17:37 -0500, Simo Sorce wrote: > > On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: > > > This patch is independent from my patches 0028-0031 and can be merged in > > > any order. > > > > > > This patch has a bug, but I can't figure it out. We need to set > > > nsslapd-access-userattr-strict on cn=config to "off". > > > > Uhmm what is the effect on ACL evaluation of changing this boolean ? > > I can;t figure out from your commit not from 389ds commit what exactly > > changes and how it impacts the security of the directory. > > > > I ask because I was planning on using userattr to protect some > > operations in the password plugin but was waiting due to bug: > > https://fedorahosted.org/389/ticket/47571 which is beeing resolved. > > > > I want to make sure your change won't change what this ACIs would allow. > > > > Is this option simply allowing the use of add/delete ACIs to be > > specified in conjunction with userattr, so that a user can add an attr > > only if it contains its own DN ? > > > > Will it allow the user to add multiple values to the same attr as long > > as one of the is the userDN ? O will it restrict that case ? > > > > (I know that ipaTokenOwner is a single-value attribute, but the > > mechanism you are enabling here is general, and I want to be sure of > > what the semantics are) > > After testing, it was determined that the 389DS patch #47653 does in > fact permit addition if any of the multi-valued attributes match the > condition. This is definitely problematic. > > After discussion today with nkinder, simo, nhosoi, we agreed to > roll-back patch #47653 and find an alternate approach. This also > invalidates patch freeipa-npmccallum-0032. Simo will follow up this > email with an alternate proposal. Sorry for the delay, my proposal is to add a new keyword to the ACI system: selfattr selfattr is similar to userattr + #userdn, the syntax is simply: (selfattr=attrname) attrname is the name of the attribute that will be tested by the ACI evaluator, and the semantics combined with the various allow flags are the following: allow add: an entry can be added if and only if attrname = userDN where the user DN is the authenticated user DN. Furthermore the only value (is attrname is multivalued) allowed is again userDN allow delete: an entry can be deleted only if attrname has exclusively one value, the DN of the authenticated user For the write,read,search operation I am not sure we really need a special syntax, maybe we should actually disallow the combination. If we allow it we may (or not) want to have the following behavior: allow write: the only value that can be added to or removed from attrname is the authenticated userDN allow read: the entry can be searched but the only value returned for attrname is that of the authenticated userDN if present allow search/compare: the entry can be searched only if attrname contains the authenticated userDN I suspect these 3 behavrios can be obtained with different syntaxes too, for example using targeattr/targetattrfilter, in that case, maybe it is better to just restrict selfattr to be valid with add/delete operations for now. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Sun Jan 12 12:17:37 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 12 Jan 2014 13:17:37 +0100 Subject: [Freeipa-devel] FreeIPA OTP End-to-End In-Reply-To: <20140110232059.GA22677@redhat.com> References: <1386968251.1948.25.camel@localhost.localdomain> <1389306368.1962.31.camel@localhost.localdomain> <20140110232059.GA22677@redhat.com> Message-ID: <20140112121737.GD29208@hendrix> On Sat, Jan 11, 2014 at 01:20:59AM +0200, Alexander Bokovoy wrote: > On Thu, 09 Jan 2014, Nathaniel McCallum wrote: > >New RPMs are up: http://npmccallum.fedorapeople.org/freeipa-otp/rpms/ > Just as a note -- we can use copr service to provide a better experience > for testing. I made a copr repo with previous patchset last year: > http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ > Any Fedora contributor can make own copr repositories. > > >WHAT'S NEW IN THE RPMS? > >* 389ds OTP Last Token Plugin > >* 389ds OTP Sync Plugin > >* HOTP token support > >* OTP UI is now working > > > >All of the non-UI code is currently on the list. Petr is working on UI > >cleanup. You can see all the patches here: > >https://github.com/npmccallum/freeipa/tree/otp > >https://github.com/npmccallum/freeipa/tree/otpui > > > >KNOWN ISSUES > >Setting User Auth Type globally doesn't work: > >https://fedorahosted.org/freeipa/ticket/4105 > > > >SELinux is broken on F20 (should be fixed in rawhide): > >https://bugzilla.redhat.com/show_bug.cgi?id=970163 > There seem to be two parts, one is covered by this bug and another one > is related to SSSD/logind communication: > > allow sssd_t systemd_logind_var_run_t:dir search; > allow sssd_t systemd_logind_var_run_t:file { read getattr open }; Interesting, which version are you running? The logind support is currently only present in master (aka 1.12 dev) > > >User's can't add their own tokens. A patch to fix this is in the RPMs, > >but currently has a bug. A workaround exists. Details are here: > >https://www.redhat.com/archives/freeipa-devel/2014-January/msg00068.html > > > >Alexander Bokovoy (I think) found some issues when interacting with > >pkinit. I don't know the state of this. > It is unclear what exactly happens but from Jakub Hrozek's testing we > saw that on client side (preauth2.c) in tryagain() code 'pkinit' module > gets control despite 'otp' module returns success and modified pa_data. > 'pkinit' cannot process pa_data afterwards and therefore returns error > which is interpreted by the libkrb5 as a failure of preauth processing. Right, I can see this problem on my local VM test machines. Ping me if you'd like to run some tests and I can create a tunnel. Petr Vobornik was also seeing some failures that seemed similar, but with my limited Kerberos knowledge I can't tell for certain if it's the same problem. From abokovoy at redhat.com Sun Jan 12 20:07:49 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 12 Jan 2014 22:07:49 +0200 Subject: [Freeipa-devel] FreeIPA OTP End-to-End In-Reply-To: <20140112121737.GD29208@hendrix> References: <1386968251.1948.25.camel@localhost.localdomain> <1389306368.1962.31.camel@localhost.localdomain> <20140110232059.GA22677@redhat.com> <20140112121737.GD29208@hendrix> Message-ID: <20140112200749.GA23915@redhat.com> On Sun, 12 Jan 2014, Jakub Hrozek wrote: >On Sat, Jan 11, 2014 at 01:20:59AM +0200, Alexander Bokovoy wrote: >> On Thu, 09 Jan 2014, Nathaniel McCallum wrote: >> >New RPMs are up: http://npmccallum.fedorapeople.org/freeipa-otp/rpms/ >> Just as a note -- we can use copr service to provide a better experience >> for testing. I made a copr repo with previous patchset last year: >> http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ >> Any Fedora contributor can make own copr repositories. >> >> >WHAT'S NEW IN THE RPMS? >> >* 389ds OTP Last Token Plugin >> >* 389ds OTP Sync Plugin >> >* HOTP token support >> >* OTP UI is now working >> > >> >All of the non-UI code is currently on the list. Petr is working on UI >> >cleanup. You can see all the patches here: >> >https://github.com/npmccallum/freeipa/tree/otp >> >https://github.com/npmccallum/freeipa/tree/otpui >> > >> >KNOWN ISSUES >> >Setting User Auth Type globally doesn't work: >> >https://fedorahosted.org/freeipa/ticket/4105 >> > >> >SELinux is broken on F20 (should be fixed in rawhide): >> >https://bugzilla.redhat.com/show_bug.cgi?id=970163 >> There seem to be two parts, one is covered by this bug and another one >> is related to SSSD/logind communication: >> >> allow sssd_t systemd_logind_var_run_t:dir search; >> allow sssd_t systemd_logind_var_run_t:file { read getattr open }; > >Interesting, which version are you running? The logind support is >currently only present in master (aka 1.12 dev) I'm running master, of course ;) >> >> >User's can't add their own tokens. A patch to fix this is in the RPMs, >> >but currently has a bug. A workaround exists. Details are here: >> >https://www.redhat.com/archives/freeipa-devel/2014-January/msg00068.html >> > >> >Alexander Bokovoy (I think) found some issues when interacting with >> >pkinit. I don't know the state of this. >> It is unclear what exactly happens but from Jakub Hrozek's testing we >> saw that on client side (preauth2.c) in tryagain() code 'pkinit' module >> gets control despite 'otp' module returns success and modified pa_data. >> 'pkinit' cannot process pa_data afterwards and therefore returns error >> which is interpreted by the libkrb5 as a failure of preauth processing. > >Right, I can see this problem on my local VM test machines. Ping me if >you'd like to run some tests and I can create a tunnel. Petr Vobornik >was also seeing some failures that seemed similar, but with my limited >Kerberos knowledge I can't tell for certain if it's the same problem. This is certainly related to some instability in these new features in Kerberos release -- we are dealing with a new code after all, only recently getting full stack to properly test it. -- / Alexander Bokovoy From jhrozek at redhat.com Mon Jan 13 09:17:50 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 13 Jan 2014 10:17:50 +0100 Subject: [Freeipa-devel] FreeIPA OTP End-to-End In-Reply-To: <20140112200749.GA23915@redhat.com> References: <1386968251.1948.25.camel@localhost.localdomain> <1389306368.1962.31.camel@localhost.localdomain> <20140110232059.GA22677@redhat.com> <20140112121737.GD29208@hendrix> <20140112200749.GA23915@redhat.com> Message-ID: <20140113091750.GD4981@hendrix.brq.redhat.com> On Sun, Jan 12, 2014 at 10:07:49PM +0200, Alexander Bokovoy wrote: > >>There seem to be two parts, one is covered by this bug and another one > >>is related to SSSD/logind communication: > >> > >>allow sssd_t systemd_logind_var_run_t:dir search; > >>allow sssd_t systemd_logind_var_run_t:file { read getattr open }; > > > >Interesting, which version are you running? The logind support is > >currently only present in master (aka 1.12 dev) > I'm running master, of course ;) Great, then would you mind submitting against Rawhide SELinux policy? 1.12 is coming up in F-21 first, so Rawhide would be the place to fix the policy. From sbose at redhat.com Mon Jan 13 12:00:02 2014 From: sbose at redhat.com (Sumit Bose) Date: Mon, 13 Jan 2014 13:00:02 +0100 Subject: [Freeipa-devel] [PATCH 125] CLDAP: do not prepend \\ Message-ID: <20140113120002.GM2855@localhost.localdomain> Hi, Scott found that the fix for https://fedorahosted.org/freeipa/ticket/4028 is not complete. After some checks and comparisons with samba and AD behaviour I came to the conclusion that the two \\ at the beginning of the NetBIOS name of the IPA server is not needed in the response of NETLOGON_NT_VERSION_5EX requests which is the only type we handle so far. In general AD seems to be smart enough the handle the \\ even in those responses but if the NetBIOS name has 15 characters the response is not accepted anymore. Please check if you can see any regressions with this change. During testing I came across two things related to samba. While looking at network trace Scott recorded it looked like Samba does not cut a long hostname for the NetBIOS name. This might be in agreement to what Metze recently posted in his master4-schannel-ok branch for netlogon_creds_cli_context_global(). As usual Metze is smarter than us and tried to minimize the chance for name collisions with the help of Jenkins hash. I just wonder why he treats the NetBIOS name only here this way and not generally? With respect to IPA we might want to consider to set 'netbios name' in the samba config explicitly to avoid disconnects? While testing against AD with other request types I've seen that in some cases the NetBIOS name was returned with the two additional \ in the beginning, even if the AD NetBIOS name already had 15 characters. Strange the name was even encoded in UCS-2 in this case. Unfortunately I was not able to find good documentation on the specifics of those packages. If you know some good docs please send me the link otherwise we might what to ask MSFT for clarification. bye, Sumit -------------- next part -------------- From 0b782064945352ad488e92b457bbfda2270ddf66 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 13 Jan 2014 10:43:33 +0100 Subject: [PATCH] CLDAP: do not prepend \\ For NETLOGON_NT_VERSION_5EX requests the prepended \\ is not expected in the PDC NetBIOS name. In general AD seems to be smart enough to handle the two \ signs. But if the NetBIOS name reaches the maximum of 15 character AD does not accept the responses anymore. Fixes https://fedorahosted.org/freeipa/ticket/4028 --- daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c index 9ba05829418a0d1de46f2c7776cc15c54a9eab1c..c03172d474589ddee84f1cfa5395c23fdba83bcb 100644 --- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c @@ -163,7 +163,7 @@ static int ipa_cldap_encode_netlogon(char *fq_hostname, char *domain, nlr->domain_name = name; /* copy the first 15 characters of the fully qualified hostname*/ - pdc_name = talloc_asprintf(nlr, "\\\\%.*s", NETBIOS_NAME_MAX, fq_hostname); + pdc_name = talloc_asprintf(nlr, "%.*s", NETBIOS_NAME_MAX, fq_hostname); for (p = pdc_name; *p; p++) { /* Create the NetBIOS name from the first segment of the hostname */ -- 1.8.1.4 From jcholast at redhat.com Mon Jan 13 12:41:20 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 13 Jan 2014 13:41:20 +0100 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <1389385309.2072.12.camel@localhost.localdomain> References: <52CEC0AE.9040502@redhat.com> <1389385309.2072.12.camel@localhost.localdomain> Message-ID: <52D3DEF0.7020302@redhat.com> Hi, On 10.1.2014 21:21, Nathaniel McCallum wrote: > On Thu, 2014-01-09 at 16:30 +0100, Tomas Babej wrote: >> Hi, >> >> Adds a parameter that represents a DateTime format using datetime.datetime >> object from python's native datetime library. >> >> In the CLI, accepts one of the following formats: >> Accepts subset of values defined by ISO 8601: >> %Y-%m-%dT%H:%M:%S >> %Y-%m-%dT%H:%M >> '%Y%m%dT%H:%M:%S' >> '%Y%m%dT%H:%M' >> >> Also accepts LDAP Generalized time in the following format: >> '%Y%m%d%H%M%SZ' >> >> As a simplification, it does not deal with timezone info and ISO 8601 >> values with timezone info (+-hhmm) are rejected. Values are expected >> to be in the UTC timezone. >> >> Values are saved to LDAP as LDAP Generalized time values in the format >> '%Y%m%d%H%SZ' (no time fractions and UTC timezone is assumed). To avoid >> confusion, in addition to subset of ISO 8601 values, the LDAP generalized >> time in the format '%Y%m%d%H%M%SZ' is also accepted as an input (as this >> is the >> format user will see on the output). >> >> Part of: https://fedorahosted.org/freeipa/ticket/3306 > > The date/time syntax formats are not compliant with ISO 8601. You stated > they are expected to be in UTC timezone, but no 'Z' is expected in most > of them. This is not only non-standard, but would prevent you from every > supporting local time in the future. +1, please require the trailing "Z". I think generalized time format should be the preferred one, as it is stored in LDAP and thus returned by commands. Also, do we really need all of these other formats? Few nitpicks about DateTime implementation: * you should call Param._convert_scalar from DateTime._convert_scalar * raise ConversionError instead of ValidationError and use get_param_name() for name * instead of "isinstance(value, str) or isinstance(value, unicode)" use "isinstance(value, basestring)" * don't use pythonisms in public error messages (""does not match any of accepted formats: %s" % self.accepted_formats") * public error messages should be translatable It should look something like this (untested, from top of my head): type = datetime.datetime type_error = _('must be a date/time value') def _convert_scalar(self, value, index=None): if isinstance(value, basestring): for date_format in self.accepted_formats: try: time = datetime.datetime.strptime(value, date_format) return time except ValueError: pass # If we get here, the strptime call did not succeed for any # the accepted formats, therefore raise error error = _("does not match any of accepted formats: %s") % (', '.join(self.accepted_formats)) raise ConversionError(name=self.get_param_name(), index=index, error=error) return super(DateTime, self)._convert_scalar(value, index) + if isinstance(value, DateTime): + return str(value) Return datetime object here please, or at least unicode in generalized time format (or whatever the preferred format is, see above). + elif isinstance(val, datetime.datetime): + return val.strftime("%Y%m%dT%H:%M:%S") Again, please use the preferred format here please. Honza -- Jan Cholasta From pvoborni at redhat.com Mon Jan 13 13:57:13 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 13 Jan 2014 14:57:13 +0100 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <52D3DEF0.7020302@redhat.com> References: <52CEC0AE.9040502@redhat.com> <1389385309.2072.12.camel@localhost.localdomain> <52D3DEF0.7020302@redhat.com> Message-ID: <52D3F0B9.4050302@redhat.com> On 13.1.2014 13:41, Jan Cholasta wrote: > Hi, > > On 10.1.2014 21:21, Nathaniel McCallum wrote: >> On Thu, 2014-01-09 at 16:30 +0100, Tomas Babej wrote: >>> Hi, >>> >>> Adds a parameter that represents a DateTime format using >>> datetime.datetime >>> object from python's native datetime library. >>> >>> In the CLI, accepts one of the following formats: >>> Accepts subset of values defined by ISO 8601: >>> %Y-%m-%dT%H:%M:%S >>> %Y-%m-%dT%H:%M >>> '%Y%m%dT%H:%M:%S' >>> '%Y%m%dT%H:%M' >>> >>> Also accepts LDAP Generalized time in the following format: >>> '%Y%m%d%H%M%SZ' >>> >>> As a simplification, it does not deal with timezone info and ISO 8601 >>> values with timezone info (+-hhmm) are rejected. Values are expected >>> to be in the UTC timezone. >>> >>> Values are saved to LDAP as LDAP Generalized time values in the format >>> '%Y%m%d%H%SZ' (no time fractions and UTC timezone is assumed). To avoid >>> confusion, in addition to subset of ISO 8601 values, the LDAP >>> generalized >>> time in the format '%Y%m%d%H%M%SZ' is also accepted as an input (as this >>> is the >>> format user will see on the output). >>> >>> Part of: https://fedorahosted.org/freeipa/ticket/3306 >> >> The date/time syntax formats are not compliant with ISO 8601. You stated >> they are expected to be in UTC timezone, but no 'Z' is expected in most >> of them. This is not only non-standard, but would prevent you from every >> supporting local time in the future. > > +1, please require the trailing "Z". > > > I think generalized time format should be the preferred one, as it is > stored in LDAP and thus returned by commands. Also, do we really need > all of these other formats? +1 That API should accept and always return generalized time. But UIs(CLI, Web) should display something more human readable. Like: %Y-%m-%dT%H:%M:%SZ or IMHO better (but not ISO 8601): %Y-%m-%d %H:%M:%SZ ie. 2014-03-08 14:16:55Z compared to 2014-03-08T14:16:55Z or 20140308141655Z Both should accept input value in the same format. Usage of different output and input formats is confusing. Thus I agree with supporting more input formats. Decision whether it should be done on API level or client level is another matter. I has been implementing the Web UI part and I think we should also support a formats without time component. My initial impl. supports combinations of: var dates = [ ['YYYY-MM-DD', /^(\d{4})-(\d{2})-(\d{2})$/], ['YYYYMMDD',/^(\d{4})(\d{2})(\d{2})$/] ]; var times = [ ['HH:mm:ss', /^(\d\d):(\d\d):(\d\d)Z$/], ['HH:mm', /^(\d\d):(\d\d)Z$/], ['HH', /^(\d\d)Z$/] ]; + generalized time ['YYYYMMDDHHmmssZ',/^(\d{4})(\d{2})(\d{2})(\d{2})(\d{2})(\d{2})Z$/] with /( |T)/ as divider and time optional. Both UIs should also tell the user what is the expected format (at least one of them). Getting incorrect format error without knowing it is annoying. > > > Few nitpicks about DateTime implementation: > > * you should call Param._convert_scalar from DateTime._convert_scalar > * raise ConversionError instead of ValidationError and use > get_param_name() for name > * instead of "isinstance(value, str) or isinstance(value, unicode)" > use "isinstance(value, basestring)" > * don't use pythonisms in public error messages (""does not match any > of accepted formats: %s" % self.accepted_formats") > * public error messages should be translatable > > It should look something like this (untested, from top of my head): > > type = datetime.datetime > type_error = _('must be a date/time value') > > def _convert_scalar(self, value, index=None): > if isinstance(value, basestring): > for date_format in self.accepted_formats: > try: > time = datetime.datetime.strptime(value, date_format) > return time > except ValueError: > pass > > # If we get here, the strptime call did not succeed for any > # the accepted formats, therefore raise error > > error = _("does not match any of accepted formats: %s") % > (', '.join(self.accepted_formats)) > > raise ConversionError(name=self.get_param_name(), > index=index, > error=error) > > return super(DateTime, self)._convert_scalar(value, index) > > > + if isinstance(value, DateTime): > + return str(value) > > Return datetime object here please, or at least unicode in generalized > time format (or whatever the preferred format is, see above). > > > + elif isinstance(val, datetime.datetime): > + return val.strftime("%Y%m%dT%H:%M:%S") > > Again, please use the preferred format here please. > > > Honza > -- Petr Vobornik From pvoborni at redhat.com Mon Jan 13 16:09:59 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 13 Jan 2014 17:09:59 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI Message-ID: <52D40FD7.5090301@redhat.com> Hi, these patches implements the OTP Web UI. Last 5 patches is the OTP UI. First 6 patches is a little refactoring/bug fixes needed for them. General password dialog is introduced to avoid another implementation. Self-service UI is implemented to be very simple. Atm user can choose only token name. Admin interface allows to enter all values. It's based on the RCUE work -> we need to push RCUE first. Thanks Nathaniel for review of the last font package. It will speed things up. Know bugs: - there is clash in id's of checkboxes preventing editation of subsequently displayed ones with the same name. Will be fixed in separate patch. - bugs caused by bugs in API (adding/removal of own tokens in self-service, inability to enter key on token creation - https://fedorahosted.org/freeipa/ticket/4099) - datetime format (widget+validator) will be implemented in separate patch - no support of not reviewed CLI patches (HOTP..) Cgit: http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp https://fedorahosted.org/freeipa/ticket/3369 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0531-Added-empty-value-meaning-to-boolean-formatter.patch Type: text/x-patch Size: 2882 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0532-Declarative-replacement-of-array-item-in-specificati.patch Type: text/x-patch Size: 3635 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0533-Fixed-doc-examples-in-Spec_mod.patch Type: text/x-patch Size: 1310 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0534-Password-Dialog.patch Type: text/x-patch Size: 11243 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0535-Use-general-password-dialog-for-host-OTP.patch Type: text/x-patch Size: 6300 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0536-Fix-handling-of-action-visibility-change-in-action-p.patch Type: text/x-patch Size: 1525 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0537-UI-for-OTP-tokens.patch Type: text/x-patch Size: 15643 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0538-UI-for-radius-proxy.patch Type: text/x-patch Size: 7697 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0539-UI-for-managing-user-auth-types.patch Type: text/x-patch Size: 2002 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0540-Added-QRcode-generation-to-Web-UI.patch Type: text/x-patch Size: 33138 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0541-Support-OTP-in-form-based-auth.patch Type: text/x-patch Size: 2294 bytes Desc: not available URL: From rcritten at redhat.com Mon Jan 13 16:11:30 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 13 Jan 2014 11:11:30 -0500 Subject: [Freeipa-devel] [PATCH] 0336 rpcserver: Consolidate __call__ in xmlclient and jsonclient_kerb In-Reply-To: <52A76915.8060007@redhat.com> References: <52A76915.8060007@redhat.com> Message-ID: <52D41032.5060801@redhat.com> Petr Viktorin wrote: > See commit message & ticket. > > https://fedorahosted.org/freeipa/ticket/4069 Our handling of XML-RPC introspection is iffy as it is and this would remove those methods completely. Can you add them back into the xmlserver class? rob From rcritten at redhat.com Mon Jan 13 16:19:18 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 13 Jan 2014 11:19:18 -0500 Subject: [Freeipa-devel] [PATCH] 0335 ipa-replica-install: Move check for existing host before DNS resolution check In-Reply-To: <52A71945.6040503@redhat.com> References: <52A71945.6040503@redhat.com> Message-ID: <52D41206.6000101@redhat.com> Petr Viktorin wrote: > See commit message & ticket for details. > > https://fedorahosted.org/freeipa/ticket/3889 If memory serves this was done so that both the replication and the host checks would be done so the admin wouldn't die a death of a thousand cuts. If a leftover agreement exists then the replica install will fail. You delete the agreement. The next install may fail too if the host exists. We should check for both before quitting. rob From rcritten at redhat.com Mon Jan 13 16:36:29 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 13 Jan 2014 11:36:29 -0500 Subject: [Freeipa-devel] [PATCH] 0084 Make sure state of services is preserved after client uninstall In-Reply-To: <528A2876.8050503@redhat.com> References: <527BBF0E.6070902@redhat.com> <528645E9.6050706@redhat.com> <528A2876.8050503@redhat.com> Message-ID: <52D4160D.5090600@redhat.com> Ana Krivokapic wrote: > On 11/15/2013 05:03 PM, Tomas Babej wrote: >> On 11/07/2013 05:25 PM, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch addresses tickethttps://fedorahosted.org/freeipa/ticket/3790. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Looking good.. >> >> I have two questions: >> >> >> 1.) Nitpick: I'd suggest we rename the save_state(service) and >> restore_state(service) to more descriptive >> save_service_state/restore_service_state? >> > > Well, if the argument you are passing to these function does not have a > name which suggests it is a service (which it should have anyway), you > can do: `save_state(service=x)`. So I don't think > `save_service_state(x)` is more readable. > >> 2.) There are other places in ipa-client-install where we save and >> restore the state of the service. Having abstracted that into a >> function, should we use this at other places as well? >> >> > > I looked at other instances in ipa-client-install where service states > are saved and restored. It seems that each of these cases includes some > custom logic which does not make it possible to use the two functions > I've added. It looks fine to me as-is. I couldn't find any other services to include in this which is indeed a shame as this significantly simplifies things. ACK rob From npmccallum at redhat.com Mon Jan 13 19:14:20 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 13 Jan 2014 14:14:20 -0500 (EST) Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <52D40FD7.5090301@redhat.com> References: <52D40FD7.5090301@redhat.com> Message-ID: <1915672064.674370.1389640460333.JavaMail.root@redhat.com> Petr, HOTP support should be trivial to add. In the CLI it is just --type=hotp. Everything else is the same, with the exception of the new optional --counter parameter. In soft tokens, this parameter should never be used. Nathaniel ----- Original Message ----- > Hi, > > these patches implements the OTP Web UI. > > Last 5 patches is the OTP UI. > > First 6 patches is a little refactoring/bug fixes needed for them. > General password dialog is introduced to avoid another implementation. > > Self-service UI is implemented to be very simple. Atm user can choose > only token name. Admin interface allows to enter all values. > > It's based on the RCUE work -> we need to push RCUE first. Thanks > Nathaniel for review of the last font package. It will speed things up. > > Know bugs: > - there is clash in id's of checkboxes preventing editation of > subsequently displayed ones with the same name. Will be fixed in > separate patch. > - bugs caused by bugs in API (adding/removal of own tokens in > self-service, inability to enter key on token creation - > https://fedorahosted.org/freeipa/ticket/4099) > - datetime format (widget+validator) will be implemented in separate patch > - no support of not reviewed CLI patches (HOTP..) > > Cgit: > http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp > > https://fedorahosted.org/freeipa/ticket/3369 > -- > Petr Vobornik > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Mon Jan 13 19:45:16 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 13 Jan 2014 14:45:16 -0500 Subject: [Freeipa-devel] python-kerberos patch Message-ID: <52D4424C.7040101@redhat.com> In an effort to be able to to use GSS-Proxy as a client in IPA I've written a patch against python-kerberos to add a call to gss_cred_inquire so we can peek at the current principal name. This will replace the python-krbV call in ipapython/util.py::get_current_principal(). The patch is pending review upstream at https://trac.calendarserver.org/ticket/830#comment:1 but it hasn't seen any activity yet and I'm impatient. Anyone have a few moments to take a look? I'm not super happy with the way one has to call it and some feedback would be helpful. rob From simo at redhat.com Mon Jan 13 21:23:43 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 13 Jan 2014 16:23:43 -0500 Subject: [Freeipa-devel] python-kerberos patch In-Reply-To: <52D4424C.7040101@redhat.com> References: <52D4424C.7040101@redhat.com> Message-ID: <1389648223.26102.397.camel@willson.li.ssimo.org> On Mon, 2014-01-13 at 14:45 -0500, Rob Crittenden wrote: > In an effort to be able to to use GSS-Proxy as a client in IPA I've > written a patch against python-kerberos to add a call to > gss_cred_inquire so we can peek at the current principal name. This will > replace the python-krbV call in ipapython/util.py::get_current_principal(). > > The patch is pending review upstream at > https://trac.calendarserver.org/ticket/830#comment:1 but it hasn't seen > any activity yet and I'm impatient. > > Anyone have a few moments to take a look? I'm not super happy with the > way one has to call it and some feedback would be helpful. I do not like their python API, but ... we can;t change that. One the C code: you call it yadda_client_yadda but then you user server_creds as the variable name, that's confusing. You should simply initialize name and name_token to 0 and unconditionally free/release them on error, and do that all at the end based on the return you want. Also you can simplify string copying.. How I'd rewrite the last 15 lines after gss_display_name() if (GSS_ERROR(maj_stat)) { set_gss_error(maj_stat, min_stat); ret = AUTH_GSS_ERROR; goto end; } state->username = strndup(name_token.value, name_token.length); if (!state->username) { set_gss_error(GSS_S_FAILURE, ENOMEM); ret = AUTH_GSS_ERROR; } end: (void)gss_release_cred(&min_stat, &server_creds); (void)gss_release_name(&min_stat, &name); (void)gss_release_buffer(&min_state, name_token); return ret; } You could simplify even more without using ret, and jumping to end on any maj_stat error and at end if (maj_stat != GSS_S_COMPLETE) { set_gss_error(maj_state, min_stat); ... Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Tue Jan 14 08:27:24 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 14 Jan 2014 09:27:24 +0100 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <52D3F0B9.4050302@redhat.com> References: <52CEC0AE.9040502@redhat.com> <1389385309.2072.12.camel@localhost.localdomain> <52D3DEF0.7020302@redhat.com> <52D3F0B9.4050302@redhat.com> Message-ID: <52D4F4EC.3020707@redhat.com> On 13.1.2014 14:57, Petr Vobornik wrote: > On 13.1.2014 13:41, Jan Cholasta wrote: >> Hi, >> >> On 10.1.2014 21:21, Nathaniel McCallum wrote: >>> On Thu, 2014-01-09 at 16:30 +0100, Tomas Babej wrote: >>>> Hi, >>>> >>>> Adds a parameter that represents a DateTime format using >>>> datetime.datetime >>>> object from python's native datetime library. >>>> >>>> In the CLI, accepts one of the following formats: >>>> Accepts subset of values defined by ISO 8601: >>>> %Y-%m-%dT%H:%M:%S >>>> %Y-%m-%dT%H:%M >>>> '%Y%m%dT%H:%M:%S' >>>> '%Y%m%dT%H:%M' >>>> >>>> Also accepts LDAP Generalized time in the following format: >>>> '%Y%m%d%H%M%SZ' >>>> >>>> As a simplification, it does not deal with timezone info and ISO 8601 >>>> values with timezone info (+-hhmm) are rejected. Values are expected >>>> to be in the UTC timezone. >>>> >>>> Values are saved to LDAP as LDAP Generalized time values in the format >>>> '%Y%m%d%H%SZ' (no time fractions and UTC timezone is assumed). To avoid >>>> confusion, in addition to subset of ISO 8601 values, the LDAP >>>> generalized >>>> time in the format '%Y%m%d%H%M%SZ' is also accepted as an input (as >>>> this >>>> is the >>>> format user will see on the output). >>>> >>>> Part of: https://fedorahosted.org/freeipa/ticket/3306 >>> >>> The date/time syntax formats are not compliant with ISO 8601. You stated >>> they are expected to be in UTC timezone, but no 'Z' is expected in most >>> of them. This is not only non-standard, but would prevent you from every >>> supporting local time in the future. >> >> +1, please require the trailing "Z". >> >> >> I think generalized time format should be the preferred one, as it is >> stored in LDAP and thus returned by commands. Also, do we really need >> all of these other formats? > > +1 That API should accept and always return generalized time. > > But UIs(CLI, Web) should display something more human readable. Like: > %Y-%m-%dT%H:%M:%SZ or IMHO better (but not ISO 8601): %Y-%m-%d %H:%M:%SZ > ie. 2014-03-08 14:16:55Z compared to 2014-03-08T14:16:55Z or > 20140308141655Z > > Both should accept input value in the same format. Usage of different > output and input formats is confusing. Thus I agree with supporting more > input formats. Decision whether it should be done on API level or client > level is another matter. If you want human readable output, you have to do the conversion from generalized time on clients. If you want to support local time and timezones, you have to do some processing on the client as well. I would be perfectly happy if we supported only generalized time over the wire and did conversion from/to human readable on clients. > > I has been implementing the Web UI part and I think we should also > support a formats without time component. My initial impl. supports > combinations of: > > var dates = [ > ['YYYY-MM-DD', /^(\d{4})-(\d{2})-(\d{2})$/], > ['YYYYMMDD',/^(\d{4})(\d{2})(\d{2})$/] > ]; > > var times = [ > ['HH:mm:ss', /^(\d\d):(\d\d):(\d\d)Z$/], > ['HH:mm', /^(\d\d):(\d\d)Z$/], > ['HH', /^(\d\d)Z$/] > ]; > + generalized time > ['YYYYMMDDHHmmssZ',/^(\d{4})(\d{2})(\d{2})(\d{2})(\d{2})(\d{2})Z$/] > > with /( |T)/ as divider and time optional. > > Both UIs should also tell the user what is the expected format (at least > one of them). Getting incorrect format error without knowing it is > annoying. The current code raises a ValidationError including the list of formats. > >> >> >> Few nitpicks about DateTime implementation: >> >> * you should call Param._convert_scalar from DateTime._convert_scalar >> * raise ConversionError instead of ValidationError and use >> get_param_name() for name >> * instead of "isinstance(value, str) or isinstance(value, unicode)" >> use "isinstance(value, basestring)" >> * don't use pythonisms in public error messages (""does not match any >> of accepted formats: %s" % self.accepted_formats") >> * public error messages should be translatable >> >> It should look something like this (untested, from top of my head): >> >> type = datetime.datetime >> type_error = _('must be a date/time value') >> >> def _convert_scalar(self, value, index=None): >> if isinstance(value, basestring): >> for date_format in self.accepted_formats: >> try: >> time = datetime.datetime.strptime(value, >> date_format) >> return time >> except ValueError: >> pass >> >> # If we get here, the strptime call did not succeed for any >> # the accepted formats, therefore raise error >> >> error = _("does not match any of accepted formats: %s") % >> (', '.join(self.accepted_formats)) >> >> raise ConversionError(name=self.get_param_name(), >> index=index, >> error=error) >> >> return super(DateTime, self)._convert_scalar(value, index) >> >> >> + if isinstance(value, DateTime): >> + return str(value) >> >> Return datetime object here please, or at least unicode in generalized >> time format (or whatever the preferred format is, see above). >> >> >> + elif isinstance(val, datetime.datetime): >> + return val.strftime("%Y%m%dT%H:%M:%S") >> >> Again, please use the preferred format here please. >> >> >> Honza >> > > -- Jan Cholasta From jcholast at redhat.com Tue Jan 14 08:28:37 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 14 Jan 2014 09:28:37 +0100 Subject: [Freeipa-devel] [PATCH 0138] ipalib: Expose krbPrincipalExpiration in CLI In-Reply-To: <52CEC0C9.70905@redhat.com> References: <52CEC0C9.70905@redhat.com> Message-ID: <52D4F535.3080509@redhat.com> On 9.1.2014 16:31, Tomas Babej wrote: > Hi, > > Adds a krbPrincipalExpiration attribute to the user class > in user.py ipalib plugin as a DateTime parameter. > > Part of: https://fedorahosted.org/freeipa/ticket/3306 > ACK. -- Jan Cholasta From mkosek at redhat.com Tue Jan 14 08:30:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 14 Jan 2014 09:30:16 +0100 Subject: [Freeipa-devel] [PATCH] 0084 Make sure state of services is preserved after client uninstall In-Reply-To: <52D4160D.5090600@redhat.com> References: <527BBF0E.6070902@redhat.com> <528645E9.6050706@redhat.com> <528A2876.8050503@redhat.com> <52D4160D.5090600@redhat.com> Message-ID: <52D4F598.3020609@redhat.com> On 01/13/2014 05:36 PM, Rob Crittenden wrote: > Ana Krivokapic wrote: >> On 11/15/2013 05:03 PM, Tomas Babej wrote: >>> On 11/07/2013 05:25 PM, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> This patch addresses tickethttps://fedorahosted.org/freeipa/ticket/3790. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> Looking good.. >>> >>> I have two questions: >>> >>> >>> 1.) Nitpick: I'd suggest we rename the save_state(service) and >>> restore_state(service) to more descriptive >>> save_service_state/restore_service_state? >>> >> >> Well, if the argument you are passing to these function does not have a >> name which suggests it is a service (which it should have anyway), you >> can do: `save_state(service=x)`. So I don't think >> `save_service_state(x)` is more readable. >> >>> 2.) There are other places in ipa-client-install where we save and >>> restore the state of the service. Having abstracted that into a >>> function, should we use this at other places as well? >>> >>> >> >> I looked at other instances in ipa-client-install where service states >> are saved and restored. It seems that each of these cases includes some >> custom logic which does not make it possible to use the two functions >> I've added. > > It looks fine to me as-is. I couldn't find any other services to include in > this which is indeed a shame as this significantly simplifies things. > > ACK > > rob Thanks for the review. Pushed to master. Martin From jcholast at redhat.com Tue Jan 14 08:33:31 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 14 Jan 2014 09:33:31 +0100 Subject: [Freeipa-devel] [PATCH 0139] acl: Remove krbPrincipalExpiration from list of excluded attrs In-Reply-To: <52CEC0E6.6030706@redhat.com> References: <52CEC0E6.6030706@redhat.com> Message-ID: <52D4F65B.4030608@redhat.com> On 9.1.2014 16:31, Tomas Babej wrote: > Hi, > > Since we're exposing the krbPrincipalExpiration attribute for direct > editing in the CLI, remove it from the list of attributes that > admin cannot edit by default. > > Part of: https://fedorahosted.org/freeipa/ticket/3306 > ACK. -- Jan Cholasta From jcholast at redhat.com Tue Jan 14 08:33:56 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 14 Jan 2014 09:33:56 +0100 Subject: [Freeipa-devel] [PATCH 0140] [PATCH 140/140] ipalib: Use DateTime parameter class for OTP token In-Reply-To: <52CEC112.9010802@redhat.com> References: <52CEC112.9010802@redhat.com> Message-ID: <52D4F674.5080302@redhat.com> On 9.1.2014 16:32, Tomas Babej wrote: > Hi, > > For ipatokennotbefore and ipatokennotafter attributes use DateTime > parameter class instead of Str, since these are represented as > LDAP Generalized Time in LDAP. > > Tomas > ACK. -- Jan Cholasta From pviktori at redhat.com Tue Jan 14 09:19:25 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 14 Jan 2014 10:19:25 +0100 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <52D4F4EC.3020707@redhat.com> References: <52CEC0AE.9040502@redhat.com> <1389385309.2072.12.camel@localhost.localdomain> <52D3DEF0.7020302@redhat.com> <52D3F0B9.4050302@redhat.com> <52D4F4EC.3020707@redhat.com> Message-ID: <52D5011D.30707@redhat.com> On 01/14/2014 09:27 AM, Jan Cholasta wrote: > On 13.1.2014 14:57, Petr Vobornik wrote: >> On 13.1.2014 13:41, Jan Cholasta wrote: >>> Hi, >>> >>> On 10.1.2014 21:21, Nathaniel McCallum wrote: >>>> On Thu, 2014-01-09 at 16:30 +0100, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> Adds a parameter that represents a DateTime format using >>>>> datetime.datetime >>>>> object from python's native datetime library. >>>>> >>>>> In the CLI, accepts one of the following formats: >>>>> Accepts subset of values defined by ISO 8601: >>>>> %Y-%m-%dT%H:%M:%S >>>>> %Y-%m-%dT%H:%M >>>>> '%Y%m%dT%H:%M:%S' >>>>> '%Y%m%dT%H:%M' >>>>> >>>>> Also accepts LDAP Generalized time in the following format: >>>>> '%Y%m%d%H%M%SZ' >>>>> >>>>> As a simplification, it does not deal with timezone info and ISO 8601 >>>>> values with timezone info (+-hhmm) are rejected. Values are expected >>>>> to be in the UTC timezone. >>>>> >>>>> Values are saved to LDAP as LDAP Generalized time values in the format >>>>> '%Y%m%d%H%SZ' (no time fractions and UTC timezone is assumed). To >>>>> avoid >>>>> confusion, in addition to subset of ISO 8601 values, the LDAP >>>>> generalized >>>>> time in the format '%Y%m%d%H%M%SZ' is also accepted as an input (as >>>>> this >>>>> is the >>>>> format user will see on the output). >>>>> >>>>> Part of: https://fedorahosted.org/freeipa/ticket/3306 >>>> >>>> The date/time syntax formats are not compliant with ISO 8601. You >>>> stated >>>> they are expected to be in UTC timezone, but no 'Z' is expected in most >>>> of them. This is not only non-standard, but would prevent you from >>>> every >>>> supporting local time in the future. >>> >>> +1, please require the trailing "Z". >>> >>> >>> I think generalized time format should be the preferred one, as it is >>> stored in LDAP and thus returned by commands. Also, do we really need >>> all of these other formats? >> >> +1 That API should accept and always return generalized time. >> >> But UIs(CLI, Web) should display something more human readable. Like: >> %Y-%m-%dT%H:%M:%SZ or IMHO better (but not ISO 8601): %Y-%m-%d %H:%M:%SZ >> ie. 2014-03-08 14:16:55Z compared to 2014-03-08T14:16:55Z or >> 20140308141655Z >> >> Both should accept input value in the same format. Usage of different >> output and input formats is confusing. Thus I agree with supporting more >> input formats. Decision whether it should be done on API level or client >> level is another matter. > > If you want human readable output, you have to do the conversion from > generalized time on clients. If you want to support local time and > timezones, you have to do some processing on the client as well. I would > be perfectly happy if we supported only generalized time over the wire > and did conversion from/to human readable on clients. > >> >> I has been implementing the Web UI part and I think we should also >> support a formats without time component. My initial impl. supports >> combinations of: >> >> var dates = [ >> ['YYYY-MM-DD', /^(\d{4})-(\d{2})-(\d{2})$/], >> ['YYYYMMDD',/^(\d{4})(\d{2})(\d{2})$/] >> ]; >> >> var times = [ >> ['HH:mm:ss', /^(\d\d):(\d\d):(\d\d)Z$/], >> ['HH:mm', /^(\d\d):(\d\d)Z$/], >> ['HH', /^(\d\d)Z$/] >> ]; >> + generalized time >> ['YYYYMMDDHHmmssZ',/^(\d{4})(\d{2})(\d{2})(\d{2})(\d{2})(\d{2})Z$/] >> >> with /( |T)/ as divider and time optional. >> >> Both UIs should also tell the user what is the expected format (at least >> one of them). Getting incorrect format error without knowing it is >> annoying. > > The current code raises a ValidationError including the list of formats. On yesterday's meeting, Simo said that on the wire and for CLI output, we should use generalized time. I disagree with using it for CLI ouptut, as I find generalized time unreadable, but for the API it's the obvious choice. I believe we should require the "Z" postfix in all formats, so that 1) users are forced to be aware that it's UTC, and 2) we can theoretically support local time in the future. I think the supported input formats should be: %Y%m%d%H%M%SZ (generalized time) %Y-%m-%dT%H:%M:%SZ (ISO 8601, with seconds) %Y-%m-%dT%H:%MZ (ISO 8601, without seconds) %Y-%m-%dZ (ISO 8601, date only) I also think we should accept a space instead of the "T", as Petr? said above. -- Petr? From pspacek at redhat.com Tue Jan 14 09:40:52 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 Jan 2014 10:40:52 +0100 Subject: [Freeipa-devel] [PATCH] 0079 Enable Retro Changelog and Content Synchronization DS plugins In-Reply-To: <52970DF0.2040800@redhat.com> References: <526A8828.3010807@redhat.com> <526FA000.7000806@redhat.com> <526FF70D.408@redhat.com> <52970DF0.2040800@redhat.com> Message-ID: <52D50624.9010507@redhat.com> On 28.11.2013 10:33, Ana Krivokapic wrote: > On 10/29/2013 06:57 PM, Ana Krivokapic wrote: >> On 10/29/2013 12:46 PM, Martin Kosek wrote: >>> On 10/25/2013 05:03 PM, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3967. >>>> >>> NACK. I do not think this will work well with the case when DNS is not used. As >>> bind-dyndb-ldap is not required component, FreeIPA could be installed on a >>> machine without bind installed. And in that case, /var/named/ won't be there. >>> >>> I think that this directory will follow similar pattern as >>> %{_localstatedir}/lib/ipa/pki-ca/publish >>> and be just %ghost and be created in when bind-dyndb-ldap is being configured >>> in bindinstance.py. >>> >>> Martin >> Fixed, updated patch attached. >> > The patch needed a rebase. There was a copy&paste error in install/updates/20-syncrepl.update , attached patch fixes it. I have tested the install & upgrade scenarios without and with one replica and it works for me, functional ACK. Please push it to master if nobody objects against the code. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0079-04-Enable-Retro-Changelog-and-Content-Synchronization-D.patch Type: text/x-patch Size: 4400 bytes Desc: not available URL: From pspacek at redhat.com Tue Jan 14 09:53:09 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 Jan 2014 10:53:09 +0100 Subject: [Freeipa-devel] [PATCH 0006] Treat error during write to /etc/resolv.conf as non-fatal Message-ID: <52D50905.4020400@redhat.com> Hello, Treat error during write to /etc/resolv.conf as non-fatal. https://fedorahosted.org/freeipa/ticket/4110 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0006-Treat-error-during-write-to-etc-resolv.conf-as-non-f.patch Type: text/x-patch Size: 1507 bytes Desc: not available URL: From jcholast at redhat.com Tue Jan 14 10:31:52 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 14 Jan 2014 11:31:52 +0100 Subject: [Freeipa-devel] [PATCHES] 225-230 Drop support for the legacy LDAP API In-Reply-To: <52D00B84.1090804@redhat.com> References: <52A72DA8.4090104@redhat.com> <52AB16B8.6050808@redhat.com> <52AEC654.5040602@redhat.com> <52AF03F2.2090904@redhat.com> <52CBF8FB.7090808@redhat.com> <52D00B84.1090804@redhat.com> Message-ID: <52D51218.1090304@redhat.com> On 10.1.2014 16:02, Petr Viktorin wrote: > On 01/07/2014 01:54 PM, Jan Cholasta wrote: >> On 16.12.2013 14:45, Petr Viktorin wrote: >>> On 12/16/2013 10:22 AM, Jan Cholasta wrote: >>>> On 13.12.2013 15:16, Petr Viktorin wrote: >>>>> On 12/10/2013 04:05 PM, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> I believe the time has come to drop support for the legacy (dn, >>>>>> entry_attrs) tuple API and move to the new LDAPEntry API exclusively. >>>>>> The attached patches convert existing code which uses the old API to >>>>>> the >>>>>> new API and remove backward compatibility code from the ipaldap >>>>>> module. >>>>>> >>>>>> Note that there are still some functions/methods which accept >>>>>> separate >>>>>> dn and entry_attrs arguments, they will be adapted to LDAPEntry >>>>>> later. >>>>>> >>>>>> Honza >>>>> >>>>> The first N-1 patches can be tested,acked,pushed independently, right? >>>> >>>> Yes. >>>> >>>>> If that's the case, ACK for 225 >>> >>> Pushed that one to master, 5 more to go. >>> bc3f3381c6bf0b4941889b775025a60f56318551 >>> > > 226 needs a rebase. > > 227: in install/tools/ipa-adtrust-install: > > + entry_attrs = conn.make_entry( > + dn, > + objectclass=['top', 'pkiuser', 'nscontainer'], > + usercertificate=cert) > + conn.add_entry(entry_attrs) > > Shouldn't it be `usercertificate=[cert]` now? Similarly in ra_cert, and > in ipa-server-install with ipacertificatesubjectbase > > Otherwise this looks good. > > 228: in ipaserver/install/plugins/update_idranges.py, again we should > use lists > > Otherwise it looks good > > 229: ACK > Rebased and fixed everything, updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-226.2-Convert-remaining-frontend-code-to-LDAPEntry-API.patch Type: text/x-patch Size: 100682 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-227.2-Convert-remaining-installer-code-to-LDAPEntry-API.patch Type: text/x-patch Size: 14382 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-228.2-Convert-remaining-update-code-to-LDAPEntry-API.patch Type: text/x-patch Size: 10421 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-229.2-Convert-remaining-test-code-to-LDAPEntry-API.patch Type: text/x-patch Size: 3334 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-230.2-Raise-an-exception-when-legacy-LDAP-API-is-used.patch Type: text/x-patch Size: 3254 bytes Desc: not available URL: From abokovoy at redhat.com Tue Jan 14 12:02:33 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 14 Jan 2014 14:02:33 +0200 Subject: [Freeipa-devel] [PATCH] 0130 -- create missing idranges in trust-fetch-domains Message-ID: <20140114120233.GK12003@redhat.com> Hi, attached patch implements missing idranges when new child domains discovered through 'ipa trust-fetch-domains'. This functionality existed in 'ipa trust-add' but was not exposed in the 'ipa trust-fetch-domains'. Additionally, error message is shown in case trust name is incorrect. https://fedorahosted.org/freeipa/ticket/4104 https://fedorahosted.org/freeipa/ticket/4111 -- / Alexander Bokovoy -------------- next part -------------- >From 4c5cc55deb4e346169ead3ebaac52e847adde424 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 14 Jan 2014 13:55:56 +0200 Subject: [PATCH] trust-fetch-domains: create ranges for new child domains When trust is added, we do create ranges for discovered child domains. However, this functionality was not available through 'trust-fetch-domains' command. Additionally, make sure non-existing trust will report proper error in trust-fetch-domains. https://fedorahosted.org/freeipa/ticket/4111 https://fedorahosted.org/freeipa/ticket/4104 --- ipalib/plugins/trust.py | 246 ++++++++++++++++++++++++++---------------------- 1 file changed, 134 insertions(+), 112 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 76d609f..6466f28 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -188,6 +188,114 @@ def make_trust_dn(env, trust_type, dn): return DN(dn, container_dn) return dn +def add_range(self, range_name, dom_sid, *keys, **options): + """ + First, we try to derive the parameters of the ID range based on the + information contained in the Active Directory. + + If that was not successful, we go for our usual defaults (random base, + range size 200 000, ipa-ad-trust range type). + + Any of these can be overriden by passing appropriate CLI options + to the trust-add command. + """ + + range_size = None + range_type = None + base_id = None + + # First, get information about ID space from AD + # However, we skip this step if other than ipa-ad-trust-posix + # range type is enforced + + if options.get('range_type', None) in (None, u'ipa-ad-trust-posix'): + + # Get the base dn + domain = keys[-1] + basedn = realm_to_suffix(domain) + + # Search for information contained in + # CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System + info_filter = '(objectClass=msSFU30DomainInfo)' + info_dn = DN('CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System')\ + + basedn + + # Get the domain validator + domain_validator = ipaserver.dcerpc.DomainValidator(self.api) + if not domain_validator.is_configured(): + raise errors.NotFound( + reason=_('Cannot search in trusted domains without own ' + 'domain configured. Make sure you have run ' + 'ipa-adtrust-install on the IPA server first')) + + # KDC might not get refreshed data at the first time, + # retry several times + for retry in range(10): + info_list = domain_validator.search_in_dc(domain, + info_filter, + None, + SCOPE_SUBTREE, + basedn=info_dn, + quiet=True) + + if info_list: + info = info_list[0] + break + else: + sleep(2) + + required_msSFU_attrs = ['msSFU30MaxUidNumber', 'msSFU30OrderNumber'] + + if not info_list: + # We were unable to gain UNIX specific info from the AD + self.log.debug("Unable to gain POSIX info from the AD") + else: + if all(attr in info for attr in required_msSFU_attrs): + self.log.debug("Able to gain POSIX info from the AD") + range_type = u'ipa-ad-trust-posix' + + max_uid = info.get('msSFU30MaxUidNumber') + max_gid = info.get('msSFU30MaxGidNumber', None) + max_id = int(max(max_uid, max_gid)[0]) + + base_id = int(info.get('msSFU30OrderNumber')[0]) + range_size = (1 + (max_id - base_id) / DEFAULT_RANGE_SIZE)\ + * DEFAULT_RANGE_SIZE + + # Second, options given via the CLI options take precedence to discovery + if options.get('range_type', None): + range_type = options.get('range_type', None) + elif not range_type: + range_type = u'ipa-ad-trust' + + if options.get('range_size', None): + range_size = options.get('range_size', None) + elif not range_size: + range_size = DEFAULT_RANGE_SIZE + + if options.get('base_id', None): + base_id = options.get('base_id', None) + elif not base_id: + # Generate random base_id if not discovered nor given via CLI + base_id = DEFAULT_RANGE_SIZE + ( + pysss_murmur.murmurhash3( + dom_sid, + len(dom_sid), 0xdeadbeefL + ) % 10000 + ) * DEFAULT_RANGE_SIZE + + # Finally, add new ID range + self.api.Command['idrange_add'](range_name, + ipabaseid=base_id, + ipaidrangesize=range_size, + ipabaserid=0, + iparangetype=range_type, + ipanttrusteddomainsid=dom_sid) + + # Return the values that were generated inside this function + return range_type, range_size, base_id + + class trust(LDAPObject): """ Trust object. @@ -341,8 +449,8 @@ sides. # Store the created range type, since for POSIX trusts no # ranges for the subdomains should be added, POSIX attributes # provide a global mapping across all subdomains - (created_range_type, _, _) = self.add_range(range_name, dom_sid, - *keys, **options) + (created_range_type, _, _) = add_range(self, range_name, dom_sid, + *keys, **options) else: created_range_type = old_range['result']['iparangetype'][0] @@ -382,8 +490,8 @@ sides. # Try to add the range for each subdomain try: - self.add_range(range_name, dom_sid, *keys, - **passed_options) + add_range(self, range_name, dom_sid, *keys, + **passed_options) except errors.DuplicateEntry: pass @@ -549,113 +657,6 @@ sides. return old_range, range_name, dom_sid - def add_range(self, range_name, dom_sid, *keys, **options): - """ - First, we try to derive the parameters of the ID range based on the - information contained in the Active Directory. - - If that was not successful, we go for our usual defaults (random base, - range size 200 000, ipa-ad-trust range type). - - Any of these can be overriden by passing appropriate CLI options - to the trust-add command. - """ - - range_size = None - range_type = None - base_id = None - - # First, get information about ID space from AD - # However, we skip this step if other than ipa-ad-trust-posix - # range type is enforced - - if options.get('range_type', None) in (None, u'ipa-ad-trust-posix'): - - # Get the base dn - domain = keys[-1] - basedn = realm_to_suffix(domain) - - # Search for information contained in - # CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System - info_filter = '(objectClass=msSFU30DomainInfo)' - info_dn = DN('CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System')\ - + basedn - - # Get the domain validator - domain_validator = ipaserver.dcerpc.DomainValidator(self.api) - if not domain_validator.is_configured(): - raise errors.NotFound( - reason=_('Cannot search in trusted domains without own ' - 'domain configured. Make sure you have run ' - 'ipa-adtrust-install on the IPA server first')) - - # KDC might not get refreshed data at the first time, - # retry several times - for retry in range(10): - info_list = domain_validator.search_in_dc(domain, - info_filter, - None, - SCOPE_SUBTREE, - basedn=info_dn, - quiet=True) - - if info_list: - info = info_list[0] - break - else: - sleep(2) - - required_msSFU_attrs = ['msSFU30MaxUidNumber', 'msSFU30OrderNumber'] - - if not info_list: - # We were unable to gain UNIX specific info from the AD - self.log.debug("Unable to gain POSIX info from the AD") - else: - if all(attr in info for attr in required_msSFU_attrs): - self.log.debug("Able to gain POSIX info from the AD") - range_type = u'ipa-ad-trust-posix' - - max_uid = info.get('msSFU30MaxUidNumber') - max_gid = info.get('msSFU30MaxGidNumber', None) - max_id = int(max(max_uid, max_gid)[0]) - - base_id = int(info.get('msSFU30OrderNumber')[0]) - range_size = (1 + (max_id - base_id) / DEFAULT_RANGE_SIZE)\ - * DEFAULT_RANGE_SIZE - - # Second, options given via the CLI options take precedence to discovery - if options.get('range_type', None): - range_type = options.get('range_type', None) - elif not range_type: - range_type = u'ipa-ad-trust' - - if options.get('range_size', None): - range_size = options.get('range_size', None) - elif not range_size: - range_size = DEFAULT_RANGE_SIZE - - if options.get('base_id', None): - base_id = options.get('base_id', None) - elif not base_id: - # Generate random base_id if not discovered nor given via CLI - base_id = DEFAULT_RANGE_SIZE + ( - pysss_murmur.murmurhash3( - dom_sid, - len(dom_sid), 0xdeadbeefL - ) % 10000 - ) * DEFAULT_RANGE_SIZE - - # Finally, add new ID range - api.Command['idrange_add'](range_name, - ipabaseid=base_id, - ipaidrangesize=range_size, - ipabaserid=0, - iparangetype=range_type, - ipanttrusteddomainsid=dom_sid) - - # Return the values that were generated inside this function - return range_type, range_size, base_id - def execute_ad(self, full_join, *keys, **options): # Join domain using full credentials and with random trustdom # secret (will be generated by the join method) @@ -1246,6 +1247,11 @@ def fetch_domains_from_trust(self, trustinstance, trust_entry, **options): if not domains: return result + # trust range must exist by the time fetch_domains_from_trust is called + range_name = trust_name.upper() + '_id_range' + old_range = api.Command.idrange_show(range_name, raw=True)['result'] + idrange_type = old_range['iparangetype'] + for dom in domains: dom['trust_type'] = u'ad' try: @@ -1255,8 +1261,15 @@ def fetch_domains_from_trust(self, trustinstance, trust_entry, **options): dom['all'] = options['all'] if 'raw' in options: dom['raw'] = options['raw'] + res = self.api.Command.trustdomain_add(trust_name, name, **dom) result.append(res['result']) + + if idrange_type != u'ipa-ad-trust-posix': + range_name = name.upper() + '_id_range' + dom['range_type'] = u'ipa-ad-trust' + add_range(self, range_name, dom['ipanttrusteddomainsid'], + trust_name, name, **dom) except errors.DuplicateEntry: # Ignore updating duplicate entries pass @@ -1277,7 +1290,16 @@ class trust_fetch_domains(LDAPRetrieve): 'sub-package of IPA' ) ) - trust = self.api.Command.trust_show(keys[0], raw=True)['result'] + try: + trust = self.api.Command.trust_show(keys[0], raw=True)['result'] + except AssertionError: + raise errors.NotFound( + name=_('AD Trust setup'), + reason=_( + 'Cannot refresh list of the trusted forest domains ' + 'because there is no trust to the forest with this name' + ) + ) trustinstance = ipaserver.dcerpc.TrustDomainJoins(self.api) if not trustinstance.configured: -- 1.8.4.2 From mkosek at redhat.com Tue Jan 14 12:20:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 14 Jan 2014 13:20:32 +0100 Subject: [Freeipa-devel] [PATCH] 0130 -- create missing idranges in trust-fetch-domains In-Reply-To: <20140114120233.GK12003@redhat.com> References: <20140114120233.GK12003@redhat.com> Message-ID: <52D52B90.5090202@redhat.com> On 01/14/2014 01:02 PM, Alexander Bokovoy wrote: > Hi, > > attached patch implements missing idranges when new child domains > discovered through 'ipa trust-fetch-domains'. This functionality existed > in 'ipa trust-add' but was not exposed in the 'ipa trust-fetch-domains'. > > Additionally, error message is shown in case trust name is incorrect. > > https://fedorahosted.org/freeipa/ticket/4104 > https://fedorahosted.org/freeipa/ticket/4111 > I did not test the patch, just few observations from reading it: 1) Why are you moving add_range method from trust object to the module? IMO it could be left there, it belongs to the object. Plus, the patch won't be that big and easier to backport. add_range can be still referred from other commands as "self.obj.add_range", no need to move it. 2) This part looks *very* suspicious: - trust = self.api.Command.trust_show(keys[0], raw=True)['result'] + try: + trust = self.api.Command.trust_show(keys[0], raw=True)['result'] + except AssertionError: I do not think that AssertionError should be raised and caught in normal operation, it should be an exceptional exception raised when the world falls apart IMO. I.e. I would rather see some PublicError or Exception based exception to be raised in trust_show in that case... Martin From abokovoy at redhat.com Tue Jan 14 12:27:38 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 14 Jan 2014 14:27:38 +0200 Subject: [Freeipa-devel] [PATCH] 0130 -- create missing idranges in trust-fetch-domains In-Reply-To: <52D52B90.5090202@redhat.com> References: <20140114120233.GK12003@redhat.com> <52D52B90.5090202@redhat.com> Message-ID: <20140114122738.GM12003@redhat.com> On Tue, 14 Jan 2014, Martin Kosek wrote: >On 01/14/2014 01:02 PM, Alexander Bokovoy wrote: >> Hi, >> >> attached patch implements missing idranges when new child domains >> discovered through 'ipa trust-fetch-domains'. This functionality existed >> in 'ipa trust-add' but was not exposed in the 'ipa trust-fetch-domains'. >> >> Additionally, error message is shown in case trust name is incorrect. >> >> https://fedorahosted.org/freeipa/ticket/4104 >> https://fedorahosted.org/freeipa/ticket/4111 >> > >I did not test the patch, just few observations from reading it: It is generally wrong to base opinion purely on reading the code (see below why) :) >1) Why are you moving add_range method from trust object to the module? IMO it >could be left there, it belongs to the object. Plus, the patch won't be that >big and easier to backport. add_range can be still referred from other commands >as "self.obj.add_range", no need to move it. It was in trust_add class, not in the object. I need it in the other code and without explicit dependency on the object. >2) This part looks *very* suspicious: > >- trust = self.api.Command.trust_show(keys[0], raw=True)['result'] >+ try: >+ trust = self.api.Command.trust_show(keys[0], raw=True)['result'] >+ except AssertionError: > >I do not think that AssertionError should be raised and caught in normal >operation, it should be an exceptional exception raised when the world falls >apart IMO. I.e. I would rather see some PublicError or Exception based >exception to be raised in trust_show in that case... It *is* raised and should be caught because this particular snippet is to catch situation when wrong trust domain name is passed. Previously the code simply generated server-side exception which resulted in 'internal error'. -- / Alexander Bokovoy From mkosek at redhat.com Tue Jan 14 12:35:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 14 Jan 2014 13:35:29 +0100 Subject: [Freeipa-devel] [PATCH] 0130 -- create missing idranges in trust-fetch-domains In-Reply-To: <20140114122738.GM12003@redhat.com> References: <20140114120233.GK12003@redhat.com> <52D52B90.5090202@redhat.com> <20140114122738.GM12003@redhat.com> Message-ID: <52D52F11.3090704@redhat.com> On 01/14/2014 01:27 PM, Alexander Bokovoy wrote: > On Tue, 14 Jan 2014, Martin Kosek wrote: >> On 01/14/2014 01:02 PM, Alexander Bokovoy wrote: >>> Hi, >>> >>> attached patch implements missing idranges when new child domains >>> discovered through 'ipa trust-fetch-domains'. This functionality existed >>> in 'ipa trust-add' but was not exposed in the 'ipa trust-fetch-domains'. >>> >>> Additionally, error message is shown in case trust name is incorrect. >>> >>> https://fedorahosted.org/freeipa/ticket/4104 >>> https://fedorahosted.org/freeipa/ticket/4111 >>> >> >> I did not test the patch, just few observations from reading it: > It is generally wrong to base opinion purely on reading the code (see below > why) :) One does not need to run the code that see the places where it may be rusty :) > >> 1) Why are you moving add_range method from trust object to the module? IMO it >> could be left there, it belongs to the object. Plus, the patch won't be that >> big and easier to backport. add_range can be still referred from other commands >> as "self.obj.add_range", no need to move it. > It was in trust_add class, not in the object. I need it in the other > code and without explicit dependency on the object. Ok. Though I would still consider having it rather in the trust object to make it easier accessible from other modules, though our API system. > >> 2) This part looks *very* suspicious: >> >> - trust = self.api.Command.trust_show(keys[0], raw=True)['result'] >> + try: >> + trust = self.api.Command.trust_show(keys[0], raw=True)['result'] >> + except AssertionError: >> >> I do not think that AssertionError should be raised and caught in normal >> operation, it should be an exceptional exception raised when the world falls >> apart IMO. I.e. I would rather see some PublicError or Exception based >> exception to be raised in trust_show in that case... > It *is* raised and should be caught because this particular snippet is > to catch situation when wrong trust domain name is passed. Previously > the code simply generated server-side exception which resulted in > 'internal error'. Ok, understood. My point is, trust_show should not raise AssertException just because wrong trust domain is passed. There are better means to express that error - ValidationError or NotFound, based on the situation. Martin From pviktori at redhat.com Tue Jan 14 13:09:33 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 14 Jan 2014 14:09:33 +0100 Subject: [Freeipa-devel] [PATCH] 0335 ipa-replica-install: Move check for existing host before DNS resolution check In-Reply-To: <52D41206.6000101@redhat.com> References: <52A71945.6040503@redhat.com> <52D41206.6000101@redhat.com> Message-ID: <52D5370D.5050101@redhat.com> On 01/13/2014 05:19 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> See commit message & ticket for details. >> >> https://fedorahosted.org/freeipa/ticket/3889 > > If memory serves this was done so that both the replication and the host > checks would be done so the admin wouldn't die a death of a thousand cuts. > > If a leftover agreement exists then the replica install will fail. You > delete the agreement. The next install may fail too if the host exists. > We should check for both before quitting. AFAIK nowadays ipa-replica-manage del should also remove the host entry, so it's correct to suggest just that. -- Petr? From abokovoy at redhat.com Tue Jan 14 13:09:58 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 14 Jan 2014 15:09:58 +0200 Subject: [Freeipa-devel] [PATCH 125] CLDAP: do not prepend \\ In-Reply-To: <20140113120002.GM2855@localhost.localdomain> References: <20140113120002.GM2855@localhost.localdomain> Message-ID: <20140114130958.GN12003@redhat.com> On Mon, 13 Jan 2014, Sumit Bose wrote: >Hi, > >Scott found that the fix for >https://fedorahosted.org/freeipa/ticket/4028 is not complete. After some >checks and comparisons with samba and AD behaviour I came to the >conclusion that the two \\ at the beginning of the NetBIOS name of the >IPA server is not needed in the response of NETLOGON_NT_VERSION_5EX >requests which is the only type we handle so far. > >In general AD seems to be smart enough the handle the \\ even in those >responses but if the NetBIOS name has 15 characters the response is not >accepted anymore. > >Please check if you can see any regressions with this change. > >During testing I came across two things related to samba. >While looking at network trace Scott recorded it looked like Samba does >not cut a long hostname for the NetBIOS name. This might be in agreement >to what Metze recently posted in his master4-schannel-ok branch for >netlogon_creds_cli_context_global(). As usual Metze is smarter than us >and tried to minimize the chance for name collisions with the help of >Jenkins hash. I just wonder why he treats the NetBIOS name only here >this way and not generally? With respect to IPA we might want to >consider to set 'netbios name' in the samba config explicitly to avoid >disconnects? Yes, we may do that in ipa-adtrust-install. >While testing against AD with other request types I've seen that in some >cases the NetBIOS name was returned with the two additional \ in the >beginning, even if the AD NetBIOS name already had 15 characters. >Strange the name was even encoded in UCS-2 in this case. Unfortunately I >was not able to find good documentation on the specifics of those >packages. If you know some good docs please send me the link otherwise >we might what to ask MSFT for clarification. According to MS-ADTS, NetbiosComputerName field is --------------------------------------------------------------------- UTF-8 encoded value of the NetBIOS name of the server, compressed as specified in [RFC1035] section 4.1.4. To get the decompressed string, see section 6.3.7. --------------------------------------------------------------------- According to MS-NBTE (2.2.1), ---------------------------------------------------------------------- This document clarifies the ambiguity by specifying that the name space is defined as sixteen 8-bit binary bytes, with no restrictions, except that the name SHOULD NOT<2><3> start with an asterisk (*). ---------------------------------------------------------------------- Cases when \\ and UCS-2 encoding are used seem to be remnants of the older implementations. I think they should be ignored at best. >From 0b782064945352ad488e92b457bbfda2270ddf66 Mon Sep 17 00:00:00 2001 >From: Sumit Bose >Date: Mon, 13 Jan 2014 10:43:33 +0100 >Subject: [PATCH] CLDAP: do not prepend \\ > >For NETLOGON_NT_VERSION_5EX requests the prepended \\ is not expected in >the PDC NetBIOS name. In general AD seems to be smart enough to handle >the two \ signs. But if the NetBIOS name reaches the maximum of 15 >character AD does not accept the responses anymore. > >Fixes https://fedorahosted.org/freeipa/ticket/4028 >--- > daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >index 9ba05829418a0d1de46f2c7776cc15c54a9eab1c..c03172d474589ddee84f1cfa5395c23fdba83bcb 100644 >--- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >+++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >@@ -163,7 +163,7 @@ static int ipa_cldap_encode_netlogon(char *fq_hostname, char *domain, > nlr->domain_name = name; > > /* copy the first 15 characters of the fully qualified hostname*/ >- pdc_name = talloc_asprintf(nlr, "\\\\%.*s", NETBIOS_NAME_MAX, fq_hostname); >+ pdc_name = talloc_asprintf(nlr, "%.*s", NETBIOS_NAME_MAX, fq_hostname); > > for (p = pdc_name; *p; p++) { > /* Create the NetBIOS name from the first segment of the hostname */ ACK. -- / Alexander Bokovoy From pviktori at redhat.com Tue Jan 14 13:39:19 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 14 Jan 2014 14:39:19 +0100 Subject: [Freeipa-devel] [PATCH] 0336 rpcserver: Consolidate __call__ in xmlclient and jsonclient_kerb In-Reply-To: <52D41032.5060801@redhat.com> References: <52A76915.8060007@redhat.com> <52D41032.5060801@redhat.com> Message-ID: <52D53E07.3010006@redhat.com> On 01/13/2014 05:11 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> See commit message & ticket. >> >> https://fedorahosted.org/freeipa/ticket/4069 > > Our handling of XML-RPC introspection is iffy as it is and this would > remove those methods completely. Can you add them back into the > xmlserver class? Not just iffy, it's non-existent. See https://fedorahosted.org/freeipa/ticket/2937. The patch removes the __system dict which has been unused since at least Jason's web UI work in 2009, Git tells me. The patch did leave the actual methods. Well, actually it's not that hard to get these working again; see attached patch (which can be reviewed separately). -- Petr? P.S. to test raw XML, you can use: curl -v \ -H "referer:https://`hostname`/ipa" \ -H "Content-Type:text/xml" \ -H "Accept:applicaton/xml" \ --negotiate -u : \ --delegation always \ --cacert /etc/ipa/ca.crt \ -d " system.methodHelp stringping " -X POST https://`hostname`/ipa/xml -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0450-Implement-XML-introspection.patch Type: text/x-patch Size: 8524 bytes Desc: not available URL: From abokovoy at redhat.com Tue Jan 14 14:03:06 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 14 Jan 2014 16:03:06 +0200 Subject: [Freeipa-devel] [PATCH] 0130 -- create missing idranges in trust-fetch-domains In-Reply-To: <52D52F11.3090704@redhat.com> References: <20140114120233.GK12003@redhat.com> <52D52B90.5090202@redhat.com> <20140114122738.GM12003@redhat.com> <52D52F11.3090704@redhat.com> Message-ID: <20140114140305.GO12003@redhat.com> On Tue, 14 Jan 2014, Martin Kosek wrote: >On 01/14/2014 01:27 PM, Alexander Bokovoy wrote: >> On Tue, 14 Jan 2014, Martin Kosek wrote: >>> On 01/14/2014 01:02 PM, Alexander Bokovoy wrote: >>>> Hi, >>>> >>>> attached patch implements missing idranges when new child domains >>>> discovered through 'ipa trust-fetch-domains'. This functionality existed >>>> in 'ipa trust-add' but was not exposed in the 'ipa trust-fetch-domains'. >>>> >>>> Additionally, error message is shown in case trust name is incorrect. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4104 >>>> https://fedorahosted.org/freeipa/ticket/4111 >>>> >>> >>> I did not test the patch, just few observations from reading it: >> It is generally wrong to base opinion purely on reading the code (see below >> why) :) > >One does not need to run the code that see the places where it may be rusty :) > >> >>> 1) Why are you moving add_range method from trust object to the module? IMO it >>> could be left there, it belongs to the object. Plus, the patch won't be that >>> big and easier to backport. add_range can be still referred from other commands >>> as "self.obj.add_range", no need to move it. >> It was in trust_add class, not in the object. I need it in the other >> code and without explicit dependency on the object. > >Ok. Though I would still consider having it rather in the trust object to make >it easier accessible from other modules, though our API system. I deliberately don't want that. This is internal API for purposes of trust code -- do you envision any situation when anyone else might want to create idranges programmatically for child domains of the existing trust? Note that you are required to know fairly low-level details of the AD trusts to call it. > >> >>> 2) This part looks *very* suspicious: >>> >>> - trust = self.api.Command.trust_show(keys[0], raw=True)['result'] >>> + try: >>> + trust = self.api.Command.trust_show(keys[0], raw=True)['result'] >>> + except AssertionError: >>> >>> I do not think that AssertionError should be raised and caught in normal >>> operation, it should be an exceptional exception raised when the world falls >>> apart IMO. I.e. I would rather see some PublicError or Exception based >>> exception to be raised in trust_show in that case... >> It *is* raised and should be caught because this particular snippet is >> to catch situation when wrong trust domain name is passed. Previously >> the code simply generated server-side exception which resulted in >> 'internal error'. > >Ok, understood. My point is, trust_show should not raise AssertException just >because wrong trust domain is passed. There are better means to express that >error - ValidationError or NotFound, based on the situation. Yes, this is due to the way trust.get_dn() is built. Do not commit this patch yet (though building packages for testing would be good), I'm reworking it a bit to move this logic to get_dn() -- otherwise LDAPRetrieve() will always issue AssertError. -- / Alexander Bokovoy From sbose at redhat.com Tue Jan 14 14:17:37 2014 From: sbose at redhat.com (Sumit Bose) Date: Tue, 14 Jan 2014 15:17:37 +0100 Subject: [Freeipa-devel] [PATCH] 0130 -- create missing idranges in trust-fetch-domains In-Reply-To: <20140114140305.GO12003@redhat.com> References: <20140114120233.GK12003@redhat.com> <52D52B90.5090202@redhat.com> <20140114122738.GM12003@redhat.com> <52D52F11.3090704@redhat.com> <20140114140305.GO12003@redhat.com> Message-ID: <20140114141737.GQ2855@localhost.localdomain> On Tue, Jan 14, 2014 at 04:03:06PM +0200, Alexander Bokovoy wrote: > On Tue, 14 Jan 2014, Martin Kosek wrote: > >On 01/14/2014 01:27 PM, Alexander Bokovoy wrote: > >>On Tue, 14 Jan 2014, Martin Kosek wrote: > >>>On 01/14/2014 01:02 PM, Alexander Bokovoy wrote: > >>>>Hi, > >>>> > >>>>attached patch implements missing idranges when new child domains > >>>>discovered through 'ipa trust-fetch-domains'. This functionality existed > >>>>in 'ipa trust-add' but was not exposed in the 'ipa trust-fetch-domains'. > >>>> > >>>>Additionally, error message is shown in case trust name is incorrect. > >>>> > >>>>https://fedorahosted.org/freeipa/ticket/4104 > >>>>https://fedorahosted.org/freeipa/ticket/4111 > >>>> > >>> > >>>I did not test the patch, just few observations from reading it: > >>It is generally wrong to base opinion purely on reading the code (see below > >>why) :) > > > >One does not need to run the code that see the places where it may be rusty :) > > > >> > >>>1) Why are you moving add_range method from trust object to the module? IMO it > >>>could be left there, it belongs to the object. Plus, the patch won't be that > >>>big and easier to backport. add_range can be still referred from other commands > >>>as "self.obj.add_range", no need to move it. > >>It was in trust_add class, not in the object. I need it in the other > >>code and without explicit dependency on the object. > > > >Ok. Though I would still consider having it rather in the trust object to make > >it easier accessible from other modules, though our API system. > I deliberately don't want that. This is internal API for purposes of > trust code -- do you envision any situation when anyone else might want > to create idranges programmatically for child domains of the existing > trust? Note that you are required to know fairly low-level details of > the AD trusts to call it. > > > > >> > >>>2) This part looks *very* suspicious: > >>> > >>>- trust = self.api.Command.trust_show(keys[0], raw=True)['result'] > >>>+ try: > >>>+ trust = self.api.Command.trust_show(keys[0], raw=True)['result'] > >>>+ except AssertionError: > >>> > >>>I do not think that AssertionError should be raised and caught in normal > >>>operation, it should be an exceptional exception raised when the world falls > >>>apart IMO. I.e. I would rather see some PublicError or Exception based > >>>exception to be raised in trust_show in that case... > >>It *is* raised and should be caught because this particular snippet is > >>to catch situation when wrong trust domain name is passed. Previously > >>the code simply generated server-side exception which resulted in > >>'internal error'. > > > >Ok, understood. My point is, trust_show should not raise AssertException just > >because wrong trust domain is passed. There are better means to express that > >error - ValidationError or NotFound, based on the situation. > Yes, this is due to the way trust.get_dn() is built. Do not commit this > patch yet (though building packages for testing would be good), I'm > reworking it a bit to move this logic to get_dn() -- otherwise > LDAPRetrieve() will always issue AssertError. I guess I already hit this while testing. trust-fetch-domains does not work for valid forest roots anymore :-) Btw, can you add the forest root check to trustdomain-find as well? bye, Sumit > > -- > / Alexander Bokovoy > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pviktori at redhat.com Tue Jan 14 14:19:49 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 14 Jan 2014 15:19:49 +0100 Subject: [Freeipa-devel] [PATCH 0138] ipalib: Expose krbPrincipalExpiration in CLI In-Reply-To: <52D4F535.3080509@redhat.com> References: <52CEC0C9.70905@redhat.com> <52D4F535.3080509@redhat.com> Message-ID: <52D54785.8070509@redhat.com> On 01/14/2014 09:28 AM, Jan Cholasta wrote: > On 9.1.2014 16:31, Tomas Babej wrote: >> Hi, >> >> Adds a krbPrincipalExpiration attribute to the user class >> in user.py ipalib plugin as a DateTime parameter. >> >> Part of: https://fedorahosted.org/freeipa/ticket/3306 >> > > ACK. This apparently depends on tbabej-0137, so let's not push it yet. -- Petr? From pviktori at redhat.com Tue Jan 14 14:20:51 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 14 Jan 2014 15:20:51 +0100 Subject: [Freeipa-devel] [PATCH 0140] [PATCH 140/140] ipalib: Use DateTime parameter class for OTP token In-Reply-To: <52D4F674.5080302@redhat.com> References: <52CEC112.9010802@redhat.com> <52D4F674.5080302@redhat.com> Message-ID: <52D547C3.4060309@redhat.com> On 01/14/2014 09:33 AM, Jan Cholasta wrote: > On 9.1.2014 16:32, Tomas Babej wrote: >> Hi, >> >> For ipatokennotbefore and ipatokennotafter attributes use DateTime >> parameter class instead of Str, since these are represented as >> LDAP Generalized Time in LDAP. >> >> Tomas >> > > ACK. This apparently depends on tbabej-0137, so let's not push it yet. -- Petr? From pviktori at redhat.com Tue Jan 14 14:22:53 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 14 Jan 2014 15:22:53 +0100 Subject: [Freeipa-devel] [PATCH 0139] acl: Remove krbPrincipalExpiration from list of excluded attrs In-Reply-To: <52D4F65B.4030608@redhat.com> References: <52CEC0E6.6030706@redhat.com> <52D4F65B.4030608@redhat.com> Message-ID: <52D5483D.5060903@redhat.com> On 01/14/2014 09:33 AM, Jan Cholasta wrote: > On 9.1.2014 16:31, Tomas Babej wrote: >> Hi, >> >> Since we're exposing the krbPrincipalExpiration attribute for direct >> editing in the CLI, remove it from the list of attributes that >> admin cannot edit by default. >> >> Part of: https://fedorahosted.org/freeipa/ticket/3306 >> > > ACK. > Pushed to master: 3e1386a57e915a71c87471ee65877f3ab01fc724 -- Petr? From pviktori at redhat.com Tue Jan 14 15:39:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 14 Jan 2014 16:39:17 +0100 Subject: [Freeipa-devel] [PATCH] 0079 Enable Retro Changelog and Content Synchronization DS plugins In-Reply-To: <52D50624.9010507@redhat.com> References: <526A8828.3010807@redhat.com> <526FA000.7000806@redhat.com> <526FF70D.408@redhat.com> <52970DF0.2040800@redhat.com> <52D50624.9010507@redhat.com> Message-ID: <52D55A25.2000500@redhat.com> On 01/14/2014 10:40 AM, Petr Spacek wrote: > On 28.11.2013 10:33, Ana Krivokapic wrote: >> On 10/29/2013 06:57 PM, Ana Krivokapic wrote: >>> On 10/29/2013 12:46 PM, Martin Kosek wrote: >>>> On 10/25/2013 05:03 PM, Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> This patch addresses ticket >>>>> https://fedorahosted.org/freeipa/ticket/3967. >>>>> >>>> NACK. I do not think this will work well with the case when DNS is >>>> not used. As >>>> bind-dyndb-ldap is not required component, FreeIPA could be >>>> installed on a >>>> machine without bind installed. And in that case, /var/named/ won't >>>> be there. >>>> >>>> I think that this directory will follow similar pattern as >>>> %{_localstatedir}/lib/ipa/pki-ca/publish >>>> and be just %ghost and be created in when bind-dyndb-ldap is being >>>> configured >>>> in bindinstance.py. >>>> >>>> Martin >>> Fixed, updated patch attached. >>> >> The patch needed a rebase. > > There was a copy&paste error in install/updates/20-syncrepl.update , > attached patch fixes it. > > I have tested the install & upgrade scenarios without and with one > replica and it works for me, functional ACK. > > Please push it to master if nobody objects against the code. Thanks! No objections, pushed: 689382dc833e687d30349b10a8fd7dc740d54d08 -- Petr? From mkosek at redhat.com Tue Jan 14 15:39:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 14 Jan 2014 16:39:56 +0100 Subject: [Freeipa-devel] [PATCH 0138] ipalib: Expose krbPrincipalExpiration in CLI In-Reply-To: <52D54785.8070509@redhat.com> References: <52CEC0C9.70905@redhat.com> <52D4F535.3080509@redhat.com> <52D54785.8070509@redhat.com> Message-ID: <52D55A4C.7020805@redhat.com> On 01/14/2014 03:19 PM, Petr Viktorin wrote: > On 01/14/2014 09:28 AM, Jan Cholasta wrote: >> On 9.1.2014 16:31, Tomas Babej wrote: >>> Hi, >>> >>> Adds a krbPrincipalExpiration attribute to the user class >>> in user.py ipalib plugin as a DateTime parameter. >>> >>> Part of: https://fedorahosted.org/freeipa/ticket/3306 >>> >> >> ACK. > > This apparently depends on tbabej-0137, so let's not push it yet. > Right. That's why try to keep the dependent patches fixing one ticket in a single thread, Tomas :-) Martin From jcholast at redhat.com Tue Jan 14 15:43:41 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 14 Jan 2014 16:43:41 +0100 Subject: [Freeipa-devel] [PATCH 0138] ipalib: Expose krbPrincipalExpiration in CLI In-Reply-To: <52D55A4C.7020805@redhat.com> References: <52CEC0C9.70905@redhat.com> <52D4F535.3080509@redhat.com> <52D54785.8070509@redhat.com> <52D55A4C.7020805@redhat.com> Message-ID: <52D55B2D.6060607@redhat.com> On 14.1.2014 16:39, Martin Kosek wrote: > On 01/14/2014 03:19 PM, Petr Viktorin wrote: >> On 01/14/2014 09:28 AM, Jan Cholasta wrote: >>> On 9.1.2014 16:31, Tomas Babej wrote: >>>> Hi, >>>> >>>> Adds a krbPrincipalExpiration attribute to the user class >>>> in user.py ipalib plugin as a DateTime parameter. >>>> >>>> Part of: https://fedorahosted.org/freeipa/ticket/3306 >>>> >>> >>> ACK. >> >> This apparently depends on tbabej-0137, so let's not push it yet. >> > > Right. That's why try to keep the dependent patches fixing one ticket in a > single thread, Tomas :-) +1 -- Jan Cholasta From pviktori at redhat.com Tue Jan 14 17:02:52 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 14 Jan 2014 18:02:52 +0100 Subject: [Freeipa-devel] [PATCH] 0451 integration tests OpenSSHTransport: Expand tilde to home in, root_ssh_key_filename Message-ID: <52D56DBC.9080207@redhat.com> https://fedorahosted.org/freeipa/ticket/4115 The tilde was not expanded in the $IPA_ROOT_SSH_KEY configuration variable, so the default (~/.ssh/id_rsa) did not work. Here's a fix. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0451-integration-tests-OpenSSHTransport-Expand-tilde-to-h.patch Type: text/x-patch Size: 1322 bytes Desc: not available URL: From simo at redhat.com Tue Jan 14 18:03:47 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 14 Jan 2014 13:03:47 -0500 Subject: [Freeipa-devel] [PATCH] 0451 integration tests OpenSSHTransport: Expand tilde to home in, root_ssh_key_filename In-Reply-To: <52D56DBC.9080207@redhat.com> References: <52D56DBC.9080207@redhat.com> Message-ID: <1389722627.26102.421.camel@willson.li.ssimo.org> On Tue, 2014-01-14 at 18:02 +0100, Petr Viktorin wrote: > https://fedorahosted.org/freeipa/ticket/4115 > > The tilde was not expanded in the $IPA_ROOT_SSH_KEY configuration > variable, so the default (~/.ssh/id_rsa) did not work. > Here's a fix. Looks good. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Jan 14 18:12:02 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 14 Jan 2014 13:12:02 -0500 Subject: [Freeipa-devel] python-kerberos patch In-Reply-To: <1389648223.26102.397.camel@willson.li.ssimo.org> References: <52D4424C.7040101@redhat.com> <1389648223.26102.397.camel@willson.li.ssimo.org> Message-ID: <52D57DF2.4090803@redhat.com> Simo Sorce wrote: > On Mon, 2014-01-13 at 14:45 -0500, Rob Crittenden wrote: >> In an effort to be able to to use GSS-Proxy as a client in IPA I've >> written a patch against python-kerberos to add a call to >> gss_cred_inquire so we can peek at the current principal name. This will >> replace the python-krbV call in ipapython/util.py::get_current_principal(). >> >> The patch is pending review upstream at >> https://trac.calendarserver.org/ticket/830#comment:1 but it hasn't seen >> any activity yet and I'm impatient. >> >> Anyone have a few moments to take a look? I'm not super happy with the >> way one has to call it and some feedback would be helpful. > > I do not like their python API, but ... we can;t change that. > > One the C code: > you call it yadda_client_yadda but then you user server_creds as the > variable name, that's confusing. > > You should simply initialize name and name_token to 0 and > unconditionally free/release them on error, and do that all at the end > based on the return you want. > > Also you can simplify string copying.. > > How I'd rewrite the last 15 lines after gss_display_name() > > if (GSS_ERROR(maj_stat)) { > set_gss_error(maj_stat, min_stat); > ret = AUTH_GSS_ERROR; > goto end; > } > > state->username = strndup(name_token.value, name_token.length); > if (!state->username) { > set_gss_error(GSS_S_FAILURE, ENOMEM); > ret = AUTH_GSS_ERROR; > } > > end: > (void)gss_release_cred(&min_stat, &server_creds); > (void)gss_release_name(&min_stat, &name); > (void)gss_release_buffer(&min_state, name_token); > > return ret; > } > > > You could simplify even more without using ret, and jumping to end on > any maj_stat error and at end > if (maj_stat != GSS_S_COMPLETE) { > set_gss_error(maj_state, min_stat); > ... > > Simo. > Thanks for the detailed review. I applied your changes and updated the attachment on the upstream ticket. If you think it is acceptable, I'd like to add this patch to at least rawhide if not F-20. rob From rcritten at redhat.com Tue Jan 14 18:59:16 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 14 Jan 2014 13:59:16 -0500 Subject: [Freeipa-devel] [PATCH] 0335 ipa-replica-install: Move check for existing host before DNS resolution check In-Reply-To: <52D5370D.5050101@redhat.com> References: <52A71945.6040503@redhat.com> <52D41206.6000101@redhat.com> <52D5370D.5050101@redhat.com> Message-ID: <52D58904.6040509@redhat.com> Petr Viktorin wrote: > On 01/13/2014 05:19 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> See commit message & ticket for details. >>> >>> https://fedorahosted.org/freeipa/ticket/3889 >> >> If memory serves this was done so that both the replication and the host >> checks would be done so the admin wouldn't die a death of a thousand >> cuts. >> >> If a leftover agreement exists then the replica install will fail. You >> delete the agreement. The next install may fail too if the host exists. >> We should check for both before quitting. > > AFAIK nowadays ipa-replica-manage del should also remove the host entry, > so it's correct to suggest just that. > I couldn't find any place in the code the host is removed. This would have to be a pretty specialized case because you'd only remove the host if you were also deleting the last agreement. rob From rcritten at redhat.com Tue Jan 14 19:44:31 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 14 Jan 2014 14:44:31 -0500 Subject: [Freeipa-devel] [PATCH] 1105 fix creating host with --password= Message-ID: <52D5939F.2060800@redhat.com> Fix creating a host with --password= (yes, an empty password). The ticket has full reproduction details. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1105-host-password.patch Type: text/x-diff Size: 2853 bytes Desc: not available URL: From simo at redhat.com Tue Jan 14 20:56:14 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 14 Jan 2014 15:56:14 -0500 Subject: [Freeipa-devel] [PATCHES] 506-507 Fix ticket #4085 Message-ID: <1389732974.26102.439.camel@willson.li.ssimo.org> Uniform fallback for global_policy and stop explicitly adding the default policy to all user accounts. Tested. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-506-Harmonize-policy-discovery-to-kdb-driver.patch Type: text/x-patch Size: 5442 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-507-Stop-adding-a-default-password-policy-reference.patch Type: text/x-patch Size: 1752 bytes Desc: not available URL: From simo at redhat.com Tue Jan 14 20:57:40 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 14 Jan 2014 15:57:40 -0500 Subject: [Freeipa-devel] python-kerberos patch In-Reply-To: <52D57DF2.4090803@redhat.com> References: <52D4424C.7040101@redhat.com> <1389648223.26102.397.camel@willson.li.ssimo.org> <52D57DF2.4090803@redhat.com> Message-ID: <1389733060.26102.441.camel@willson.li.ssimo.org> On Tue, 2014-01-14 at 13:12 -0500, Rob Crittenden wrote: > Simo Sorce wrote: > > On Mon, 2014-01-13 at 14:45 -0500, Rob Crittenden wrote: > >> In an effort to be able to to use GSS-Proxy as a client in IPA I've > >> written a patch against python-kerberos to add a call to > >> gss_cred_inquire so we can peek at the current principal name. This will > >> replace the python-krbV call in ipapython/util.py::get_current_principal(). > >> > >> The patch is pending review upstream at > >> https://trac.calendarserver.org/ticket/830#comment:1 but it hasn't seen > >> any activity yet and I'm impatient. > >> > >> Anyone have a few moments to take a look? I'm not super happy with the > >> way one has to call it and some feedback would be helpful. > > > > I do not like their python API, but ... we can;t change that. > > > > One the C code: > > you call it yadda_client_yadda but then you user server_creds as the > > variable name, that's confusing. > > > > You should simply initialize name and name_token to 0 and > > unconditionally free/release them on error, and do that all at the end > > based on the return you want. > > > > Also you can simplify string copying.. > > > > How I'd rewrite the last 15 lines after gss_display_name() > > > > if (GSS_ERROR(maj_stat)) { > > set_gss_error(maj_stat, min_stat); > > ret = AUTH_GSS_ERROR; > > goto end; > > } > > > > state->username = strndup(name_token.value, name_token.length); > > if (!state->username) { > > set_gss_error(GSS_S_FAILURE, ENOMEM); > > ret = AUTH_GSS_ERROR; > > } > > > > end: > > (void)gss_release_cred(&min_stat, &server_creds); > > (void)gss_release_name(&min_stat, &name); > > (void)gss_release_buffer(&min_state, name_token); > > > > return ret; > > } > > > > > > You could simplify even more without using ret, and jumping to end on > > any maj_stat error and at end > > if (maj_stat != GSS_S_COMPLETE) { > > set_gss_error(maj_state, min_stat); > > ... > > > > Simo. > > > > Thanks for the detailed review. I applied your changes and updated the > attachment on the upstream ticket. Looks good. > If you think it is acceptable, I'd like to add this patch to at least > rawhide if not F-20. Maybe rawhide, but I'd like to know that upstream accepted the python API for it before committing, the last thing we want is to have incompatible python API should upstream decide they do not like the one you proposed. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed Jan 15 07:59:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Jan 2014 08:59:42 +0100 Subject: [Freeipa-devel] [PATCH] 446 sudoOrder missing in sudoers Message-ID: <52D63FEE.2000803@redhat.com> sudoers compat plugin configuration missed the sudoOrder attribute and it thus did not show up in ou=sudoers. Add the definion to update file. https://fedorahosted.org/freeipa/ticket/4107 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-446-sudoorder-missing-in-sudoers.patch Type: text/x-patch Size: 1076 bytes Desc: not available URL: From mkosek at redhat.com Wed Jan 15 08:32:47 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Jan 2014 09:32:47 +0100 Subject: [Freeipa-devel] [PATCH] 447 Add missing example to sudorule Message-ID: <52D647AF.6020405@redhat.com> https://fedorahosted.org/freeipa/ticket/4090 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-447-add-missing-example-to-sudorule.patch Type: text/x-patch Size: 1461 bytes Desc: not available URL: From jcholast at redhat.com Wed Jan 15 08:57:12 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 15 Jan 2014 09:57:12 +0100 Subject: [Freeipa-devel] [PATCH] 232 Increase service startup timeout default Message-ID: <52D64D68.9090206@redhat.com> Hi, the attached patch should fix . I have also attached patch 179, which fixes a related bug in certificate renewal. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-179-Do-not-start-the-service-in-stopped_service-if-it-wa.patch Type: text/x-patch Size: 1115 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-232-Increase-service-startup-timeout-default.patch Type: text/x-patch Size: 745 bytes Desc: not available URL: From mkosek at redhat.com Wed Jan 15 09:03:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Jan 2014 10:03:46 +0100 Subject: [Freeipa-devel] [PATCH] 1105 fix creating host with --password= In-Reply-To: <52D5939F.2060800@redhat.com> References: <52D5939F.2060800@redhat.com> Message-ID: <52D64EF2.6050209@redhat.com> On 01/14/2014 08:44 PM, Rob Crittenden wrote: > Fix creating a host with --password= (yes, an empty password). The ticket has > full reproduction details. > > rob Works fine, thanks for the test. ACK, pushed to master, ipa-3-3. Martin From pspacek at redhat.com Wed Jan 15 09:11:37 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 15 Jan 2014 10:11:37 +0100 Subject: [Freeipa-devel] Why is RPM posttrans quiet? Message-ID: <52D650C9.9020005@redhat.com> Hello list, I just found that freeipa.spec silences all messages from %posttrans scripts, which makes me a bit nervous: %posttrans server # This must be run in posttrans so that updates from previous # execution that may no longer be shipped are not applied. /usr/sbin/ipa-ldap-updater --upgrade --quiet >/dev/null || : /usr/sbin/ipa-upgradeconfig --quiet >/dev/null || : # Restart IPA processes. This must be also run in postrans so that plugins # and software is in consistent state python -c "import sys; from ipaserver.install import installutils; sys.exit(0 if installutils.is_ipa_configured() else 1);" > /dev/null 2>&1 # NOTE: systemd specific section if [ $? -eq 0 ]; then /bin/systemctl try-restart ipa.service >/dev/null 2>&1 || : fi # END I can't find such requirement in https://fedoraproject.org/wiki/Packaging:Guidelines Is there any particular reason for that? Does anybody have objections against removing redirection to /dev/null? (With appropriate handling for non-existent binaries, of course.) -- Petr^2 Spacek From mkosek at redhat.com Wed Jan 15 09:27:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Jan 2014 10:27:58 +0100 Subject: [Freeipa-devel] Why is RPM posttrans quiet? In-Reply-To: <52D650C9.9020005@redhat.com> References: <52D650C9.9020005@redhat.com> Message-ID: <52D6549E.10805@redhat.com> On 01/15/2014 10:11 AM, Petr Spacek wrote: > Hello list, > > I just found that freeipa.spec silences all messages from %posttrans scripts, > which makes me a bit nervous: > > %posttrans server > # This must be run in posttrans so that updates from previous > # execution that may no longer be shipped are not applied. > /usr/sbin/ipa-ldap-updater --upgrade --quiet >/dev/null || : > /usr/sbin/ipa-upgradeconfig --quiet >/dev/null || : > > # Restart IPA processes. This must be also run in postrans so that plugins > # and software is in consistent state > python -c "import sys; from ipaserver.install import installutils; sys.exit(0 > if installutils.is_ipa_configured() else 1);" > /dev/null 2>&1 > # NOTE: systemd specific section > if [ $? -eq 0 ]; then > /bin/systemctl try-restart ipa.service >/dev/null 2>&1 || : > fi > # END > > > I can't find such requirement in > https://fedoraproject.org/wiki/Packaging:Guidelines > > Is there any particular reason for that? > > Does anybody have objections against removing redirection to /dev/null? (With > appropriate handling for non-existent binaries, of course.) IIRC, we decided to only print errors in the RPM updater, thus the --quiet option. We do not print INFO and DEBUG logs to avoid cluttering RPM update transcript and only display meaningful information. This is a bit related: https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=79a427277a12925bca3f170cc7a255a2a9e45a10 Martin From jcholast at redhat.com Wed Jan 15 09:46:01 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 15 Jan 2014 10:46:01 +0100 Subject: [Freeipa-devel] [PATCH] 233 Fix ipa-client-automount uninstall when fstore is empty Message-ID: <52D658D9.9040005@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-233-Fix-ipa-client-automount-uninstall-when-fstore-is-em.patch Type: text/x-patch Size: 1016 bytes Desc: not available URL: From jcholast at redhat.com Wed Jan 15 09:49:59 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 15 Jan 2014 10:49:59 +0100 Subject: [Freeipa-devel] [PATCH] 233 Fix ipa-client-automount uninstall when fstore is empty In-Reply-To: <52D658D9.9040005@redhat.com> References: <52D658D9.9040005@redhat.com> Message-ID: <52D659C7.6080805@redhat.com> On 15.1.2014 10:46, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza I mean . -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-233.1-Fix-ipa-client-automount-uninstall-when-fstore-is-em.patch Type: text/x-patch Size: 1016 bytes Desc: not available URL: From jcholast at redhat.com Wed Jan 15 09:53:36 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 15 Jan 2014 10:53:36 +0100 Subject: [Freeipa-devel] [PATCH] 447 Add missing example to sudorule In-Reply-To: <52D647AF.6020405@redhat.com> References: <52D647AF.6020405@redhat.com> Message-ID: <52D65AA0.1090204@redhat.com> On 15.1.2014 09:32, Martin Kosek wrote: > https://fedorahosted.org/freeipa/ticket/4090 ACK. -- Jan Cholasta From jcholast at redhat.com Wed Jan 15 09:58:18 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 15 Jan 2014 10:58:18 +0100 Subject: [Freeipa-devel] [PATCH] 446 sudoOrder missing in sudoers In-Reply-To: <52D63FEE.2000803@redhat.com> References: <52D63FEE.2000803@redhat.com> Message-ID: <52D65BBA.60900@redhat.com> Hi, On 15.1.2014 08:59, Martin Kosek wrote: > sudoers compat plugin configuration missed the sudoOrder attribute > and it thus did not show up in ou=sudoers. Add the definion to update > file. > > https://fedorahosted.org/freeipa/ticket/4107 ACK with minor nitpick: add:schema-compat-entry-attribute:sudoOrder=%{sudoOrder} ^ A space would look nice here and be consistent with what the rest of the update file is formatted like. Honza -- Jan Cholasta From mkosek at redhat.com Wed Jan 15 10:01:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Jan 2014 11:01:01 +0100 Subject: [Freeipa-devel] [PATCH] 446 sudoOrder missing in sudoers In-Reply-To: <52D65BBA.60900@redhat.com> References: <52D63FEE.2000803@redhat.com> <52D65BBA.60900@redhat.com> Message-ID: <52D65C5D.40202@redhat.com> On 01/15/2014 10:58 AM, Jan Cholasta wrote: > Hi, > > On 15.1.2014 08:59, Martin Kosek wrote: >> sudoers compat plugin configuration missed the sudoOrder attribute >> and it thus did not show up in ou=sudoers. Add the definion to update >> file. >> >> https://fedorahosted.org/freeipa/ticket/4107 > > ACK with minor nitpick: > > add:schema-compat-entry-attribute:sudoOrder=%{sudoOrder} > ^ > > A space would look nice here and be consistent with what the rest of the update > file is formatted like. > > Honza > I fixed the space and pushed to master, ipa-3-3. Martin From mkosek at redhat.com Wed Jan 15 10:02:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Jan 2014 11:02:02 +0100 Subject: [Freeipa-devel] [PATCH] 447 Add missing example to sudorule In-Reply-To: <52D65AA0.1090204@redhat.com> References: <52D647AF.6020405@redhat.com> <52D65AA0.1090204@redhat.com> Message-ID: <52D65C9A.6040804@redhat.com> On 01/15/2014 10:53 AM, Jan Cholasta wrote: > On 15.1.2014 09:32, Martin Kosek wrote: >> https://fedorahosted.org/freeipa/ticket/4090 > > ACK. > Pushed to master, ipa-3-3. Martin From jpazdziora at redhat.com Wed Jan 15 10:13:27 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 15 Jan 2014 18:13:27 +0800 Subject: [Freeipa-devel] Why is RPM posttrans quiet? In-Reply-To: <52D650C9.9020005@redhat.com> References: <52D650C9.9020005@redhat.com> Message-ID: <20140115101327.GB20514@redhat.com> On Wed, Jan 15, 2014 at 10:11:37AM +0100, Petr Spacek wrote: > Hello list, > > I just found that freeipa.spec silences all messages from %posttrans > scripts, which makes me a bit nervous: > > %posttrans server > # This must be run in posttrans so that updates from previous > # execution that may no longer be shipped are not applied. > /usr/sbin/ipa-ldap-updater --upgrade --quiet >/dev/null || : > /usr/sbin/ipa-upgradeconfig --quiet >/dev/null || : > > # Restart IPA processes. This must be also run in postrans so that plugins > # and software is in consistent state > python -c "import sys; from ipaserver.install import installutils; > sys.exit(0 if installutils.is_ipa_configured() else 1);" > /dev/null > 2>&1 > # NOTE: systemd specific section > if [ $? -eq 0 ]; then > /bin/systemctl try-restart ipa.service >/dev/null 2>&1 || : > fi > # END > > > I can't find such requirement in > https://fedoraproject.org/wiki/Packaging:Guidelines > > Is there any particular reason for that? > > Does anybody have objections against removing redirection to > /dev/null? (With appropriate handling for non-existent binaries, of > course.) It reminds me of https://bugzilla.redhat.com/show_bug.cgi?id=606239 https://bugzilla.redhat.com/show_bug.cgi?id=615763 The problem is, you will not see that output when using yum in RHEL 6 anyway. And maybe in the past it even killed something? The examples in https://fedoraproject.org/wiki/Packaging:ScriptletSnippets all have the redirect but no explanation why. Maybe poking relevant Fedora people could yield some definitive answer? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From abokovoy at redhat.com Wed Jan 15 10:20:51 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 12:20:51 +0200 Subject: [Freeipa-devel] [PATCH] 232 Increase service startup timeout default In-Reply-To: <52D64D68.9090206@redhat.com> References: <52D64D68.9090206@redhat.com> Message-ID: <20140115102051.GW12003@redhat.com> On Wed, 15 Jan 2014, Jan Cholasta wrote: >Hi, > >the attached patch should fix >. > >I have also attached patch 179, which fixes a related bug in >certificate renewal. NACK for this part: >This fixes a possible NSS database corruption in renew_ca_cert. >--- > ipaserver/install/installutils.py | 3 --- > 1 file changed, 3 deletions(-) > >diff --git a/ipaserver/install/installutils.py b/ipaserver/install/installutils.py >index 67eabc2..0ba9c2e 100644 >--- a/ipaserver/install/installutils.py >+++ b/ipaserver/install/installutils.py >@@ -820,9 +820,6 @@ def stopped_service(service, instance_name=""): > root_logger.debug('Service %s%s is not running, continue.', service, > log_instance_name) > yield >- root_logger.debug('Starting %s%s.', service, log_instance_name) >- ipaservices.knownservices[service].start(instance_name) >- return > else: > # Stop the service, do the required stuff and start it again > root_logger.debug('Stopping %s%s.', service, log_instance_name) You need to wrap yield into try: finally: block. I have a patch for similar case in private_cache() few lines above this code. > >diff --git a/ipalib/constants.py b/ipalib/constants.py >index d3e61ca..ae08277 100644 >--- a/ipalib/constants.py >+++ b/ipalib/constants.py >@@ -119,7 +119,7 @@ DEFAULT_CONFIG = ( > ('rpc_protocol', 'jsonrpc'), > > # Time to wait for a service to start, in seconds >- ('startup_timeout', 120), >+ ('startup_timeout', 300), > > # Web Application mount points > ('mount_ipa', '/ipa/'), ACK for this one. -- / Alexander Bokovoy From mkosek at redhat.com Wed Jan 15 11:10:27 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Jan 2014 12:10:27 +0100 Subject: [Freeipa-devel] [PATCH] 233 Fix ipa-client-automount uninstall when fstore is empty In-Reply-To: <52D659C7.6080805@redhat.com> References: <52D658D9.9040005@redhat.com> <52D659C7.6080805@redhat.com> Message-ID: <52D66CA3.7060907@redhat.com> On 01/15/2014 10:49 AM, Jan Cholasta wrote: > On 15.1.2014 10:46, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza > > I mean . ACK. Pushed to master, ipa-3-3. Martin From mkosek at redhat.com Wed Jan 15 11:17:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Jan 2014 12:17:16 +0100 Subject: [Freeipa-devel] [PATCH] 232 Increase service startup timeout default In-Reply-To: <20140115102051.GW12003@redhat.com> References: <52D64D68.9090206@redhat.com> <20140115102051.GW12003@redhat.com> Message-ID: <52D66E3C.60007@redhat.com> On 01/15/2014 11:20 AM, Alexander Bokovoy wrote: > On Wed, 15 Jan 2014, Jan Cholasta wrote: >> Hi, >> >> the attached patch should fix . >> >> I have also attached patch 179, which fixes a related bug in certificate >> renewal. > > NACK for this part: >> This fixes a possible NSS database corruption in renew_ca_cert. >> --- >> ipaserver/install/installutils.py | 3 --- >> 1 file changed, 3 deletions(-) >> >> diff --git a/ipaserver/install/installutils.py >> b/ipaserver/install/installutils.py >> index 67eabc2..0ba9c2e 100644 >> --- a/ipaserver/install/installutils.py >> +++ b/ipaserver/install/installutils.py >> @@ -820,9 +820,6 @@ def stopped_service(service, instance_name=""): >> root_logger.debug('Service %s%s is not running, continue.', service, >> log_instance_name) >> yield >> - root_logger.debug('Starting %s%s.', service, log_instance_name) >> - ipaservices.knownservices[service].start(instance_name) >> - return >> else: >> # Stop the service, do the required stuff and start it again >> root_logger.debug('Stopping %s%s.', service, log_instance_name) > You need to wrap yield into try: finally: block. I have a patch for > similar case in private_cache() few lines above this code. > >> >> diff --git a/ipalib/constants.py b/ipalib/constants.py >> index d3e61ca..ae08277 100644 >> --- a/ipalib/constants.py >> +++ b/ipalib/constants.py >> @@ -119,7 +119,7 @@ DEFAULT_CONFIG = ( >> ('rpc_protocol', 'jsonrpc'), >> >> # Time to wait for a service to start, in seconds >> - ('startup_timeout', 120), >> + ('startup_timeout', 300), >> >> # Web Application mount points >> ('mount_ipa', '/ipa/'), > ACK for this one. > Additionally, shouldn't we make the renew_ca_cert script more robust and do the changes in LDAP datababase or certDB even if CA does not start and timeouts? (as indicated in #4078) IMO it is much easier for administrator to just start a CA manually, but with correct cert renewed, than figure out which part of renew procedure was not completed. I mean this part: # Done withing stopped_service context, CA restarted here update_cert_config(nickname, cert) <<< should not fail there if CA did not start, just report error and continue vvvvv if nickname == 'subsystemCert cert-pki-ca': update_people_entry('pkidbuser', cert) if nickname == 'auditSigningCert cert-pki-ca': # Fix trust on the audit cert Martin From jcholast at redhat.com Wed Jan 15 11:43:25 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 15 Jan 2014 12:43:25 +0100 Subject: [Freeipa-devel] [PATCH] 232 Increase service startup timeout default In-Reply-To: <52D66E3C.60007@redhat.com> References: <52D64D68.9090206@redhat.com> <20140115102051.GW12003@redhat.com> <52D66E3C.60007@redhat.com> Message-ID: <52D6745D.4060008@redhat.com> On 15.1.2014 12:17, Martin Kosek wrote: > On 01/15/2014 11:20 AM, Alexander Bokovoy wrote: >> On Wed, 15 Jan 2014, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch should fix . >>> >>> I have also attached patch 179, which fixes a related bug in certificate >>> renewal. >> >> NACK for this part: >>> This fixes a possible NSS database corruption in renew_ca_cert. >>> --- >>> ipaserver/install/installutils.py | 3 --- >>> 1 file changed, 3 deletions(-) >>> >>> diff --git a/ipaserver/install/installutils.py >>> b/ipaserver/install/installutils.py >>> index 67eabc2..0ba9c2e 100644 >>> --- a/ipaserver/install/installutils.py >>> +++ b/ipaserver/install/installutils.py >>> @@ -820,9 +820,6 @@ def stopped_service(service, instance_name=""): >>> root_logger.debug('Service %s%s is not running, continue.', service, >>> log_instance_name) >>> yield >>> - root_logger.debug('Starting %s%s.', service, log_instance_name) >>> - ipaservices.knownservices[service].start(instance_name) >>> - return >>> else: >>> # Stop the service, do the required stuff and start it again >>> root_logger.debug('Stopping %s%s.', service, log_instance_name) >> You need to wrap yield into try: finally: block. I have a patch for >> similar case in private_cache() few lines above this code. There is no cleanup needed for this particular yield. Also this is not really the concern of the patch, it does exactly what the commit message says. Since you are already fixing a similar case, I would suggest you amend your patch with any changes you deem necessary, I don't see why a single fix should be dispersed among multiple patches. >> >>> >>> diff --git a/ipalib/constants.py b/ipalib/constants.py >>> index d3e61ca..ae08277 100644 >>> --- a/ipalib/constants.py >>> +++ b/ipalib/constants.py >>> @@ -119,7 +119,7 @@ DEFAULT_CONFIG = ( >>> ('rpc_protocol', 'jsonrpc'), >>> >>> # Time to wait for a service to start, in seconds >>> - ('startup_timeout', 120), >>> + ('startup_timeout', 300), >>> >>> # Web Application mount points >>> ('mount_ipa', '/ipa/'), >> ACK for this one. >> > > > Additionally, shouldn't we make the renew_ca_cert script more robust and do the > changes in LDAP datababase or certDB even if CA does not start and timeouts? > (as indicated in #4078) > > IMO it is much easier for administrator to just start a CA manually, but with > correct cert renewed, than figure out which part of renew procedure was not > completed. > > I mean this part: > > # Done withing stopped_service context, CA restarted here > update_cert_config(nickname, cert) <<< should not fail there if CA did not > start, just report error and continue vvvvv The CA should not be started here at all. Patch 179 fixes that. > > if nickname == 'subsystemCert cert-pki-ca': > update_people_entry('pkidbuser', cert) > > if nickname == 'auditSigningCert cert-pki-ca': > # Fix trust on the audit cert > > Martin > -- Jan Cholasta From abokovoy at redhat.com Wed Jan 15 12:14:08 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 14:14:08 +0200 Subject: [Freeipa-devel] [PATCH] 0130 -- create missing idranges in trust-fetch-domains In-Reply-To: <20140114141737.GQ2855@localhost.localdomain> References: <20140114120233.GK12003@redhat.com> <52D52B90.5090202@redhat.com> <20140114122738.GM12003@redhat.com> <52D52F11.3090704@redhat.com> <20140114140305.GO12003@redhat.com> <20140114141737.GQ2855@localhost.localdomain> Message-ID: <20140115121408.GY12003@redhat.com> On Tue, 14 Jan 2014, Sumit Bose wrote: >On Tue, Jan 14, 2014 at 04:03:06PM +0200, Alexander Bokovoy wrote: >> On Tue, 14 Jan 2014, Martin Kosek wrote: >> >On 01/14/2014 01:27 PM, Alexander Bokovoy wrote: >> >>On Tue, 14 Jan 2014, Martin Kosek wrote: >> >>>On 01/14/2014 01:02 PM, Alexander Bokovoy wrote: >> >>>>Hi, >> >>>> >> >>>>attached patch implements missing idranges when new child domains >> >>>>discovered through 'ipa trust-fetch-domains'. This functionality existed >> >>>>in 'ipa trust-add' but was not exposed in the 'ipa trust-fetch-domains'. >> >>>> >> >>>>Additionally, error message is shown in case trust name is incorrect. >> >>>> >> >>>>https://fedorahosted.org/freeipa/ticket/4104 >> >>>>https://fedorahosted.org/freeipa/ticket/4111 >> >>>> >> >>> >> >>>I did not test the patch, just few observations from reading it: >> >>It is generally wrong to base opinion purely on reading the code (see below >> >>why) :) >> > >> >One does not need to run the code that see the places where it may be rusty :) >> > >> >> >> >>>1) Why are you moving add_range method from trust object to the module? IMO it >> >>>could be left there, it belongs to the object. Plus, the patch won't be that >> >>>big and easier to backport. add_range can be still referred from other commands >> >>>as "self.obj.add_range", no need to move it. >> >>It was in trust_add class, not in the object. I need it in the other >> >>code and without explicit dependency on the object. >> > >> >Ok. Though I would still consider having it rather in the trust object to make >> >it easier accessible from other modules, though our API system. >> I deliberately don't want that. This is internal API for purposes of >> trust code -- do you envision any situation when anyone else might want >> to create idranges programmatically for child domains of the existing >> trust? Note that you are required to know fairly low-level details of >> the AD trusts to call it. >> >> > >> >> >> >>>2) This part looks *very* suspicious: >> >>> >> >>>- trust = self.api.Command.trust_show(keys[0], raw=True)['result'] >> >>>+ try: >> >>>+ trust = self.api.Command.trust_show(keys[0], raw=True)['result'] >> >>>+ except AssertionError: >> >>> >> >>>I do not think that AssertionError should be raised and caught in normal >> >>>operation, it should be an exceptional exception raised when the world falls >> >>>apart IMO. I.e. I would rather see some PublicError or Exception based >> >>>exception to be raised in trust_show in that case... >> >>It *is* raised and should be caught because this particular snippet is >> >>to catch situation when wrong trust domain name is passed. Previously >> >>the code simply generated server-side exception which resulted in >> >>'internal error'. >> > >> >Ok, understood. My point is, trust_show should not raise AssertException just >> >because wrong trust domain is passed. There are better means to express that >> >error - ValidationError or NotFound, based on the situation. >> Yes, this is due to the way trust.get_dn() is built. Do not commit this >> patch yet (though building packages for testing would be good), I'm >> reworking it a bit to move this logic to get_dn() -- otherwise >> LDAPRetrieve() will always issue AssertError. > >I guess I already hit this while testing. trust-fetch-domains does not >work for valid forest roots anymore :-) > >Btw, can you add the forest root check to trustdomain-find as well? I've fixed it by returning an exception from get_dn(), as it is expected from other objects' get_dn(). new version attached. -- / Alexander Bokovoy -------------- next part -------------- >From ecc34e33996c499236a59212167f2ce495d28209 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 14 Jan 2014 13:55:56 +0200 Subject: [PATCH] trust-fetch-domains: create ranges for new child domains When trust is added, we do create ranges for discovered child domains. However, this functionality was not available through 'trust-fetch-domains' command. Additionally, make sure non-existing trust will report proper error in trust-fetch-domains. https://fedorahosted.org/freeipa/ticket/4111 https://fedorahosted.org/freeipa/ticket/4104 --- ipalib/plugins/trust.py | 246 ++++++++++++++++++++++++++---------------------- 1 file changed, 132 insertions(+), 114 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 76d609f..f563ac4 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -188,6 +188,114 @@ def make_trust_dn(env, trust_type, dn): return DN(dn, container_dn) return dn +def add_range(self, range_name, dom_sid, *keys, **options): + """ + First, we try to derive the parameters of the ID range based on the + information contained in the Active Directory. + + If that was not successful, we go for our usual defaults (random base, + range size 200 000, ipa-ad-trust range type). + + Any of these can be overriden by passing appropriate CLI options + to the trust-add command. + """ + + range_size = None + range_type = None + base_id = None + + # First, get information about ID space from AD + # However, we skip this step if other than ipa-ad-trust-posix + # range type is enforced + + if options.get('range_type', None) in (None, u'ipa-ad-trust-posix'): + + # Get the base dn + domain = keys[-1] + basedn = realm_to_suffix(domain) + + # Search for information contained in + # CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System + info_filter = '(objectClass=msSFU30DomainInfo)' + info_dn = DN('CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System')\ + + basedn + + # Get the domain validator + domain_validator = ipaserver.dcerpc.DomainValidator(self.api) + if not domain_validator.is_configured(): + raise errors.NotFound( + reason=_('Cannot search in trusted domains without own ' + 'domain configured. Make sure you have run ' + 'ipa-adtrust-install on the IPA server first')) + + # KDC might not get refreshed data at the first time, + # retry several times + for retry in range(10): + info_list = domain_validator.search_in_dc(domain, + info_filter, + None, + SCOPE_SUBTREE, + basedn=info_dn, + quiet=True) + + if info_list: + info = info_list[0] + break + else: + sleep(2) + + required_msSFU_attrs = ['msSFU30MaxUidNumber', 'msSFU30OrderNumber'] + + if not info_list: + # We were unable to gain UNIX specific info from the AD + self.log.debug("Unable to gain POSIX info from the AD") + else: + if all(attr in info for attr in required_msSFU_attrs): + self.log.debug("Able to gain POSIX info from the AD") + range_type = u'ipa-ad-trust-posix' + + max_uid = info.get('msSFU30MaxUidNumber') + max_gid = info.get('msSFU30MaxGidNumber', None) + max_id = int(max(max_uid, max_gid)[0]) + + base_id = int(info.get('msSFU30OrderNumber')[0]) + range_size = (1 + (max_id - base_id) / DEFAULT_RANGE_SIZE)\ + * DEFAULT_RANGE_SIZE + + # Second, options given via the CLI options take precedence to discovery + if options.get('range_type', None): + range_type = options.get('range_type', None) + elif not range_type: + range_type = u'ipa-ad-trust' + + if options.get('range_size', None): + range_size = options.get('range_size', None) + elif not range_size: + range_size = DEFAULT_RANGE_SIZE + + if options.get('base_id', None): + base_id = options.get('base_id', None) + elif not base_id: + # Generate random base_id if not discovered nor given via CLI + base_id = DEFAULT_RANGE_SIZE + ( + pysss_murmur.murmurhash3( + dom_sid, + len(dom_sid), 0xdeadbeefL + ) % 10000 + ) * DEFAULT_RANGE_SIZE + + # Finally, add new ID range + self.api.Command['idrange_add'](range_name, + ipabaseid=base_id, + ipaidrangesize=range_size, + ipabaserid=0, + iparangetype=range_type, + ipanttrusteddomainsid=dom_sid) + + # Return the values that were generated inside this function + return range_type, range_size, base_id + + class trust(LDAPObject): """ Trust object. @@ -261,8 +369,8 @@ class trust(LDAPObject): try: result = ldap.get_entries(DN(self.container_dn, self.env.basedn), ldap.SCOPE_SUBTREE, filter, ['']) - except errors.NotFound: - return None + except errors.NotFound, e: + raise e else: if len(result) > 1: raise errors.OnlyOneValueAllowed(attr='trust domain') @@ -341,8 +449,8 @@ sides. # Store the created range type, since for POSIX trusts no # ranges for the subdomains should be added, POSIX attributes # provide a global mapping across all subdomains - (created_range_type, _, _) = self.add_range(range_name, dom_sid, - *keys, **options) + (created_range_type, _, _) = add_range(self, range_name, dom_sid, + *keys, **options) else: created_range_type = old_range['result']['iparangetype'][0] @@ -382,8 +490,8 @@ sides. # Try to add the range for each subdomain try: - self.add_range(range_name, dom_sid, *keys, - **passed_options) + add_range(self, range_name, dom_sid, *keys, + **passed_options) except errors.DuplicateEntry: pass @@ -549,120 +657,17 @@ sides. return old_range, range_name, dom_sid - def add_range(self, range_name, dom_sid, *keys, **options): - """ - First, we try to derive the parameters of the ID range based on the - information contained in the Active Directory. - - If that was not successful, we go for our usual defaults (random base, - range size 200 000, ipa-ad-trust range type). - - Any of these can be overriden by passing appropriate CLI options - to the trust-add command. - """ - - range_size = None - range_type = None - base_id = None - - # First, get information about ID space from AD - # However, we skip this step if other than ipa-ad-trust-posix - # range type is enforced - - if options.get('range_type', None) in (None, u'ipa-ad-trust-posix'): - - # Get the base dn - domain = keys[-1] - basedn = realm_to_suffix(domain) - - # Search for information contained in - # CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System - info_filter = '(objectClass=msSFU30DomainInfo)' - info_dn = DN('CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System')\ - + basedn - - # Get the domain validator - domain_validator = ipaserver.dcerpc.DomainValidator(self.api) - if not domain_validator.is_configured(): - raise errors.NotFound( - reason=_('Cannot search in trusted domains without own ' - 'domain configured. Make sure you have run ' - 'ipa-adtrust-install on the IPA server first')) - - # KDC might not get refreshed data at the first time, - # retry several times - for retry in range(10): - info_list = domain_validator.search_in_dc(domain, - info_filter, - None, - SCOPE_SUBTREE, - basedn=info_dn, - quiet=True) - - if info_list: - info = info_list[0] - break - else: - sleep(2) - - required_msSFU_attrs = ['msSFU30MaxUidNumber', 'msSFU30OrderNumber'] - - if not info_list: - # We were unable to gain UNIX specific info from the AD - self.log.debug("Unable to gain POSIX info from the AD") - else: - if all(attr in info for attr in required_msSFU_attrs): - self.log.debug("Able to gain POSIX info from the AD") - range_type = u'ipa-ad-trust-posix' - - max_uid = info.get('msSFU30MaxUidNumber') - max_gid = info.get('msSFU30MaxGidNumber', None) - max_id = int(max(max_uid, max_gid)[0]) - - base_id = int(info.get('msSFU30OrderNumber')[0]) - range_size = (1 + (max_id - base_id) / DEFAULT_RANGE_SIZE)\ - * DEFAULT_RANGE_SIZE - - # Second, options given via the CLI options take precedence to discovery - if options.get('range_type', None): - range_type = options.get('range_type', None) - elif not range_type: - range_type = u'ipa-ad-trust' - - if options.get('range_size', None): - range_size = options.get('range_size', None) - elif not range_size: - range_size = DEFAULT_RANGE_SIZE - - if options.get('base_id', None): - base_id = options.get('base_id', None) - elif not base_id: - # Generate random base_id if not discovered nor given via CLI - base_id = DEFAULT_RANGE_SIZE + ( - pysss_murmur.murmurhash3( - dom_sid, - len(dom_sid), 0xdeadbeefL - ) % 10000 - ) * DEFAULT_RANGE_SIZE - - # Finally, add new ID range - api.Command['idrange_add'](range_name, - ipabaseid=base_id, - ipaidrangesize=range_size, - ipabaserid=0, - iparangetype=range_type, - ipanttrusteddomainsid=dom_sid) - - # Return the values that were generated inside this function - return range_type, range_size, base_id - def execute_ad(self, full_join, *keys, **options): # Join domain using full credentials and with random trustdom # secret (will be generated by the join method) # First see if the trust is already in place # Force retrieval of the trust object by not passing trust_type - dn = self.obj.get_dn(keys[-1]) + try: + dn = self.obj.get_dn(keys[-1]) + except errors.NotFound: + dn = None + if dn: summary = _('Re-established trust to domain "%(value)s"') else: @@ -794,6 +799,7 @@ class trust_show(LDAPRetrieve): def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) # Translate ipanttrusttype to trusttype # and ipanttrustdirection to trustdirection # if --raw not used @@ -1246,6 +1252,11 @@ def fetch_domains_from_trust(self, trustinstance, trust_entry, **options): if not domains: return result + # trust range must exist by the time fetch_domains_from_trust is called + range_name = trust_name.upper() + '_id_range' + old_range = api.Command.idrange_show(range_name, raw=True)['result'] + idrange_type = old_range['iparangetype'] + for dom in domains: dom['trust_type'] = u'ad' try: @@ -1255,8 +1266,15 @@ def fetch_domains_from_trust(self, trustinstance, trust_entry, **options): dom['all'] = options['all'] if 'raw' in options: dom['raw'] = options['raw'] + res = self.api.Command.trustdomain_add(trust_name, name, **dom) result.append(res['result']) + + if idrange_type != u'ipa-ad-trust-posix': + range_name = name.upper() + '_id_range' + dom['range_type'] = u'ipa-ad-trust' + add_range(self, range_name, dom['ipanttrusteddomainsid'], + trust_name, name, **dom) except errors.DuplicateEntry: # Ignore updating duplicate entries pass -- 1.8.4.2 From abokovoy at redhat.com Wed Jan 15 12:21:44 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 14:21:44 +0200 Subject: [Freeipa-devel] [PATCH] 232 Increase service startup timeout default In-Reply-To: <52D6745D.4060008@redhat.com> References: <52D64D68.9090206@redhat.com> <20140115102051.GW12003@redhat.com> <52D66E3C.60007@redhat.com> <52D6745D.4060008@redhat.com> Message-ID: <20140115122144.GZ12003@redhat.com> On Wed, 15 Jan 2014, Jan Cholasta wrote: >On 15.1.2014 12:17, Martin Kosek wrote: >>On 01/15/2014 11:20 AM, Alexander Bokovoy wrote: >>>On Wed, 15 Jan 2014, Jan Cholasta wrote: >>>>Hi, >>>> >>>>the attached patch should fix . >>>> >>>>I have also attached patch 179, which fixes a related bug in certificate >>>>renewal. >>> >>>NACK for this part: >>>>This fixes a possible NSS database corruption in renew_ca_cert. >>>>--- >>>>ipaserver/install/installutils.py | 3 --- >>>>1 file changed, 3 deletions(-) >>>> >>>>diff --git a/ipaserver/install/installutils.py >>>>b/ipaserver/install/installutils.py >>>>index 67eabc2..0ba9c2e 100644 >>>>--- a/ipaserver/install/installutils.py >>>>+++ b/ipaserver/install/installutils.py >>>>@@ -820,9 +820,6 @@ def stopped_service(service, instance_name=""): >>>> root_logger.debug('Service %s%s is not running, continue.', service, >>>> log_instance_name) >>>> yield >>>>- root_logger.debug('Starting %s%s.', service, log_instance_name) >>>>- ipaservices.knownservices[service].start(instance_name) >>>>- return >>>> else: >>>> # Stop the service, do the required stuff and start it again >>>> root_logger.debug('Stopping %s%s.', service, log_instance_name) >>>You need to wrap yield into try: finally: block. I have a patch for >>>similar case in private_cache() few lines above this code. > >There is no cleanup needed for this particular yield. Also this is >not really the concern of the patch, it does exactly what the commit >message says. Since you are already fixing a similar case, I would >suggest you amend your patch with any changes you deem necessary, I >don't see why a single fix should be dispersed among multiple >patches. Patch attached, it obsoletes your patch 179. -- / Alexander Bokovoy -------------- next part -------------- >From a201bd425d988257769f096093198e16c23e7065 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 15 Jan 2014 14:16:49 +0200 Subject: [PATCH 2/2] ipaserver/install/installutils: clean up properly after yield When a context to which we yield generates exception, the code in private_ccache() and stopped_service() didn't get called for cleanup. Additionally, in stopped_service() one should not start a previously stopped service after the context returned control to us because the original state was with stopped service already. Fixes https://fedorahosted.org/freeipa/ticket/4078 --- ipaserver/install/installutils.py | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/ipaserver/install/installutils.py b/ipaserver/install/installutils.py index cc53f75..67216f1 100644 --- a/ipaserver/install/installutils.py +++ b/ipaserver/install/installutils.py @@ -786,15 +786,16 @@ def private_ccache(path=None): os.environ['KRB5CCNAME'] = path - yield - - if original_value is not None: - os.environ['KRB5CCNAME'] = original_value - else: - os.environ.pop('KRB5CCNAME') + try: + yield + finally: + if original_value is not None: + os.environ['KRB5CCNAME'] = original_value + else: + os.environ.pop('KRB5CCNAME') - if os.path.exists(path): - os.remove(path) + if os.path.exists(path): + os.remove(path) @contextmanager @@ -820,13 +821,13 @@ def stopped_service(service, instance_name=""): root_logger.debug('Service %s%s is not running, continue.', service, log_instance_name) yield - root_logger.debug('Starting %s%s.', service, log_instance_name) - ipaservices.knownservices[service].start(instance_name) return else: # Stop the service, do the required stuff and start it again root_logger.debug('Stopping %s%s.', service, log_instance_name) ipaservices.knownservices[service].stop(instance_name) - yield - root_logger.debug('Starting %s%s.', service, log_instance_name) - ipaservices.knownservices[service].start(instance_name) + try: + yield + finally: + root_logger.debug('Starting %s%s.', service, log_instance_name) + ipaservices.knownservices[service].start(instance_name) -- 1.8.4.2 From jcholast at redhat.com Wed Jan 15 12:51:49 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 15 Jan 2014 13:51:49 +0100 Subject: [Freeipa-devel] [PATCH] 232 Increase service startup timeout default In-Reply-To: <20140115122144.GZ12003@redhat.com> References: <52D64D68.9090206@redhat.com> <20140115102051.GW12003@redhat.com> <52D66E3C.60007@redhat.com> <52D6745D.4060008@redhat.com> <20140115122144.GZ12003@redhat.com> Message-ID: <52D68465.3030303@redhat.com> On 15.1.2014 13:21, Alexander Bokovoy wrote: > On Wed, 15 Jan 2014, Jan Cholasta wrote: >> On 15.1.2014 12:17, Martin Kosek wrote: >>> On 01/15/2014 11:20 AM, Alexander Bokovoy wrote: >>>> On Wed, 15 Jan 2014, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patch should fix >>>>> . >>>>> >>>>> I have also attached patch 179, which fixes a related bug in >>>>> certificate >>>>> renewal. >>>> >>>> NACK for this part: >>>>> This fixes a possible NSS database corruption in renew_ca_cert. >>>>> --- >>>>> ipaserver/install/installutils.py | 3 --- >>>>> 1 file changed, 3 deletions(-) >>>>> >>>>> diff --git a/ipaserver/install/installutils.py >>>>> b/ipaserver/install/installutils.py >>>>> index 67eabc2..0ba9c2e 100644 >>>>> --- a/ipaserver/install/installutils.py >>>>> +++ b/ipaserver/install/installutils.py >>>>> @@ -820,9 +820,6 @@ def stopped_service(service, instance_name=""): >>>>> root_logger.debug('Service %s%s is not running, continue.', >>>>> service, >>>>> log_instance_name) >>>>> yield >>>>> - root_logger.debug('Starting %s%s.', service, >>>>> log_instance_name) >>>>> - ipaservices.knownservices[service].start(instance_name) >>>>> - return >>>>> else: >>>>> # Stop the service, do the required stuff and start it again >>>>> root_logger.debug('Stopping %s%s.', service, >>>>> log_instance_name) >>>> You need to wrap yield into try: finally: block. I have a patch for >>>> similar case in private_cache() few lines above this code. >> >> There is no cleanup needed for this particular yield. Also this is not >> really the concern of the patch, it does exactly what the commit >> message says. Since you are already fixing a similar case, I would >> suggest you amend your patch with any changes you deem necessary, I >> don't see why a single fix should be dispersed among multiple patches. > Patch attached, it obsoletes your patch 179. Thanks, but I don't understand why you squashed my patch 179 into your patch, the fixes are for separate issues (yield exception handling vs. previously stopped service being started). -- Jan Cholasta From abokovoy at redhat.com Wed Jan 15 12:55:58 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 14:55:58 +0200 Subject: [Freeipa-devel] [PATCH] 232 Increase service startup timeout default In-Reply-To: <52D68465.3030303@redhat.com> References: <52D64D68.9090206@redhat.com> <20140115102051.GW12003@redhat.com> <52D66E3C.60007@redhat.com> <52D6745D.4060008@redhat.com> <20140115122144.GZ12003@redhat.com> <52D68465.3030303@redhat.com> Message-ID: <20140115125558.GA12003@redhat.com> On Wed, 15 Jan 2014, Jan Cholasta wrote: >On 15.1.2014 13:21, Alexander Bokovoy wrote: >>On Wed, 15 Jan 2014, Jan Cholasta wrote: >>>On 15.1.2014 12:17, Martin Kosek wrote: >>>>On 01/15/2014 11:20 AM, Alexander Bokovoy wrote: >>>>>On Wed, 15 Jan 2014, Jan Cholasta wrote: >>>>>>Hi, >>>>>> >>>>>>the attached patch should fix >>>>>>. >>>>>> >>>>>>I have also attached patch 179, which fixes a related bug in >>>>>>certificate >>>>>>renewal. >>>>> >>>>>NACK for this part: >>>>>>This fixes a possible NSS database corruption in renew_ca_cert. >>>>>>--- >>>>>>ipaserver/install/installutils.py | 3 --- >>>>>>1 file changed, 3 deletions(-) >>>>>> >>>>>>diff --git a/ipaserver/install/installutils.py >>>>>>b/ipaserver/install/installutils.py >>>>>>index 67eabc2..0ba9c2e 100644 >>>>>>--- a/ipaserver/install/installutils.py >>>>>>+++ b/ipaserver/install/installutils.py >>>>>>@@ -820,9 +820,6 @@ def stopped_service(service, instance_name=""): >>>>>> root_logger.debug('Service %s%s is not running, continue.', >>>>>>service, >>>>>> log_instance_name) >>>>>> yield >>>>>>- root_logger.debug('Starting %s%s.', service, >>>>>>log_instance_name) >>>>>>- ipaservices.knownservices[service].start(instance_name) >>>>>>- return >>>>>> else: >>>>>> # Stop the service, do the required stuff and start it again >>>>>> root_logger.debug('Stopping %s%s.', service, >>>>>>log_instance_name) >>>>>You need to wrap yield into try: finally: block. I have a patch for >>>>>similar case in private_cache() few lines above this code. >>> >>>There is no cleanup needed for this particular yield. Also this is not >>>really the concern of the patch, it does exactly what the commit >>>message says. Since you are already fixing a similar case, I would >>>suggest you amend your patch with any changes you deem necessary, I >>>don't see why a single fix should be dispersed among multiple patches. >>Patch attached, it obsoletes your patch 179. > >Thanks, but I don't understand why you squashed my patch 179 into >your patch, the fixes are for separate issues (yield exception >handling vs. previously stopped service being started). Because you just said above: >>>suggest you amend your patch with any changes you deem necessary, I >>>don't see why a single fix should be dispersed among multiple patches. "a single fix" is now not dispersed among multiple patches. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Jan 15 13:47:57 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 15:47:57 +0200 Subject: [Freeipa-devel] [PATCH] 0132 Show status of the trusted domain in trustdomain-find Message-ID: <20140115134757.GB12003@redhat.com> Hi! This patch implements showing whether domains associated with the trust enabled or disabled. One can enable/disable child domains through trustdomain-enable/trustdomain-disable. Forest root domain will always be enabled. Implements https://fedorahosted.org/freeipa/ticket/4096 -- / Alexander Bokovoy -------------- next part -------------- >From bcab61dbe7f4dbf96fcb892e26b96f8d4565b3c9 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 15 Jan 2014 15:42:10 +0200 Subject: [PATCH 3/3] trustdomain-find: report status of the (sub)domain Show status of each enumerated domain trustdomain-find shows list of domains associated with the trust. Each domain except the trust forest root can be enabled or disabled with the help of trustdomain-enable and trustdomain-disable commands. https://fedorahosted.org/freeipa/ticket/4096 --- ipalib/plugins/trust.py | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index f563ac4..b11ee7c 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -21,7 +21,7 @@ from ipalib.plugins.baseldap import * from ipalib.plugins.dns import dns_container_exists from ipapython.ipautil import realm_to_suffix -from ipalib import api, Str, StrEnum, Password, _, ngettext +from ipalib import api, Str, StrEnum, Password, Bool, _, ngettext from ipalib import Command from ipalib import errors from ldap import SCOPE_SUBTREE @@ -1187,8 +1187,24 @@ api.register(trustdomain) class trustdomain_find(LDAPSearch): __doc__ = _('Search domains of the trust') + has_output_params = LDAPSearch.has_output_params + ( + Flag('domain_enabled', label= _('Domain enabled')), + ) def pre_callback(self, ldap, filters, attrs_list, base_dn, scope, *args, **options): return (filters, base_dn, ldap.SCOPE_SUBTREE) + + def post_callback(self, ldap, entries, truncated, *args, **options): + trust_dn = self.obj.get_dn(args[0], trust_type=u'ad') + trust_entry = ldap.get_entry(trust_dn) + for entry in entries: + sid = entry['ipanttrusteddomainsid'][0] + if sid in trust_entry['ipantsidblacklistincoming']: + entry['domain_enabled'] = [False] + else: + entry['domain_enabled'] = [True] + return truncated + + api.register(trustdomain_find) class trustdomain_mod(LDAPUpdate): -- 1.8.4.2 From sbose at redhat.com Wed Jan 15 13:54:10 2014 From: sbose at redhat.com (Sumit Bose) Date: Wed, 15 Jan 2014 14:54:10 +0100 Subject: [Freeipa-devel] [PATCH] 0130 -- create missing idranges in trust-fetch-domains In-Reply-To: <20140115121408.GY12003@redhat.com> References: <20140114120233.GK12003@redhat.com> <52D52B90.5090202@redhat.com> <20140114122738.GM12003@redhat.com> <52D52F11.3090704@redhat.com> <20140114140305.GO12003@redhat.com> <20140114141737.GQ2855@localhost.localdomain> <20140115121408.GY12003@redhat.com> Message-ID: <20140115135410.GA6041@localhost.localdomain> On Wed, Jan 15, 2014 at 02:14:08PM +0200, Alexander Bokovoy wrote: > On Tue, 14 Jan 2014, Sumit Bose wrote: > >On Tue, Jan 14, 2014 at 04:03:06PM +0200, Alexander Bokovoy wrote: > >>On Tue, 14 Jan 2014, Martin Kosek wrote: > >>>On 01/14/2014 01:27 PM, Alexander Bokovoy wrote: > >>>>On Tue, 14 Jan 2014, Martin Kosek wrote: > >>>>>On 01/14/2014 01:02 PM, Alexander Bokovoy wrote: > >>>>>>Hi, > >>>>>> > >>>>>>attached patch implements missing idranges when new child domains > >>>>>>discovered through 'ipa trust-fetch-domains'. This functionality existed > >>>>>>in 'ipa trust-add' but was not exposed in the 'ipa trust-fetch-domains'. > >>>>>> > >>>>>>Additionally, error message is shown in case trust name is incorrect. > >>>>>> > >>>>>>https://fedorahosted.org/freeipa/ticket/4104 > >>>>>>https://fedorahosted.org/freeipa/ticket/4111 > >>>>>> > >>>>> > >>>>>I did not test the patch, just few observations from reading it: > >>>>It is generally wrong to base opinion purely on reading the code (see below > >>>>why) :) > >>> > >>>One does not need to run the code that see the places where it may be rusty :) > >>> > >>>> > >>>>>1) Why are you moving add_range method from trust object to the module? IMO it > >>>>>could be left there, it belongs to the object. Plus, the patch won't be that > >>>>>big and easier to backport. add_range can be still referred from other commands > >>>>>as "self.obj.add_range", no need to move it. > >>>>It was in trust_add class, not in the object. I need it in the other > >>>>code and without explicit dependency on the object. > >>> > >>>Ok. Though I would still consider having it rather in the trust object to make > >>>it easier accessible from other modules, though our API system. > >>I deliberately don't want that. This is internal API for purposes of > >>trust code -- do you envision any situation when anyone else might want > >>to create idranges programmatically for child domains of the existing > >>trust? Note that you are required to know fairly low-level details of > >>the AD trusts to call it. > >> > >>> > >>>> > >>>>>2) This part looks *very* suspicious: > >>>>> > >>>>>- trust = self.api.Command.trust_show(keys[0], raw=True)['result'] > >>>>>+ try: > >>>>>+ trust = self.api.Command.trust_show(keys[0], raw=True)['result'] > >>>>>+ except AssertionError: > >>>>> > >>>>>I do not think that AssertionError should be raised and caught in normal > >>>>>operation, it should be an exceptional exception raised when the world falls > >>>>>apart IMO. I.e. I would rather see some PublicError or Exception based > >>>>>exception to be raised in trust_show in that case... > >>>>It *is* raised and should be caught because this particular snippet is > >>>>to catch situation when wrong trust domain name is passed. Previously > >>>>the code simply generated server-side exception which resulted in > >>>>'internal error'. > >>> > >>>Ok, understood. My point is, trust_show should not raise AssertException just > >>>because wrong trust domain is passed. There are better means to express that > >>>error - ValidationError or NotFound, based on the situation. > >>Yes, this is due to the way trust.get_dn() is built. Do not commit this > >>patch yet (though building packages for testing would be good), I'm > >>reworking it a bit to move this logic to get_dn() -- otherwise > >>LDAPRetrieve() will always issue AssertError. > > > >I guess I already hit this while testing. trust-fetch-domains does not > >work for valid forest roots anymore :-) > > > >Btw, can you add the forest root check to trustdomain-find as well? > I've fixed it by returning an exception from get_dn(), as it is expected > from other objects' get_dn(). > > new version attached. Thanks. I can give functional ACK. All my checks are working as expected, idranges are added if needed and 'ipa: ERROR: no such entry' is displayed if the forest name is invalid. Btw I think you can add https://fedorahosted.org/freeipa/ticket/4095 to the commit message as well. The python code looks good to me as well. bye, Sumit > > -- > / Alexander Bokovoy From mkosek at redhat.com Wed Jan 15 14:02:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Jan 2014 15:02:04 +0100 Subject: [Freeipa-devel] [PATCH] 0130 -- create missing idranges in trust-fetch-domains In-Reply-To: <20140115135410.GA6041@localhost.localdomain> References: <20140114120233.GK12003@redhat.com> <52D52B90.5090202@redhat.com> <20140114122738.GM12003@redhat.com> <52D52F11.3090704@redhat.com> <20140114140305.GO12003@redhat.com> <20140114141737.GQ2855@localhost.localdomain> <20140115121408.GY12003@redhat.com> <20140115135410.GA6041@localhost.localdomain> Message-ID: <52D694DC.7010608@redhat.com> On 01/15/2014 02:54 PM, Sumit Bose wrote: > On Wed, Jan 15, 2014 at 02:14:08PM +0200, Alexander Bokovoy wrote: >> On Tue, 14 Jan 2014, Sumit Bose wrote: >>> On Tue, Jan 14, 2014 at 04:03:06PM +0200, Alexander Bokovoy wrote: >>>> On Tue, 14 Jan 2014, Martin Kosek wrote: >>>>> On 01/14/2014 01:27 PM, Alexander Bokovoy wrote: >>>>>> On Tue, 14 Jan 2014, Martin Kosek wrote: >>>>>>> On 01/14/2014 01:02 PM, Alexander Bokovoy wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> attached patch implements missing idranges when new child domains >>>>>>>> discovered through 'ipa trust-fetch-domains'. This functionality existed >>>>>>>> in 'ipa trust-add' but was not exposed in the 'ipa trust-fetch-domains'. >>>>>>>> >>>>>>>> Additionally, error message is shown in case trust name is incorrect. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4104 >>>>>>>> https://fedorahosted.org/freeipa/ticket/4111 >>>>>>>> >>>>>>> >>>>>>> I did not test the patch, just few observations from reading it: >>>>>> It is generally wrong to base opinion purely on reading the code (see below >>>>>> why) :) >>>>> >>>>> One does not need to run the code that see the places where it may be rusty :) >>>>> >>>>>> >>>>>>> 1) Why are you moving add_range method from trust object to the module? IMO it >>>>>>> could be left there, it belongs to the object. Plus, the patch won't be that >>>>>>> big and easier to backport. add_range can be still referred from other commands >>>>>>> as "self.obj.add_range", no need to move it. >>>>>> It was in trust_add class, not in the object. I need it in the other >>>>>> code and without explicit dependency on the object. >>>>> >>>>> Ok. Though I would still consider having it rather in the trust object to make >>>>> it easier accessible from other modules, though our API system. >>>> I deliberately don't want that. This is internal API for purposes of >>>> trust code -- do you envision any situation when anyone else might want >>>> to create idranges programmatically for child domains of the existing >>>> trust? Note that you are required to know fairly low-level details of >>>> the AD trusts to call it. >>>> >>>>> >>>>>> >>>>>>> 2) This part looks *very* suspicious: >>>>>>> >>>>>>> - trust = self.api.Command.trust_show(keys[0], raw=True)['result'] >>>>>>> + try: >>>>>>> + trust = self.api.Command.trust_show(keys[0], raw=True)['result'] >>>>>>> + except AssertionError: >>>>>>> >>>>>>> I do not think that AssertionError should be raised and caught in normal >>>>>>> operation, it should be an exceptional exception raised when the world falls >>>>>>> apart IMO. I.e. I would rather see some PublicError or Exception based >>>>>>> exception to be raised in trust_show in that case... >>>>>> It *is* raised and should be caught because this particular snippet is >>>>>> to catch situation when wrong trust domain name is passed. Previously >>>>>> the code simply generated server-side exception which resulted in >>>>>> 'internal error'. >>>>> >>>>> Ok, understood. My point is, trust_show should not raise AssertException just >>>>> because wrong trust domain is passed. There are better means to express that >>>>> error - ValidationError or NotFound, based on the situation. >>>> Yes, this is due to the way trust.get_dn() is built. Do not commit this >>>> patch yet (though building packages for testing would be good), I'm >>>> reworking it a bit to move this logic to get_dn() -- otherwise >>>> LDAPRetrieve() will always issue AssertError. >>> >>> I guess I already hit this while testing. trust-fetch-domains does not >>> work for valid forest roots anymore :-) >>> >>> Btw, can you add the forest root check to trustdomain-find as well? >> I've fixed it by returning an exception from get_dn(), as it is expected >> from other objects' get_dn(). >> >> new version attached. > > Thanks. I can give functional ACK. All my checks are working as > expected, idranges are added if needed and 'ipa: ERROR: no such entry' > is displayed if the forest name is invalid. Btw I think you can add > https://fedorahosted.org/freeipa/ticket/4095 to the commit message as > well. > > The python code looks good to me as well. > > bye, > Sumit I have just few of my usual code purity rants :) What is the meaning of this? - except errors.NotFound: - return None + except errors.NotFound, e: + raise e Looks like NOOP to me, except it reraises the exception and thus hides the origin. Otherwise it looks fine. Martin From abokovoy at redhat.com Wed Jan 15 14:10:27 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 16:10:27 +0200 Subject: [Freeipa-devel] [PATCH] 0130 -- create missing idranges in trust-fetch-domains In-Reply-To: <52D694DC.7010608@redhat.com> References: <20140114120233.GK12003@redhat.com> <52D52B90.5090202@redhat.com> <20140114122738.GM12003@redhat.com> <52D52F11.3090704@redhat.com> <20140114140305.GO12003@redhat.com> <20140114141737.GQ2855@localhost.localdomain> <20140115121408.GY12003@redhat.com> <20140115135410.GA6041@localhost.localdomain> <52D694DC.7010608@redhat.com> Message-ID: <20140115141027.GC12003@redhat.com> On Wed, 15 Jan 2014, Martin Kosek wrote: >On 01/15/2014 02:54 PM, Sumit Bose wrote: >> On Wed, Jan 15, 2014 at 02:14:08PM +0200, Alexander Bokovoy wrote: >>> On Tue, 14 Jan 2014, Sumit Bose wrote: >>>> On Tue, Jan 14, 2014 at 04:03:06PM +0200, Alexander Bokovoy wrote: >>>>> On Tue, 14 Jan 2014, Martin Kosek wrote: >>>>>> On 01/14/2014 01:27 PM, Alexander Bokovoy wrote: >>>>>>> On Tue, 14 Jan 2014, Martin Kosek wrote: >>>>>>>> On 01/14/2014 01:02 PM, Alexander Bokovoy wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> attached patch implements missing idranges when new child domains >>>>>>>>> discovered through 'ipa trust-fetch-domains'. This functionality existed >>>>>>>>> in 'ipa trust-add' but was not exposed in the 'ipa trust-fetch-domains'. >>>>>>>>> >>>>>>>>> Additionally, error message is shown in case trust name is incorrect. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4104 >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4111 >>>>>>>>> >>>>>>>> >>>>>>>> I did not test the patch, just few observations from reading it: >>>>>>> It is generally wrong to base opinion purely on reading the code (see below >>>>>>> why) :) >>>>>> >>>>>> One does not need to run the code that see the places where it may be rusty :) >>>>>> >>>>>>> >>>>>>>> 1) Why are you moving add_range method from trust object to the module? IMO it >>>>>>>> could be left there, it belongs to the object. Plus, the patch won't be that >>>>>>>> big and easier to backport. add_range can be still referred from other commands >>>>>>>> as "self.obj.add_range", no need to move it. >>>>>>> It was in trust_add class, not in the object. I need it in the other >>>>>>> code and without explicit dependency on the object. >>>>>> >>>>>> Ok. Though I would still consider having it rather in the trust object to make >>>>>> it easier accessible from other modules, though our API system. >>>>> I deliberately don't want that. This is internal API for purposes of >>>>> trust code -- do you envision any situation when anyone else might want >>>>> to create idranges programmatically for child domains of the existing >>>>> trust? Note that you are required to know fairly low-level details of >>>>> the AD trusts to call it. >>>>> >>>>>> >>>>>>> >>>>>>>> 2) This part looks *very* suspicious: >>>>>>>> >>>>>>>> - trust = self.api.Command.trust_show(keys[0], raw=True)['result'] >>>>>>>> + try: >>>>>>>> + trust = self.api.Command.trust_show(keys[0], raw=True)['result'] >>>>>>>> + except AssertionError: >>>>>>>> >>>>>>>> I do not think that AssertionError should be raised and caught in normal >>>>>>>> operation, it should be an exceptional exception raised when the world falls >>>>>>>> apart IMO. I.e. I would rather see some PublicError or Exception based >>>>>>>> exception to be raised in trust_show in that case... >>>>>>> It *is* raised and should be caught because this particular snippet is >>>>>>> to catch situation when wrong trust domain name is passed. Previously >>>>>>> the code simply generated server-side exception which resulted in >>>>>>> 'internal error'. >>>>>> >>>>>> Ok, understood. My point is, trust_show should not raise AssertException just >>>>>> because wrong trust domain is passed. There are better means to express that >>>>>> error - ValidationError or NotFound, based on the situation. >>>>> Yes, this is due to the way trust.get_dn() is built. Do not commit this >>>>> patch yet (though building packages for testing would be good), I'm >>>>> reworking it a bit to move this logic to get_dn() -- otherwise >>>>> LDAPRetrieve() will always issue AssertError. >>>> >>>> I guess I already hit this while testing. trust-fetch-domains does not >>>> work for valid forest roots anymore :-) >>>> >>>> Btw, can you add the forest root check to trustdomain-find as well? >>> I've fixed it by returning an exception from get_dn(), as it is expected >>> from other objects' get_dn(). >>> >>> new version attached. >> >> Thanks. I can give functional ACK. All my checks are working as >> expected, idranges are added if needed and 'ipa: ERROR: no such entry' >> is displayed if the forest name is invalid. Btw I think you can add >> https://fedorahosted.org/freeipa/ticket/4095 to the commit message as >> well. >> >> The python code looks good to me as well. >> >> bye, >> Sumit > >I have just few of my usual code purity rants :) > >What is the meaning of this? > >- except errors.NotFound: >- return None >+ except errors.NotFound, e: >+ raise e > >Looks like NOOP to me, except it reraises the exception and thus hides the origin. The full try block looks like this: try: except errors.NotFound, e: raise e else: The key here is that it is get_dn(). errors.NotFound here has special meaning and is intercepted by the framework, never checked by the LDAP* operations (LDAPRetrieve, LDAPSearch, ...). Other exceptions may get produced and they'll get shown in the logs but errors.NotFound from get_dn() will never appear in the stacktrace. The change from 'return None' to re-raising exception is intentional. I could have dropped the whole 'except ...:' stanza too but this is more of being explicit in intent here to make clear we want to drop out exceptionally from get_dn() when entry was not found. Majority of other get_dn() implementations don't touch LDAP entries at this point, that makes logical difference here. -- / Alexander Bokovoy From mkosek at redhat.com Wed Jan 15 14:18:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Jan 2014 15:18:55 +0100 Subject: [Freeipa-devel] [PATCH] 0130 -- create missing idranges in trust-fetch-domains In-Reply-To: <20140115141027.GC12003@redhat.com> References: <20140114120233.GK12003@redhat.com> <52D52B90.5090202@redhat.com> <20140114122738.GM12003@redhat.com> <52D52F11.3090704@redhat.com> <20140114140305.GO12003@redhat.com> <20140114141737.GQ2855@localhost.localdomain> <20140115121408.GY12003@redhat.com> <20140115135410.GA6041@localhost.localdomain> <52D694DC.7010608@redhat.com> <20140115141027.GC12003@redhat.com> Message-ID: <52D698CF.9050302@redhat.com> On 01/15/2014 03:10 PM, Alexander Bokovoy wrote: > On Wed, 15 Jan 2014, Martin Kosek wrote: >> On 01/15/2014 02:54 PM, Sumit Bose wrote: >>> On Wed, Jan 15, 2014 at 02:14:08PM +0200, Alexander Bokovoy wrote: >>>> On Tue, 14 Jan 2014, Sumit Bose wrote: >>>>> On Tue, Jan 14, 2014 at 04:03:06PM +0200, Alexander Bokovoy wrote: >>>>>> On Tue, 14 Jan 2014, Martin Kosek wrote: >>>>>>> On 01/14/2014 01:27 PM, Alexander Bokovoy wrote: >>>>>>>> On Tue, 14 Jan 2014, Martin Kosek wrote: >>>>>>>>> On 01/14/2014 01:02 PM, Alexander Bokovoy wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> attached patch implements missing idranges when new child domains >>>>>>>>>> discovered through 'ipa trust-fetch-domains'. This functionality existed >>>>>>>>>> in 'ipa trust-add' but was not exposed in the 'ipa trust-fetch-domains'. >>>>>>>>>> >>>>>>>>>> Additionally, error message is shown in case trust name is incorrect. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4104 >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4111 >>>>>>>>>> >>>>>>>>> >>>>>>>>> I did not test the patch, just few observations from reading it: >>>>>>>> It is generally wrong to base opinion purely on reading the code (see >>>>>>>> below >>>>>>>> why) :) >>>>>>> >>>>>>> One does not need to run the code that see the places where it may be >>>>>>> rusty :) >>>>>>> >>>>>>>> >>>>>>>>> 1) Why are you moving add_range method from trust object to the >>>>>>>>> module? IMO it >>>>>>>>> could be left there, it belongs to the object. Plus, the patch won't >>>>>>>>> be that >>>>>>>>> big and easier to backport. add_range can be still referred from other >>>>>>>>> commands >>>>>>>>> as "self.obj.add_range", no need to move it. >>>>>>>> It was in trust_add class, not in the object. I need it in the other >>>>>>>> code and without explicit dependency on the object. >>>>>>> >>>>>>> Ok. Though I would still consider having it rather in the trust object >>>>>>> to make >>>>>>> it easier accessible from other modules, though our API system. >>>>>> I deliberately don't want that. This is internal API for purposes of >>>>>> trust code -- do you envision any situation when anyone else might want >>>>>> to create idranges programmatically for child domains of the existing >>>>>> trust? Note that you are required to know fairly low-level details of >>>>>> the AD trusts to call it. >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> 2) This part looks *very* suspicious: >>>>>>>>> >>>>>>>>> - trust = self.api.Command.trust_show(keys[0], raw=True)['result'] >>>>>>>>> + try: >>>>>>>>> + trust = self.api.Command.trust_show(keys[0], >>>>>>>>> raw=True)['result'] >>>>>>>>> + except AssertionError: >>>>>>>>> >>>>>>>>> I do not think that AssertionError should be raised and caught in normal >>>>>>>>> operation, it should be an exceptional exception raised when the world >>>>>>>>> falls >>>>>>>>> apart IMO. I.e. I would rather see some PublicError or Exception based >>>>>>>>> exception to be raised in trust_show in that case... >>>>>>>> It *is* raised and should be caught because this particular snippet is >>>>>>>> to catch situation when wrong trust domain name is passed. Previously >>>>>>>> the code simply generated server-side exception which resulted in >>>>>>>> 'internal error'. >>>>>>> >>>>>>> Ok, understood. My point is, trust_show should not raise AssertException >>>>>>> just >>>>>>> because wrong trust domain is passed. There are better means to express >>>>>>> that >>>>>>> error - ValidationError or NotFound, based on the situation. >>>>>> Yes, this is due to the way trust.get_dn() is built. Do not commit this >>>>>> patch yet (though building packages for testing would be good), I'm >>>>>> reworking it a bit to move this logic to get_dn() -- otherwise >>>>>> LDAPRetrieve() will always issue AssertError. >>>>> >>>>> I guess I already hit this while testing. trust-fetch-domains does not >>>>> work for valid forest roots anymore :-) >>>>> >>>>> Btw, can you add the forest root check to trustdomain-find as well? >>>> I've fixed it by returning an exception from get_dn(), as it is expected >>>> from other objects' get_dn(). >>>> >>>> new version attached. >>> >>> Thanks. I can give functional ACK. All my checks are working as >>> expected, idranges are added if needed and 'ipa: ERROR: no such entry' >>> is displayed if the forest name is invalid. Btw I think you can add >>> https://fedorahosted.org/freeipa/ticket/4095 to the commit message as >>> well. >>> >>> The python code looks good to me as well. >>> >>> bye, >>> Sumit >> >> I have just few of my usual code purity rants :) >> >> What is the meaning of this? >> >> - except errors.NotFound: >> - return None >> + except errors.NotFound, e: >> + raise e >> >> Looks like NOOP to me, except it reraises the exception and thus hides the >> origin. > The full try block looks like this: > > try: > > except errors.NotFound, e: > raise e > else: > > > The key here is that it is get_dn(). errors.NotFound here has special > meaning and is intercepted by the framework, never checked by the LDAP* > operations (LDAPRetrieve, LDAPSearch, ...). Other exceptions may get > produced and they'll get shown in the logs but errors.NotFound from > get_dn() will never appear in the stacktrace. > > The change from 'return None' to re-raising exception is intentional. I > could have dropped the whole 'except ...:' stanza too but this is more of > being explicit in intent here to make clear we want to drop out > exceptionally from get_dn() when entry was not found. Thanks for explanation, but it still does not make sense to me and is IMO a wrong and confusing statement. We also want to drop out in errors.DatabaseError, errors.DatabaseTimeOut, errors.LimitsExceeded and we do not add a special except statement for it. If you really want to add a note about the NotFound case, I would suggest using rather comment which would be less confusing and more informative. Martin From abokovoy at redhat.com Wed Jan 15 14:28:05 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 16:28:05 +0200 Subject: [Freeipa-devel] [PATCH] 0130 -- create missing idranges in trust-fetch-domains In-Reply-To: <52D698CF.9050302@redhat.com> References: <52D52B90.5090202@redhat.com> <20140114122738.GM12003@redhat.com> <52D52F11.3090704@redhat.com> <20140114140305.GO12003@redhat.com> <20140114141737.GQ2855@localhost.localdomain> <20140115121408.GY12003@redhat.com> <20140115135410.GA6041@localhost.localdomain> <52D694DC.7010608@redhat.com> <20140115141027.GC12003@redhat.com> <52D698CF.9050302@redhat.com> Message-ID: <20140115142805.GD12003@redhat.com> On Wed, 15 Jan 2014, Martin Kosek wrote: >On 01/15/2014 03:10 PM, Alexander Bokovoy wrote: >> On Wed, 15 Jan 2014, Martin Kosek wrote: >>> On 01/15/2014 02:54 PM, Sumit Bose wrote: >>>> On Wed, Jan 15, 2014 at 02:14:08PM +0200, Alexander Bokovoy wrote: >>>>> On Tue, 14 Jan 2014, Sumit Bose wrote: >>>>>> On Tue, Jan 14, 2014 at 04:03:06PM +0200, Alexander Bokovoy wrote: >>>>>>> On Tue, 14 Jan 2014, Martin Kosek wrote: >>>>>>>> On 01/14/2014 01:27 PM, Alexander Bokovoy wrote: >>>>>>>>> On Tue, 14 Jan 2014, Martin Kosek wrote: >>>>>>>>>> On 01/14/2014 01:02 PM, Alexander Bokovoy wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> attached patch implements missing idranges when new child domains >>>>>>>>>>> discovered through 'ipa trust-fetch-domains'. This functionality existed >>>>>>>>>>> in 'ipa trust-add' but was not exposed in the 'ipa trust-fetch-domains'. >>>>>>>>>>> >>>>>>>>>>> Additionally, error message is shown in case trust name is incorrect. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4104 >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4111 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I did not test the patch, just few observations from reading it: >>>>>>>>> It is generally wrong to base opinion purely on reading the code (see >>>>>>>>> below >>>>>>>>> why) :) >>>>>>>> >>>>>>>> One does not need to run the code that see the places where it may be >>>>>>>> rusty :) >>>>>>>> >>>>>>>>> >>>>>>>>>> 1) Why are you moving add_range method from trust object to the >>>>>>>>>> module? IMO it >>>>>>>>>> could be left there, it belongs to the object. Plus, the patch won't >>>>>>>>>> be that >>>>>>>>>> big and easier to backport. add_range can be still referred from other >>>>>>>>>> commands >>>>>>>>>> as "self.obj.add_range", no need to move it. >>>>>>>>> It was in trust_add class, not in the object. I need it in the other >>>>>>>>> code and without explicit dependency on the object. >>>>>>>> >>>>>>>> Ok. Though I would still consider having it rather in the trust object >>>>>>>> to make >>>>>>>> it easier accessible from other modules, though our API system. >>>>>>> I deliberately don't want that. This is internal API for purposes of >>>>>>> trust code -- do you envision any situation when anyone else might want >>>>>>> to create idranges programmatically for child domains of the existing >>>>>>> trust? Note that you are required to know fairly low-level details of >>>>>>> the AD trusts to call it. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> 2) This part looks *very* suspicious: >>>>>>>>>> >>>>>>>>>> - trust = self.api.Command.trust_show(keys[0], raw=True)['result'] >>>>>>>>>> + try: >>>>>>>>>> + trust = self.api.Command.trust_show(keys[0], >>>>>>>>>> raw=True)['result'] >>>>>>>>>> + except AssertionError: >>>>>>>>>> >>>>>>>>>> I do not think that AssertionError should be raised and caught in normal >>>>>>>>>> operation, it should be an exceptional exception raised when the world >>>>>>>>>> falls >>>>>>>>>> apart IMO. I.e. I would rather see some PublicError or Exception based >>>>>>>>>> exception to be raised in trust_show in that case... >>>>>>>>> It *is* raised and should be caught because this particular snippet is >>>>>>>>> to catch situation when wrong trust domain name is passed. Previously >>>>>>>>> the code simply generated server-side exception which resulted in >>>>>>>>> 'internal error'. >>>>>>>> >>>>>>>> Ok, understood. My point is, trust_show should not raise AssertException >>>>>>>> just >>>>>>>> because wrong trust domain is passed. There are better means to express >>>>>>>> that >>>>>>>> error - ValidationError or NotFound, based on the situation. >>>>>>> Yes, this is due to the way trust.get_dn() is built. Do not commit this >>>>>>> patch yet (though building packages for testing would be good), I'm >>>>>>> reworking it a bit to move this logic to get_dn() -- otherwise >>>>>>> LDAPRetrieve() will always issue AssertError. >>>>>> >>>>>> I guess I already hit this while testing. trust-fetch-domains does not >>>>>> work for valid forest roots anymore :-) >>>>>> >>>>>> Btw, can you add the forest root check to trustdomain-find as well? >>>>> I've fixed it by returning an exception from get_dn(), as it is expected >>>>> from other objects' get_dn(). >>>>> >>>>> new version attached. >>>> >>>> Thanks. I can give functional ACK. All my checks are working as >>>> expected, idranges are added if needed and 'ipa: ERROR: no such entry' >>>> is displayed if the forest name is invalid. Btw I think you can add >>>> https://fedorahosted.org/freeipa/ticket/4095 to the commit message as >>>> well. >>>> >>>> The python code looks good to me as well. >>>> >>>> bye, >>>> Sumit >>> >>> I have just few of my usual code purity rants :) >>> >>> What is the meaning of this? >>> >>> - except errors.NotFound: >>> - return None >>> + except errors.NotFound, e: >>> + raise e >>> >>> Looks like NOOP to me, except it reraises the exception and thus hides the >>> origin. >> The full try block looks like this: >> >> try: >> >> except errors.NotFound, e: >> raise e >> else: >> >> >> The key here is that it is get_dn(). errors.NotFound here has special >> meaning and is intercepted by the framework, never checked by the LDAP* >> operations (LDAPRetrieve, LDAPSearch, ...). Other exceptions may get >> produced and they'll get shown in the logs but errors.NotFound from >> get_dn() will never appear in the stacktrace. >> >> The change from 'return None' to re-raising exception is intentional. I >> could have dropped the whole 'except ...:' stanza too but this is more of >> being explicit in intent here to make clear we want to drop out >> exceptionally from get_dn() when entry was not found. > >Thanks for explanation, but it still does not make sense to me and is IMO a >wrong and confusing statement. We also want to drop out in >errors.DatabaseError, errors.DatabaseTimeOut, errors.LimitsExceeded and we do >not add a special except statement for it. > >If you really want to add a note about the NotFound case, I would suggest using >rather comment which would be less confusing and more informative. Well, I tried to explain it :) You can drop that bit if you want. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Jan 15 14:43:54 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 16:43:54 +0200 Subject: [Freeipa-devel] [PATCH] 0130 -- create missing idranges in trust-fetch-domains In-Reply-To: <20140115142805.GD12003@redhat.com> References: <20140114122738.GM12003@redhat.com> <52D52F11.3090704@redhat.com> <20140114140305.GO12003@redhat.com> <20140114141737.GQ2855@localhost.localdomain> <20140115121408.GY12003@redhat.com> <20140115135410.GA6041@localhost.localdomain> <52D694DC.7010608@redhat.com> <20140115141027.GC12003@redhat.com> <52D698CF.9050302@redhat.com> <20140115142805.GD12003@redhat.com> Message-ID: <20140115144354.GE12003@redhat.com> On Wed, 15 Jan 2014, Alexander Bokovoy wrote: >>>>>>new version attached. >>>>> >>>>>Thanks. I can give functional ACK. All my checks are working as >>>>>expected, idranges are added if needed and 'ipa: ERROR: no such entry' >>>>>is displayed if the forest name is invalid. Btw I think you can add >>>>>https://fedorahosted.org/freeipa/ticket/4095 to the commit message as >>>>>well. >>>>> >>>>>The python code looks good to me as well. >>>>> >>>>>bye, >>>>>Sumit >>>> >>>>I have just few of my usual code purity rants :) >>>> >>>>What is the meaning of this? >>>> >>>>- except errors.NotFound: >>>>- return None >>>>+ except errors.NotFound, e: >>>>+ raise e >>>> >>>>Looks like NOOP to me, except it reraises the exception and thus hides the >>>>origin. >>>The full try block looks like this: >>> >>> try: >>> >>> except errors.NotFound, e: >>> raise e >>> else: >>> >>> >>>The key here is that it is get_dn(). errors.NotFound here has special >>>meaning and is intercepted by the framework, never checked by the LDAP* >>>operations (LDAPRetrieve, LDAPSearch, ...). Other exceptions may get >>>produced and they'll get shown in the logs but errors.NotFound from >>>get_dn() will never appear in the stacktrace. >>> >>>The change from 'return None' to re-raising exception is intentional. I >>>could have dropped the whole 'except ...:' stanza too but this is more of >>>being explicit in intent here to make clear we want to drop out >>>exceptionally from get_dn() when entry was not found. >> >>Thanks for explanation, but it still does not make sense to me and is IMO a >>wrong and confusing statement. We also want to drop out in >>errors.DatabaseError, errors.DatabaseTimeOut, errors.LimitsExceeded and we do >>not add a special except statement for it. >> >>If you really want to add a note about the NotFound case, I would suggest using >>rather comment which would be less confusing and more informative. >Well, I tried to explain it :) > >You can drop that bit if you want. Since it required removal of the whole try block, I've made new version. -- / Alexander Bokovoy -------------- next part -------------- >From ffce3308c0a7038be533b60af8ce43c5005994ca Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 14 Jan 2014 13:55:56 +0200 Subject: [PATCH 1/3] trust-fetch-domains: create ranges for new child domains When trust is added, we do create ranges for discovered child domains. However, this functionality was not available through 'trust-fetch-domains' command. Additionally, make sure non-existing trust will report proper error in trust-fetch-domains. https://fedorahosted.org/freeipa/ticket/4111 https://fedorahosted.org/freeipa/ticket/4104 --- ipalib/plugins/trust.py | 256 +++++++++++++++++++++++++----------------------- 1 file changed, 135 insertions(+), 121 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 76d609f..a16c230 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -188,6 +188,114 @@ def make_trust_dn(env, trust_type, dn): return DN(dn, container_dn) return dn +def add_range(self, range_name, dom_sid, *keys, **options): + """ + First, we try to derive the parameters of the ID range based on the + information contained in the Active Directory. + + If that was not successful, we go for our usual defaults (random base, + range size 200 000, ipa-ad-trust range type). + + Any of these can be overriden by passing appropriate CLI options + to the trust-add command. + """ + + range_size = None + range_type = None + base_id = None + + # First, get information about ID space from AD + # However, we skip this step if other than ipa-ad-trust-posix + # range type is enforced + + if options.get('range_type', None) in (None, u'ipa-ad-trust-posix'): + + # Get the base dn + domain = keys[-1] + basedn = realm_to_suffix(domain) + + # Search for information contained in + # CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System + info_filter = '(objectClass=msSFU30DomainInfo)' + info_dn = DN('CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System')\ + + basedn + + # Get the domain validator + domain_validator = ipaserver.dcerpc.DomainValidator(self.api) + if not domain_validator.is_configured(): + raise errors.NotFound( + reason=_('Cannot search in trusted domains without own ' + 'domain configured. Make sure you have run ' + 'ipa-adtrust-install on the IPA server first')) + + # KDC might not get refreshed data at the first time, + # retry several times + for retry in range(10): + info_list = domain_validator.search_in_dc(domain, + info_filter, + None, + SCOPE_SUBTREE, + basedn=info_dn, + quiet=True) + + if info_list: + info = info_list[0] + break + else: + sleep(2) + + required_msSFU_attrs = ['msSFU30MaxUidNumber', 'msSFU30OrderNumber'] + + if not info_list: + # We were unable to gain UNIX specific info from the AD + self.log.debug("Unable to gain POSIX info from the AD") + else: + if all(attr in info for attr in required_msSFU_attrs): + self.log.debug("Able to gain POSIX info from the AD") + range_type = u'ipa-ad-trust-posix' + + max_uid = info.get('msSFU30MaxUidNumber') + max_gid = info.get('msSFU30MaxGidNumber', None) + max_id = int(max(max_uid, max_gid)[0]) + + base_id = int(info.get('msSFU30OrderNumber')[0]) + range_size = (1 + (max_id - base_id) / DEFAULT_RANGE_SIZE)\ + * DEFAULT_RANGE_SIZE + + # Second, options given via the CLI options take precedence to discovery + if options.get('range_type', None): + range_type = options.get('range_type', None) + elif not range_type: + range_type = u'ipa-ad-trust' + + if options.get('range_size', None): + range_size = options.get('range_size', None) + elif not range_size: + range_size = DEFAULT_RANGE_SIZE + + if options.get('base_id', None): + base_id = options.get('base_id', None) + elif not base_id: + # Generate random base_id if not discovered nor given via CLI + base_id = DEFAULT_RANGE_SIZE + ( + pysss_murmur.murmurhash3( + dom_sid, + len(dom_sid), 0xdeadbeefL + ) % 10000 + ) * DEFAULT_RANGE_SIZE + + # Finally, add new ID range + self.api.Command['idrange_add'](range_name, + ipabaseid=base_id, + ipaidrangesize=range_size, + ipabaserid=0, + iparangetype=range_type, + ipanttrusteddomainsid=dom_sid) + + # Return the values that were generated inside this function + return range_type, range_size, base_id + + class trust(LDAPObject): """ Trust object. @@ -258,15 +366,11 @@ class trust(LDAPObject): filter = ldap.make_filter({'objectclass': ['ipaNTTrustedDomain'], 'cn': [keys[-1]] }, rules=ldap.MATCH_ALL) filter = ldap.combine_filters((filter, "ipaNTSIDBlacklistIncoming=*"), rules=ldap.MATCH_ALL) - try: - result = ldap.get_entries(DN(self.container_dn, self.env.basedn), - ldap.SCOPE_SUBTREE, filter, ['']) - except errors.NotFound: - return None - else: - if len(result) > 1: - raise errors.OnlyOneValueAllowed(attr='trust domain') - return result[0].dn + result = ldap.get_entries(DN(self.container_dn, self.env.basedn), + ldap.SCOPE_SUBTREE, filter, ['']) + if len(result) > 1: + raise errors.OnlyOneValueAllowed(attr='trust domain') + return result[0].dn dn=make_trust_dn(self.env, trust_type, DN(*sdn)) return dn @@ -341,8 +445,8 @@ sides. # Store the created range type, since for POSIX trusts no # ranges for the subdomains should be added, POSIX attributes # provide a global mapping across all subdomains - (created_range_type, _, _) = self.add_range(range_name, dom_sid, - *keys, **options) + (created_range_type, _, _) = add_range(self, range_name, dom_sid, + *keys, **options) else: created_range_type = old_range['result']['iparangetype'][0] @@ -382,8 +486,8 @@ sides. # Try to add the range for each subdomain try: - self.add_range(range_name, dom_sid, *keys, - **passed_options) + add_range(self, range_name, dom_sid, *keys, + **passed_options) except errors.DuplicateEntry: pass @@ -549,120 +653,17 @@ sides. return old_range, range_name, dom_sid - def add_range(self, range_name, dom_sid, *keys, **options): - """ - First, we try to derive the parameters of the ID range based on the - information contained in the Active Directory. - - If that was not successful, we go for our usual defaults (random base, - range size 200 000, ipa-ad-trust range type). - - Any of these can be overriden by passing appropriate CLI options - to the trust-add command. - """ - - range_size = None - range_type = None - base_id = None - - # First, get information about ID space from AD - # However, we skip this step if other than ipa-ad-trust-posix - # range type is enforced - - if options.get('range_type', None) in (None, u'ipa-ad-trust-posix'): - - # Get the base dn - domain = keys[-1] - basedn = realm_to_suffix(domain) - - # Search for information contained in - # CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System - info_filter = '(objectClass=msSFU30DomainInfo)' - info_dn = DN('CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System')\ - + basedn - - # Get the domain validator - domain_validator = ipaserver.dcerpc.DomainValidator(self.api) - if not domain_validator.is_configured(): - raise errors.NotFound( - reason=_('Cannot search in trusted domains without own ' - 'domain configured. Make sure you have run ' - 'ipa-adtrust-install on the IPA server first')) - - # KDC might not get refreshed data at the first time, - # retry several times - for retry in range(10): - info_list = domain_validator.search_in_dc(domain, - info_filter, - None, - SCOPE_SUBTREE, - basedn=info_dn, - quiet=True) - - if info_list: - info = info_list[0] - break - else: - sleep(2) - - required_msSFU_attrs = ['msSFU30MaxUidNumber', 'msSFU30OrderNumber'] - - if not info_list: - # We were unable to gain UNIX specific info from the AD - self.log.debug("Unable to gain POSIX info from the AD") - else: - if all(attr in info for attr in required_msSFU_attrs): - self.log.debug("Able to gain POSIX info from the AD") - range_type = u'ipa-ad-trust-posix' - - max_uid = info.get('msSFU30MaxUidNumber') - max_gid = info.get('msSFU30MaxGidNumber', None) - max_id = int(max(max_uid, max_gid)[0]) - - base_id = int(info.get('msSFU30OrderNumber')[0]) - range_size = (1 + (max_id - base_id) / DEFAULT_RANGE_SIZE)\ - * DEFAULT_RANGE_SIZE - - # Second, options given via the CLI options take precedence to discovery - if options.get('range_type', None): - range_type = options.get('range_type', None) - elif not range_type: - range_type = u'ipa-ad-trust' - - if options.get('range_size', None): - range_size = options.get('range_size', None) - elif not range_size: - range_size = DEFAULT_RANGE_SIZE - - if options.get('base_id', None): - base_id = options.get('base_id', None) - elif not base_id: - # Generate random base_id if not discovered nor given via CLI - base_id = DEFAULT_RANGE_SIZE + ( - pysss_murmur.murmurhash3( - dom_sid, - len(dom_sid), 0xdeadbeefL - ) % 10000 - ) * DEFAULT_RANGE_SIZE - - # Finally, add new ID range - api.Command['idrange_add'](range_name, - ipabaseid=base_id, - ipaidrangesize=range_size, - ipabaserid=0, - iparangetype=range_type, - ipanttrusteddomainsid=dom_sid) - - # Return the values that were generated inside this function - return range_type, range_size, base_id - def execute_ad(self, full_join, *keys, **options): # Join domain using full credentials and with random trustdom # secret (will be generated by the join method) # First see if the trust is already in place # Force retrieval of the trust object by not passing trust_type - dn = self.obj.get_dn(keys[-1]) + try: + dn = self.obj.get_dn(keys[-1]) + except errors.NotFound: + dn = None + if dn: summary = _('Re-established trust to domain "%(value)s"') else: @@ -794,6 +795,7 @@ class trust_show(LDAPRetrieve): def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) # Translate ipanttrusttype to trusttype # and ipanttrustdirection to trustdirection # if --raw not used @@ -1246,6 +1248,11 @@ def fetch_domains_from_trust(self, trustinstance, trust_entry, **options): if not domains: return result + # trust range must exist by the time fetch_domains_from_trust is called + range_name = trust_name.upper() + '_id_range' + old_range = api.Command.idrange_show(range_name, raw=True)['result'] + idrange_type = old_range['iparangetype'] + for dom in domains: dom['trust_type'] = u'ad' try: @@ -1255,8 +1262,15 @@ def fetch_domains_from_trust(self, trustinstance, trust_entry, **options): dom['all'] = options['all'] if 'raw' in options: dom['raw'] = options['raw'] + res = self.api.Command.trustdomain_add(trust_name, name, **dom) result.append(res['result']) + + if idrange_type != u'ipa-ad-trust-posix': + range_name = name.upper() + '_id_range' + dom['range_type'] = u'ipa-ad-trust' + add_range(self, range_name, dom['ipanttrusteddomainsid'], + trust_name, name, **dom) except errors.DuplicateEntry: # Ignore updating duplicate entries pass -- 1.8.4.2 From mkosek at redhat.com Wed Jan 15 14:46:27 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Jan 2014 15:46:27 +0100 Subject: [Freeipa-devel] [PATCH] 0130 -- create missing idranges in trust-fetch-domains In-Reply-To: <20140115144354.GE12003@redhat.com> References: <20140114122738.GM12003@redhat.com> <52D52F11.3090704@redhat.com> <20140114140305.GO12003@redhat.com> <20140114141737.GQ2855@localhost.localdomain> <20140115121408.GY12003@redhat.com> <20140115135410.GA6041@localhost.localdomain> <52D694DC.7010608@redhat.com> <20140115141027.GC12003@redhat.com> <52D698CF.9050302@redhat.com> <20140115142805.GD12003@redhat.com> <20140115144354.GE12003@redhat.com> Message-ID: <52D69F43.6030903@redhat.com> On 01/15/2014 03:43 PM, Alexander Bokovoy wrote: > On Wed, 15 Jan 2014, Alexander Bokovoy wrote: >>>>>>> new version attached. >>>>>> >>>>>> Thanks. I can give functional ACK. All my checks are working as >>>>>> expected, idranges are added if needed and 'ipa: ERROR: no such entry' >>>>>> is displayed if the forest name is invalid. Btw I think you can add >>>>>> https://fedorahosted.org/freeipa/ticket/4095 to the commit message as >>>>>> well. >>>>>> >>>>>> The python code looks good to me as well. >>>>>> >>>>>> bye, >>>>>> Sumit >>>>> >>>>> I have just few of my usual code purity rants :) >>>>> >>>>> What is the meaning of this? >>>>> >>>>> - except errors.NotFound: >>>>> - return None >>>>> + except errors.NotFound, e: >>>>> + raise e >>>>> >>>>> Looks like NOOP to me, except it reraises the exception and thus hides the >>>>> origin. >>>> The full try block looks like this: >>>> >>>> try: >>>> >>>> except errors.NotFound, e: >>>> raise e >>>> else: >>>> >>>> >>>> The key here is that it is get_dn(). errors.NotFound here has special >>>> meaning and is intercepted by the framework, never checked by the LDAP* >>>> operations (LDAPRetrieve, LDAPSearch, ...). Other exceptions may get >>>> produced and they'll get shown in the logs but errors.NotFound from >>>> get_dn() will never appear in the stacktrace. >>>> >>>> The change from 'return None' to re-raising exception is intentional. I >>>> could have dropped the whole 'except ...:' stanza too but this is more of >>>> being explicit in intent here to make clear we want to drop out >>>> exceptionally from get_dn() when entry was not found. >>> >>> Thanks for explanation, but it still does not make sense to me and is IMO a >>> wrong and confusing statement. We also want to drop out in >>> errors.DatabaseError, errors.DatabaseTimeOut, errors.LimitsExceeded and we do >>> not add a special except statement for it. >>> >>> If you really want to add a note about the NotFound case, I would suggest using >>> rather comment which would be less confusing and more informative. >> Well, I tried to explain it :) >> >> You can drop that bit if you want. > Since it required removal of the whole try block, I've made new version. > I already did it on my own few second ago :) So updated and pushed to master, ipa-3-3. Martin From sbose at redhat.com Wed Jan 15 15:00:14 2014 From: sbose at redhat.com (Sumit Bose) Date: Wed, 15 Jan 2014 16:00:14 +0100 Subject: [Freeipa-devel] [PATCH] 0132 Show status of the trusted domain in trustdomain-find In-Reply-To: <20140115134757.GB12003@redhat.com> References: <20140115134757.GB12003@redhat.com> Message-ID: <20140115150014.GB6041@localhost.localdomain> On Wed, Jan 15, 2014 at 03:47:57PM +0200, Alexander Bokovoy wrote: > Hi! > > This patch implements showing whether domains associated with the trust > enabled or disabled. One can enable/disable child domains through > trustdomain-enable/trustdomain-disable. Forest root domain will always > be enabled. > > Implements https://fedorahosted.org/freeipa/ticket/4096 ACK for working as expected. Python code looks good to my layman's eyes as well. bye, Sumit > > -- > / Alexander Bokovoy From mkosek at redhat.com Wed Jan 15 15:19:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Jan 2014 16:19:50 +0100 Subject: [Freeipa-devel] [PATCH] 0132 Show status of the trusted domain in trustdomain-find In-Reply-To: <20140115150014.GB6041@localhost.localdomain> References: <20140115134757.GB12003@redhat.com> <20140115150014.GB6041@localhost.localdomain> Message-ID: <52D6A716.8060200@redhat.com> On 01/15/2014 04:00 PM, Sumit Bose wrote: > On Wed, Jan 15, 2014 at 03:47:57PM +0200, Alexander Bokovoy wrote: >> Hi! >> >> This patch implements showing whether domains associated with the trust >> enabled or disabled. One can enable/disable child domains through >> trustdomain-enable/trustdomain-disable. Forest root domain will always >> be enabled. >> >> Implements https://fedorahosted.org/freeipa/ticket/4096 > > ACK for working as expected. Python code looks good to my layman's eyes > as well. > > bye, > Sumit Looks good to my nitpicky eyes as well. Pushed to master, ipa-3-3. Martin From mkosek at redhat.com Wed Jan 15 15:28:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Jan 2014 16:28:03 +0100 Subject: [Freeipa-devel] [PATCH 125] CLDAP: do not prepend \\ In-Reply-To: <20140114130958.GN12003@redhat.com> References: <20140113120002.GM2855@localhost.localdomain> <20140114130958.GN12003@redhat.com> Message-ID: <52D6A903.40100@redhat.com> On 01/14/2014 02:09 PM, Alexander Bokovoy wrote: > On Mon, 13 Jan 2014, Sumit Bose wrote: >> Hi, >> >> Scott found that the fix for >> https://fedorahosted.org/freeipa/ticket/4028 is not complete. After some >> checks and comparisons with samba and AD behaviour I came to the >> conclusion that the two \\ at the beginning of the NetBIOS name of the >> IPA server is not needed in the response of NETLOGON_NT_VERSION_5EX >> requests which is the only type we handle so far. >> >> In general AD seems to be smart enough the handle the \\ even in those >> responses but if the NetBIOS name has 15 characters the response is not >> accepted anymore. >> >> Please check if you can see any regressions with this change. >> >> During testing I came across two things related to samba. >> While looking at network trace Scott recorded it looked like Samba does >> not cut a long hostname for the NetBIOS name. This might be in agreement >> to what Metze recently posted in his master4-schannel-ok branch for >> netlogon_creds_cli_context_global(). As usual Metze is smarter than us >> and tried to minimize the chance for name collisions with the help of >> Jenkins hash. I just wonder why he treats the NetBIOS name only here >> this way and not generally? With respect to IPA we might want to >> consider to set 'netbios name' in the samba config explicitly to avoid >> disconnects? > Yes, we may do that in ipa-adtrust-install. > > >> While testing against AD with other request types I've seen that in some >> cases the NetBIOS name was returned with the two additional \ in the >> beginning, even if the AD NetBIOS name already had 15 characters. >> Strange the name was even encoded in UCS-2 in this case. Unfortunately I >> was not able to find good documentation on the specifics of those >> packages. If you know some good docs please send me the link otherwise >> we might what to ask MSFT for clarification. > According to MS-ADTS, NetbiosComputerName field is > --------------------------------------------------------------------- > UTF-8 encoded value of the NetBIOS name of the server, compressed as > specified in [RFC1035] section 4.1.4. To get the decompressed string, > see section 6.3.7. > --------------------------------------------------------------------- > > According to MS-NBTE (2.2.1), > ---------------------------------------------------------------------- > This document clarifies the ambiguity by specifying that the name space > is defined as sixteen 8-bit binary bytes, with no restrictions, except > that the name SHOULD NOT<2><3> start with an asterisk (*). > ---------------------------------------------------------------------- > > Cases when \\ and UCS-2 encoding are used seem to be remnants of the > older implementations. I think they should be ignored at best. > >> From 0b782064945352ad488e92b457bbfda2270ddf66 Mon Sep 17 00:00:00 2001 >> From: Sumit Bose >> Date: Mon, 13 Jan 2014 10:43:33 +0100 >> Subject: [PATCH] CLDAP: do not prepend \\ >> >> For NETLOGON_NT_VERSION_5EX requests the prepended \\ is not expected in >> the PDC NetBIOS name. In general AD seems to be smart enough to handle >> the two \ signs. But if the NetBIOS name reaches the maximum of 15 >> character AD does not accept the responses anymore. >> >> Fixes https://fedorahosted.org/freeipa/ticket/4028 >> --- >> daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >> b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >> index >> 9ba05829418a0d1de46f2c7776cc15c54a9eab1c..c03172d474589ddee84f1cfa5395c23fdba83bcb >> 100644 >> --- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >> +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >> @@ -163,7 +163,7 @@ static int ipa_cldap_encode_netlogon(char *fq_hostname, >> char *domain, >> nlr->domain_name = name; >> >> /* copy the first 15 characters of the fully qualified hostname*/ >> - pdc_name = talloc_asprintf(nlr, "\\\\%.*s", NETBIOS_NAME_MAX, fq_hostname); >> + pdc_name = talloc_asprintf(nlr, "%.*s", NETBIOS_NAME_MAX, fq_hostname); >> >> for (p = pdc_name; *p; p++) { >> /* Create the NetBIOS name from the first segment of the hostname */ > ACK. > Pushed to master, ipa-3-3. Martin From rcritten at redhat.com Wed Jan 15 16:11:17 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 15 Jan 2014 11:11:17 -0500 Subject: [Freeipa-devel] Why is RPM posttrans quiet? In-Reply-To: <20140115101327.GB20514@redhat.com> References: <52D650C9.9020005@redhat.com> <20140115101327.GB20514@redhat.com> Message-ID: <52D6B325.9020608@redhat.com> Jan Pazdziora wrote: > On Wed, Jan 15, 2014 at 10:11:37AM +0100, Petr Spacek wrote: >> Hello list, >> >> I just found that freeipa.spec silences all messages from %posttrans >> scripts, which makes me a bit nervous: >> >> %posttrans server >> # This must be run in posttrans so that updates from previous >> # execution that may no longer be shipped are not applied. >> /usr/sbin/ipa-ldap-updater --upgrade --quiet >/dev/null || : >> /usr/sbin/ipa-upgradeconfig --quiet >/dev/null || : >> >> # Restart IPA processes. This must be also run in postrans so that plugins >> # and software is in consistent state >> python -c "import sys; from ipaserver.install import installutils; >> sys.exit(0 if installutils.is_ipa_configured() else 1);" > /dev/null >> 2>&1 >> # NOTE: systemd specific section >> if [ $? -eq 0 ]; then >> /bin/systemctl try-restart ipa.service >/dev/null 2>&1 || : >> fi >> # END >> >> >> I can't find such requirement in >> https://fedoraproject.org/wiki/Packaging:Guidelines >> >> Is there any particular reason for that? >> >> Does anybody have objections against removing redirection to >> /dev/null? (With appropriate handling for non-existent binaries, of >> course.) > > It reminds me of > > https://bugzilla.redhat.com/show_bug.cgi?id=606239 > https://bugzilla.redhat.com/show_bug.cgi?id=615763 > > The problem is, you will not see that output when using yum in > RHEL 6 anyway. And maybe in the past it even killed something? > > The examples in > > https://fedoraproject.org/wiki/Packaging:ScriptletSnippets > > all have the redirect but no explanation why. > > Maybe poking relevant Fedora people could yield some definitive > answer? > I don't know about any packaging requirements but we got a fair bit of push back whenever we include output in rpm in bugs like https://bugzilla.redhat.com/show_bug.cgi?id=538859 That isn't exactly definitive though, as Jan points out asking the Fedora packaging folks is probably the way to go. rob From jcholast at redhat.com Wed Jan 15 16:30:36 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 15 Jan 2014 17:30:36 +0100 Subject: [Freeipa-devel] [PATCH] 232 Increase service startup timeout default In-Reply-To: <20140115125558.GA12003@redhat.com> References: <52D64D68.9090206@redhat.com> <20140115102051.GW12003@redhat.com> <52D66E3C.60007@redhat.com> <52D6745D.4060008@redhat.com> <20140115122144.GZ12003@redhat.com> <52D68465.3030303@redhat.com> <20140115125558.GA12003@redhat.com> Message-ID: <52D6B7AC.9070907@redhat.com> On 15.1.2014 13:55, Alexander Bokovoy wrote: > On Wed, 15 Jan 2014, Jan Cholasta wrote: >> On 15.1.2014 13:21, Alexander Bokovoy wrote: >>> On Wed, 15 Jan 2014, Jan Cholasta wrote: >>>> On 15.1.2014 12:17, Martin Kosek wrote: >>>>> On 01/15/2014 11:20 AM, Alexander Bokovoy wrote: >>>>>> On Wed, 15 Jan 2014, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> the attached patch should fix >>>>>>> . >>>>>>> >>>>>>> I have also attached patch 179, which fixes a related bug in >>>>>>> certificate >>>>>>> renewal. >>>>>> >>>>>> NACK for this part: >>>>>>> This fixes a possible NSS database corruption in renew_ca_cert. >>>>>>> --- >>>>>>> ipaserver/install/installutils.py | 3 --- >>>>>>> 1 file changed, 3 deletions(-) >>>>>>> >>>>>>> diff --git a/ipaserver/install/installutils.py >>>>>>> b/ipaserver/install/installutils.py >>>>>>> index 67eabc2..0ba9c2e 100644 >>>>>>> --- a/ipaserver/install/installutils.py >>>>>>> +++ b/ipaserver/install/installutils.py >>>>>>> @@ -820,9 +820,6 @@ def stopped_service(service, instance_name=""): >>>>>>> root_logger.debug('Service %s%s is not running, continue.', >>>>>>> service, >>>>>>> log_instance_name) >>>>>>> yield >>>>>>> - root_logger.debug('Starting %s%s.', service, >>>>>>> log_instance_name) >>>>>>> - ipaservices.knownservices[service].start(instance_name) >>>>>>> - return >>>>>>> else: >>>>>>> # Stop the service, do the required stuff and start it again >>>>>>> root_logger.debug('Stopping %s%s.', service, >>>>>>> log_instance_name) >>>>>> You need to wrap yield into try: finally: block. I have a patch for >>>>>> similar case in private_cache() few lines above this code. >>>> >>>> There is no cleanup needed for this particular yield. Also this is not >>>> really the concern of the patch, it does exactly what the commit >>>> message says. Since you are already fixing a similar case, I would >>>> suggest you amend your patch with any changes you deem necessary, I >>>> don't see why a single fix should be dispersed among multiple patches. >>> Patch attached, it obsoletes your patch 179. >> >> Thanks, but I don't understand why you squashed my patch 179 into your >> patch, the fixes are for separate issues (yield exception handling vs. >> previously stopped service being started). > Because you just said above: >>>> suggest you amend your patch with any changes you deem necessary, I >>>> don't see why a single fix should be dispersed among multiple patches. > "a single fix" is now not dispersed among multiple patches. Well, now it's multiple fixes in a single patch. What I meant to end up with is single fix per single patch (see attachment). -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-179-Do-not-start-the-service-in-stopped_service-if-it-wa.patch Type: text/x-patch Size: 1115 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-abbra-0131-ipaserver-install-installutils-clean-up-properly-aft-1.patch Type: text/x-patch Size: 1900 bytes Desc: not available URL: From abokovoy at redhat.com Wed Jan 15 16:31:54 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 18:31:54 +0200 Subject: [Freeipa-devel] [PATCH] 0133 Use standard_list_of_entries for trust-resolve Message-ID: <20140115163154.GF12003@redhat.com> Hi! When looking into https://fedorahosted.org/freeipa/ticket/4113, I decided to use output.standard_list_of_entries instead of a locally defined list of entries. This solves the problem with wrong exit code in CLI when non-resolvable SID is given, but only for a single SID. If multiple SID specified and some of them were not resolved, the exit code will still be 0 (success) but truncated flag will be set. This corresponds to the framework behavior in other cases. -- / Alexander Bokovoy -------------- next part -------------- >From 56b19598170ce9468be3a91b3e9942eba5e4bd89 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 15 Jan 2014 17:51:25 +0200 Subject: [PATCH 2/2] trust-resolve: improve output by using standard_list_of_entries Use output.standard_list_of_entries instead of own output format gives benefit of returning proper process exit code in CLI. https://fedorahosted.org/freeipa/ticket/4113 --- ipalib/plugins/trust.py | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 3d412c9..3809f8b 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -992,14 +992,13 @@ class trust_resolve(Command): Str('sid', label= _('SID')), ) - has_output = ( - output.ListOfEntries('result'), - ) + has_output = output.standard_list_of_entries + msg_summary = _('Resolved %(count)d security identifiers') def execute(self, *keys, **options): result = list() if not _nss_idmap_installed: - return dict(result=result) + return dict(result=result, count=0, truncated=True) try: sids = map(lambda x: str(x), options['sids']) xlate = pysss_nss_idmap.getnamebysid(sids) @@ -1012,7 +1011,10 @@ class trust_resolve(Command): except ValueError, e: pass - return dict(result=result) + len_sids = len(options['sids']) + len_result = len(result) + truncated = len_sids != len_result + return dict(result=result, count=len_result, truncated=truncated) api.register(trust_resolve) -- 1.8.4.2 From abokovoy at redhat.com Wed Jan 15 16:38:35 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 18:38:35 +0200 Subject: [Freeipa-devel] [PATCH] 232 Increase service startup timeout default In-Reply-To: <52D6B7AC.9070907@redhat.com> References: <52D64D68.9090206@redhat.com> <20140115102051.GW12003@redhat.com> <52D66E3C.60007@redhat.com> <52D6745D.4060008@redhat.com> <20140115122144.GZ12003@redhat.com> <52D68465.3030303@redhat.com> <20140115125558.GA12003@redhat.com> <52D6B7AC.9070907@redhat.com> Message-ID: <20140115163835.GG12003@redhat.com> On Wed, 15 Jan 2014, Jan Cholasta wrote: >>>>>don't see why a single fix should be dispersed among multiple patches. >>>>Patch attached, it obsoletes your patch 179. >>> >>>Thanks, but I don't understand why you squashed my patch 179 into your >>>patch, the fixes are for separate issues (yield exception handling vs. >>>previously stopped service being started). >>Because you just said above: >>>>>suggest you amend your patch with any changes you deem necessary, I >>>>>don't see why a single fix should be dispersed among multiple patches. >>"a single fix" is now not dispersed among multiple patches. > >Well, now it's multiple fixes in a single patch. What I meant to end >up with is single fix per single patch (see attachment). Now it is clearer. :) ACK to these patches. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Jan 15 17:24:00 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 19:24:00 +0200 Subject: [Freeipa-devel] [PATCH] 0133 Use standard_list_of_entries for trust-resolve In-Reply-To: <20140115163154.GF12003@redhat.com> References: <20140115163154.GF12003@redhat.com> Message-ID: <20140115172400.GH12003@redhat.com> On Wed, 15 Jan 2014, Alexander Bokovoy wrote: > Hi! > > When looking into https://fedorahosted.org/freeipa/ticket/4113, I > decided to use output.standard_list_of_entries instead of a locally > defined list of entries. This solves the problem with wrong exit code in > CLI when non-resolvable SID is given, but only for a single SID. If > multiple SID specified and some of them were not resolved, the exit code > will still be 0 (success) but truncated flag will be set. This > corresponds to the framework behavior in other cases. Thanks to Sumit, here is updated patch because I forgot to run makeapi ;( :) -- / Alexander Bokovoy -------------- next part -------------- >From 972afcc0a23f067249c505824377581c28812733 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 15 Jan 2014 17:51:25 +0200 Subject: [PATCH 2/2] trust-resolve: improve output by using standard_list_of_entries Use output.standard_list_of_entries instead of own output format gives benefit of returning proper process exit code in CLI. https://fedorahosted.org/freeipa/ticket/4113 --- API.txt | 5 ++++- ipalib/plugins/trust.py | 12 +++++++----- 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/API.txt b/API.txt index a6c3aed..fc5cbc6 100644 --- a/API.txt +++ b/API.txt @@ -3666,12 +3666,15 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: Output('value', , None) command: trust_resolve -args: 0,4,1 +args: 0,4,4 option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('sids+', csv=True) option: Str('version?', exclude='webui') +output: Output('count', , None) output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) command: trust_show args: 1,4,3 arg: Str('cn', attribute=True, cli_name='realm', multivalue=False, primary_key=True, query=True, required=True) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 3d412c9..3809f8b 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -992,14 +992,13 @@ class trust_resolve(Command): Str('sid', label= _('SID')), ) - has_output = ( - output.ListOfEntries('result'), - ) + has_output = output.standard_list_of_entries + msg_summary = _('Resolved %(count)d security identifiers') def execute(self, *keys, **options): result = list() if not _nss_idmap_installed: - return dict(result=result) + return dict(result=result, count=0, truncated=True) try: sids = map(lambda x: str(x), options['sids']) xlate = pysss_nss_idmap.getnamebysid(sids) @@ -1012,7 +1011,10 @@ class trust_resolve(Command): except ValueError, e: pass - return dict(result=result) + len_sids = len(options['sids']) + len_result = len(result) + truncated = len_sids != len_result + return dict(result=result, count=len_result, truncated=truncated) api.register(trust_resolve) -- 1.8.4.2 From sbose at redhat.com Wed Jan 15 17:33:22 2014 From: sbose at redhat.com (Sumit Bose) Date: Wed, 15 Jan 2014 18:33:22 +0100 Subject: [Freeipa-devel] [PATCH] 0133 Use standard_list_of_entries for trust-resolve In-Reply-To: <20140115172400.GH12003@redhat.com> References: <20140115163154.GF12003@redhat.com> <20140115172400.GH12003@redhat.com> Message-ID: <20140115173322.GC14122@localhost.localdomain> On Wed, Jan 15, 2014 at 07:24:00PM +0200, Alexander Bokovoy wrote: > On Wed, 15 Jan 2014, Alexander Bokovoy wrote: > >Hi! > > > >When looking into https://fedorahosted.org/freeipa/ticket/4113, I > >decided to use output.standard_list_of_entries instead of a locally > >defined list of entries. This solves the problem with wrong exit code in > >CLI when non-resolvable SID is given, but only for a single SID. If > >multiple SID specified and some of them were not resolved, the exit code > >will still be 0 (success) but truncated flag will be set. This > >corresponds to the framework behavior in other cases. > Thanks to Sumit, here is updated patch because I forgot to run makeapi > ;( > > :) Currently I see: [sbose at ipa18-devel freeipa]$ ipa trust-resolve --sids sdfasdf ------------------------------- Resolved 0 security identifiers ------------------------------- ---------------------------- Number of entries returned 0 ---------------------------- [sbose at ipa18-devel freeipa]$ echo $? 1 Would it be possible to return only one of the summaries to the user? Otherwise the patch works as expected and the output is better than the empty one before. bye, Sumit > > -- > / Alexander Bokovoy From abokovoy at redhat.com Wed Jan 15 18:00:57 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 20:00:57 +0200 Subject: [Freeipa-devel] [PATCH] 0133 Use standard_list_of_entries for trust-resolve In-Reply-To: <20140115173322.GC14122@localhost.localdomain> References: <20140115163154.GF12003@redhat.com> <20140115172400.GH12003@redhat.com> <20140115173322.GC14122@localhost.localdomain> Message-ID: <20140115180057.GA25995@redhat.com> On Wed, 15 Jan 2014, Sumit Bose wrote: >On Wed, Jan 15, 2014 at 07:24:00PM +0200, Alexander Bokovoy wrote: >> On Wed, 15 Jan 2014, Alexander Bokovoy wrote: >> >Hi! >> > >> >When looking into https://fedorahosted.org/freeipa/ticket/4113, I >> >decided to use output.standard_list_of_entries instead of a locally >> >defined list of entries. This solves the problem with wrong exit code in >> >CLI when non-resolvable SID is given, but only for a single SID. If >> >multiple SID specified and some of them were not resolved, the exit code >> >will still be 0 (success) but truncated flag will be set. This >> >corresponds to the framework behavior in other cases. >> Thanks to Sumit, here is updated patch because I forgot to run makeapi >> ;( >> >> :) > >Currently I see: > >[sbose at ipa18-devel freeipa]$ ipa trust-resolve --sids sdfasdf >------------------------------- >Resolved 0 security identifiers >------------------------------- >---------------------------- >Number of entries returned 0 >---------------------------- >[sbose at ipa18-devel freeipa]$ echo $? >1 > >Would it be possible to return only one of the summaries to the user? >Otherwise the patch works as expected and the output is better than the >empty one before. May be invert summary and tell how many security identifiers were not resolved? -- / Alexander Bokovoy From mkosek at redhat.com Wed Jan 15 20:01:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Jan 2014 15:01:49 -0500 (EST) Subject: [Freeipa-devel] [PATCH] 0133 Use standard_list_of_entries for trust-resolve In-Reply-To: <20140115180057.GA25995@redhat.com> References: <20140115163154.GF12003@redhat.com> <20140115172400.GH12003@redhat.com> <20140115173322.GC14122@localhost.localdomain> <20140115180057.GA25995@redhat.com> Message-ID: <1973485732.3401521.1389816109923.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Alexander Bokovoy" > To: "Sumit Bose" > Cc: freeipa-devel at redhat.com > Sent: Wednesday, January 15, 2014 7:00:57 PM > Subject: Re: [Freeipa-devel] [PATCH] 0133 Use standard_list_of_entries for trust-resolve > > On Wed, 15 Jan 2014, Sumit Bose wrote: > >On Wed, Jan 15, 2014 at 07:24:00PM +0200, Alexander Bokovoy wrote: > >> On Wed, 15 Jan 2014, Alexander Bokovoy wrote: > >> >Hi! > >> > > >> >When looking into https://fedorahosted.org/freeipa/ticket/4113, I > >> >decided to use output.standard_list_of_entries instead of a locally > >> >defined list of entries. This solves the problem with wrong exit code in > >> >CLI when non-resolvable SID is given, but only for a single SID. If > >> >multiple SID specified and some of them were not resolved, the exit code > >> >will still be 0 (success) but truncated flag will be set. This > >> >corresponds to the framework behavior in other cases. > >> Thanks to Sumit, here is updated patch because I forgot to run makeapi > >> ;( > >> > >> :) > > > >Currently I see: > > > >[sbose at ipa18-devel freeipa]$ ipa trust-resolve --sids sdfasdf > >------------------------------- > >Resolved 0 security identifiers > >------------------------------- > >---------------------------- > >Number of entries returned 0 > >---------------------------- > >[sbose at ipa18-devel freeipa]$ echo $? > >1 > > > >Would it be possible to return only one of the summaries to the user? > >Otherwise the patch works as expected and the output is better than the > >empty one before. > May be invert summary and tell how many security identifiers were not > resolved? I am personally not convinced this is the right way to fix #4113, for several reasons: 1) The output modification will most probably break FreeIPA 3.2.x or FreeIPA 3.3.x clients who expect different output (the command was introduced in https://fedorahosted.org/freeipa/ticket/3302). 2) I do not think this output is really giving better experience for users. When I get 0 results, does it mean that SID is wrong? Or it is correct but not existent in AD? Or is it correct, existent in AD but SSSD is broken? Instead of checking $?, I would rather expect appropriate errors to be returned - errors.NotFound, errors.ValidationError. Maybe we should return entries for all SIDs but instead of filling sid, name and type for each entry, we would fill "sid" and "error" with appropriate error. Would that help? Martin From abokovoy at redhat.com Wed Jan 15 20:27:33 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 22:27:33 +0200 Subject: [Freeipa-devel] [PATCH] 0133 Use standard_list_of_entries for trust-resolve In-Reply-To: <1973485732.3401521.1389816109923.JavaMail.root@redhat.com> References: <20140115163154.GF12003@redhat.com> <20140115172400.GH12003@redhat.com> <20140115173322.GC14122@localhost.localdomain> <20140115180057.GA25995@redhat.com> <1973485732.3401521.1389816109923.JavaMail.root@redhat.com> Message-ID: <20140115202733.GA29778@redhat.com> On Wed, 15 Jan 2014, Martin Kosek wrote: >----- Original Message ----- >> From: "Alexander Bokovoy" >> To: "Sumit Bose" >> Cc: freeipa-devel at redhat.com >> Sent: Wednesday, January 15, 2014 7:00:57 PM >> Subject: Re: [Freeipa-devel] [PATCH] 0133 Use standard_list_of_entries for trust-resolve >> >> On Wed, 15 Jan 2014, Sumit Bose wrote: >> >On Wed, Jan 15, 2014 at 07:24:00PM +0200, Alexander Bokovoy wrote: >> >> On Wed, 15 Jan 2014, Alexander Bokovoy wrote: >> >> >Hi! >> >> > >> >> >When looking into https://fedorahosted.org/freeipa/ticket/4113, I >> >> >decided to use output.standard_list_of_entries instead of a locally >> >> >defined list of entries. This solves the problem with wrong exit code in >> >> >CLI when non-resolvable SID is given, but only for a single SID. If >> >> >multiple SID specified and some of them were not resolved, the exit code >> >> >will still be 0 (success) but truncated flag will be set. This >> >> >corresponds to the framework behavior in other cases. >> >> Thanks to Sumit, here is updated patch because I forgot to run makeapi >> >> ;( >> >> >> >> :) >> > >> >Currently I see: >> > >> >[sbose at ipa18-devel freeipa]$ ipa trust-resolve --sids sdfasdf >> >------------------------------- >> >Resolved 0 security identifiers >> >------------------------------- >> >---------------------------- >> >Number of entries returned 0 >> >---------------------------- >> >[sbose at ipa18-devel freeipa]$ echo $? >> >1 >> > >> >Would it be possible to return only one of the summaries to the user? >> >Otherwise the patch works as expected and the output is better than the >> >empty one before. >> May be invert summary and tell how many security identifiers were not >> resolved? > >I am personally not convinced this is the right way to fix #4113, for >several reasons: > >1) The output modification will most probably break FreeIPA 3.2.x or >FreeIPA 3.3.x clients who expect different output (the command was >introduced in https://fedorahosted.org/freeipa/ticket/3302). This command is only used within Web UI. It is not supposed to be used by CLI for anything, it was marked for CLI only for some QE request at the time we still had issues with SID resolution in sssd. I'd rather mark it NO_CLI=True because it is really a tool for Web UI asynchronous resolution of SIDs to names for external members of groups. >2) I do not think this output is really giving better experience for >users. When I get 0 results, does it mean that SID is wrong? Or it is >correct but not existent in AD? Or is it correct, existent in AD but >SSSD is broken? >Instead of checking $?, I would rather expect appropriate errors to be >returned - errors.NotFound, errors.ValidationError. Maybe we should >return entries for all SIDs but instead of filling sid, name and type >for each entry, we would fill "sid" and "error" with appropriate error. >Would that help? This will be overkill for Web UI where it is really not needed. All we need is a list of resolved SIDs as names. Missing name will simply leave SID in the UI. -- / Alexander Bokovoy From rcritten at redhat.com Wed Jan 15 20:31:18 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 15 Jan 2014 15:31:18 -0500 Subject: [Freeipa-devel] [PATCHES] 506-507 Fix ticket #4085 In-Reply-To: <1389732974.26102.439.camel@willson.li.ssimo.org> References: <1389732974.26102.439.camel@willson.li.ssimo.org> Message-ID: <52D6F016.5090509@redhat.com> Simo Sorce wrote: > Uniform fallback for global_policy and stop explicitly adding the > default policy to all user accounts. > > Tested. > > Simo. ACK but you need this change in order for the unit tests to pass: diff --git a/ipatests/test_xmlrpc/test_user_plugin.py b/ipatests/test_xmlrpc/ test_user_plugin.py index 14a4b50..9b17775 100644 --- a/ipatests/test_xmlrpc/test_user_plugin.py +++ b/ipatests/test_xmlrpc/test_user_plugin.py @@ -99,10 +99,6 @@ def get_user_result(uid, givenname, sn, operation='sh ow', omit=[], mepmanagedentry=[get_group_dn(uid)], objectclass=add_oc(objectclasses.user, u'ipantuserattrs'), krbprincipalname=[u'%s@%s' % (uid, api.env.realm)], - krbpwdpolicyreference=[DN(('cn', 'global_policy'), - ('cn', api.env.realm), - ('cn', 'kerberos'), - api.env.basedn)], ) if operation in ('show', 'show-all', 'find', 'mod'): result.update( From abokovoy at redhat.com Wed Jan 15 20:37:46 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 22:37:46 +0200 Subject: [Freeipa-devel] [PATCH] 0133 Use standard_list_of_entries for trust-resolve In-Reply-To: <20140115202733.GA29778@redhat.com> References: <20140115163154.GF12003@redhat.com> <20140115172400.GH12003@redhat.com> <20140115173322.GC14122@localhost.localdomain> <20140115180057.GA25995@redhat.com> <1973485732.3401521.1389816109923.JavaMail.root@redhat.com> <20140115202733.GA29778@redhat.com> Message-ID: <20140115203746.GB29778@redhat.com> On Wed, 15 Jan 2014, Alexander Bokovoy wrote: >>I am personally not convinced this is the right way to fix #4113, for >>several reasons: >> >>1) The output modification will most probably break FreeIPA 3.2.x or >>FreeIPA 3.3.x clients who expect different output (the command was >>introduced in https://fedorahosted.org/freeipa/ticket/3302). >This command is only used within Web UI. It is not supposed to be used >by CLI for anything, it was marked for CLI only for some QE request at >the time we still had issues with SID resolution in sssd. I'd rather >mark it NO_CLI=True because it is really a tool for Web UI asynchronous >resolution of SIDs to names for external members of groups. Also note that from Web UI side the output change proposed in this patch is an extension of what Web UI expects. All the old fields are the same, it is only a bit of metadata added alongside with previously provided 'result' array. Since Web UI references data by field name, no change is needed: sidxlate_command.on_success = function(data, text_status, xhr) { for (var i=0; i< data.result.result.length; i++) { var entry = data.result.result[i]; if (entry.sid[0] in xlate) { xlate[entry.sid[0]].resolve(entry.name[0]); } } }; -- / Alexander Bokovoy From simo at redhat.com Wed Jan 15 22:04:26 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 15 Jan 2014 17:04:26 -0500 Subject: [Freeipa-devel] [PATCHES] 506-507 Fix ticket #4085 In-Reply-To: <52D6F016.5090509@redhat.com> References: <1389732974.26102.439.camel@willson.li.ssimo.org> <52D6F016.5090509@redhat.com> Message-ID: <1389823466.26102.489.camel@willson.li.ssimo.org> On Wed, 2014-01-15 at 15:31 -0500, Rob Crittenden wrote: > Simo Sorce wrote: > > Uniform fallback for global_policy and stop explicitly adding the > > default policy to all user accounts. > > > > Tested. > > > > Simo. > > ACK but you need this change in order for the unit tests to pass: > > diff --git a/ipatests/test_xmlrpc/test_user_plugin.py > b/ipatests/test_xmlrpc/ > test_user_plugin.py > index 14a4b50..9b17775 100644 > --- a/ipatests/test_xmlrpc/test_user_plugin.py > +++ b/ipatests/test_xmlrpc/test_user_plugin.py > @@ -99,10 +99,6 @@ def get_user_result(uid, givenname, sn, operation='sh > ow', omit=[], > mepmanagedentry=[get_group_dn(uid)], > objectclass=add_oc(objectclasses.user, u'ipantuserattrs'), > krbprincipalname=[u'%s@%s' % (uid, api.env.realm)], > - krbpwdpolicyreference=[DN(('cn', 'global_policy'), > - ('cn', api.env.realm), > - ('cn', 'kerberos'), > - api.env.basedn)], > ) > if operation in ('show', 'show-all', 'find', 'mod'): > result.update( > Attached both patches again, the first is the same as before, the second is updated with the above snippet. Thanks for the review. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-507-2-Stop-adding-a-default-password-policy-reference.patch Type: text/x-patch Size: 2713 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-506-Harmonize-policy-discovery-to-kdb-driver.patch Type: text/x-patch Size: 5442 bytes Desc: not available URL: From rcritten at redhat.com Wed Jan 15 22:06:05 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 15 Jan 2014 17:06:05 -0500 Subject: [Freeipa-devel] [PATCHES] 506-507 Fix ticket #4085 In-Reply-To: <1389823466.26102.489.camel@willson.li.ssimo.org> References: <1389732974.26102.439.camel@willson.li.ssimo.org> <52D6F016.5090509@redhat.com> <1389823466.26102.489.camel@willson.li.ssimo.org> Message-ID: <52D7064D.3040901@redhat.com> Simo Sorce wrote: > On Wed, 2014-01-15 at 15:31 -0500, Rob Crittenden wrote: >> Simo Sorce wrote: >>> Uniform fallback for global_policy and stop explicitly adding the >>> default policy to all user accounts. >>> >>> Tested. >>> >>> Simo. >> >> ACK but you need this change in order for the unit tests to pass: >> >> diff --git a/ipatests/test_xmlrpc/test_user_plugin.py >> b/ipatests/test_xmlrpc/ >> test_user_plugin.py >> index 14a4b50..9b17775 100644 >> --- a/ipatests/test_xmlrpc/test_user_plugin.py >> +++ b/ipatests/test_xmlrpc/test_user_plugin.py >> @@ -99,10 +99,6 @@ def get_user_result(uid, givenname, sn, operation='sh >> ow', omit=[], >> mepmanagedentry=[get_group_dn(uid)], >> objectclass=add_oc(objectclasses.user, u'ipantuserattrs'), >> krbprincipalname=[u'%s@%s' % (uid, api.env.realm)], >> - krbpwdpolicyreference=[DN(('cn', 'global_policy'), >> - ('cn', api.env.realm), >> - ('cn', 'kerberos'), >> - api.env.basedn)], >> ) >> if operation in ('show', 'show-all', 'find', 'mod'): >> result.update( >> > > Attached both patches again, the first is the same as before, the > second is updated with the above snippet. > > Thanks for the review. > > Simo. > ACK From mkosek at redhat.com Thu Jan 16 08:18:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 16 Jan 2014 09:18:58 +0100 Subject: [Freeipa-devel] [PATCHES] 506-507 Fix ticket #4085 In-Reply-To: <52D7064D.3040901@redhat.com> References: <1389732974.26102.439.camel@willson.li.ssimo.org> <52D6F016.5090509@redhat.com> <1389823466.26102.489.camel@willson.li.ssimo.org> <52D7064D.3040901@redhat.com> Message-ID: <52D795F2.2090808@redhat.com> On 01/15/2014 11:06 PM, Rob Crittenden wrote: > Simo Sorce wrote: >> On Wed, 2014-01-15 at 15:31 -0500, Rob Crittenden wrote: >>> Simo Sorce wrote: >>>> Uniform fallback for global_policy and stop explicitly adding the >>>> default policy to all user accounts. >>>> >>>> Tested. >>>> >>>> Simo. >>> >>> ACK but you need this change in order for the unit tests to pass: >>> >>> diff --git a/ipatests/test_xmlrpc/test_user_plugin.py >>> b/ipatests/test_xmlrpc/ >>> test_user_plugin.py >>> index 14a4b50..9b17775 100644 >>> --- a/ipatests/test_xmlrpc/test_user_plugin.py >>> +++ b/ipatests/test_xmlrpc/test_user_plugin.py >>> @@ -99,10 +99,6 @@ def get_user_result(uid, givenname, sn, operation='sh >>> ow', omit=[], >>> mepmanagedentry=[get_group_dn(uid)], >>> objectclass=add_oc(objectclasses.user, u'ipantuserattrs'), >>> krbprincipalname=[u'%s@%s' % (uid, api.env.realm)], >>> - krbpwdpolicyreference=[DN(('cn', 'global_policy'), >>> - ('cn', api.env.realm), >>> - ('cn', 'kerberos'), >>> - api.env.basedn)], >>> ) >>> if operation in ('show', 'show-all', 'find', 'mod'): >>> result.update( >>> >> >> Attached both patches again, the first is the same as before, the >> second is updated with the above snippet. >> >> Thanks for the review. >> >> Simo. >> > > ACK Pushed to master, ipa-3-3 (I just had to rebase the ipatests update patch as tested user entry was not consolidated and krbpwdpolicyreference was defined in about 20 places). Martin From pviktori at redhat.com Thu Jan 16 09:35:12 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 16 Jan 2014 10:35:12 +0100 Subject: [Freeipa-devel] [PATCH] 0133 Use standard_list_of_entries for trust-resolve In-Reply-To: <20140115172400.GH12003@redhat.com> References: <20140115163154.GF12003@redhat.com> <20140115172400.GH12003@redhat.com> Message-ID: <52D7A7D0.90105@redhat.com> On 01/15/2014 06:24 PM, Alexander Bokovoy wrote: [...] > Thanks to Sumit, here is updated patch because I forgot to run makeapi > ;( > > :) You should tell the computer to remind you next time :) For the record, I have this in my .git/hooks/post-commit: ./makeapi git status --short Runs makeapi, and alerts me of any non-committed changes (which include API.txt if that changed). Works quite well in my particular workflow. -- Petr? From pvoborni at redhat.com Thu Jan 16 11:06:17 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 16 Jan 2014 12:06:17 +0100 Subject: [Freeipa-devel] [PATCH] 463-530 First part of RCUE adoption In-Reply-To: <52C6A132.7000701@redhat.com> References: <528620F5.3010206@redhat.com> <52937156.6070303@redhat.com> <52989A5D.1030405@redhat.com> <5298BAB3.4030108@redhat.com> <52C6A132.7000701@redhat.com> Message-ID: <52D7BD29.6010700@redhat.com> On 3.1.2014 12:38, Petr Vobornik wrote: > On 29.11.2013 17:02, Ana Krivokapic wrote: >> On 11/29/2013 02:45 PM, Ana Krivokapic wrote: >>> >On 11/25/2013 04:48 PM, Ana Krivokapic wrote: >>>> >>On 11/15/2013 02:26 PM, Petr Vobornik wrote: >>>>> >>>Hello list, >>>>> >>> >>>>> >>>this is a first part of RCUE adoption effort. Main themes of >>>>> this patch set are: >>>>> >>> >>>>> >>>- use RCUE navigation >>>>> >>>- new styles for textboxes, textareas, radio/checkbox buttons >>>>> and buttons- >>>>> >>>part of >>>>> >>>- new internal form layout (tables replaced by divs) >>>>> >>>- layout does not have fixed >>>>> size >>>>> >>>- new dialog styles + removed dependency on jQuery UI dialog >>>>> >>>- icons replaced by Font Awesome glyphs >>>>> >>> >>>>> >>>Example is at: >>>>> >>> >>>>> >>>Some reasonings and additional info: >>>>> >>> >>>>> >>>1. RCUE includes Bootstrap which defines o lot of styles for a >>>>> lot of things. >>>>> >>>That messed up the UI and therefore I did the form changes now. >>>>> >>> >>>>> >>>2. jQuery UI is pretty big lib and we used it only for dialog >>>>> and buttons. >>>>> >>>Buttons were replaced by RCUE buttons so removal of dialog >>>>> dependency was a >>>>> >>>obvious step to get rid of the whole lib. The lib is removed >>>>> from main UI but >>>>> >>>is still present in separate pages - will be removed later. >>>>> >>> >>>>> >>>3. Dojo and jQuery were upgraded to latest >>>>> >>>versions. >>>>> >>> >>>>> >>>This approach was ACKed by Kyle from a design perspective with a >>>>> note that we >>>>> >>>will review and fixed some styling after second phase. We should >>>>> not release >>>>> >>>until then. >>>>> >>> >>>>> >>>The second phase, which I'm working on right now, will consist of: >>>>> >>> * login screen >>>>> >>> * new styles for standalone pages >>>>> >>> * necessary responsive enhancement (the ultimate future goal >>>>> is responsive >>>>> >>>layout) >>>>> >>> >>>>> >>>It's quite a lot of patches so I did not attach them here. You >>>>> can see the >>>>> >>>code in my private repo: >>>>> branch >>>>> >>>'rcue'. >>>> >>I tested this phase of RCUE adoption effort, overall it looks and >>>> works great. A >>>> >>couple of findings: >>>> >> >>>> >>1) Two ui integration tests are failing, I guess this is due to >>>> the re-arranging >>>> >>of elements on the automember page. So the tests should be amended >>>> to reflect >>>> >>that change. >> Commit ee4f6540490a16f0fbb5cdd02097a9b3ff354252 works around the >> navigation >> issue which caused tests to fail. ACK. >> > > I've unbundled font files from FreeIPA Web UI > - Open Sans will be in new fedora package - open-sans-fonts > - Font Awesome as well - fontawesome-fonts > - Overpass fonts are no longer used > > Branch rcue-fonts-unbundled > git://fedorapeople.org/home/fedora/pvoborni/public_git/freeipa.git > contains the changes. It's 6 additional commits on top of the reviewed > rcue branch. 5 commits were squashed in order to reduce size of the > final push. Attaching all of the patches for reference. > > open-sans-fonts and fontawesome-fonts Fedora packages are still on review: > - https://bugzilla.redhat.com/show_bug.cgi?id=1035897 > - https://bugzilla.redhat.com/show_bug.cgi?id=1026376 > > Reviewer for open-sans-fonts needed. > > OTP UI will be rebased on top of this effort. > The review is not blocked anymore - both fonts are available in updates testing. -- Petr Vobornik From pviktori at redhat.com Thu Jan 16 12:02:29 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 16 Jan 2014 13:02:29 +0100 Subject: [Freeipa-devel] [PATCH] 0335 ipa-replica-install: Move check for existing host before DNS resolution check In-Reply-To: <52D58904.6040509@redhat.com> References: <52A71945.6040503@redhat.com> <52D41206.6000101@redhat.com> <52D5370D.5050101@redhat.com> <52D58904.6040509@redhat.com> Message-ID: <52D7CA55.6030908@redhat.com> On 01/14/2014 07:59 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 01/13/2014 05:19 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> See commit message & ticket for details. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3889 >>> >>> If memory serves this was done so that both the replication and the host >>> checks would be done so the admin wouldn't die a death of a thousand >>> cuts. >>> >>> If a leftover agreement exists then the replica install will fail. You >>> delete the agreement. The next install may fail too if the host exists. >>> We should check for both before quitting. >> >> AFAIK nowadays ipa-replica-manage del should also remove the host entry, >> so it's correct to suggest just that. >> > > I couldn't find any place in the code the host is removed. This would > have to be a pretty specialized case because you'd only remove the host > if you were also deleting the last agreement. Well, `ipa-replica-manage del` does remove all agreements. So if we suggest deleting the replica, it makes no sense to suggest running `ipa host-del` after it. $ ipa host-find --------------- 3 hosts matched --------------- Host name: vm-183.idm.lab.eng.brq.redhat.com Principal name: host/vm-183.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM Password: False Keytab: True Managed by: vm-183.idm.lab.eng.brq.redhat.com Host name: vm-221.idm.lab.eng.brq.redhat.com Principal name: host/vm-221.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM Password: False Keytab: True Managed by: vm-221.idm.lab.eng.brq.redhat.com SSH public key fingerprint: 35:59:48:7F:EA:A5:FC:CF:AA:93:7E:F0:BE:29:EC:A6 (ssh-rsa), A7:8A:B4:99:61:FC:C6:1A:B5:62:CD:56:F4:BD:49:CA (ecdsa-sha2-nistp256) Host name: vm-223.idm.lab.eng.brq.redhat.com Principal name: host/vm-223.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM Password: False Keytab: True Managed by: vm-223.idm.lab.eng.brq.redhat.com SSH public key fingerprint: 7B:D1:4D:3E:5D:45:78:6D:4E:0A:4C:F4:DF:D9:7D:CE (ssh-rsa) ---------------------------- Number of entries returned 3 ---------------------------- $ ipa-replica-manage list vm-223.idm.lab.eng.brq.redhat.com vm-183.idm.lab.eng.brq.redhat.com: replica vm-221.idm.lab.eng.brq.redhat.com: replica $ ipa-replica-manage del vm-223.idm.lab.eng.brq.redhat.com Deleting a master is irreversible. To reconnect to the remote master you will need to prepare a new replica file and re-install. Continue to delete? [no]: y Deleting replication agreements between vm-223.idm.lab.eng.brq.redhat.com and vm-183.idm.lab.eng.brq.redhat.com, vm-221.idm.lab.eng.brq.redhat.com ipa: INFO: Setting agreement cn=meTovm-183.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch ipa: INFO: Deleting schedule 2358-2359 0 from agreement cn=meTovm-183.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping tree,cn=config ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica acquired successfully: Incremental update succeeded: start: 0: end: 0 Deleted replication agreement from 'vm-183.idm.lab.eng.brq.redhat.com' to 'vm-223.idm.lab.eng.brq.redhat.com' ipa: INFO: Setting agreement cn=meTovm-221.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch ipa: INFO: Deleting schedule 2358-2359 0 from agreement cn=meTovm-221.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping tree,cn=config ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica acquired successfully: Incremental update succeeded: start: 0: end: 0 Deleted replication agreement from 'vm-221.idm.lab.eng.brq.redhat.com' to 'vm-223.idm.lab.eng.brq.redhat.com' Background task created to clean replication data. This may take a while. This may be safely interrupted with Ctrl+C $ ipa host-find --------------- 2 hosts matched --------------- Host name: vm-183.idm.lab.eng.brq.redhat.com Principal name: host/vm-183.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM Password: False Keytab: True Managed by: vm-183.idm.lab.eng.brq.redhat.com Host name: vm-221.idm.lab.eng.brq.redhat.com Principal name: host/vm-221.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM Password: False Keytab: True Managed by: vm-221.idm.lab.eng.brq.redhat.com SSH public key fingerprint: 35:59:48:7F:EA:A5:FC:CF:AA:93:7E:F0:BE:29:EC:A6 (ssh-rsa), A7:8A:B4:99:61:FC:C6:1A:B5:62:CD:56:F4:BD:49:CA (ecdsa-sha2-nistp256) ---------------------------- Number of entries returned 2 ---------------------------- $ ipa host-del vm-223.idm.lab.eng.brq.redhat.com ipa: ERROR: vm-223.idm.lab.eng.brq.redhat.com: host not found $ -- Petr? From mkosek at redhat.com Thu Jan 16 13:16:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 16 Jan 2014 14:16:19 +0100 Subject: [Freeipa-devel] [PATCH] 448-449 Switch httpd to use default CCACHE Message-ID: <52D7DBA3.3010206@redhat.com> [freeipa-mkosek-448-add-runas-option-to-run-function.patch]: Run function can now run the specified command as different user by setting the EUID and EGID for executed process. [freeipa-mkosek-449-switch-httpd-to-use-default-ccache.patch]: Stock httpd no longer uses systemd EnvironmentFile option which is making FreeIPA's KRB5CCNAME setting ineffective. This can lead in hard to debug problems during subsequent ipa-server-install's where HTTP may use a stale CCACHE in the default kernel keyring CCACHE. Avoid forcing custom CCACHE and switch to system one, just make sure that it is properly cleaned by kdestroy run as "apache" user during FreeIPA server installation process. https://fedorahosted.org/freeipa/ticket/4084 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-448-add-runas-option-to-run-function.patch Type: text/x-patch Size: 2088 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-449-switch-httpd-to-use-default-ccache.patch Type: text/x-patch Size: 3717 bytes Desc: not available URL: From mkosek at redhat.com Thu Jan 16 14:23:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 16 Jan 2014 15:23:17 +0100 Subject: [Freeipa-devel] [PATCH] 463-530 First part of RCUE adoption In-Reply-To: <52D7BD29.6010700@redhat.com> References: <528620F5.3010206@redhat.com> <52937156.6070303@redhat.com> <52989A5D.1030405@redhat.com> <5298BAB3.4030108@redhat.com> <52C6A132.7000701@redhat.com> <52D7BD29.6010700@redhat.com> Message-ID: <52D7EB55.2060102@redhat.com> On 01/16/2014 12:06 PM, Petr Vobornik wrote: > On 3.1.2014 12:38, Petr Vobornik wrote: >> On 29.11.2013 17:02, Ana Krivokapic wrote: >>> On 11/29/2013 02:45 PM, Ana Krivokapic wrote: >>>> >On 11/25/2013 04:48 PM, Ana Krivokapic wrote: >>>>> >>On 11/15/2013 02:26 PM, Petr Vobornik wrote: >>>>>> >>>Hello list, >>>>>> >>> >>>>>> >>>this is a first part of RCUE adoption effort. Main themes of >>>>>> this patch set are: >>>>>> >>> >>>>>> >>>- use RCUE navigation >>>>>> >>>- new styles for textboxes, textareas, radio/checkbox buttons >>>>>> and buttons- >>>>>> >>>part of >>>>>> >>>- new internal form layout (tables replaced by divs) >>>>>> >>>- layout does not have fixed >>>>>> size >>>>>> >>>- new dialog styles + removed dependency on jQuery UI dialog >>>>>> >>>- icons replaced by Font Awesome glyphs >>>>>> >>> >>>>>> >>>Example is at: >>>>>> >>> >>>>>> >>>Some reasonings and additional info: >>>>>> >>> >>>>>> >>>1. RCUE includes Bootstrap which defines o lot of styles for a >>>>>> lot of things. >>>>>> >>>That messed up the UI and therefore I did the form changes now. >>>>>> >>> >>>>>> >>>2. jQuery UI is pretty big lib and we used it only for dialog >>>>>> and buttons. >>>>>> >>>Buttons were replaced by RCUE buttons so removal of dialog >>>>>> dependency was a >>>>>> >>>obvious step to get rid of the whole lib. The lib is removed >>>>>> from main UI but >>>>>> >>>is still present in separate pages - will be removed later. >>>>>> >>> >>>>>> >>>3. Dojo and jQuery were upgraded to latest >>>>>> >>>versions. >>>>>> >>> >>>>>> >>>This approach was ACKed by Kyle from a design perspective with a >>>>>> note that we >>>>>> >>>will review and fixed some styling after second phase. We should >>>>>> not release >>>>>> >>>until then. >>>>>> >>> >>>>>> >>>The second phase, which I'm working on right now, will consist of: >>>>>> >>> * login screen >>>>>> >>> * new styles for standalone pages >>>>>> >>> * necessary responsive enhancement (the ultimate future goal >>>>>> is responsive >>>>>> >>>layout) >>>>>> >>> >>>>>> >>>It's quite a lot of patches so I did not attach them here. You >>>>>> can see the >>>>>> >>>code in my private repo: >>>>>> branch >>>>>> >>>'rcue'. >>>>> >>I tested this phase of RCUE adoption effort, overall it looks and >>>>> works great. A >>>>> >>couple of findings: >>>>> >> >>>>> >>1) Two ui integration tests are failing, I guess this is due to >>>>> the re-arranging >>>>> >>of elements on the automember page. So the tests should be amended >>>>> to reflect >>>>> >>that change. >>> Commit ee4f6540490a16f0fbb5cdd02097a9b3ff354252 works around the >>> navigation >>> issue which caused tests to fail. ACK. >>> >> >> I've unbundled font files from FreeIPA Web UI >> - Open Sans will be in new fedora package - open-sans-fonts >> - Font Awesome as well - fontawesome-fonts >> - Overpass fonts are no longer used >> >> Branch rcue-fonts-unbundled >> git://fedorapeople.org/home/fedora/pvoborni/public_git/freeipa.git >> contains the changes. It's 6 additional commits on top of the reviewed >> rcue branch. 5 commits were squashed in order to reduce size of the >> final push. Attaching all of the patches for reference. >> >> open-sans-fonts and fontawesome-fonts Fedora packages are still on review: >> - https://bugzilla.redhat.com/show_bug.cgi?id=1035897 >> - https://bugzilla.redhat.com/show_bug.cgi?id=1026376 >> >> Reviewer for open-sans-fonts needed. >> >> OTP UI will be rebased on top of this effort. >> > > The review is not blocked anymore - both fonts are available in updates testing. I tested the 'rcue-fonts-unbundled' branch and it works for me. Given Ana's previous review, the only unreviewed patch is the top one switching to using the external fonts you packaged [1]. I found just one issue in the patch - the version of ipa.conf was not bumped, thus the upgrade would fail as ipa.conf would not be updated. If this is fixed, I would be OK with pushing this work to master so that you can base your next work on a stable grounds. Adding Simo and Rob to CC to notify them about this bigger push so that they can express any concerns. Note that current state is still not ready to be released as is, it still has some rough edges, but it will at least give others developers opportunity to test it. Martin [1] http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/commit/?h=datetime-ui&id=3d976cdb60e122ea722ecb3bd03a78b25ef105ca From mkosek at redhat.com Thu Jan 16 16:06:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 16 Jan 2014 17:06:19 +0100 Subject: [Freeipa-devel] [PATCH 0006] Treat error during write to /etc/resolv.conf as non-fatal In-Reply-To: <52D50905.4020400@redhat.com> References: <52D50905.4020400@redhat.com> Message-ID: <52D8037B.4060104@redhat.com> On 01/14/2014 10:53 AM, Petr Spacek wrote: > Hello, > > Treat error during write to /etc/resolv.conf as non-fatal. > > https://fedorahosted.org/freeipa/ticket/4110 There was a discussion with Rob and Petr on IRC wheter there should not be a pre-install check for resolv.conf. But given this is quite a corner case and we already report error level log message, we do not need to overengineer it ATM. ACK, pushed to master. I just changed redundant "str(e)" to "e" before pushing. Martin From abokovoy at redhat.com Thu Jan 16 17:29:17 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 16 Jan 2014 19:29:17 +0200 Subject: [Freeipa-devel] [PATCH] 0134 support bool type in CLI list output Message-ID: <20140116172917.GK12003@redhat.com> Hi, when testing changes to trustdomain-find to display status of the child domain (Domain enabled: True/False), Steeve found that on RHEL 7 beta Python doesn't coerce bool to string, while on Fedora 20 it does. To work around this issue I decided to extend encode_binary() method by converting bool values to unicode in CLI output. Steeve will file a ticket shortly. -- / Alexander Bokovoy -------------- next part -------------- >From 1b3d0f2313a66f546307bec42a3fb9624bd35a45 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 16 Jan 2014 19:19:11 +0200 Subject: [PATCH 3/3] CLI output: support bool values within records CLI output formatting code did not expect list of entries where some attributes of the record have bool type. CLI output was only accepting bool values at the topmost level. --- ipalib/cli.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ipalib/cli.py b/ipalib/cli.py index 4cf007d..4b56d0b 100644 --- a/ipalib/cli.py +++ b/ipalib/cli.py @@ -158,6 +158,8 @@ class textui(backend.Backend): """ if type(value) is str: return base64.b64encode(value) + elif type(value) is bool: + return unicode(value) else: return value -- 1.8.4.2 From abokovoy at redhat.com Thu Jan 16 17:32:21 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 16 Jan 2014 19:32:21 +0200 Subject: [Freeipa-devel] [PATCH] 0134 support bool type in CLI list output In-Reply-To: <20140116172917.GK12003@redhat.com> References: <20140116172917.GK12003@redhat.com> Message-ID: <20140116173221.GL12003@redhat.com> On Thu, 16 Jan 2014, Alexander Bokovoy wrote: > Hi, > > when testing changes to trustdomain-find to display status of the child > domain (Domain enabled: True/False), Steeve found that on RHEL 7 beta > Python doesn't coerce bool to string, while on Fedora 20 it does. > > To work around this issue I decided to extend encode_binary() method by > converting bool values to unicode in CLI output. > > Steeve will file a ticket shortly. Here is the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1054376 -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jan 16 18:35:06 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 16 Jan 2014 20:35:06 +0200 Subject: [Freeipa-devel] [PATCH] 0135 resolve SIDs to names in group-show for external members Message-ID: <20140116183506.GM12003@redhat.com> Hi, when group contains external members, they are specified using SIDs. Use trust-resolve command to convert them back on group-show. https://bugzilla.redhat.com/show_bug.cgi?id=1054391 -- / Alexander Bokovoy -------------- next part -------------- >From 3b0080d928bc7eb574a6d9705a7274b774ff372f Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 16 Jan 2014 20:31:37 +0200 Subject: [PATCH 4/4] group-show: resolve external members of the groups Perform SID to name conversion for existing external members of the groups if trust is configured. https://bugzilla.redhat.com/show_bug.cgi?id=1054391 --- ipalib/plugins/group.py | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/ipalib/plugins/group.py b/ipalib/plugins/group.py index 02eeb10..8010ec8 100644 --- a/ipalib/plugins/group.py +++ b/ipalib/plugins/group.py @@ -387,6 +387,20 @@ api.register(group_find) class group_show(LDAPRetrieve): __doc__ = _('Display information about a named group.') has_output_params = LDAPRetrieve.has_output_params + (ipaexternalmember_param,) + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + if ('ipaexternalmember' in entry_attrs and + len(entry_attrs['ipaexternalmember']) > 0 and + 'trust_resolve' in self.Command): + sids = entry_attrs['ipaexternalmember'] + result = self.Command.trust_resolve(sids=sids) + for entry in result['result']: + try: + idx = sids.index(entry['sid'][0]) + sids[idx] = entry['name'] + except ValueError: + pass + return dn api.register(group_show) -- 1.8.4.2 From dpal at redhat.com Thu Jan 16 21:14:24 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 16 Jan 2014 16:14:24 -0500 Subject: [Freeipa-devel] [PATCH] 0134 support bool type in CLI list output In-Reply-To: <20140116173221.GL12003@redhat.com> References: <20140116172917.GK12003@redhat.com> <20140116173221.GL12003@redhat.com> Message-ID: <52D84BB0.6020407@redhat.com> On 01/16/2014 12:32 PM, Alexander Bokovoy wrote: > On Thu, 16 Jan 2014, Alexander Bokovoy wrote: >> Hi, >> >> when testing changes to trustdomain-find to display status of the child >> domain (Domain enabled: True/False), Steeve found that on RHEL 7 beta >> Python doesn't coerce bool to string, while on Fedora 20 it does. >> >> To work around this issue I decided to extend encode_binary() method by >> converting bool values to unicode in CLI output. >> >> Steeve will file a ticket shortly. > Here is the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1054376 > https://fedorahosted.org/freeipa/ticket/4122 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Thu Jan 16 21:15:26 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 16 Jan 2014 16:15:26 -0500 Subject: [Freeipa-devel] [PATCH] 0135 resolve SIDs to names in group-show for external members In-Reply-To: <20140116183506.GM12003@redhat.com> References: <20140116183506.GM12003@redhat.com> Message-ID: <52D84BEE.90401@redhat.com> On 01/16/2014 01:35 PM, Alexander Bokovoy wrote: > Hi, > > when group contains external members, they are specified using SIDs. Use > trust-resolve command to convert them back on group-show. > > https://bugzilla.redhat.com/show_bug.cgi?id=1054391 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel https://fedorahosted.org/freeipa/ticket/4123 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Thu Jan 16 23:35:05 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 17 Jan 2014 00:35:05 +0100 Subject: [Freeipa-devel] [PATCH] 0134 support bool type in CLI list output In-Reply-To: <52D84BB0.6020407@redhat.com> References: <20140116172917.GK12003@redhat.com> <20140116173221.GL12003@redhat.com> <52D84BB0.6020407@redhat.com> Message-ID: <52D86CA9.7010907@redhat.com> On 01/16/2014 10:14 PM, Dmitri Pal wrote: > On 01/16/2014 12:32 PM, Alexander Bokovoy wrote: >> On Thu, 16 Jan 2014, Alexander Bokovoy wrote: >>> Hi, >>> >>> when testing changes to trustdomain-find to display status of the child >>> domain (Domain enabled: True/False), Steeve found that on RHEL 7 beta >>> Python doesn't coerce bool to string, while on Fedora 20 it does. >>> >>> To work around this issue I decided to extend encode_binary() method by >>> converting bool values to unicode in CLI output. >>> >>> Steeve will file a ticket shortly. >> Here is the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1054376 >> > https://fedorahosted.org/freeipa/ticket/4122 > This looks like something I touched in commit 7ec4d58; could you check if it solves the issue? https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=7ec4d58bf71077da5859ab798640479955fbdd48 -- Petr? From abokovoy at redhat.com Fri Jan 17 07:32:01 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 17 Jan 2014 09:32:01 +0200 Subject: [Freeipa-devel] [PATCH] 0134 support bool type in CLI list output In-Reply-To: <52D86CA9.7010907@redhat.com> References: <20140116172917.GK12003@redhat.com> <20140116173221.GL12003@redhat.com> <52D84BB0.6020407@redhat.com> <52D86CA9.7010907@redhat.com> Message-ID: <20140117073201.GP12003@redhat.com> On Fri, 17 Jan 2014, Petr Viktorin wrote: >On 01/16/2014 10:14 PM, Dmitri Pal wrote: >>On 01/16/2014 12:32 PM, Alexander Bokovoy wrote: >>>On Thu, 16 Jan 2014, Alexander Bokovoy wrote: >>>>Hi, >>>> >>>>when testing changes to trustdomain-find to display status of the child >>>>domain (Domain enabled: True/False), Steeve found that on RHEL 7 beta >>>>Python doesn't coerce bool to string, while on Fedora 20 it does. >>>> >>>>To work around this issue I decided to extend encode_binary() method by >>>>converting bool values to unicode in CLI output. >>>> >>>>Steeve will file a ticket shortly. >>>Here is the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1054376 >>> >>https://fedorahosted.org/freeipa/ticket/4122 >> > >This looks like something I touched in commit 7ec4d58; could you >check if it solves the issue? > >https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=7ec4d58bf71077da5859ab798640479955fbdd48 This commit isn't in 3.3 branch which explains why it failed on RHEL 7. I think we should propagate your commit to 3.3 branch. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Jan 17 07:59:54 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 17 Jan 2014 09:59:54 +0200 Subject: [Freeipa-devel] [PATCH] 0134 support bool type in CLI list output In-Reply-To: <20140117073201.GP12003@redhat.com> References: <20140116172917.GK12003@redhat.com> <20140116173221.GL12003@redhat.com> <52D84BB0.6020407@redhat.com> <52D86CA9.7010907@redhat.com> <20140117073201.GP12003@redhat.com> Message-ID: <20140117075954.GQ12003@redhat.com> On Fri, 17 Jan 2014, Alexander Bokovoy wrote: >On Fri, 17 Jan 2014, Petr Viktorin wrote: >>On 01/16/2014 10:14 PM, Dmitri Pal wrote: >>>On 01/16/2014 12:32 PM, Alexander Bokovoy wrote: >>>>On Thu, 16 Jan 2014, Alexander Bokovoy wrote: >>>>>Hi, >>>>> >>>>>when testing changes to trustdomain-find to display status of the child >>>>>domain (Domain enabled: True/False), Steeve found that on RHEL 7 beta >>>>>Python doesn't coerce bool to string, while on Fedora 20 it does. >>>>> >>>>>To work around this issue I decided to extend encode_binary() method by >>>>>converting bool values to unicode in CLI output. >>>>> >>>>>Steeve will file a ticket shortly. >>>>Here is the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1054376 >>>> >>>https://fedorahosted.org/freeipa/ticket/4122 >>> >> >>This looks like something I touched in commit 7ec4d58; could you >>check if it solves the issue? >> >>https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=7ec4d58bf71077da5859ab798640479955fbdd48 >This commit isn't in 3.3 branch which explains why it failed on RHEL 7. > >I think we should propagate your commit to 3.3 branch. I've pushed 7ec4d58b to ipa-3-3 branch. We can withdraw my patch 0134. -- / Alexander Bokovoy From mkosek at redhat.com Fri Jan 17 08:30:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 Jan 2014 09:30:14 +0100 Subject: [Freeipa-devel] [PATCH] 450 Remove missing VERSION warning in dnsrecord-mod Message-ID: <52D8EA16.9010602@redhat.com> dnsrecord-mod may call dnsrecord-delentry command when all records are deleted. However, the version was not passwd to delentry and it resulted in a warning. https://fedorahosted.org/freeipa/ticket/4120 ---- Pushed as a one-liner to master, ipa-3-3. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-450-remove-missing-version-warning-in-dnsrecord-mod.patch Type: text/x-patch Size: 1075 bytes Desc: not available URL: From mkosek at redhat.com Fri Jan 17 09:15:41 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 Jan 2014 10:15:41 +0100 Subject: [Freeipa-devel] [PATCH] 232 Increase service startup timeout default In-Reply-To: <20140115163835.GG12003@redhat.com> References: <52D64D68.9090206@redhat.com> <20140115102051.GW12003@redhat.com> <52D66E3C.60007@redhat.com> <52D6745D.4060008@redhat.com> <20140115122144.GZ12003@redhat.com> <52D68465.3030303@redhat.com> <20140115125558.GA12003@redhat.com> <52D6B7AC.9070907@redhat.com> <20140115163835.GG12003@redhat.com> Message-ID: <52D8F4BD.4010405@redhat.com> On 01/15/2014 05:38 PM, Alexander Bokovoy wrote: > On Wed, 15 Jan 2014, Jan Cholasta wrote: >>>>>> don't see why a single fix should be dispersed among multiple patches. >>>>> Patch attached, it obsoletes your patch 179. >>>> >>>> Thanks, but I don't understand why you squashed my patch 179 into your >>>> patch, the fixes are for separate issues (yield exception handling vs. >>>> previously stopped service being started). >>> Because you just said above: >>>>>> suggest you amend your patch with any changes you deem necessary, I >>>>>> don't see why a single fix should be dispersed among multiple patches. >>> "a single fix" is now not dispersed among multiple patches. >> >> Well, now it's multiple fixes in a single patch. What I meant to end up with >> is single fix per single patch (see attachment). > Now it is clearer. :) > > ACK to these patches. > All 3 latches are now pushed to master, ipa-3-3. Martin From abokovoy at redhat.com Fri Jan 17 09:49:18 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 17 Jan 2014 11:49:18 +0200 Subject: [Freeipa-devel] [PATCH] 0135 resolve SIDs to names in group-show for external members In-Reply-To: <20140116183506.GM12003@redhat.com> References: <20140116183506.GM12003@redhat.com> Message-ID: <20140117094918.GR12003@redhat.com> On Thu, 16 Jan 2014, Alexander Bokovoy wrote: >Hi, > >when group contains external members, they are specified using SIDs. Use >trust-resolve command to convert them back on group-show. > >https://bugzilla.redhat.com/show_bug.cgi?id=1054391 Sumit found omission on name translation. New patch is attached. -- / Alexander Bokovoy -------------- next part -------------- >From d7ce2cd8e646b7d07f80d19f4aa945e74b084aa7 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 16 Jan 2014 20:31:37 +0200 Subject: [PATCH 4/4] group-show: resolve external members of the groups Perform SID to name conversion for existing external members of the groups if trust is configured. https://bugzilla.redhat.com/show_bug.cgi?id=1054391 https://fedorahosted.org/freeipa/ticket/4123 --- ipalib/plugins/group.py | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/ipalib/plugins/group.py b/ipalib/plugins/group.py index 02eeb10..dac5500 100644 --- a/ipalib/plugins/group.py +++ b/ipalib/plugins/group.py @@ -387,6 +387,21 @@ api.register(group_find) class group_show(LDAPRetrieve): __doc__ = _('Display information about a named group.') has_output_params = LDAPRetrieve.has_output_params + (ipaexternalmember_param,) + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + if ('ipaexternalmember' in entry_attrs and + len(entry_attrs['ipaexternalmember']) > 0 and + 'trust_resolve' in self.Command and + not options.get('raw', False)): + sids = entry_attrs['ipaexternalmember'] + result = self.Command.trust_resolve(sids=sids) + for entry in result['result']: + try: + idx = sids.index(entry['sid'][0]) + sids[idx] = entry['name'][0] + except ValueError: + pass + return dn api.register(group_show) -- 1.8.4.2 From jcholast at redhat.com Fri Jan 17 10:39:07 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 17 Jan 2014 11:39:07 +0100 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <52CFE8BC.8010201@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> Message-ID: <52D9084B.20702@redhat.com> On 10.1.2014 13:34, Martin Kosek wrote: > On 01/09/2014 04:49 PM, Simo Sorce wrote: >> On Thu, 2014-01-09 at 10:44 -0500, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 01/09/2014 03:12 PM, Simo Sorce wrote: >> >>>>>> Also maybe we should allow admins to bypass the need to have an actual >>>>>> object to represent the alt name ? >>> >>> I'd rather not. This would allow a rogue admin to create a cert for >>> www.google.com. Sure, they could also create a host for that but forcing >>> them to add more entries increases the chances of them getting caught >>> doing it. >> >> They can remove the host right after they create a cert, I honestly do >> not think this is a valid concern. If your admin is rouge he can already >> take full ownership of your infrastructure in many ways, preventing >> setting a name in a cert doesn't really make a difference IMO. >> >> However I would be ok to limit this to some new "Security Admin/CA >> Admin" role that is not assigned by default. >> >> Simo. >> > > Ok, let's reach some conclusion here. I would really like to not defer this > feature for too long, it is quite wanted. Would creating new virtual operation > "Request certificate with SAN" make the situation better? It would not be so > difficult to do, the check_access function can already access virtual operation > name as a parameter, we just need to call it. Why don't we treat SAN hostnames the same way as the subject hostname? The way I see it, with SAN the only difference is that there is a set of hostnames instead of just a single hostname, so maybe we should support requesting a certificate for a set of hosts/services instead of just a single host/service. As far as authorization is concerned, currently you can request a certificate for a single host/service, if you have the "Request certificate" permission and write access to the host/service entry. With multiple hosts/services, you would be able to request a certificate if you have the "Request certificate" permission and write access to *all* of the host/certificate entries you are requesting the certificate for. Effectively this means that cert-request would accept multiple principals instead of single principal and the automatic revocation code in cert-request, host-del and service-del would take into account that a single certificate might be assigned to multiple entities. -- Jan Cholasta From sbose at redhat.com Fri Jan 17 10:50:07 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 17 Jan 2014 11:50:07 +0100 Subject: [Freeipa-devel] [PATCH] 0135 resolve SIDs to names in group-show for external members In-Reply-To: <20140117094918.GR12003@redhat.com> References: <20140116183506.GM12003@redhat.com> <20140117094918.GR12003@redhat.com> Message-ID: <20140117105007.GD23022@localhost.localdomain> On Fri, Jan 17, 2014 at 11:49:18AM +0200, Alexander Bokovoy wrote: > On Thu, 16 Jan 2014, Alexander Bokovoy wrote: > >Hi, > > > >when group contains external members, they are specified using SIDs. Use > >trust-resolve command to convert them back on group-show. > > > >https://bugzilla.redhat.com/show_bug.cgi?id=1054391 > Sumit found omission on name translation. New patch is attached. > > -- > / Alexander Bokovoy Patch now works as expected and python code looks good to me, so ACK. It would be nice if anyone else can check the python code before committing the patch. bye, Sumit From mkosek at redhat.com Fri Jan 17 11:09:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 Jan 2014 12:09:03 +0100 Subject: [Freeipa-devel] [PATCH] 0135 resolve SIDs to names in group-show for external members In-Reply-To: <20140117105007.GD23022@localhost.localdomain> References: <20140116183506.GM12003@redhat.com> <20140117094918.GR12003@redhat.com> <20140117105007.GD23022@localhost.localdomain> Message-ID: <52D90F4F.3080304@redhat.com> On 01/17/2014 11:50 AM, Sumit Bose wrote: > On Fri, Jan 17, 2014 at 11:49:18AM +0200, Alexander Bokovoy wrote: >> On Thu, 16 Jan 2014, Alexander Bokovoy wrote: >>> Hi, >>> >>> when group contains external members, they are specified using SIDs. Use >>> trust-resolve command to convert them back on group-show. >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1054391 >> Sumit found omission on name translation. New patch is attached. >> >> -- >> / Alexander Bokovoy > > Patch now works as expected and python code looks good to me, so ACK. > It would be nice if anyone else can check the python code before > committing the patch. > > bye, > Sumit Sumit, did you also test Web UI? We should check how it works there, we may no longer need to call trust-resolve internally there given it was changed on server side. If not, Petr1 plans to check that now. Martin From sbose at redhat.com Fri Jan 17 11:27:02 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 17 Jan 2014 12:27:02 +0100 Subject: [Freeipa-devel] [PATCH] 0135 resolve SIDs to names in group-show for external members In-Reply-To: <52D90F4F.3080304@redhat.com> References: <20140116183506.GM12003@redhat.com> <20140117094918.GR12003@redhat.com> <20140117105007.GD23022@localhost.localdomain> <52D90F4F.3080304@redhat.com> Message-ID: <20140117112702.GE23022@localhost.localdomain> On Fri, Jan 17, 2014 at 12:09:03PM +0100, Martin Kosek wrote: > On 01/17/2014 11:50 AM, Sumit Bose wrote: > > On Fri, Jan 17, 2014 at 11:49:18AM +0200, Alexander Bokovoy wrote: > >> On Thu, 16 Jan 2014, Alexander Bokovoy wrote: > >>> Hi, > >>> > >>> when group contains external members, they are specified using SIDs. Use > >>> trust-resolve command to convert them back on group-show. > >>> > >>> https://bugzilla.redhat.com/show_bug.cgi?id=1054391 > >> Sumit found omission on name translation. New patch is attached. > >> > >> -- > >> / Alexander Bokovoy > > > > Patch now works as expected and python code looks good to me, so ACK. > > It would be nice if anyone else can check the python code before > > committing the patch. > > > > bye, > > Sumit > > Sumit, did you also test Web UI? We should check how it works there, we may no > longer need to call trust-resolve internally there given it was changed on > server side. > > If not, Petr1 plans to check that now. sorry, no, I didn't check it. bye, Sumit > > Martin From pvoborni at redhat.com Fri Jan 17 12:02:18 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 17 Jan 2014 13:02:18 +0100 Subject: [Freeipa-devel] [PATCH] 0135 resolve SIDs to names in group-show for external members In-Reply-To: <20140117112702.GE23022@localhost.localdomain> References: <20140116183506.GM12003@redhat.com> <20140117094918.GR12003@redhat.com> <20140117105007.GD23022@localhost.localdomain> <52D90F4F.3080304@redhat.com> <20140117112702.GE23022@localhost.localdomain> Message-ID: <52D91BCA.7040005@redhat.com> On 17.1.2014 12:27, Sumit Bose wrote: > On Fri, Jan 17, 2014 at 12:09:03PM +0100, Martin Kosek wrote: >> On 01/17/2014 11:50 AM, Sumit Bose wrote: >>> On Fri, Jan 17, 2014 at 11:49:18AM +0200, Alexander Bokovoy wrote: >>>> On Thu, 16 Jan 2014, Alexander Bokovoy wrote: >>>>> Hi, >>>>> >>>>> when group contains external members, they are specified using SIDs. Use >>>>> trust-resolve command to convert them back on group-show. >>>>> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1054391 >>>> Sumit found omission on name translation. New patch is attached. >>>> >>>> -- >>>> / Alexander Bokovoy >>> >>> Patch now works as expected and python code looks good to me, so ACK. >>> It would be nice if anyone else can check the python code before >>> committing the patch. >>> >>> bye, >>> Sumit >> >> Sumit, did you also test Web UI? We should check how it works there, we may no >> longer need to call trust-resolve internally there given it was changed on >> server side. >> >> If not, Petr1 plans to check that now. > > sorry, no, I didn't check it. > > bye, > Sumit > >> >> Martin On my test system trust-resolve command is somehow broken. It doesn't return any names; therefore I was not able to test Alexander's patch properly. Anyway, attached patch removes the functionality from Web UI. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0542-Remove-SID-resolve-call-from-Web-UI.patch Type: text/x-patch Size: 2940 bytes Desc: not available URL: From abokovoy at redhat.com Fri Jan 17 12:13:03 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 17 Jan 2014 14:13:03 +0200 Subject: [Freeipa-devel] [PATCH] 0136 ipa-adtrust-install configure host netbios name by default Message-ID: <20140117121303.GS12003@redhat.com> https://fedorahosted.org/freeipa/ticket/4116 -- / Alexander Bokovoy -------------- next part -------------- >From a37901e6464e79e10555187d0f8b54d0a7176be0 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 17 Jan 2014 14:09:34 +0200 Subject: [PATCH 5/5] ipa-adtrust-install: configure host netbios name by default Ensure we set host netbios name by default in smb.conf https://fedorahosted.org/freeipa/ticket/4116 --- install/share/smb.conf.template | 1 + ipaserver/install/adtrustinstance.py | 3 +++ 2 files changed, 4 insertions(+) diff --git a/install/share/smb.conf.template b/install/share/smb.conf.template index 086b0fc..2908b99 100644 --- a/install/share/smb.conf.template +++ b/install/share/smb.conf.template @@ -1,5 +1,6 @@ [global] workgroup = $NETBIOS_NAME +netbios name = $HOST_NETBIOS_NAME realm = $REALM kerberos method = dedicated keytab dedicated keytab file = FILE:/etc/samba/samba.keytab diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index 2f1c999..5eb6157 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -124,6 +124,7 @@ class ADTRUSTInstance(service.Service): self.secondary_rid_base = None self.fqdn = None + self.host_netbios_name = None self.realm = None self.domain_name = None @@ -151,6 +152,7 @@ class ADTRUSTInstance(service.Service): # Values obtained from API.env self.fqdn = self.fqdn or api.env.host + self.host_netbios_name = make_netbios_name(self.fqdn) self.realm = self.realm or api.env.realm self.domain_name = self.domain_name or api.env.domain @@ -769,6 +771,7 @@ class ADTRUSTInstance(service.Service): self.sub_dict = dict(REALM = self.realm, SUFFIX = self.suffix, NETBIOS_NAME = self.netbios_name, + HOST_NETBIOS_NAME = self.host_netbios_name, SMB_DN = self.smb_dn, LDAPI_SOCKET = self.ldapi_socket, FQDN = self.fqdn) -- 1.8.4.2 From sbose at redhat.com Fri Jan 17 12:26:59 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 17 Jan 2014 13:26:59 +0100 Subject: [Freeipa-devel] [PATCH] 0135 resolve SIDs to names in group-show for external members In-Reply-To: <52D91BCA.7040005@redhat.com> References: <20140116183506.GM12003@redhat.com> <20140117094918.GR12003@redhat.com> <20140117105007.GD23022@localhost.localdomain> <52D90F4F.3080304@redhat.com> <20140117112702.GE23022@localhost.localdomain> <52D91BCA.7040005@redhat.com> Message-ID: <20140117122659.GK23022@localhost.localdomain> On Fri, Jan 17, 2014 at 01:02:18PM +0100, Petr Vobornik wrote: > On 17.1.2014 12:27, Sumit Bose wrote: > >On Fri, Jan 17, 2014 at 12:09:03PM +0100, Martin Kosek wrote: > >>On 01/17/2014 11:50 AM, Sumit Bose wrote: > >>>On Fri, Jan 17, 2014 at 11:49:18AM +0200, Alexander Bokovoy wrote: > >>>>On Thu, 16 Jan 2014, Alexander Bokovoy wrote: > >>>>>Hi, > >>>>> > >>>>>when group contains external members, they are specified using SIDs. Use > >>>>>trust-resolve command to convert them back on group-show. > >>>>> > >>>>>https://bugzilla.redhat.com/show_bug.cgi?id=1054391 > >>>>Sumit found omission on name translation. New patch is attached. > >>>> > >>>>-- > >>>>/ Alexander Bokovoy > >>> > >>>Patch now works as expected and python code looks good to me, so ACK. > >>>It would be nice if anyone else can check the python code before > >>>committing the patch. > >>> > >>>bye, > >>>Sumit > >> > >>Sumit, did you also test Web UI? We should check how it works there, we may no > >>longer need to call trust-resolve internally there given it was changed on > >>server side. > >> > >>If not, Petr1 plans to check that now. > > > >sorry, no, I didn't check it. > > > >bye, > >Sumit > > > >> > >>Martin > > On my test system trust-resolve command is somehow broken. It > doesn't return any names; therefore I was not able to test > Alexander's patch properly. > > Anyway, attached patch removes the functionality from Web UI. WebUI still translates the SIDs here, so ACK. bye, Sumit > -- > Petr Vobornik From thozza at redhat.com Fri Jan 17 15:06:11 2014 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 17 Jan 2014 16:06:11 +0100 Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] Fix warning duplicate 'const' declaration specifier In-Reply-To: <20131030082131.GA32671@mail.corp.redhat.com> References: <20131030082131.GA32671@mail.corp.redhat.com> Message-ID: <52D946E3.8060805@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/30/2013 09:21 AM, Lukas Slebodnik wrote: > ehlo, > > There were few warnings in bind-dyndb-ldap "duplicate 'const' declaration > specifier". > > It does not make sense to have const twice in declaration > like a "const settings_set_t const settings_default_set" > This one was false positive. > > The 2nd warning revealed potential problem. > const char const * dns_str > With previous declaration, you cannot modify data, but you can modify > pointer itself. > *dns_str = "asdasd" //compilation error > dns_str++ //works fine > > If you want to disable modification data and disable modification of pointer > you will need to have 2nd const modifier after star "*" > > You can find some examples of "const" usage in attached file test.c or > you can read article with explanation of next declaration > "char *(*(**foo [][8])())[];" > http://eli.thegreenplace.net/2008/07/18/reading-c-type-declarations/ > > Simple patch is attached. > > LS > ACK. Looks good. Regards, Tomas Hozza -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS2UbdAAoJEMWIetUdnzwtqKIIAKEnhrYiT85yvGYkMVUjGZ5Y s42WXAcJOswo8rAiZwbMPmyGU7Imr+tEYf92Uu8S9kRipI6RnQYO0WFjt/HP/qQJ DblisCEgrWiPwYRTrEVuk2K7HZXUIvcEhB6KXgGPLsBw0bNFxb8FYs2GND4NjByU c/OCTGLaRsRxqX7sLn4UYZl32xic/QKJUeUWkfSgCbB7hzAOQJh65I5pW8e8LJre DBihpudiWVs2c13rIxyAyvbGcJ9X3HUuiRt/j2kWIhK4ESzB7Rf2cE3R1Frz7Do9 uDz8/q9WXIXmmQKCnK3zc8IM1LukPBYQUFN2j9ThiqzDFb/lMhGpXO3EeNRtiMM= =t8pR -----END PGP SIGNATURE----- From thozza at redhat.com Fri Jan 17 15:13:10 2014 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 17 Jan 2014 16:13:10 +0100 Subject: [Freeipa-devel] [PATCH 0204] Remove obsolete zr_get_rbt() function from zone register In-Reply-To: <5280C540.8030604@redhat.com> References: <5280C540.8030604@redhat.com> Message-ID: <52D94886.7000902@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/11/2013 12:53 PM, Petr Spacek wrote: > Hello, > > Remove obsolete zr_get_rbt() function from zone register. > ACK. Patch looks good. Regards, Tomas Hozza -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS2UiGAAoJEMWIetUdnzwtACUH/jygrRD1QKit5atNb416vWUM qTE/ozdZ6bFfRB9ndFSj3n8Qcq9wqOV493Dbe+Hhh8fdKmCSzqJ3MN6UpFhmv4M6 O0jAkYnMDqd+k5zb9+bVtqdj0SLvtzfqLGVL7ydxzg4zMp/H2Su1YdRARt/KkYUA z3nosofXgU418v0gG/+wegQKCzJPqQ7F/+ZuF6QbC9BAwYjpQA4FoH/gNZk7QuoU LafA/OveHEGgfmVq+5bcxMFYty2tLgWifRBCGruECwOc4qu8mhwVlZKb4FpsX5nR R5qh7W93d372QL/1I+QSHA4Z2rOYUhc04OBL90xPjf48jlzu8MnqRujvYddgy1U= =kk7O -----END PGP SIGNATURE----- From mkosek at redhat.com Fri Jan 17 15:18:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 Jan 2014 16:18:16 +0100 Subject: [Freeipa-devel] [PATCH] 451 Hide trust-resolve command Message-ID: <52D949B8.7000402@redhat.com> We do not need to expose a public FreeIPA specific interface to resolve SIDs to names. The interface is only used internally to resolve SIDs when external group members are listed. Additionally, the command interface is not prepared for regular user and can give rather confusing results. Hide it from CLI. The API itself is still accessible and compatible with older clients. https://fedorahosted.org/freeipa/ticket/4113 ---- This patch comes from a discussion between developers and testers whether this interface is still useful or not. Give it hides the trust-resolve command from CLI, it obsoletes Alexander's patch 133. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-451-hide-trust-resolve-command.patch Type: text/x-patch Size: 1164 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jan 17 17:54:00 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 17 Jan 2014 18:54:00 +0100 Subject: [Freeipa-devel] [PATCH] 543 Trust domains Web UI Message-ID: <52D96E38.1020308@redhat.com> Note: this version of the patch is especially prepared for ipa-3-3 branch. Add Web UI counterpart of following CLI commands: * trust-fetch-domains Refresh list of the domains associated with the trust * trustdomain-del Remove infromation about the domain associated with the trust. * trustdomain-disable Disable use of IPA resources by the domain of the trust * trustdomain-enable Allow use of IPA resources by the domain of the trust * trustdomain-find Search domains of the trust https://fedorahosted.org/freeipa/ticket/4119 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0543-Trust-domains-Web-UI.patch Type: text/x-patch Size: 6987 bytes Desc: not available URL: From rcritten at redhat.com Fri Jan 17 21:24:00 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 17 Jan 2014 16:24:00 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy Message-ID: <52D99F70.3060305@redhat.com> Implement an IPA RESTful Foreman-compatible smart proxy. This exposes hosts and hostgroups via an unauthenticated REST API. The idea is that this service runs on the Foreman server and only listens on local ports. It is a CherryPy-based server and that handles the majority of REST for us. I included some tests, they can be executed with: nosetests -v smartproxy/tests It is installable as a separate RPM but the local machine needs to be an IPA client. Configuration instructions are in the ipa-rest.1 man page. This requires an updated python-kerberos currently only available in rawhide: python-kerberos-1.1-13.fc21 http://www.freeipa.org/page/V3/Smart_Proxy rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1106-rest.patch Type: text/x-diff Size: 41557 bytes Desc: not available URL: From dpal at redhat.com Fri Jan 17 22:08:31 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 17 Jan 2014 17:08:31 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52D99F70.3060305@redhat.com> References: <52D99F70.3060305@redhat.com> Message-ID: <52D9A9DF.7030706@redhat.com> On 01/17/2014 04:24 PM, Rob Crittenden wrote: > Implement an IPA RESTful Foreman-compatible smart proxy. This exposes > hosts and hostgroups via an unauthenticated REST API. The idea is that > this service runs on the Foreman server and only listens on local ports. > > It is a CherryPy-based server and that handles the majority of REST > for us. > > I included some tests, they can be executed with: nosetests -v > smartproxy/tests > > It is installable as a separate RPM but the local machine needs to be > an IPA client. Configuration instructions are in the ipa-rest.1 man page. > > This requires an updated python-kerberos currently only available in > rawhide: python-kerberos-1.1-13.fc21 > > http://www.freeipa.org/page/V3/Smart_Proxy > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel What kind of the pre configuration it requires on IPA side. Should we setup some special permission for the host that would run this proxy? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Jan 17 22:14:21 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 17 Jan 2014 17:14:21 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52D9A9DF.7030706@redhat.com> References: <52D99F70.3060305@redhat.com> <52D9A9DF.7030706@redhat.com> Message-ID: <52D9AB3D.4040007@redhat.com> Dmitri Pal wrote: > On 01/17/2014 04:24 PM, Rob Crittenden wrote: >> Implement an IPA RESTful Foreman-compatible smart proxy. This exposes >> hosts and hostgroups via an unauthenticated REST API. The idea is that >> this service runs on the Foreman server and only listens on local ports. >> >> It is a CherryPy-based server and that handles the majority of REST >> for us. >> >> I included some tests, they can be executed with: nosetests -v >> smartproxy/tests >> >> It is installable as a separate RPM but the local machine needs to be >> an IPA client. Configuration instructions are in the ipa-rest.1 man page. >> >> This requires an updated python-kerberos currently only available in >> rawhide: python-kerberos-1.1-13.fc21 >> >> http://www.freeipa.org/page/V3/Smart_Proxy >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > What kind of the pre configuration it requires on IPA side. > Should we setup some special permission for the host that would run this > proxy? Nothing is required on the server. I tested this on and off a server and it is largely independent. I document how to create a role and what privileges it needs. For the time being I'm using a normal IPA user as a service user for this. If we add services to roles I'd prefer that, https://fedorahosted.org/freeipa/ticket/3164 . rob From tbabej at redhat.com Mon Jan 20 08:33:00 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 20 Jan 2014 09:33:00 +0100 Subject: [Freeipa-devel] [PATCH 0141] ipatests: Check for legacy_client attribute presence Message-ID: <52DCDF3C.2010004@redhat.com> Hi, When legacy client tests fail during IPA installation, the legacy client test produces an additional misleading error (the real cause is reported as well). This happens due the fact that we try to cleanup host that was not yet defined. We need to check for this attribute being defined before unapplying fixes there. https://fedorahosted.org/freeipa/ticket/4124 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0141-ipatests-Check-for-legacy_client-attribute-presence-.patch Type: text/x-patch Size: 1550 bytes Desc: not available URL: From tbabej at redhat.com Mon Jan 20 08:43:32 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 20 Jan 2014 09:43:32 +0100 Subject: [Freeipa-devel] [PATCH 0142] ipatests: Remove sudo calls from tasks Message-ID: <52DCE1B4.1090707@redhat.com> Hi, Sudo calls are not necessary since we log in as a root. Additionally, sudo requires tty in default configuration, which is not acquired when using OpenSSH transport. https://fedorahosted.org/freeipa/ticket/4125 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0142-ipatests-Remove-sudo-calls-from-tasks.patch Type: text/x-patch Size: 1147 bytes Desc: not available URL: From mkosek at redhat.com Mon Jan 20 08:55:20 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Jan 2014 09:55:20 +0100 Subject: [Freeipa-devel] [PATCH] 0135 resolve SIDs to names in group-show for external members In-Reply-To: <20140117122659.GK23022@localhost.localdomain> References: <20140116183506.GM12003@redhat.com> <20140117094918.GR12003@redhat.com> <20140117105007.GD23022@localhost.localdomain> <52D90F4F.3080304@redhat.com> <20140117112702.GE23022@localhost.localdomain> <52D91BCA.7040005@redhat.com> <20140117122659.GK23022@localhost.localdomain> Message-ID: <52DCE478.8070907@redhat.com> On 01/17/2014 01:26 PM, Sumit Bose wrote: > On Fri, Jan 17, 2014 at 01:02:18PM +0100, Petr Vobornik wrote: >> On 17.1.2014 12:27, Sumit Bose wrote: >>> On Fri, Jan 17, 2014 at 12:09:03PM +0100, Martin Kosek wrote: >>>> On 01/17/2014 11:50 AM, Sumit Bose wrote: >>>>> On Fri, Jan 17, 2014 at 11:49:18AM +0200, Alexander Bokovoy wrote: >>>>>> On Thu, 16 Jan 2014, Alexander Bokovoy wrote: >>>>>>> Hi, >>>>>>> >>>>>>> when group contains external members, they are specified using SIDs. Use >>>>>>> trust-resolve command to convert them back on group-show. >>>>>>> >>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1054391 >>>>>> Sumit found omission on name translation. New patch is attached. >>>>>> >>>>>> -- >>>>>> / Alexander Bokovoy >>>>> >>>>> Patch now works as expected and python code looks good to me, so ACK. >>>>> It would be nice if anyone else can check the python code before >>>>> committing the patch. >>>>> >>>>> bye, >>>>> Sumit >>>> >>>> Sumit, did you also test Web UI? We should check how it works there, we may no >>>> longer need to call trust-resolve internally there given it was changed on >>>> server side. >>>> >>>> If not, Petr1 plans to check that now. >>> >>> sorry, no, I didn't check it. >>> >>> bye, >>> Sumit >>> >>>> >>>> Martin >> >> On my test system trust-resolve command is somehow broken. It >> doesn't return any names; therefore I was not able to test >> Alexander's patch properly. >> >> Anyway, attached patch removes the functionality from Web UI. > > WebUI still translates the SIDs here, so ACK. > > bye, > Sumit Thanks. Pushed both Web UI and Alexander's group-show patch to master, ipa-3-3 (I had to rebase Petr's patch there a little). Martin From tbabej at redhat.com Mon Jan 20 09:31:21 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 20 Jan 2014 10:31:21 +0100 Subject: [Freeipa-devel] [PATCH 0141] ipatests: Check for legacy_client attribute presence In-Reply-To: <52DCDF3C.2010004@redhat.com> References: <52DCDF3C.2010004@redhat.com> Message-ID: <52DCECE9.7080105@redhat.com> Yep, 100% bug coverage. Updated patch attached. On 01/20/2014 09:33 AM, Tomas Babej wrote: > Hi, > > When legacy client tests fail during IPA installation, the legacy > client test produces an additional misleading error > (the real cause is reported as well). This happens due the fact > that we try to cleanup host that was not yet defined. We need to > check for this attribute being defined before unapplying fixes there. > > https://fedorahosted.org/freeipa/ticket/4124 > > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0141-2-ipatests-Check-for-legacy_client-attribute-presence-.patch Type: text/x-patch Size: 1552 bytes Desc: not available URL: From mkosek at redhat.com Mon Jan 20 09:39:30 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Jan 2014 10:39:30 +0100 Subject: [Freeipa-devel] [PATCH] 0136 ipa-adtrust-install configure host netbios name by default In-Reply-To: <20140117121303.GS12003@redhat.com> References: <20140117121303.GS12003@redhat.com> Message-ID: <52DCEED2.8070605@redhat.com> On 01/17/2014 01:13 PM, Alexander Bokovoy wrote: > https://fedorahosted.org/freeipa/ticket/4116 Works fine. ACK, pushed to master, ipa-3-3. Martin From jcholast at redhat.com Mon Jan 20 10:07:36 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 20 Jan 2014 11:07:36 +0100 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <52D9084B.20702@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> Message-ID: <52DCF568.9000508@redhat.com> On 17.1.2014 11:39, Jan Cholasta wrote: > On 10.1.2014 13:34, Martin Kosek wrote: >> On 01/09/2014 04:49 PM, Simo Sorce wrote: >>> On Thu, 2014-01-09 at 10:44 -0500, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> On 01/09/2014 03:12 PM, Simo Sorce wrote: >>> >>>>>>> Also maybe we should allow admins to bypass the need to have an >>>>>>> actual >>>>>>> object to represent the alt name ? >>>> >>>> I'd rather not. This would allow a rogue admin to create a cert for >>>> www.google.com. Sure, they could also create a host for that but >>>> forcing >>>> them to add more entries increases the chances of them getting caught >>>> doing it. >>> >>> They can remove the host right after they create a cert, I honestly do >>> not think this is a valid concern. If your admin is rouge he can already >>> take full ownership of your infrastructure in many ways, preventing >>> setting a name in a cert doesn't really make a difference IMO. >>> >>> However I would be ok to limit this to some new "Security Admin/CA >>> Admin" role that is not assigned by default. >>> >>> Simo. >>> >> >> Ok, let's reach some conclusion here. I would really like to not defer >> this >> feature for too long, it is quite wanted. Would creating new virtual >> operation >> "Request certificate with SAN" make the situation better? It would not >> be so >> difficult to do, the check_access function can already access virtual >> operation >> name as a parameter, we just need to call it. > > Why don't we treat SAN hostnames the same way as the subject hostname? > The way I see it, with SAN the only difference is that there is a set of > hostnames instead of just a single hostname, so maybe we should support > requesting a certificate for a set of hosts/services instead of just a > single host/service. > > As far as authorization is concerned, currently you can request a > certificate for a single host/service, if you have the "Request > certificate" permission and write access to the host/service entry. With > multiple hosts/services, you would be able to request a certificate if > you have the "Request certificate" permission and write access to *all* > of the host/certificate entries you are requesting the certificate for. > > Effectively this means that cert-request would accept multiple > principals instead of single principal and the automatic revocation code > in cert-request, host-del and service-del would take into account that a > single certificate might be assigned to multiple entities. > See attachment for patch which implements the above design. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-234-Support-SAN-in-cert-request.patch Type: text/x-patch Size: 12534 bytes Desc: not available URL: From pviktori at redhat.com Mon Jan 20 11:23:45 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 20 Jan 2014 12:23:45 +0100 Subject: [Freeipa-devel] [PATCHES] 225-230 Drop support for the legacy LDAP API In-Reply-To: <52D51218.1090304@redhat.com> References: <52A72DA8.4090104@redhat.com> <52AB16B8.6050808@redhat.com> <52AEC654.5040602@redhat.com> <52AF03F2.2090904@redhat.com> <52CBF8FB.7090808@redhat.com> <52D00B84.1090804@redhat.com> <52D51218.1090304@redhat.com> Message-ID: <52DD0741.2040209@redhat.com> On 01/14/2014 11:31 AM, Jan Cholasta wrote: > On 10.1.2014 16:02, Petr Viktorin wrote: >> On 01/07/2014 01:54 PM, Jan Cholasta wrote: >>> On 16.12.2013 14:45, Petr Viktorin wrote: >>>> On 12/16/2013 10:22 AM, Jan Cholasta wrote: >>>>> On 13.12.2013 15:16, Petr Viktorin wrote: >>>>>> On 12/10/2013 04:05 PM, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I believe the time has come to drop support for the legacy (dn, >>>>>>> entry_attrs) tuple API and move to the new LDAPEntry API >>>>>>> exclusively. >>>>>>> The attached patches convert existing code which uses the old API to >>>>>>> the >>>>>>> new API and remove backward compatibility code from the ipaldap >>>>>>> module. >>>>>>> >>>>>>> Note that there are still some functions/methods which accept >>>>>>> separate >>>>>>> dn and entry_attrs arguments, they will be adapted to LDAPEntry >>>>>>> later. >>>>>>> >>>>>>> Honza >>>>>> >>>>>> The first N-1 patches can be tested,acked,pushed independently, >>>>>> right? >>>>> >>>>> Yes. >>>>> >>>>>> If that's the case, ACK for 225 >>>> >>>> Pushed that one to master, 5 more to go. >>>> bc3f3381c6bf0b4941889b775025a60f56318551 >>>> >> >> 226 needs a rebase. >> >> 227: in install/tools/ipa-adtrust-install: >> >> + entry_attrs = conn.make_entry( >> + dn, >> + objectclass=['top', 'pkiuser', 'nscontainer'], >> + usercertificate=cert) >> + conn.add_entry(entry_attrs) >> >> Shouldn't it be `usercertificate=[cert]` now? Similarly in ra_cert, and >> in ipa-server-install with ipacertificatesubjectbase >> >> Otherwise this looks good. >> >> 228: in ipaserver/install/plugins/update_idranges.py, again we should >> use lists >> >> Otherwise it looks good >> >> 229: ACK >> > > Rebased and fixed everything, updated patches attached. Here, patch 226 breaks tests for selinuxusermap_enable/disable, at least. The EmptyModlist and AlreadyActive/AlreadyInactive error is no longer raised, since the previous entry state is no longer retrieved. -- Petr? From pviktori at redhat.com Mon Jan 20 13:22:52 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 20 Jan 2014 14:22:52 +0100 Subject: [Freeipa-devel] [PATCH 0141] ipatests: Check for legacy_client attribute presence In-Reply-To: <52DCECE9.7080105@redhat.com> References: <52DCDF3C.2010004@redhat.com> <52DCECE9.7080105@redhat.com> Message-ID: <52DD232C.4000809@redhat.com> On 01/20/2014 10:31 AM, Tomas Babej wrote: > Yep, 100% bug coverage. > > Updated patch attached. > > On 01/20/2014 09:33 AM, Tomas Babej wrote: >> Hi, >> >> When legacy client tests fail during IPA installation, the legacy >> client test produces an additional misleading error >> (the real cause is reported as well). This happens due the fact >> that we try to cleanup host that was not yet defined. We need to >> check for this attribute being defined before unapplying fixes there. >> >> https://fedorahosted.org/freeipa/ticket/4124 This and 0141 look good, but I don't yet have the setup to test them -- after all these tests are still being developed. If they pass in your environment we should push as one-liners. -- Petr? From pviktori at redhat.com Mon Jan 20 14:28:04 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 20 Jan 2014 15:28:04 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52D99F70.3060305@redhat.com> References: <52D99F70.3060305@redhat.com> Message-ID: <52DD3274.9060401@redhat.com> On 01/17/2014 10:24 PM, Rob Crittenden wrote: > Implement an IPA RESTful Foreman-compatible smart proxy. This exposes > hosts and hostgroups via an unauthenticated REST API. The idea is that > this service runs on the Foreman server and only listens on local ports. > > It is a CherryPy-based server and that handles the majority of REST for us. > > I included some tests, they can be executed with: nosetests -v > smartproxy/tests Why is it not a part of ipatests? > It is installable as a separate RPM but the local machine needs to be an > IPA client. Configuration instructions are in the ipa-rest.1 man page. > > This requires an updated python-kerberos currently only available in > rawhide: python-kerberos-1.1-13.fc21 > > http://www.freeipa.org/page/V3/Smart_Proxy Is there any chance that this will grow into a real Python module? If so, it use a less generic directory name. -- Petr? From pviktori at redhat.com Mon Jan 20 14:33:49 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 20 Jan 2014 15:33:49 +0100 Subject: [Freeipa-devel] [PATCH 0142] ipatests: Remove sudo calls from tasks In-Reply-To: <52DCE1B4.1090707@redhat.com> References: <52DCE1B4.1090707@redhat.com> Message-ID: <52DD33CD.9050100@redhat.com> On 01/20/2014 09:43 AM, Tomas Babej wrote: > Hi, > > Sudo calls are not necessary since we log in as a root. Additionally, > sudo requires tty in default configuration, which is not acquired > when using OpenSSH transport. > > https://fedorahosted.org/freeipa/ticket/4125 > > Tomas ACK, pushed to: master: 5403648afd7dde69bf774f5dbdd2d07873ec3f84 ipa-3-3: dc1a1189e18c5d579570506bdf839f18aa94db6b -- Petr? From pviktori at redhat.com Mon Jan 20 14:36:20 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 20 Jan 2014 15:36:20 +0100 Subject: [Freeipa-devel] [PATCH 0141] ipatests: Check for legacy_client attribute presence In-Reply-To: <52DD232C.4000809@redhat.com> References: <52DCDF3C.2010004@redhat.com> <52DCECE9.7080105@redhat.com> <52DD232C.4000809@redhat.com> Message-ID: <52DD3464.1090109@redhat.com> On 01/20/2014 02:22 PM, Petr Viktorin wrote: > On 01/20/2014 10:31 AM, Tomas Babej wrote: >> Yep, 100% bug coverage. >> >> Updated patch attached. >> >> On 01/20/2014 09:33 AM, Tomas Babej wrote: >>> Hi, >>> >>> When legacy client tests fail during IPA installation, the legacy >>> client test produces an additional misleading error >>> (the real cause is reported as well). This happens due the fact >>> that we try to cleanup host that was not yet defined. We need to >>> check for this attribute being defined before unapplying fixes there. >>> >>> https://fedorahosted.org/freeipa/ticket/4124 > > This and 0141 look good, but I don't yet have the setup to test them -- > after all these tests are still being developed. > If they pass in your environment we should push as one-liners. Pushed to: master: 2adfaa3a9bd94707d9cc78f9fb6bd85d53477db2 ipa-3-3: cfaaeb9dadbb30cea0b1306f065c485d2dd82974 -- Petr? From abokovoy at redhat.com Mon Jan 20 14:49:21 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 20 Jan 2014 16:49:21 +0200 Subject: [Freeipa-devel] [PATCH] 0137 ipasam: remove child domains before removing trust Message-ID: <20140120144921.GT12003@redhat.com> Hi! Make sure we delete child domains before removing the trust itself as LDAP protocol does not allow removing non-leaf objects. This has non-obvious effect -- old code did remove cross-realm principals and then removed trust object. However, for trusts with child domains the trust domain object was not removed as LDAP server prevents removing non-leaf objects. It resulted in the object still existing but cross-realm principals missing. The trust is thus non-functioning. This situation can be triggered with a second 'ipa trust-add' call. Fix the code by removing child domains first and then remove the forest root trusted domain object. https://fedorahosted.org/freeipa/ticket/4126 -- / Alexander Bokovoy -------------- next part -------------- >From 320ac44326dfd48b7639f0b3637f974b96189cd7 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 20 Jan 2014 16:42:48 +0200 Subject: [PATCH 2/2] ipasam: delete trusted child domains before removing the trust LDAP protocol doesn't allow deleting non-leaf entries. One needs to remove all leaves first before removing the tree node. https://fedorahosted.org/freeipa/ticket/4126 --- daemons/ipa-sam/ipa_sam.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index 674085d..beca629 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -2437,6 +2437,44 @@ done: return status; } +static int delete_subtree(struct ldapsam_privates *ldap_state, const char* dn) +{ + LDAP *state = priv2ld(ldap_state); + int rc; + char *filter = NULL; + int scope = LDAP_SCOPE_SUBTREE; + LDAPMessage *result = NULL; + LDAPMessage *entry = NULL; + char *entry_dn = NULL; + + /* use 'dn' for a temporary talloc context */ + filter = talloc_asprintf(dn, "(objectClass=*)"); + if (filter == NULL) { + return LDAP_NO_MEMORY; + } + + rc = smbldap_search(ldap_state->smbldap_state, dn, scope, filter, NULL, 0, &result); + TALLOC_FREE(filter); + + if (result != NULL) { + smbldap_talloc_autofree_ldapmsg(dn, result); + } + + for (entry = ldap_first_entry(state, result); + entry != NULL; + entry = ldap_next_entry(state, entry)) { + entry_dn = get_dn(dn, state, entry); + /* remove child entries */ + if ((entry_dn != NULL) && (strcmp(entry_dn, dn) != 0)) { + rc = smbldap_delete(ldap_state->smbldap_state, entry_dn); + } + } + rc = smbldap_delete(ldap_state->smbldap_state, dn); + + /* caller will destroy dn */ + return rc; +} + static NTSTATUS ipasam_del_trusted_domain(struct pdb_methods *methods, const char *domain) { @@ -2490,6 +2528,11 @@ static NTSTATUS ipasam_del_trusted_domain(struct pdb_methods *methods, } ret = smbldap_delete(ldap_state->smbldap_state, dn); + if (ret == LDAP_NOT_ALLOWED_ON_NONLEAF) { + /* delete_subtree will use 'dn' as temporary context too */ + ret = delete_subtree(ldap_state, dn); + } + if (ret != LDAP_SUCCESS) { status = NT_STATUS_UNSUCCESSFUL; goto done; -- 1.8.4.2 From mkosek at redhat.com Mon Jan 20 15:01:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Jan 2014 16:01:38 +0100 Subject: [Freeipa-devel] [PATCH] 0137 ipasam: remove child domains before removing trust In-Reply-To: <20140120144921.GT12003@redhat.com> References: <20140120144921.GT12003@redhat.com> Message-ID: <52DD3A52.8050303@redhat.com> On 01/20/2014 03:49 PM, Alexander Bokovoy wrote: > Hi! > > Make sure we delete child domains before removing the trust itself as > LDAP protocol does not allow removing non-leaf objects. > > This has non-obvious effect -- old code did remove cross-realm > principals and then removed trust object. However, for trusts with child > domains the trust domain object was not removed as LDAP server prevents > removing non-leaf objects. It resulted in the object still existing but > cross-realm principals missing. The trust is thus non-functioning. This > situation can be triggered with a second 'ipa trust-add' call. > > Fix the code by removing child domains first and then remove the forest > root trusted domain object. > > https://fedorahosted.org/freeipa/ticket/4126 Thanks for the patch! I did not test, I am just thinking about this search: + + rc = smbldap_search(ldap_state->smbldap_state, dn, scope, filter, NULL, 0, &result); + TALLOC_FREE(filter); + - shouldn't you search with SCOPE_ONELEVEL given we do not dive deeper anyway? - shouldn't we search with filter "(objectclass=ipaNTTrustedDomain)" just to make sure we do not delete anything we do not want to be deleted? For example if the function gets a wrong DN, we may want to make sure we don't delete the whole DIT Additionally, I think we should add few DEBUG messages, so that in debug log we see we are doing this deletion. Martin From abokovoy at redhat.com Mon Jan 20 15:18:30 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 20 Jan 2014 17:18:30 +0200 Subject: [Freeipa-devel] [PATCH] 0137 ipasam: remove child domains before removing trust In-Reply-To: <52DD3A52.8050303@redhat.com> References: <20140120144921.GT12003@redhat.com> <52DD3A52.8050303@redhat.com> Message-ID: <20140120151830.GU12003@redhat.com> On Mon, 20 Jan 2014, Martin Kosek wrote: >On 01/20/2014 03:49 PM, Alexander Bokovoy wrote: >> Hi! >> >> Make sure we delete child domains before removing the trust itself as >> LDAP protocol does not allow removing non-leaf objects. >> >> This has non-obvious effect -- old code did remove cross-realm >> principals and then removed trust object. However, for trusts with child >> domains the trust domain object was not removed as LDAP server prevents >> removing non-leaf objects. It resulted in the object still existing but >> cross-realm principals missing. The trust is thus non-functioning. This >> situation can be triggered with a second 'ipa trust-add' call. >> >> Fix the code by removing child domains first and then remove the forest >> root trusted domain object. >> >> https://fedorahosted.org/freeipa/ticket/4126 > >Thanks for the patch! I did not test, I am just thinking about this search: > >+ >+ rc = smbldap_search(ldap_state->smbldap_state, dn, scope, filter, NULL, 0, >&result); >+ TALLOC_FREE(filter); >+ > > - shouldn't you search with SCOPE_ONELEVEL given we do not dive deeper anyway? No. We need to remove dn but to remove it we need to remove everything under it. Thus, we don't care what is there, since whole dn (cn=TRUSTNAME,cn=ad,cn=trusts,$SUFFIX) will be deleted anyway. >- shouldn't we search with filter "(objectclass=ipaNTTrustedDomain)" just to >make sure we do not delete anything we do not want to be deleted? For example >if the function gets a wrong DN, we may want to make sure we don't delete the >whole DIT We should delete everything under 'dn' which is cn=TRUSTNAME,cn=ad,cn=trusts,$SUFFIX >Additionally, I think we should add few DEBUG messages, so that in debug log we >see we are doing this deletion. We'll see them at level 5 anyway because of smbldap_delete(): [2014/01/20 17:14:02.965144, 5, pid=5111, effective(874400000, 874400000), real(874400000, 0)] ../source3/lib/smbldap.c:1535(smbldap_delete) smbldap_delete: dn => [cn=ad12y.ad12x.weald.vda.li,cn=ad12x.weald.vda.li,cn=ad,cn=trusts,dc=ipa,dc=weald,dc=vda,dc=li] [2014/01/20 17:14:03.034982, 5, pid=5111, effective(874400000, 874400000), real(874400000, 0)] ../source3/lib/smbldap.c:1535(smbldap_delete) smbldap_delete: dn => [cn=ad12x.weald.vda.li,cn=ad,cn=trusts,dc=ipa,dc=weald,dc=vda,dc=li] I don't think we need to add more. -- / Alexander Bokovoy From tbabej at redhat.com Mon Jan 20 15:20:10 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 20 Jan 2014 16:20:10 +0100 Subject: [Freeipa-devel] [Trusts] Admin enforcing POSIX range when it's not being detected Message-ID: <52DD3EAA.7000903@redhat.com> Hey! Let us discuss a which behaviour we should take with trust-add command. Currently, if you run: $ ipa trust-add --type ad Range type (POSIX or non-POSIX) is being detected automatically. However, if you run: $ ipa trust-add --type ad --range-type=ipa-ad-trust-posix You override the detection of the SFU support on the AD. This is not a problem when you have a AD with POSIX support, and you try to enforce a non-posix range type. However, if you *think* you have SFU up and running, but you don't (or we just can't access the information for whatever reason), you end up enforcing POSIX range type while not defining any of the expected attributes. Currently, not defining base_id simply means you will have one generated from SID. So you end up with a posix range like this one: Range name: ADPOSIX.QE_id_range First Posix ID of the range: *280400000* Number of IDs in the range: 200000 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-3655340000-3880942204-3419777279 Range type: Active Directory trust range *with POSIX attributes* The question is, what position should we take? 1.) Are we going to stick with the defaults estabilished by AD? (base_id: 10000) 2.) Or are we going to bail out in this case and report an error? Tomas From simo at redhat.com Mon Jan 20 15:36:10 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 20 Jan 2014 10:36:10 -0500 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <52DCF568.9000508@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> Message-ID: <1390232170.2370.60.camel@willson.li.ssimo.org> On Mon, 2014-01-20 at 11:07 +0100, Jan Cholasta wrote: > On 17.1.2014 11:39, Jan Cholasta wrote: > > On 10.1.2014 13:34, Martin Kosek wrote: > >> On 01/09/2014 04:49 PM, Simo Sorce wrote: > >>> On Thu, 2014-01-09 at 10:44 -0500, Rob Crittenden wrote: > >>>> Martin Kosek wrote: > >>>>> On 01/09/2014 03:12 PM, Simo Sorce wrote: > >>> > >>>>>>> Also maybe we should allow admins to bypass the need to have an > >>>>>>> actual > >>>>>>> object to represent the alt name ? > >>>> > >>>> I'd rather not. This would allow a rogue admin to create a cert for > >>>> www.google.com. Sure, they could also create a host for that but > >>>> forcing > >>>> them to add more entries increases the chances of them getting caught > >>>> doing it. > >>> > >>> They can remove the host right after they create a cert, I honestly do > >>> not think this is a valid concern. If your admin is rouge he can already > >>> take full ownership of your infrastructure in many ways, preventing > >>> setting a name in a cert doesn't really make a difference IMO. > >>> > >>> However I would be ok to limit this to some new "Security Admin/CA > >>> Admin" role that is not assigned by default. > >>> > >>> Simo. > >>> > >> > >> Ok, let's reach some conclusion here. I would really like to not defer > >> this > >> feature for too long, it is quite wanted. Would creating new virtual > >> operation > >> "Request certificate with SAN" make the situation better? It would not > >> be so > >> difficult to do, the check_access function can already access virtual > >> operation > >> name as a parameter, we just need to call it. > > > > Why don't we treat SAN hostnames the same way as the subject hostname? > > The way I see it, with SAN the only difference is that there is a set of > > hostnames instead of just a single hostname, so maybe we should support > > requesting a certificate for a set of hosts/services instead of just a > > single host/service. > > > > As far as authorization is concerned, currently you can request a > > certificate for a single host/service, if you have the "Request > > certificate" permission and write access to the host/service entry. With > > multiple hosts/services, you would be able to request a certificate if > > you have the "Request certificate" permission and write access to *all* > > of the host/certificate entries you are requesting the certificate for. > > > > Effectively this means that cert-request would accept multiple > > principals instead of single principal and the automatic revocation code > > in cert-request, host-del and service-del would take into account that a > > single certificate might be assigned to multiple entities. > > > > See attachment for patch which implements the above design. Hi Jan, I am a bit too far removed from the code to fully understand the change just from the diff. Could you please add a short explanation in the commit message, a bout what the code does now differently than it did before. For example although I understand the checks you do on subjectname +subjectaltname I do not know where the principals come from or why you have a comment that says principals must all be of the same service type. Simo. -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Mon Jan 20 15:42:15 2014 From: sbose at redhat.com (Sumit Bose) Date: Mon, 20 Jan 2014 16:42:15 +0100 Subject: [Freeipa-devel] [PATCH] 0137 ipasam: remove child domains before removing trust In-Reply-To: <20140120151830.GU12003@redhat.com> References: <20140120144921.GT12003@redhat.com> <52DD3A52.8050303@redhat.com> <20140120151830.GU12003@redhat.com> Message-ID: <20140120154215.GU23022@localhost.localdomain> On Mon, Jan 20, 2014 at 05:18:30PM +0200, Alexander Bokovoy wrote: > On Mon, 20 Jan 2014, Martin Kosek wrote: > >On 01/20/2014 03:49 PM, Alexander Bokovoy wrote: > >>Hi! > >> > >>Make sure we delete child domains before removing the trust itself as > >>LDAP protocol does not allow removing non-leaf objects. > >> > >>This has non-obvious effect -- old code did remove cross-realm > >>principals and then removed trust object. However, for trusts with child > >>domains the trust domain object was not removed as LDAP server prevents > >>removing non-leaf objects. It resulted in the object still existing but > >>cross-realm principals missing. The trust is thus non-functioning. This > >>situation can be triggered with a second 'ipa trust-add' call. > >> > >>Fix the code by removing child domains first and then remove the forest > >>root trusted domain object. > >> > >>https://fedorahosted.org/freeipa/ticket/4126 > > > >Thanks for the patch! I did not test, I am just thinking about this search: > > > >+ > >+ rc = smbldap_search(ldap_state->smbldap_state, dn, scope, filter, NULL, 0, > >&result); > >+ TALLOC_FREE(filter); > >+ > > > >- shouldn't you search with SCOPE_ONELEVEL given we do not dive deeper anyway? > No. We need to remove dn but to remove it we need to remove everything > under it. Thus, we don't care what is there, since whole dn > (cn=TRUSTNAME,cn=ad,cn=trusts,$SUFFIX) will be deleted anyway. > > >- shouldn't we search with filter "(objectclass=ipaNTTrustedDomain)" just to > >make sure we do not delete anything we do not want to be deleted? For example > >if the function gets a wrong DN, we may want to make sure we don't delete the > >whole DIT > We should delete everything under 'dn' which is cn=TRUSTNAME,cn=ad,cn=trusts,$SUFFIX The user samba uses to bind to LDAP should not have the privileges to remove the whole tree. So in the worst case it will just remove all trusts. I agree with Alexander that we should remove everything below the DN of the forest root. The original idea behind putting the other domains in the forest below was that be removing the sub-tree all information about the trust was gone (except for the idranges, but that's a different story). bye, Sumit > > >Additionally, I think we should add few DEBUG messages, so that in debug log we > >see we are doing this deletion. > We'll see them at level 5 anyway because of smbldap_delete(): > [2014/01/20 17:14:02.965144, 5, pid=5111, effective(874400000, 874400000), real(874400000, 0)] ../source3/lib/smbldap.c:1535(smbldap_delete) > smbldap_delete: dn => [cn=ad12y.ad12x.weald.vda.li,cn=ad12x.weald.vda.li,cn=ad,cn=trusts,dc=ipa,dc=weald,dc=vda,dc=li] > [2014/01/20 17:14:03.034982, 5, pid=5111, effective(874400000, 874400000), real(874400000, 0)] ../source3/lib/smbldap.c:1535(smbldap_delete) > smbldap_delete: dn => [cn=ad12x.weald.vda.li,cn=ad,cn=trusts,dc=ipa,dc=weald,dc=vda,dc=li] > > I don't think we need to add more. > -- > / Alexander Bokovoy > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mkosek at redhat.com Mon Jan 20 15:56:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Jan 2014 16:56:38 +0100 Subject: [Freeipa-devel] [PATCH] 0137 ipasam: remove child domains before removing trust In-Reply-To: <20140120154215.GU23022@localhost.localdomain> References: <20140120144921.GT12003@redhat.com> <52DD3A52.8050303@redhat.com> <20140120151830.GU12003@redhat.com> <20140120154215.GU23022@localhost.localdomain> Message-ID: <52DD4736.2060906@redhat.com> On 01/20/2014 04:42 PM, Sumit Bose wrote: > On Mon, Jan 20, 2014 at 05:18:30PM +0200, Alexander Bokovoy wrote: >> On Mon, 20 Jan 2014, Martin Kosek wrote: >>> On 01/20/2014 03:49 PM, Alexander Bokovoy wrote: >>>> Hi! >>>> >>>> Make sure we delete child domains before removing the trust itself as >>>> LDAP protocol does not allow removing non-leaf objects. >>>> >>>> This has non-obvious effect -- old code did remove cross-realm >>>> principals and then removed trust object. However, for trusts with child >>>> domains the trust domain object was not removed as LDAP server prevents >>>> removing non-leaf objects. It resulted in the object still existing but >>>> cross-realm principals missing. The trust is thus non-functioning. This >>>> situation can be triggered with a second 'ipa trust-add' call. >>>> >>>> Fix the code by removing child domains first and then remove the forest >>>> root trusted domain object. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4126 >>> >>> Thanks for the patch! I did not test, I am just thinking about this search: >>> >>> + >>> + rc = smbldap_search(ldap_state->smbldap_state, dn, scope, filter, NULL, 0, >>> &result); >>> + TALLOC_FREE(filter); >>> + >>> >>> - shouldn't you search with SCOPE_ONELEVEL given we do not dive deeper anyway? >> No. We need to remove dn but to remove it we need to remove everything >> under it. Thus, we don't care what is there, since whole dn >> (cn=TRUSTNAME,cn=ad,cn=trusts,$SUFFIX) will be deleted anyway. >> >>> - shouldn't we search with filter "(objectclass=ipaNTTrustedDomain)" just to >>> make sure we do not delete anything we do not want to be deleted? For example >>> if the function gets a wrong DN, we may want to make sure we don't delete the >>> whole DIT >> We should delete everything under 'dn' which is cn=TRUSTNAME,cn=ad,cn=trusts,$SUFFIX > > The user samba uses to bind to LDAP should not have the privileges to > remove the whole tree. So in the worst case it will just remove all > trusts. > > I agree with Alexander that we should remove everything below the DN of > the forest root. The original idea behind putting the other domains in > the forest below was that be removing the sub-tree all information about > the trust was gone (except for the idranges, but that's a different > story). > > bye, > Sumit Ok, makes sense. I have no conceptual objection then. Thanks, Martin From rcritten at redhat.com Mon Jan 20 16:21:23 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 20 Jan 2014 11:21:23 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52DD3274.9060401@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> Message-ID: <52DD4D03.1050302@redhat.com> Petr Viktorin wrote: > On 01/17/2014 10:24 PM, Rob Crittenden wrote: >> Implement an IPA RESTful Foreman-compatible smart proxy. This exposes >> hosts and hostgroups via an unauthenticated REST API. The idea is that >> this service runs on the Foreman server and only listens on local ports. >> >> It is a CherryPy-based server and that handles the majority of REST >> for us. >> >> I included some tests, they can be executed with: nosetests -v >> smartproxy/tests > > Why is it not a part of ipatests? I can move it if it's a show-stopper. It seemed specific to this one directory so I stuck it there. It isn't relevant for most testing and requires some manual configuration (though CI could handle it). > >> It is installable as a separate RPM but the local machine needs to be an >> IPA client. Configuration instructions are in the ipa-rest.1 man page. >> >> This requires an updated python-kerberos currently only available in >> rawhide: python-kerberos-1.1-13.fc21 >> >> http://www.freeipa.org/page/V3/Smart_Proxy > > Is there any chance that this will grow into a real Python module? If > so, it use a less generic directory name. I guess never say never but at least for now the scope is very narrow when it comes to REST which is why I embedded everything into the server module. I don't see it changing any time soon, but if renaming the subdirectory would help I'd be open to suggestions. rob From abokovoy at redhat.com Mon Jan 20 16:42:09 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 20 Jan 2014 18:42:09 +0200 Subject: [Freeipa-devel] [PATCH] 451 Hide trust-resolve command In-Reply-To: <52D949B8.7000402@redhat.com> References: <52D949B8.7000402@redhat.com> Message-ID: <20140120164209.GV12003@redhat.com> On Fri, 17 Jan 2014, Martin Kosek wrote: >We do not need to expose a public FreeIPA specific interface to resolve >SIDs to names. The interface is only used internally to resolve SIDs >when external group members are listed. Additionally, the command interface >is not prepared for regular user and can give rather confusing results. > >Hide it from CLI. The API itself is still accessible and compatible with >older clients. > >https://fedorahosted.org/freeipa/ticket/4113 ACK, works fine for me. Web UI shows external members resolved. -- / Alexander Bokovoy From jcholast at redhat.com Mon Jan 20 16:49:10 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 20 Jan 2014 17:49:10 +0100 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <1390232170.2370.60.camel@willson.li.ssimo.org> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> Message-ID: <52DD5386.2090903@redhat.com> On 20.1.2014 16:36, Simo Sorce wrote: > On Mon, 2014-01-20 at 11:07 +0100, Jan Cholasta wrote: >> On 17.1.2014 11:39, Jan Cholasta wrote: >>> On 10.1.2014 13:34, Martin Kosek wrote: >>>> On 01/09/2014 04:49 PM, Simo Sorce wrote: >>>>> On Thu, 2014-01-09 at 10:44 -0500, Rob Crittenden wrote: >>>>>> Martin Kosek wrote: >>>>>>> On 01/09/2014 03:12 PM, Simo Sorce wrote: >>>>> >>>>>>>>> Also maybe we should allow admins to bypass the need to have an >>>>>>>>> actual >>>>>>>>> object to represent the alt name ? >>>>>> >>>>>> I'd rather not. This would allow a rogue admin to create a cert for >>>>>> www.google.com. Sure, they could also create a host for that but >>>>>> forcing >>>>>> them to add more entries increases the chances of them getting caught >>>>>> doing it. >>>>> >>>>> They can remove the host right after they create a cert, I honestly do >>>>> not think this is a valid concern. If your admin is rouge he can already >>>>> take full ownership of your infrastructure in many ways, preventing >>>>> setting a name in a cert doesn't really make a difference IMO. >>>>> >>>>> However I would be ok to limit this to some new "Security Admin/CA >>>>> Admin" role that is not assigned by default. >>>>> >>>>> Simo. >>>>> >>>> >>>> Ok, let's reach some conclusion here. I would really like to not defer >>>> this >>>> feature for too long, it is quite wanted. Would creating new virtual >>>> operation >>>> "Request certificate with SAN" make the situation better? It would not >>>> be so >>>> difficult to do, the check_access function can already access virtual >>>> operation >>>> name as a parameter, we just need to call it. >>> >>> Why don't we treat SAN hostnames the same way as the subject hostname? >>> The way I see it, with SAN the only difference is that there is a set of >>> hostnames instead of just a single hostname, so maybe we should support >>> requesting a certificate for a set of hosts/services instead of just a >>> single host/service. >>> >>> As far as authorization is concerned, currently you can request a >>> certificate for a single host/service, if you have the "Request >>> certificate" permission and write access to the host/service entry. With >>> multiple hosts/services, you would be able to request a certificate if >>> you have the "Request certificate" permission and write access to *all* >>> of the host/certificate entries you are requesting the certificate for. >>> >>> Effectively this means that cert-request would accept multiple >>> principals instead of single principal and the automatic revocation code >>> in cert-request, host-del and service-del would take into account that a >>> single certificate might be assigned to multiple entities. >>> >> >> See attachment for patch which implements the above design. > > Hi Jan, I am a bit too far removed from the code to fully understand the > change just from the diff. > > Could you please add a short explanation in the commit message, a bout > what the code does now differently than it did before. Done. > For example although I understand the checks you do on subjectname > +subjectaltname I do not know where the principals come from or why you > have a comment that says principals must all be of the same service > type. Principals come from the --principal option, which can have multiple values with the patch. The service name constraint is there so that there is a 1-to-1 mapping between principals and hostnames in the request (both subject and SAN). Without this you would be able to request a certificate for completely unrelated services and I was not sure if it's OK to allow that, since the use case here is load balancing (right?) > > Simo. > > Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-234.1-Support-requests-with-SAN-in-cert-request.patch Type: text/x-patch Size: 12860 bytes Desc: not available URL: From abokovoy at redhat.com Mon Jan 20 17:01:27 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 20 Jan 2014 19:01:27 +0200 Subject: [Freeipa-devel] [PATCH] 543 Trust domains Web UI In-Reply-To: <52D96E38.1020308@redhat.com> References: <52D96E38.1020308@redhat.com> Message-ID: <20140120170127.GW12003@redhat.com> On Fri, 17 Jan 2014, Petr Vobornik wrote: >Note: this version of the patch is especially prepared for ipa-3-3 branch. > >Add Web UI counterpart of following CLI commands: > >* trust-fetch-domains Refresh list of the domains associated with the trust >* trustdomain-del Remove infromation about the domain associated with >the trust. >* trustdomain-disable Disable use of IPA resources by the domain of >the trust >* trustdomain-enable Allow use of IPA resources by the domain of the trust >* trustdomain-find Search domains of the trust > >https://fedorahosted.org/freeipa/ticket/4119 ACK functionally, everything works for me. I wonder if you could make UI a bit smarter and prevent enable/disable actions for the forest root trusted domain. Right now selecting it for 'disable' will show you an error telling that disabling root domain is not possible. -- / Alexander Bokovoy From mkosek at redhat.com Mon Jan 20 17:26:30 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Jan 2014 18:26:30 +0100 Subject: [Freeipa-devel] [PATCH] 451 Hide trust-resolve command In-Reply-To: <20140120164209.GV12003@redhat.com> References: <52D949B8.7000402@redhat.com> <20140120164209.GV12003@redhat.com> Message-ID: <52DD5C46.6040607@redhat.com> On 01/20/2014 05:42 PM, Alexander Bokovoy wrote: > On Fri, 17 Jan 2014, Martin Kosek wrote: >> We do not need to expose a public FreeIPA specific interface to resolve >> SIDs to names. The interface is only used internally to resolve SIDs >> when external group members are listed. Additionally, the command interface >> is not prepared for regular user and can give rather confusing results. >> >> Hide it from CLI. The API itself is still accessible and compatible with >> older clients. >> >> https://fedorahosted.org/freeipa/ticket/4113 > ACK, works fine for me. Web UI shows external members resolved. Pushed to master, ipa-3-3. Martin From simo at redhat.com Mon Jan 20 17:35:55 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 20 Jan 2014 12:35:55 -0500 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <52DD5386.2090903@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> Message-ID: <1390239355.2370.72.camel@willson.li.ssimo.org> On Mon, 2014-01-20 at 17:49 +0100, Jan Cholasta wrote: > On 20.1.2014 16:36, Simo Sorce wrote: > > On Mon, 2014-01-20 at 11:07 +0100, Jan Cholasta wrote: > >> On 17.1.2014 11:39, Jan Cholasta wrote: > >>> On 10.1.2014 13:34, Martin Kosek wrote: > >>>> On 01/09/2014 04:49 PM, Simo Sorce wrote: > >>>>> On Thu, 2014-01-09 at 10:44 -0500, Rob Crittenden wrote: > >>>>>> Martin Kosek wrote: > >>>>>>> On 01/09/2014 03:12 PM, Simo Sorce wrote: > >>>>> > >>>>>>>>> Also maybe we should allow admins to bypass the need to have an > >>>>>>>>> actual > >>>>>>>>> object to represent the alt name ? > >>>>>> > >>>>>> I'd rather not. This would allow a rogue admin to create a cert for > >>>>>> www.google.com. Sure, they could also create a host for that but > >>>>>> forcing > >>>>>> them to add more entries increases the chances of them getting caught > >>>>>> doing it. > >>>>> > >>>>> They can remove the host right after they create a cert, I honestly do > >>>>> not think this is a valid concern. If your admin is rouge he can already > >>>>> take full ownership of your infrastructure in many ways, preventing > >>>>> setting a name in a cert doesn't really make a difference IMO. > >>>>> > >>>>> However I would be ok to limit this to some new "Security Admin/CA > >>>>> Admin" role that is not assigned by default. > >>>>> > >>>>> Simo. > >>>>> > >>>> > >>>> Ok, let's reach some conclusion here. I would really like to not defer > >>>> this > >>>> feature for too long, it is quite wanted. Would creating new virtual > >>>> operation > >>>> "Request certificate with SAN" make the situation better? It would not > >>>> be so > >>>> difficult to do, the check_access function can already access virtual > >>>> operation > >>>> name as a parameter, we just need to call it. > >>> > >>> Why don't we treat SAN hostnames the same way as the subject hostname? > >>> The way I see it, with SAN the only difference is that there is a set of > >>> hostnames instead of just a single hostname, so maybe we should support > >>> requesting a certificate for a set of hosts/services instead of just a > >>> single host/service. > >>> > >>> As far as authorization is concerned, currently you can request a > >>> certificate for a single host/service, if you have the "Request > >>> certificate" permission and write access to the host/service entry. With > >>> multiple hosts/services, you would be able to request a certificate if > >>> you have the "Request certificate" permission and write access to *all* > >>> of the host/certificate entries you are requesting the certificate for. > >>> > >>> Effectively this means that cert-request would accept multiple > >>> principals instead of single principal and the automatic revocation code > >>> in cert-request, host-del and service-del would take into account that a > >>> single certificate might be assigned to multiple entities. > >>> > >> > >> See attachment for patch which implements the above design. > > > > Hi Jan, I am a bit too far removed from the code to fully understand the > > change just from the diff. > > > > Could you please add a short explanation in the commit message, a bout > > what the code does now differently than it did before. > > Done. > > > For example although I understand the checks you do on subjectname > > +subjectaltname I do not know where the principals come from or why you > > have a comment that says principals must all be of the same service > > type. > > Principals come from the --principal option, which can have multiple > values with the patch. > > The service name constraint is there so that there is a 1-to-1 mapping > between principals and hostnames in the request (both subject and SAN). > Without this you would be able to request a certificate for completely > unrelated services and I was not sure if it's OK to allow that, since > the use case here is load balancing (right?) > > > > > Simo. > > > > > > Updated patch attached. > Sorry have to NACK. I was confused by the code so asked on IRC: so if I have subectname = one.ipa.lan and altname = two.ipa.net then the certificate is anchored to both HTTP/one.ipa.net AND HTTP/two.ipa.net ? yep and what happens when I create other.ipa.net with altname two.ipa.net ? does HTTP/two.ipa.net now have 2 certificates anchored ? the old certificate gets revoked and removed from HTTP/one.ipa.net and HTTP/two.ipa.net, then the new certificate is issued and anchored to HTTP/two.ipa.net and HTTP/other.ipa.net This defeats the purpose of having altnames. There are 2 reasons to have altnames: 1. just add aliases that are not shared by any other service 2. have a common alias between multiple service to allow loadbalancing (1) will not be affected, but (2) would be impossible, because as soon as I try to create the cert for one of the other nodes to be balanced the previous nodes get their certificates revoked, which defeats the whole point of creating them with a common altname. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Tue Jan 21 09:20:11 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 21 Jan 2014 10:20:11 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52DD4D03.1050302@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> Message-ID: <52DE3BCB.5030107@redhat.com> On 01/20/2014 05:21 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 01/17/2014 10:24 PM, Rob Crittenden wrote: >>> Implement an IPA RESTful Foreman-compatible smart proxy. This exposes >>> hosts and hostgroups via an unauthenticated REST API. The idea is that >>> this service runs on the Foreman server and only listens on local ports. >>> >>> It is a CherryPy-based server and that handles the majority of REST >>> for us. >>> >>> I included some tests, they can be executed with: nosetests -v >>> smartproxy/tests >> >> Why is it not a part of ipatests? > > I can move it if it's a show-stopper. It seemed specific to this one > directory so I stuck it there. It isn't relevant for most testing and > requires some manual configuration (though CI could handle it). Not strictly a show stopper, but please move it. At the very least it should end up in the freeipa-tests package. A lot of the tests (integration, webUI) need manual configuration, so this would be no exception. Of course the tests should be skipped if the configuration was not done, and the config instructions should be added to/linked from http://www.freeipa.org/page/Testing >>> It is installable as a separate RPM but the local machine needs to be an >>> IPA client. Configuration instructions are in the ipa-rest.1 man page. >>> >>> This requires an updated python-kerberos currently only available in >>> rawhide: python-kerberos-1.1-13.fc21 >>> >>> http://www.freeipa.org/page/V3/Smart_Proxy >> >> Is there any chance that this will grow into a real Python module? If >> so, it use a less generic directory name. > > I guess never say never but at least for now the scope is very narrow > when it comes to REST which is why I embedded everything into the server > module. I don't see it changing any time soon, but if renaming the > subdirectory would help I'd be open to suggestions. OK, never mind then -- Petr? From pvoborni at redhat.com Tue Jan 21 09:30:34 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 21 Jan 2014 10:30:34 +0100 Subject: [Freeipa-devel] [PATCH] 543 Trust domains Web UI In-Reply-To: <20140120170127.GW12003@redhat.com> References: <52D96E38.1020308@redhat.com> <20140120170127.GW12003@redhat.com> Message-ID: <52DE3E3A.2060703@redhat.com> On 20.1.2014 18:01, Alexander Bokovoy wrote: > On Fri, 17 Jan 2014, Petr Vobornik wrote: >> Note: this version of the patch is especially prepared for ipa-3-3 >> branch. >> >> Add Web UI counterpart of following CLI commands: >> >> * trust-fetch-domains Refresh list of the domains associated with the >> trust >> * trustdomain-del Remove infromation about the domain associated with >> the trust. >> * trustdomain-disable Disable use of IPA resources by the domain of >> the trust >> * trustdomain-enable Allow use of IPA resources by the domain of the >> trust >> * trustdomain-find Search domains of the trust >> >> https://fedorahosted.org/freeipa/ticket/4119 > ACK functionally, everything works for me. > > I wonder if you could make UI a bit smarter and prevent enable/disable > actions for the forest root trusted domain. Right now selecting it for > 'disable' will show you an error telling that disabling root domain is > not possible. > > Some enhancement could be done in this area. Similar "issue" is also present when enabling/disabling already enabled/disabled items (not just in trusted domains but also in users, HBAC and SUDO rules... pages). But what should be the ideal behavior? We must take into considerations facts as follows: - button which executes the action is enabled/disabled based on user selection - user can select multiple items - some of those items are suitable for the action (e.g., disabled items for enable action), some not (disabled for disable). - backend will tell us what succeeded and what not Current behavior: - action button is enabled when user selects any item - after action execution, user is told, if some or all items were not suitable (the action was not performed for them). If server behaves correctly this UI behavior should not cause any harm. Some possible enhancements are: 1. Do not enable action button if all selected items are not suitable for the action. If some are suitable, continue with current behavior 2. If some of selected items are not suitable, show a warning dialog which will list items for which the action will be executed and items for which it won't be. After confirmation, request will be sent only with suitable items. 3. Do not enable action button if some selected item is not suitable. #1 and #2 can be combined. I'm not a fan of #3; sounds more like a drawback. Do you have something similar in mind? Anyway I don't think this is a material for IPA 3.3. If you agree, I will open a new ticket and also ask Kyle for his option on this topic. -- Petr Vobornik From abokovoy at redhat.com Tue Jan 21 09:43:06 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 21 Jan 2014 11:43:06 +0200 Subject: [Freeipa-devel] [PATCH] 543 Trust domains Web UI In-Reply-To: <52DE3E3A.2060703@redhat.com> References: <52D96E38.1020308@redhat.com> <20140120170127.GW12003@redhat.com> <52DE3E3A.2060703@redhat.com> Message-ID: <20140121094306.GY12003@redhat.com> On Tue, 21 Jan 2014, Petr Vobornik wrote: >On 20.1.2014 18:01, Alexander Bokovoy wrote: >>On Fri, 17 Jan 2014, Petr Vobornik wrote: >>>Note: this version of the patch is especially prepared for ipa-3-3 >>>branch. >>> >>>Add Web UI counterpart of following CLI commands: >>> >>>* trust-fetch-domains Refresh list of the domains associated with the >>>trust >>>* trustdomain-del Remove infromation about the domain associated with >>>the trust. >>>* trustdomain-disable Disable use of IPA resources by the domain of >>>the trust >>>* trustdomain-enable Allow use of IPA resources by the domain of the >>>trust >>>* trustdomain-find Search domains of the trust >>> >>>https://fedorahosted.org/freeipa/ticket/4119 >>ACK functionally, everything works for me. >> >>I wonder if you could make UI a bit smarter and prevent enable/disable >>actions for the forest root trusted domain. Right now selecting it for >>'disable' will show you an error telling that disabling root domain is >>not possible. >> >> > >Some enhancement could be done in this area. Similar "issue" is also >present when enabling/disabling already enabled/disabled items (not >just in trusted domains but also in users, HBAC and SUDO rules... >pages). > >But what should be the ideal behavior? > >We must take into considerations facts as follows: >- button which executes the action is enabled/disabled based on user >selection >- user can select multiple items >- some of those items are suitable for the action (e.g., disabled >items for enable action), some not (disabled for disable). >- backend will tell us what succeeded and what not > >Current behavior: >- action button is enabled when user selects any item >- after action execution, user is told, if some or all items were not >suitable (the action was not performed for them). > >If server behaves correctly this UI behavior should not cause any harm. > >Some possible enhancements are: >1. Do not enable action button if all selected items are not suitable >for the action. If some are suitable, continue with current behavior > >2. If some of selected items are not suitable, show a warning dialog >which will list items for which the action will be executed and items >for which it won't be. After confirmation, request will be sent only >with suitable items. > >3. Do not enable action button if some selected item is not suitable. > >#1 and #2 can be combined. I'm not a fan of #3; sounds more like a drawback. > >Do you have something similar in mind? #1 and #2 would require either embedding knowledge about specific items in Web UI or extending metadata we have about commands. In both cases it looks a bit weird as it is not a metadata per se. I'm not even sure we can maintain it properly in all cases. >Anyway I don't think this is a material for IPA 3.3. If you agree, I >will open a new ticket and also ask Kyle for his option on this >topic. Yes, it is something for future but given options you presented I don't see much future in it... -- / Alexander Bokovoy From sbose at redhat.com Tue Jan 21 09:54:49 2014 From: sbose at redhat.com (Sumit Bose) Date: Tue, 21 Jan 2014 10:54:49 +0100 Subject: [Freeipa-devel] [PATCH] 0137 ipasam: remove child domains before removing trust In-Reply-To: <20140120144921.GT12003@redhat.com> References: <20140120144921.GT12003@redhat.com> Message-ID: <20140121095449.GC23022@localhost.localdomain> On Mon, Jan 20, 2014 at 04:49:21PM +0200, Alexander Bokovoy wrote: > Hi! > > Make sure we delete child domains before removing the trust itself as > LDAP protocol does not allow removing non-leaf objects. > > This has non-obvious effect -- old code did remove cross-realm > principals and then removed trust object. However, for trusts with child > domains the trust domain object was not removed as LDAP server prevents > removing non-leaf objects. It resulted in the object still existing but > cross-realm principals missing. The trust is thus non-functioning. This > situation can be triggered with a second 'ipa trust-add' call. > > Fix the code by removing child domains first and then remove the forest > root trusted domain object. > > https://fedorahosted.org/freeipa/ticket/4126 Patch is working as expected. But I would suggest to remove the 'const' from the declaration of dn (also in the caller) to avoid compiler warnings. As an alternative you can take a different talloc context, but using dn here makes sense. bye, Sumit From abokovoy at redhat.com Tue Jan 21 10:17:42 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 21 Jan 2014 12:17:42 +0200 Subject: [Freeipa-devel] [PATCH] 0137 ipasam: remove child domains before removing trust In-Reply-To: <20140121095449.GC23022@localhost.localdomain> References: <20140120144921.GT12003@redhat.com> <20140121095449.GC23022@localhost.localdomain> Message-ID: <20140121101742.GA12003@redhat.com> On Tue, 21 Jan 2014, Sumit Bose wrote: >On Mon, Jan 20, 2014 at 04:49:21PM +0200, Alexander Bokovoy wrote: >> Hi! >> >> Make sure we delete child domains before removing the trust itself as >> LDAP protocol does not allow removing non-leaf objects. >> >> This has non-obvious effect -- old code did remove cross-realm >> principals and then removed trust object. However, for trusts with child >> domains the trust domain object was not removed as LDAP server prevents >> removing non-leaf objects. It resulted in the object still existing but >> cross-realm principals missing. The trust is thus non-functioning. This >> situation can be triggered with a second 'ipa trust-add' call. >> >> Fix the code by removing child domains first and then remove the forest >> root trusted domain object. >> >> https://fedorahosted.org/freeipa/ticket/4126 > >Patch is working as expected. But I would suggest to remove the 'const' >from the declaration of dn (also in the caller) to avoid compiler >warnings. As an alternative you can take a different talloc context, but >using dn here makes sense. I've removed 'const'. Btw, gcc in F20 is smarter than yours gcc in F18, it does not issue any warnings in C99 mode for ipa_sam.c :) -- / Alexander Bokovoy -------------- next part -------------- >From 75d9594d9388f92a57f5cb99b20e9f1950ab0a15 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 20 Jan 2014 16:42:48 +0200 Subject: [PATCH 1/2] ipasam: delete trusted child domains before removing the trust LDAP protocol doesn't allow deleting non-leaf entries. One needs to remove all leaves first before removing the tree node. https://fedorahosted.org/freeipa/ticket/4126 --- daemons/ipa-sam/ipa_sam.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index 674085d..a5f84a4 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -2437,6 +2437,44 @@ done: return status; } +static int delete_subtree(struct ldapsam_privates *ldap_state, char* dn) +{ + LDAP *state = priv2ld(ldap_state); + int rc; + char *filter = NULL; + int scope = LDAP_SCOPE_SUBTREE; + LDAPMessage *result = NULL; + LDAPMessage *entry = NULL; + char *entry_dn = NULL; + + /* use 'dn' for a temporary talloc context */ + filter = talloc_asprintf(dn, "(objectClass=*)"); + if (filter == NULL) { + return LDAP_NO_MEMORY; + } + + rc = smbldap_search(ldap_state->smbldap_state, dn, scope, filter, NULL, 0, &result); + TALLOC_FREE(filter); + + if (result != NULL) { + smbldap_talloc_autofree_ldapmsg(dn, result); + } + + for (entry = ldap_first_entry(state, result); + entry != NULL; + entry = ldap_next_entry(state, entry)) { + entry_dn = get_dn(dn, state, entry); + /* remove child entries */ + if ((entry_dn != NULL) && (strcmp(entry_dn, dn) != 0)) { + rc = smbldap_delete(ldap_state->smbldap_state, entry_dn); + } + } + rc = smbldap_delete(ldap_state->smbldap_state, dn); + + /* caller will destroy dn */ + return rc; +} + static NTSTATUS ipasam_del_trusted_domain(struct pdb_methods *methods, const char *domain) { @@ -2490,6 +2528,11 @@ static NTSTATUS ipasam_del_trusted_domain(struct pdb_methods *methods, } ret = smbldap_delete(ldap_state->smbldap_state, dn); + if (ret == LDAP_NOT_ALLOWED_ON_NONLEAF) { + /* delete_subtree will use 'dn' as temporary context too */ + ret = delete_subtree(ldap_state, dn); + } + if (ret != LDAP_SUCCESS) { status = NT_STATUS_UNSUCCESSFUL; goto done; -- 1.8.4.2 From abokovoy at redhat.com Tue Jan 21 10:39:32 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 21 Jan 2014 12:39:32 +0200 Subject: [Freeipa-devel] [PATCH] 0137 ipasam: remove child domains before removing trust In-Reply-To: <20140121101742.GA12003@redhat.com> References: <20140120144921.GT12003@redhat.com> <20140121095449.GC23022@localhost.localdomain> <20140121101742.GA12003@redhat.com> Message-ID: <20140121103932.GB12003@redhat.com> On Tue, 21 Jan 2014, Alexander Bokovoy wrote: > On Tue, 21 Jan 2014, Sumit Bose wrote: >> On Mon, Jan 20, 2014 at 04:49:21PM +0200, Alexander Bokovoy wrote: >>> Hi! >>> >>> Make sure we delete child domains before removing the trust itself as >>> LDAP protocol does not allow removing non-leaf objects. >>> >>> This has non-obvious effect -- old code did remove cross-realm >>> principals and then removed trust object. However, for trusts with child >>> domains the trust domain object was not removed as LDAP server prevents >>> removing non-leaf objects. It resulted in the object still existing but >>> cross-realm principals missing. The trust is thus non-functioning. This >>> situation can be triggered with a second 'ipa trust-add' call. >>> >>> Fix the code by removing child domains first and then remove the forest >>> root trusted domain object. >>> >>> https://fedorahosted.org/freeipa/ticket/4126 >> >> Patch is working as expected. But I would suggest to remove the 'const' >> from the declaration of dn (also in the caller) to avoid compiler >> warnings. As an alternative you can take a different talloc context, but >> using dn here makes sense. > I've removed 'const'. Btw, gcc in F20 is smarter than yours gcc in F18, > it does not issue any warnings in C99 mode for ipa_sam.c :) .. and one more removal of 'const' in the caller to suit gcc < 4.8.2. -- / Alexander Bokovoy -------------- next part -------------- >From 4c58609f8e0e18f9fb4af82e176bad7cad2d20b4 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 20 Jan 2014 16:42:48 +0200 Subject: [PATCH 1/2] ipasam: delete trusted child domains before removing the trust LDAP protocol doesn't allow deleting non-leaf entries. One needs to remove all leaves first before removing the tree node. https://fedorahosted.org/freeipa/ticket/4126 --- daemons/ipa-sam/ipa_sam.c | 45 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 44 insertions(+), 1 deletion(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index 674085d..1ca504d 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -2437,6 +2437,44 @@ done: return status; } +static int delete_subtree(struct ldapsam_privates *ldap_state, char* dn) +{ + LDAP *state = priv2ld(ldap_state); + int rc; + char *filter = NULL; + int scope = LDAP_SCOPE_SUBTREE; + LDAPMessage *result = NULL; + LDAPMessage *entry = NULL; + char *entry_dn = NULL; + + /* use 'dn' for a temporary talloc context */ + filter = talloc_asprintf(dn, "(objectClass=*)"); + if (filter == NULL) { + return LDAP_NO_MEMORY; + } + + rc = smbldap_search(ldap_state->smbldap_state, dn, scope, filter, NULL, 0, &result); + TALLOC_FREE(filter); + + if (result != NULL) { + smbldap_talloc_autofree_ldapmsg(dn, result); + } + + for (entry = ldap_first_entry(state, result); + entry != NULL; + entry = ldap_next_entry(state, entry)) { + entry_dn = get_dn(dn, state, entry); + /* remove child entries */ + if ((entry_dn != NULL) && (strcmp(entry_dn, dn) != 0)) { + rc = smbldap_delete(ldap_state->smbldap_state, entry_dn); + } + } + rc = smbldap_delete(ldap_state->smbldap_state, dn); + + /* caller will destroy dn */ + return rc; +} + static NTSTATUS ipasam_del_trusted_domain(struct pdb_methods *methods, const char *domain) { @@ -2444,7 +2482,7 @@ static NTSTATUS ipasam_del_trusted_domain(struct pdb_methods *methods, struct ldapsam_privates *ldap_state = (struct ldapsam_privates *)methods->private_data; LDAPMessage *entry = NULL; - const char *dn; + char *dn; const char *domain_name; TALLOC_CTX *tmp_ctx; NTSTATUS status; @@ -2490,6 +2528,11 @@ static NTSTATUS ipasam_del_trusted_domain(struct pdb_methods *methods, } ret = smbldap_delete(ldap_state->smbldap_state, dn); + if (ret == LDAP_NOT_ALLOWED_ON_NONLEAF) { + /* delete_subtree will use 'dn' as temporary context too */ + ret = delete_subtree(ldap_state, dn); + } + if (ret != LDAP_SUCCESS) { status = NT_STATUS_UNSUCCESSFUL; goto done; -- 1.8.4.2 From sbose at redhat.com Tue Jan 21 11:06:31 2014 From: sbose at redhat.com (Sumit Bose) Date: Tue, 21 Jan 2014 12:06:31 +0100 Subject: [Freeipa-devel] [PATCH] 0137 ipasam: remove child domains before removing trust In-Reply-To: <20140121103932.GB12003@redhat.com> References: <20140120144921.GT12003@redhat.com> <20140121095449.GC23022@localhost.localdomain> <20140121101742.GA12003@redhat.com> <20140121103932.GB12003@redhat.com> Message-ID: <20140121110631.GD23022@localhost.localdomain> On Tue, Jan 21, 2014 at 12:39:32PM +0200, Alexander Bokovoy wrote: > On Tue, 21 Jan 2014, Alexander Bokovoy wrote: > >On Tue, 21 Jan 2014, Sumit Bose wrote: > >>On Mon, Jan 20, 2014 at 04:49:21PM +0200, Alexander Bokovoy wrote: > >>>Hi! > >>> > >>>Make sure we delete child domains before removing the trust itself as > >>>LDAP protocol does not allow removing non-leaf objects. > >>> > >>>This has non-obvious effect -- old code did remove cross-realm > >>>principals and then removed trust object. However, for trusts with child > >>>domains the trust domain object was not removed as LDAP server prevents > >>>removing non-leaf objects. It resulted in the object still existing but > >>>cross-realm principals missing. The trust is thus non-functioning. This > >>>situation can be triggered with a second 'ipa trust-add' call. > >>> > >>>Fix the code by removing child domains first and then remove the forest > >>>root trusted domain object. > >>> > >>>https://fedorahosted.org/freeipa/ticket/4126 > >> > >>Patch is working as expected. But I would suggest to remove the 'const' > >>from the declaration of dn (also in the caller) to avoid compiler > >>warnings. As an alternative you can take a different talloc context, but > >>using dn here makes sense. > >I've removed 'const'. Btw, gcc in F20 is smarter than yours gcc in F18, > >it does not issue any warnings in C99 mode for ipa_sam.c :) > .. and one more removal of 'const' in the caller to suit gcc < 4.8.2. ACK bye, Sumit > > -- > / Alexander Bokovoy From mkosek at redhat.com Tue Jan 21 11:23:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 21 Jan 2014 12:23:05 +0100 Subject: [Freeipa-devel] [PATCH] 463-530 First part of RCUE adoption In-Reply-To: <52D7EB55.2060102@redhat.com> References: <528620F5.3010206@redhat.com> <52937156.6070303@redhat.com> <52989A5D.1030405@redhat.com> <5298BAB3.4030108@redhat.com> <52C6A132.7000701@redhat.com> <52D7BD29.6010700@redhat.com> <52D7EB55.2060102@redhat.com> Message-ID: <52DE5899.9090500@redhat.com> On 01/16/2014 03:23 PM, Martin Kosek wrote: > On 01/16/2014 12:06 PM, Petr Vobornik wrote: >> On 3.1.2014 12:38, Petr Vobornik wrote: >>> On 29.11.2013 17:02, Ana Krivokapic wrote: >>>> On 11/29/2013 02:45 PM, Ana Krivokapic wrote: >>>>>> On 11/25/2013 04:48 PM, Ana Krivokapic wrote: >>>>>>>> On 11/15/2013 02:26 PM, Petr Vobornik wrote: >>>>>>>>>> Hello list, >>>>>>>>>> >>>>>>>>>> this is a first part of RCUE adoption effort. Main themes of >>>>>>> this patch set are: >>>>>>>>>> >>>>>>>>>> - use RCUE navigation >>>>>>>>>> - new styles for textboxes, textareas, radio/checkbox buttons >>>>>>> and buttons- >>>>>>>>>> part of >>>>>>>>>> - new internal form layout (tables replaced by divs) >>>>>>>>>> - layout does not have fixed >>>>>>> size >>>>>>>>>> - new dialog styles + removed dependency on jQuery UI dialog >>>>>>>>>> - icons replaced by Font Awesome glyphs >>>>>>>>>> >>>>>>>>>> Example is at: >>>>>>>>>> >>>>>>>>>> Some reasonings and additional info: >>>>>>>>>> >>>>>>>>>> 1. RCUE includes Bootstrap which defines o lot of styles for a >>>>>>> lot of things. >>>>>>>>>> That messed up the UI and therefore I did the form changes now. >>>>>>>>>> >>>>>>>>>> 2. jQuery UI is pretty big lib and we used it only for dialog >>>>>>> and buttons. >>>>>>>>>> Buttons were replaced by RCUE buttons so removal of dialog >>>>>>> dependency was a >>>>>>>>>> obvious step to get rid of the whole lib. The lib is removed >>>>>>> from main UI but >>>>>>>>>> is still present in separate pages - will be removed later. >>>>>>>>>> >>>>>>>>>> 3. Dojo and jQuery were upgraded to latest >>>>>>>>>> versions. >>>>>>>>>> >>>>>>>>>> This approach was ACKed by Kyle from a design perspective with a >>>>>>> note that we >>>>>>>>>> will review and fixed some styling after second phase. We should >>>>>>> not release >>>>>>>>>> until then. >>>>>>>>>> >>>>>>>>>> The second phase, which I'm working on right now, will consist of: >>>>>>>>>> * login screen >>>>>>>>>> * new styles for standalone pages >>>>>>>>>> * necessary responsive enhancement (the ultimate future goal >>>>>>> is responsive >>>>>>>>>> layout) >>>>>>>>>> >>>>>>>>>> It's quite a lot of patches so I did not attach them here. You >>>>>>> can see the >>>>>>>>>> code in my private repo: >>>>>>> branch >>>>>>>>>> 'rcue'. >>>>>>>> I tested this phase of RCUE adoption effort, overall it looks and >>>>>> works great. A >>>>>>>> couple of findings: >>>>>>>> >>>>>>>> 1) Two ui integration tests are failing, I guess this is due to >>>>>> the re-arranging >>>>>>>> of elements on the automember page. So the tests should be amended >>>>>> to reflect >>>>>>>> that change. >>>> Commit ee4f6540490a16f0fbb5cdd02097a9b3ff354252 works around the >>>> navigation >>>> issue which caused tests to fail. ACK. >>>> >>> >>> I've unbundled font files from FreeIPA Web UI >>> - Open Sans will be in new fedora package - open-sans-fonts >>> - Font Awesome as well - fontawesome-fonts >>> - Overpass fonts are no longer used >>> >>> Branch rcue-fonts-unbundled >>> git://fedorapeople.org/home/fedora/pvoborni/public_git/freeipa.git >>> contains the changes. It's 6 additional commits on top of the reviewed >>> rcue branch. 5 commits were squashed in order to reduce size of the >>> final push. Attaching all of the patches for reference. >>> >>> open-sans-fonts and fontawesome-fonts Fedora packages are still on review: >>> - https://bugzilla.redhat.com/show_bug.cgi?id=1035897 >>> - https://bugzilla.redhat.com/show_bug.cgi?id=1026376 >>> >>> Reviewer for open-sans-fonts needed. >>> >>> OTP UI will be rebased on top of this effort. >>> >> >> The review is not blocked anymore - both fonts are available in updates testing. > > I tested the 'rcue-fonts-unbundled' branch and it works for me. Given Ana's > previous review, the only unreviewed patch is the top one switching to using > the external fonts you packaged [1]. I found just one issue in the patch - the > version of ipa.conf was not bumped, thus the upgrade would fail as ipa.conf > would not be updated. > > If this is fixed, I would be OK with pushing this work to master so that you > can base your next work on a stable grounds. Adding Simo and Rob to CC to > notify them about this bigger push so that they can express any concerns. > > Note that current state is still not ready to be released as is, it still has > some rough edges, but it will at least give others developers opportunity to > test it. > > Martin > > [1] > http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/commit/?h=datetime-ui&id=3d976cdb60e122ea722ecb3bd03a78b25ef105ca I bumped up the version of the ipa.conf package in the last patch as notified. I pushed all 70 patches to master. Thanks Petr for your RCUE work so far, I am looking forward to the rest. Martin From mkosek at redhat.com Tue Jan 21 11:29:59 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 21 Jan 2014 12:29:59 +0100 Subject: [Freeipa-devel] [PATCH] 543 Trust domains Web UI In-Reply-To: <20140121094306.GY12003@redhat.com> References: <52D96E38.1020308@redhat.com> <20140120170127.GW12003@redhat.com> <52DE3E3A.2060703@redhat.com> <20140121094306.GY12003@redhat.com> Message-ID: <52DE5A37.7080404@redhat.com> On 01/21/2014 10:43 AM, Alexander Bokovoy wrote: > On Tue, 21 Jan 2014, Petr Vobornik wrote: >> On 20.1.2014 18:01, Alexander Bokovoy wrote: >>> On Fri, 17 Jan 2014, Petr Vobornik wrote: >>>> Note: this version of the patch is especially prepared for ipa-3-3 >>>> branch. >>>> >>>> Add Web UI counterpart of following CLI commands: >>>> >>>> * trust-fetch-domains Refresh list of the domains associated with the >>>> trust >>>> * trustdomain-del Remove infromation about the domain associated with >>>> the trust. >>>> * trustdomain-disable Disable use of IPA resources by the domain of >>>> the trust >>>> * trustdomain-enable Allow use of IPA resources by the domain of the >>>> trust >>>> * trustdomain-find Search domains of the trust >>>> >>>> https://fedorahosted.org/freeipa/ticket/4119 >>> ACK functionally, everything works for me. >>> >>> I wonder if you could make UI a bit smarter and prevent enable/disable >>> actions for the forest root trusted domain. Right now selecting it for >>> 'disable' will show you an error telling that disabling root domain is >>> not possible. >>> >>> >> >> Some enhancement could be done in this area. Similar "issue" is also present >> when enabling/disabling already enabled/disabled items (not just in trusted >> domains but also in users, HBAC and SUDO rules... pages). >> >> But what should be the ideal behavior? >> >> We must take into considerations facts as follows: >> - button which executes the action is enabled/disabled based on user selection >> - user can select multiple items >> - some of those items are suitable for the action (e.g., disabled items for >> enable action), some not (disabled for disable). >> - backend will tell us what succeeded and what not >> >> Current behavior: >> - action button is enabled when user selects any item >> - after action execution, user is told, if some or all items were not >> suitable (the action was not performed for them). >> >> If server behaves correctly this UI behavior should not cause any harm. >> >> Some possible enhancements are: >> 1. Do not enable action button if all selected items are not suitable for the >> action. If some are suitable, continue with current behavior >> >> 2. If some of selected items are not suitable, show a warning dialog which >> will list items for which the action will be executed and items for which it >> won't be. After confirmation, request will be sent only with suitable items. >> >> 3. Do not enable action button if some selected item is not suitable. >> >> #1 and #2 can be combined. I'm not a fan of #3; sounds more like a drawback. >> >> Do you have something similar in mind? > #1 and #2 would require either embedding knowledge about specific items in Web > UI or extending metadata we have about commands. In both cases it looks > a bit weird as it is not a metadata per se. I'm not even sure we can > maintain it properly in all cases. > >> Anyway I don't think this is a material for IPA 3.3. If you agree, I will >> open a new ticket and also ask Kyle for his option on this topic. > Yes, it is something for future but given options you presented I don't > see much future in it... > Ok. I pushed Petr's patch to master, ipa-3-3. Martin From pvoborni at redhat.com Tue Jan 21 11:32:35 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 21 Jan 2014 12:32:35 +0100 Subject: [Freeipa-devel] [PATCH] 543 Trust domains Web UI In-Reply-To: <20140121094306.GY12003@redhat.com> References: <52D96E38.1020308@redhat.com> <20140120170127.GW12003@redhat.com> <52DE3E3A.2060703@redhat.com> <20140121094306.GY12003@redhat.com> Message-ID: <52DE5AD3.2080807@redhat.com> On 21.1.2014 10:43, Alexander Bokovoy wrote: > On Tue, 21 Jan 2014, Petr Vobornik wrote: >> On 20.1.2014 18:01, Alexander Bokovoy wrote: >>> On Fri, 17 Jan 2014, Petr Vobornik wrote: >>>> Note: this version of the patch is especially prepared for ipa-3-3 >>>> branch. >>>> >>>> Add Web UI counterpart of following CLI commands: >>>> >>>> * trust-fetch-domains Refresh list of the domains associated with the >>>> trust >>>> * trustdomain-del Remove infromation about the domain associated with >>>> the trust. >>>> * trustdomain-disable Disable use of IPA resources by the domain of >>>> the trust >>>> * trustdomain-enable Allow use of IPA resources by the domain of the >>>> trust >>>> * trustdomain-find Search domains of the trust >>>> >>>> https://fedorahosted.org/freeipa/ticket/4119 >>> ACK functionally, everything works for me. >>> >>> I wonder if you could make UI a bit smarter and prevent enable/disable >>> actions for the forest root trusted domain. Right now selecting it for >>> 'disable' will show you an error telling that disabling root domain is >>> not possible. >>> >>> >> >> Some enhancement could be done in this area. Similar "issue" is also >> present when enabling/disabling already enabled/disabled items (not >> just in trusted domains but also in users, HBAC and SUDO rules... pages). >> >> But what should be the ideal behavior? >> >> We must take into considerations facts as follows: >> - button which executes the action is enabled/disabled based on user >> selection >> - user can select multiple items >> - some of those items are suitable for the action (e.g., disabled >> items for enable action), some not (disabled for disable). >> - backend will tell us what succeeded and what not >> >> Current behavior: >> - action button is enabled when user selects any item >> - after action execution, user is told, if some or all items were not >> suitable (the action was not performed for them). >> >> If server behaves correctly this UI behavior should not cause any harm. >> >> Some possible enhancements are: >> 1. Do not enable action button if all selected items are not suitable >> for the action. If some are suitable, continue with current behavior >> >> 2. If some of selected items are not suitable, show a warning dialog >> which will list items for which the action will be executed and items >> for which it won't be. After confirmation, request will be sent only >> with suitable items. >> >> 3. Do not enable action button if some selected item is not suitable. >> >> #1 and #2 can be combined. I'm not a fan of #3; sounds more like a >> drawback. >> >> Do you have something similar in mind? > #1 and #2 would require either embedding knowledge about specific items > in Web > UI or extending metadata we have about commands. In both cases it looks > a bit weird as it is not a metadata per se. I'm not even sure we can > maintain it properly in all cases. > >> Anyway I don't think this is a material for IPA 3.3. If you agree, I >> will open a new ticket and also ask Kyle for his option on this topic. > Yes, it is something for future but given options you presented I don't > see much future in it... > It's feasible. For standard enable/disable it could more or less declarative. The "root domain" case will require more embedding of specific logic. I guess it's OK, not everything can/should be driven by metadata. Anyway here's a ticket https://fedorahosted.org/freeipa/ticket/4129 (beer exchange candidate) -- Petr Vobornik From mkosek at redhat.com Tue Jan 21 11:33:25 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 21 Jan 2014 12:33:25 +0100 Subject: [Freeipa-devel] [PATCH] 0137 ipasam: remove child domains before removing trust In-Reply-To: <20140121110631.GD23022@localhost.localdomain> References: <20140120144921.GT12003@redhat.com> <20140121095449.GC23022@localhost.localdomain> <20140121101742.GA12003@redhat.com> <20140121103932.GB12003@redhat.com> <20140121110631.GD23022@localhost.localdomain> Message-ID: <52DE5B05.8010809@redhat.com> On 01/21/2014 12:06 PM, Sumit Bose wrote: > On Tue, Jan 21, 2014 at 12:39:32PM +0200, Alexander Bokovoy wrote: >> On Tue, 21 Jan 2014, Alexander Bokovoy wrote: >>> On Tue, 21 Jan 2014, Sumit Bose wrote: >>>> On Mon, Jan 20, 2014 at 04:49:21PM +0200, Alexander Bokovoy wrote: >>>>> Hi! >>>>> >>>>> Make sure we delete child domains before removing the trust itself as >>>>> LDAP protocol does not allow removing non-leaf objects. >>>>> >>>>> This has non-obvious effect -- old code did remove cross-realm >>>>> principals and then removed trust object. However, for trusts with child >>>>> domains the trust domain object was not removed as LDAP server prevents >>>>> removing non-leaf objects. It resulted in the object still existing but >>>>> cross-realm principals missing. The trust is thus non-functioning. This >>>>> situation can be triggered with a second 'ipa trust-add' call. >>>>> >>>>> Fix the code by removing child domains first and then remove the forest >>>>> root trusted domain object. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4126 >>>> >>>> Patch is working as expected. But I would suggest to remove the 'const' >>> >from the declaration of dn (also in the caller) to avoid compiler >>>> warnings. As an alternative you can take a different talloc context, but >>>> using dn here makes sense. >>> I've removed 'const'. Btw, gcc in F20 is smarter than yours gcc in F18, >>> it does not issue any warnings in C99 mode for ipa_sam.c :) >> .. and one more removal of 'const' in the caller to suit gcc < 4.8.2. > > ACK > > bye, > Sumit > Pushed to master, ipa-3-3. Martin From pviktori at redhat.com Tue Jan 21 12:10:49 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 21 Jan 2014 13:10:49 +0100 Subject: [Freeipa-devel] [PATCH] 0452 permission plugin: Do not assume attribute-level rights for new attributes are present Message-ID: <52DE63C9.7080803@redhat.com> With the --all --raw options, the code assumed attribute-level rights were set on ipaPermissionV2 attributes, even on permissions that did not have the objectclass. Check that the data is present before using it. https://fedorahosted.org/freeipa/ticket/4121 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0452-permission-plugin-Do-not-assume-attribute-level-righ.patch Type: text/x-patch Size: 2114 bytes Desc: not available URL: From jcholast at redhat.com Tue Jan 21 13:02:30 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 21 Jan 2014 14:02:30 +0100 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <1390239355.2370.72.camel@willson.li.ssimo.org> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> Message-ID: <52DE6FE6.5020901@redhat.com> On 20.1.2014 18:35, Simo Sorce wrote: > On Mon, 2014-01-20 at 17:49 +0100, Jan Cholasta wrote: >> On 20.1.2014 16:36, Simo Sorce wrote: >>> On Mon, 2014-01-20 at 11:07 +0100, Jan Cholasta wrote: >>>> On 17.1.2014 11:39, Jan Cholasta wrote: >>>>> On 10.1.2014 13:34, Martin Kosek wrote: >>>>>> On 01/09/2014 04:49 PM, Simo Sorce wrote: >>>>>>> On Thu, 2014-01-09 at 10:44 -0500, Rob Crittenden wrote: >>>>>>>> Martin Kosek wrote: >>>>>>>>> On 01/09/2014 03:12 PM, Simo Sorce wrote: >>>>>>> >>>>>>>>>>> Also maybe we should allow admins to bypass the need to have an >>>>>>>>>>> actual >>>>>>>>>>> object to represent the alt name ? >>>>>>>> >>>>>>>> I'd rather not. This would allow a rogue admin to create a cert for >>>>>>>> www.google.com. Sure, they could also create a host for that but >>>>>>>> forcing >>>>>>>> them to add more entries increases the chances of them getting caught >>>>>>>> doing it. >>>>>>> >>>>>>> They can remove the host right after they create a cert, I honestly do >>>>>>> not think this is a valid concern. If your admin is rouge he can already >>>>>>> take full ownership of your infrastructure in many ways, preventing >>>>>>> setting a name in a cert doesn't really make a difference IMO. >>>>>>> >>>>>>> However I would be ok to limit this to some new "Security Admin/CA >>>>>>> Admin" role that is not assigned by default. >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>> >>>>>> Ok, let's reach some conclusion here. I would really like to not defer >>>>>> this >>>>>> feature for too long, it is quite wanted. Would creating new virtual >>>>>> operation >>>>>> "Request certificate with SAN" make the situation better? It would not >>>>>> be so >>>>>> difficult to do, the check_access function can already access virtual >>>>>> operation >>>>>> name as a parameter, we just need to call it. >>>>> >>>>> Why don't we treat SAN hostnames the same way as the subject hostname? >>>>> The way I see it, with SAN the only difference is that there is a set of >>>>> hostnames instead of just a single hostname, so maybe we should support >>>>> requesting a certificate for a set of hosts/services instead of just a >>>>> single host/service. >>>>> >>>>> As far as authorization is concerned, currently you can request a >>>>> certificate for a single host/service, if you have the "Request >>>>> certificate" permission and write access to the host/service entry. With >>>>> multiple hosts/services, you would be able to request a certificate if >>>>> you have the "Request certificate" permission and write access to *all* >>>>> of the host/certificate entries you are requesting the certificate for. >>>>> >>>>> Effectively this means that cert-request would accept multiple >>>>> principals instead of single principal and the automatic revocation code >>>>> in cert-request, host-del and service-del would take into account that a >>>>> single certificate might be assigned to multiple entities. >>>>> >>>> >>>> See attachment for patch which implements the above design. >>> >>> Hi Jan, I am a bit too far removed from the code to fully understand the >>> change just from the diff. >>> >>> Could you please add a short explanation in the commit message, a bout >>> what the code does now differently than it did before. >> >> Done. >> >>> For example although I understand the checks you do on subjectname >>> +subjectaltname I do not know where the principals come from or why you >>> have a comment that says principals must all be of the same service >>> type. >> >> Principals come from the --principal option, which can have multiple >> values with the patch. >> >> The service name constraint is there so that there is a 1-to-1 mapping >> between principals and hostnames in the request (both subject and SAN). >> Without this you would be able to request a certificate for completely >> unrelated services and I was not sure if it's OK to allow that, since >> the use case here is load balancing (right?) >> >>> >>> Simo. >>> >>> >> >> Updated patch attached. >> > > Sorry have to NACK. > > I was confused by the code so asked on IRC: > so if I have subectname = one.ipa.lan and altname = two.ipa.net > then the certificate is anchored to both HTTP/one.ipa.net AND > HTTP/two.ipa.net ? > yep > and what happens when I create other.ipa.net with altname > two.ipa.net ? > does HTTP/two.ipa.net now have 2 certificates anchored ? > the old certificate gets revoked and removed from > HTTP/one.ipa.net and HTTP/two.ipa.net, then the new certificate is > issued and anchored to HTTP/two.ipa.net and HTTP/other.ipa.net > > This defeats the purpose of having altnames. > > There are 2 reasons to have altnames: > 1. just add aliases that are not shared by any other service > 2. have a common alias between multiple service to allow loadbalancing > > (1) will not be affected, but (2) would be impossible, because as soon > as I try to create the cert for one of the other nodes to be balanced > the previous nodes get their certificates revoked, which defeats the > whole point of creating them with a common altname. > > Simo. > Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-210.2-Allow-SAN-in-IPA-certificate-profile.patch Type: text/x-patch Size: 5005 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-234.2-Support-requests-with-SAN-in-cert-request.patch Type: text/x-patch Size: 7228 bytes Desc: not available URL: From pviktori at redhat.com Tue Jan 21 14:07:15 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 21 Jan 2014 15:07:15 +0100 Subject: [Freeipa-devel] [PATCH] 448-449 Switch httpd to use default CCACHE In-Reply-To: <52D7DBA3.3010206@redhat.com> References: <52D7DBA3.3010206@redhat.com> Message-ID: <52DE7F13.7060509@redhat.com> On 01/16/2014 02:16 PM, Martin Kosek wrote: > [freeipa-mkosek-448-add-runas-option-to-run-function.patch]: > > Run function can now run the specified command as different user by > setting the EUID and EGID for executed process. Please add the new argument to the docstring, otherwise ACK > [freeipa-mkosek-449-switch-httpd-to-use-default-ccache.patch]: > > Stock httpd no longer uses systemd EnvironmentFile option which is > making FreeIPA's KRB5CCNAME setting ineffective. This can lead in hard > to debug problems during subsequent ipa-server-install's where HTTP > may use a stale CCACHE in the default kernel keyring CCACHE. > > Avoid forcing custom CCACHE and switch to system one, just make sure > that it is properly cleaned by kdestroy run as "apache" user during > FreeIPA server installation process. > > https://fedorahosted.org/freeipa/ticket/4084 This does not fix the issue for me. On a fresh f20 machine, I installed the server, uninstalled it, and installed again. The second installation failed with the ipa-client-install error described in the ticket. -- Petr? From mkosek at redhat.com Tue Jan 21 16:12:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 21 Jan 2014 17:12:18 +0100 Subject: [Freeipa-devel] [PATCH] 448-449 Switch httpd to use default CCACHE In-Reply-To: <52DE7F13.7060509@redhat.com> References: <52D7DBA3.3010206@redhat.com> <52DE7F13.7060509@redhat.com> Message-ID: <52DE9C62.8070307@redhat.com> On 01/21/2014 03:07 PM, Petr Viktorin wrote: > On 01/16/2014 02:16 PM, Martin Kosek wrote: >> [freeipa-mkosek-448-add-runas-option-to-run-function.patch]: >> >> Run function can now run the specified command as different user by >> setting the EUID and EGID for executed process. > > Please add the new argument to the docstring, otherwise ACK > >> [freeipa-mkosek-449-switch-httpd-to-use-default-ccache.patch]: >> >> Stock httpd no longer uses systemd EnvironmentFile option which is >> making FreeIPA's KRB5CCNAME setting ineffective. This can lead in hard >> to debug problems during subsequent ipa-server-install's where HTTP >> may use a stale CCACHE in the default kernel keyring CCACHE. >> >> Avoid forcing custom CCACHE and switch to system one, just make sure >> that it is properly cleaned by kdestroy run as "apache" user during >> FreeIPA server installation process. >> >> https://fedorahosted.org/freeipa/ticket/4084 > > This does not fix the issue for me. > On a fresh f20 machine, I installed the server, uninstalled it, and installed > again. The second installation failed with the ipa-client-install error > described in the ticket. > On your VM, I saw the method I use for running a command as different process was indeed not effective. I had to change both effective and real UID/GID to make the kdestroy function working. I also added the missing docstrings in 448, both for runas as well as other missing options. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-448-2-add-runas-option-to-run-function.patch Type: text/x-patch Size: 4180 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-449-2-switch-httpd-to-use-default-ccache.patch Type: text/x-patch Size: 3717 bytes Desc: not available URL: From simo at redhat.com Tue Jan 21 16:12:28 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 21 Jan 2014 11:12:28 -0500 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <52DE6FE6.5020901@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> Message-ID: <1390320748.15404.6.camel@willson.li.ssimo.org> On Tue, 2014-01-21 at 14:02 +0100, Jan Cholasta wrote: > + request = None > + try: > + request = pkcs10.load_certificate_request(csr) > + subject = pkcs10.get_subject(request) > + subjectaltname = pkcs10.get_subjectaltname(request) Will this make the request fail if there is no subjectaltname ? Later in the patch you seem to be changing from needing managedby_host to needing write access to an entry, I am not sure I understand why that was changed. not saying it is necessarily wrong, but why the original check is not right anymore ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Tue Jan 21 16:45:44 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 21 Jan 2014 17:45:44 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <52D40FD7.5090301@redhat.com> References: <52D40FD7.5090301@redhat.com> Message-ID: <52DEA438.50904@redhat.com> On 13.1.2014 17:09, Petr Vobornik wrote: > Hi, > > these patches implements the OTP Web UI. > > Last 5 patches is the OTP UI. > > First 6 patches is a little refactoring/bug fixes needed for them. > General password dialog is introduced to avoid another implementation. > > Self-service UI is implemented to be very simple. Atm user can choose > only token name. Admin interface allows to enter all values. > > It's based on the RCUE work -> we need to push RCUE first. Thanks > Nathaniel for review of the last font package. It will speed things up. > > Know bugs: > - there is clash in id's of checkboxes preventing editation of > subsequently displayed ones with the same name. Will be fixed in > separate patch. > - bugs caused by bugs in API (adding/removal of own tokens in > self-service, inability to enter key on token creation - > https://fedorahosted.org/freeipa/ticket/4099) > - datetime format (widget+validator) will be implemented in separate patch > - no support of not reviewed CLI patches (HOTP..) > > Cgit: > http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp > > https://fedorahosted.org/freeipa/ticket/3369 > Patches were rebased because of minor conflict with trusted domains patch. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0541-1-Support-OTP-in-form-based-auth.patch Type: text/x-patch Size: 2300 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0540-1-Added-QRcode-generation-to-Web-UI.patch Type: text/x-patch Size: 33144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0539-1-UI-for-managing-user-auth-types.patch Type: text/x-patch Size: 2008 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0538-1-UI-for-radius-proxy.patch Type: text/x-patch Size: 7703 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0537-1-UI-for-OTP-tokens.patch Type: text/x-patch Size: 15668 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0536-1-Fix-handling-of-action-visibility-change-in-action-p.patch Type: text/x-patch Size: 1532 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0535-1-Use-general-password-dialog-for-host-OTP.patch Type: text/x-patch Size: 6306 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0534-1-Password-Dialog.patch Type: text/x-patch Size: 11249 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0533-1-Fixed-doc-examples-in-Spec_mod.patch Type: text/x-patch Size: 1316 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0532-1-Declarative-replacement-of-array-item-in-specificati.patch Type: text/x-patch Size: 3642 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0531-1-Added-empty-value-meaning-to-boolean-formatter.patch Type: text/x-patch Size: 2888 bytes Desc: not available URL: From npmccallum at redhat.com Tue Jan 21 22:19:28 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 21 Jan 2014 17:19:28 -0500 Subject: [Freeipa-devel] ANNOUNCE: kdcproxy 0.1.1 released Message-ID: <1390342768.1984.76.camel@localhost.localdomain> kdcproxy contains a WSGI module for proxying KDC requests over HTTP by following the MS-KKDCP protocol. It aims to be simple to deploy, with minimal configuration. https://pypi.python.org/pypi/kdcproxy https://github.com/npmccallum/kdcproxy One of the reasons I am announcing this on the freeipa-devel list is that FreeIPA may have interest in having out-of-the-box Kerberos-over-HTTPS support. I do need a pure python package review for Fedora, if anyone is interested in doing it: https://bugzilla.redhat.com/show_bug.cgi?id=1056291 From pviktori at redhat.com Wed Jan 22 09:27:42 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 22 Jan 2014 10:27:42 +0100 Subject: [Freeipa-devel] [PATCHES] 0447-0449 Add support for managed permissions In-Reply-To: <52CD738A.40105@redhat.com> References: <52CD738A.40105@redhat.com> Message-ID: <52DF8F0E.9020705@redhat.com> On 01/08/2014 04:49 PM, Petr Viktorin wrote: > Hello, > This adds "managed" permissions, the framework that will make our > default permissions merge IPA updates and user changes sanely. > > There is no updater yet, nor does this add any actual managed > permissions, so there's no user-visible change (beyond help text and a > disabled option). To test the patch you might need to touch LDAP directly. > > Ticket: https://fedorahosted.org/freeipa/ticket/4033 > Design (no updater & plugin changes yet): > http://www.freeipa.org/page/V3/Managed_Read_permissions > > 0447 - Minor fixes. > 0448 - Since you can't create managed permissions through the API, I > needed to get creative with the declarative tests. The tests will need a > custom function that adds a managed perm. > 0449 - The change itself. ping; any thoughts on this one? -- Petr? From jcholast at redhat.com Wed Jan 22 09:40:17 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 22 Jan 2014 10:40:17 +0100 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <1390320748.15404.6.camel@willson.li.ssimo.org> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> Message-ID: <52DF9201.6090806@redhat.com> On 21.1.2014 17:12, Simo Sorce wrote: > On Tue, 2014-01-21 at 14:02 +0100, Jan Cholasta wrote: >> + request = None >> + try: >> + request = pkcs10.load_certificate_request(csr) >> + subject = pkcs10.get_subject(request) >> + subjectaltname = pkcs10.get_subjectaltname(request) > > Will this make the request fail if there is no subjectaltname ? No. > > Later in the patch you seem to be changing from needing managedby_host > to needing write access to an entry, I am not sure I understand why that > was changed. not saying it is necessarily wrong, but why the original > check is not right anymore ? The original check is wrong, see . The check in my patch allows SAN only if the requesting host has write access to all of the SAN services. I'm not entirely sure if this is right, but even if it is not, I think we should still check for write access to the SAN services, so that access control can be (partially) handled by ACIs. > > Simo. > -- Jan Cholasta From pviktori at redhat.com Wed Jan 22 11:42:30 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 22 Jan 2014 12:42:30 +0100 Subject: [Freeipa-devel] [PATCH] 448-449 Switch httpd to use default CCACHE In-Reply-To: <52DE9C62.8070307@redhat.com> References: <52D7DBA3.3010206@redhat.com> <52DE7F13.7060509@redhat.com> <52DE9C62.8070307@redhat.com> Message-ID: <52DFAEA6.7000606@redhat.com> On 01/21/2014 05:12 PM, Martin Kosek wrote: > On 01/21/2014 03:07 PM, Petr Viktorin wrote: >> On 01/16/2014 02:16 PM, Martin Kosek wrote: >>> [freeipa-mkosek-448-add-runas-option-to-run-function.patch]: >>> >>> Run function can now run the specified command as different user by >>> setting the EUID and EGID for executed process. >> >> Please add the new argument to the docstring, otherwise ACK >> >>> [freeipa-mkosek-449-switch-httpd-to-use-default-ccache.patch]: >>> >>> Stock httpd no longer uses systemd EnvironmentFile option which is >>> making FreeIPA's KRB5CCNAME setting ineffective. This can lead in hard >>> to debug problems during subsequent ipa-server-install's where HTTP >>> may use a stale CCACHE in the default kernel keyring CCACHE. >>> >>> Avoid forcing custom CCACHE and switch to system one, just make sure >>> that it is properly cleaned by kdestroy run as "apache" user during >>> FreeIPA server installation process. >>> >>> https://fedorahosted.org/freeipa/ticket/4084 >> >> This does not fix the issue for me. >> On a fresh f20 machine, I installed the server, uninstalled it, and installed >> again. The second installation failed with the ipa-client-install error >> described in the ticket. >> > > On your VM, I saw the method I use for running a command as different process > was indeed not effective. I had to change both effective and real UID/GID to > make the kdestroy function working. > > I also added the missing docstrings in 448, both for runas as well as other > missing options. Great, thank you! ACK, fixed a typo in the docstring and pushed to master: f49c26db2c38e5b60a6be990b95c2926ecfa6247 For the record, this problem appeared in an install-uninstall-install cycle with no reboot. It's unlikely to appear in the wild, but happens all the time in CI and on some developers' workflows. -- Petr? From simo at redhat.com Wed Jan 22 14:34:23 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 22 Jan 2014 09:34:23 -0500 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <52DF9201.6090806@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> <52DF9201.6090806@redhat.com> Message-ID: <1390401263.15404.37.camel@willson.li.ssimo.org> On Wed, 2014-01-22 at 10:40 +0100, Jan Cholasta wrote: > On 21.1.2014 17:12, Simo Sorce wrote: > > On Tue, 2014-01-21 at 14:02 +0100, Jan Cholasta wrote: > >> + request = None > >> + try: > >> + request = pkcs10.load_certificate_request(csr) > >> + subject = pkcs10.get_subject(request) > >> + subjectaltname = pkcs10.get_subjectaltname(request) > > > > Will this make the request fail if there is no subjectaltname ? > > No. Good. > > Later in the patch you seem to be changing from needing managedby_host > > to needing write access to an entry, I am not sure I understand why that > > was changed. not saying it is necessarily wrong, but why the original > > check is not right anymore ? > > The original check is wrong, see > . > > The check in my patch allows SAN only if the requesting host has write > access to all of the SAN services. I'm not entirely sure if this is > right, but even if it is not, I think we should still check for write > access to the SAN services, so that access control can be (partially) > handled by ACIs. Right, I remembered that comment, but it just says to check the right object's managed-by, here instead you changed it to check if you can write the usercertificate. I guess it is the same *if* there is an ACI that gives write permission when the host is in the managed-by attribute, is that the reasoning ? Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Jan 22 14:39:52 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 22 Jan 2014 09:39:52 -0500 Subject: [Freeipa-devel] [PATCH] 448-449 Switch httpd to use default CCACHE In-Reply-To: <52DFAEA6.7000606@redhat.com> References: <52D7DBA3.3010206@redhat.com> <52DE7F13.7060509@redhat.com> <52DE9C62.8070307@redhat.com> <52DFAEA6.7000606@redhat.com> Message-ID: <1390401592.15404.39.camel@willson.li.ssimo.org> On Wed, 2014-01-22 at 12:42 +0100, Petr Viktorin wrote: > On 01/21/2014 05:12 PM, Martin Kosek wrote: > > On 01/21/2014 03:07 PM, Petr Viktorin wrote: > >> On 01/16/2014 02:16 PM, Martin Kosek wrote: > >>> [freeipa-mkosek-448-add-runas-option-to-run-function.patch]: > >>> > >>> Run function can now run the specified command as different user by > >>> setting the EUID and EGID for executed process. > >> > >> Please add the new argument to the docstring, otherwise ACK > >> > >>> [freeipa-mkosek-449-switch-httpd-to-use-default-ccache.patch]: > >>> > >>> Stock httpd no longer uses systemd EnvironmentFile option which is > >>> making FreeIPA's KRB5CCNAME setting ineffective. This can lead in hard > >>> to debug problems during subsequent ipa-server-install's where HTTP > >>> may use a stale CCACHE in the default kernel keyring CCACHE. > >>> > >>> Avoid forcing custom CCACHE and switch to system one, just make sure > >>> that it is properly cleaned by kdestroy run as "apache" user during > >>> FreeIPA server installation process. > >>> > >>> https://fedorahosted.org/freeipa/ticket/4084 > >> > >> This does not fix the issue for me. > >> On a fresh f20 machine, I installed the server, uninstalled it, and installed > >> again. The second installation failed with the ipa-client-install error > >> described in the ticket. > >> > > > > On your VM, I saw the method I use for running a command as different process > > was indeed not effective. I had to change both effective and real UID/GID to > > make the kdestroy function working. > > > > I also added the missing docstrings in 448, both for runas as well as other > > missing options. > > Great, thank you! ACK, fixed a typo in the docstring and pushed to > master: f49c26db2c38e5b60a6be990b95c2926ecfa6247 > > For the record, this problem appeared in an install-uninstall-install > cycle with no reboot. It's unlikely to appear in the wild, but happens > all the time in CI and on some developers' workflows. > Arghh sorry to come in late, but the second patch is not sufficient :-( You should run kdestroy -A to remove all ccaches, even non primary ones, so that non primary ones are not mistakenly picked up later. kdestroy w/o -A will only destroy the primary one if any is selected. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Wed Jan 22 15:05:47 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 22 Jan 2014 16:05:47 +0100 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <1390401263.15404.37.camel@willson.li.ssimo.org> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> <52DF9201.6090806@redhat.com> <1390401263.15404.37.camel@willson.li.ssimo.org> Message-ID: <52DFDE4B.5090401@redhat.com> On 22.1.2014 15:34, Simo Sorce wrote: > On Wed, 2014-01-22 at 10:40 +0100, Jan Cholasta wrote: >> On 21.1.2014 17:12, Simo Sorce wrote: >>> On Tue, 2014-01-21 at 14:02 +0100, Jan Cholasta wrote: >>>> + request = None >>>> + try: >>>> + request = pkcs10.load_certificate_request(csr) >>>> + subject = pkcs10.get_subject(request) >>>> + subjectaltname = pkcs10.get_subjectaltname(request) >>> >>> Will this make the request fail if there is no subjectaltname ? >> >> No. > > Good. > >>> Later in the patch you seem to be changing from needing managedby_host >>> to needing write access to an entry, I am not sure I understand why that >>> was changed. not saying it is necessarily wrong, but why the original >>> check is not right anymore ? >> >> The original check is wrong, see >> . >> >> The check in my patch allows SAN only if the requesting host has write >> access to all of the SAN services. I'm not entirely sure if this is >> right, but even if it is not, I think we should still check for write >> access to the SAN services, so that access control can be (partially) >> handled by ACIs. > > Right, I remembered that comment, but it just says to check the right > object's managed-by, here instead you changed it to check if you can > write the usercertificate. > > I guess it is the same *if* there is an ACI that gives write permission > when the host is in the managed-by attribute, is that the reasoning ? Exactly. The ACIs that allow this by default are named "Hosts can manage service Certificates and kerberos keys" and "Hosts can manage other host Certificates and kerberos keys". I think the check can be extended to users as well, so that requesting certificate with SAN is allowed only to users which have write access to the SAN services. > > Simo. > -- Jan Cholasta From mkosek at redhat.com Wed Jan 22 15:14:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 22 Jan 2014 16:14:19 +0100 Subject: [Freeipa-devel] [PATCH] 452 httpd should destroy all CCACHEs In-Reply-To: <1390401592.15404.39.camel@willson.li.ssimo.org> References: <52D7DBA3.3010206@redhat.com> <52DE7F13.7060509@redhat.com> <52DE9C62.8070307@redhat.com> <52DFAEA6.7000606@redhat.com> <1390401592.15404.39.camel@willson.li.ssimo.org> Message-ID: <52DFE04B.9000600@redhat.com> On 01/22/2014 03:39 PM, Simo Sorce wrote: > On Wed, 2014-01-22 at 12:42 +0100, Petr Viktorin wrote: >> On 01/21/2014 05:12 PM, Martin Kosek wrote: >>> On 01/21/2014 03:07 PM, Petr Viktorin wrote: >>>> On 01/16/2014 02:16 PM, Martin Kosek wrote: >>>>> [freeipa-mkosek-448-add-runas-option-to-run-function.patch]: >>>>> >>>>> Run function can now run the specified command as different user by >>>>> setting the EUID and EGID for executed process. >>>> >>>> Please add the new argument to the docstring, otherwise ACK >>>> >>>>> [freeipa-mkosek-449-switch-httpd-to-use-default-ccache.patch]: >>>>> >>>>> Stock httpd no longer uses systemd EnvironmentFile option which is >>>>> making FreeIPA's KRB5CCNAME setting ineffective. This can lead in hard >>>>> to debug problems during subsequent ipa-server-install's where HTTP >>>>> may use a stale CCACHE in the default kernel keyring CCACHE. >>>>> >>>>> Avoid forcing custom CCACHE and switch to system one, just make sure >>>>> that it is properly cleaned by kdestroy run as "apache" user during >>>>> FreeIPA server installation process. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4084 >>>> >>>> This does not fix the issue for me. >>>> On a fresh f20 machine, I installed the server, uninstalled it, and installed >>>> again. The second installation failed with the ipa-client-install error >>>> described in the ticket. >>>> >>> >>> On your VM, I saw the method I use for running a command as different process >>> was indeed not effective. I had to change both effective and real UID/GID to >>> make the kdestroy function working. >>> >>> I also added the missing docstrings in 448, both for runas as well as other >>> missing options. >> >> Great, thank you! ACK, fixed a typo in the docstring and pushed to >> master: f49c26db2c38e5b60a6be990b95c2926ecfa6247 >> >> For the record, this problem appeared in an install-uninstall-install >> cycle with no reboot. It's unlikely to appear in the wild, but happens >> all the time in CI and on some developers' workflows. >> > > Arghh sorry to come in late, but the second patch is not sufficient :-( > > You should run kdestroy -A to remove all ccaches, even non primary ones, > so that non primary ones are not mistakenly picked up later. > kdestroy w/o -A will only destroy the primary one if any is selected. > > Simo. Ok, thanks for the warning. Current patch worked in my environment, but is better to do it correctly. Attaching a patch to fix that. BTW, given you read this patch now - are you OK with the approach? Is it fine with you that we do not insist on FILE CCACHE for httpd but just use the default? Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-452-httpd-should-destroy-all-ccaches.patch Type: text/x-patch Size: 1199 bytes Desc: not available URL: From simo at redhat.com Wed Jan 22 15:42:09 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 22 Jan 2014 10:42:09 -0500 Subject: [Freeipa-devel] [PATCH] 452 httpd should destroy all CCACHEs In-Reply-To: <52DFE04B.9000600@redhat.com> References: <52D7DBA3.3010206@redhat.com> <52DE7F13.7060509@redhat.com> <52DE9C62.8070307@redhat.com> <52DFAEA6.7000606@redhat.com> <1390401592.15404.39.camel@willson.li.ssimo.org> <52DFE04B.9000600@redhat.com> Message-ID: <1390405329.15404.57.camel@willson.li.ssimo.org> On Wed, 2014-01-22 at 16:14 +0100, Martin Kosek wrote: > On 01/22/2014 03:39 PM, Simo Sorce wrote: > > On Wed, 2014-01-22 at 12:42 +0100, Petr Viktorin wrote: > >> On 01/21/2014 05:12 PM, Martin Kosek wrote: > >>> On 01/21/2014 03:07 PM, Petr Viktorin wrote: > >>>> On 01/16/2014 02:16 PM, Martin Kosek wrote: > >>>>> [freeipa-mkosek-448-add-runas-option-to-run-function.patch]: > >>>>> > >>>>> Run function can now run the specified command as different user by > >>>>> setting the EUID and EGID for executed process. > >>>> > >>>> Please add the new argument to the docstring, otherwise ACK > >>>> > >>>>> [freeipa-mkosek-449-switch-httpd-to-use-default-ccache.patch]: > >>>>> > >>>>> Stock httpd no longer uses systemd EnvironmentFile option which is > >>>>> making FreeIPA's KRB5CCNAME setting ineffective. This can lead in hard > >>>>> to debug problems during subsequent ipa-server-install's where HTTP > >>>>> may use a stale CCACHE in the default kernel keyring CCACHE. > >>>>> > >>>>> Avoid forcing custom CCACHE and switch to system one, just make sure > >>>>> that it is properly cleaned by kdestroy run as "apache" user during > >>>>> FreeIPA server installation process. > >>>>> > >>>>> https://fedorahosted.org/freeipa/ticket/4084 > >>>> > >>>> This does not fix the issue for me. > >>>> On a fresh f20 machine, I installed the server, uninstalled it, and installed > >>>> again. The second installation failed with the ipa-client-install error > >>>> described in the ticket. > >>>> > >>> > >>> On your VM, I saw the method I use for running a command as different process > >>> was indeed not effective. I had to change both effective and real UID/GID to > >>> make the kdestroy function working. > >>> > >>> I also added the missing docstrings in 448, both for runas as well as other > >>> missing options. > >> > >> Great, thank you! ACK, fixed a typo in the docstring and pushed to > >> master: f49c26db2c38e5b60a6be990b95c2926ecfa6247 > >> > >> For the record, this problem appeared in an install-uninstall-install > >> cycle with no reboot. It's unlikely to appear in the wild, but happens > >> all the time in CI and on some developers' workflows. > >> > > > > Arghh sorry to come in late, but the second patch is not sufficient :-( > > > > You should run kdestroy -A to remove all ccaches, even non primary ones, > > so that non primary ones are not mistakenly picked up later. > > kdestroy w/o -A will only destroy the primary one if any is selected. > > > > Simo. > > Ok, thanks for the warning. Current patch worked in my environment, but is > better to do it correctly. Attaching a patch to fix that. Ack to the patch > BTW, given you read this patch now - are you OK with the approach? Is it fine > with you that we do not insist on FILE CCACHE for httpd but just use the default? Yeah, I see no problem, people can always change the system wide default or add their own unit file if they really have an issue with this, so it is not like a change that pins us down in any specifically bad way. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Jan 22 15:43:27 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 22 Jan 2014 10:43:27 -0500 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <52DFDE4B.5090401@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> <52DF9201.6090806@redhat.com> <1390401263.15404.37.camel@willson.li.ssimo.org> <52DFDE4B.5090401@redhat.com> Message-ID: <1390405407.15404.58.camel@willson.li.ssimo.org> On Wed, 2014-01-22 at 16:05 +0100, Jan Cholasta wrote: > On 22.1.2014 15:34, Simo Sorce wrote: > > On Wed, 2014-01-22 at 10:40 +0100, Jan Cholasta wrote: > >> On 21.1.2014 17:12, Simo Sorce wrote: > >>> On Tue, 2014-01-21 at 14:02 +0100, Jan Cholasta wrote: > >>>> + request = None > >>>> + try: > >>>> + request = pkcs10.load_certificate_request(csr) > >>>> + subject = pkcs10.get_subject(request) > >>>> + subjectaltname = pkcs10.get_subjectaltname(request) > >>> > >>> Will this make the request fail if there is no subjectaltname ? > >> > >> No. > > > > Good. > > > >>> Later in the patch you seem to be changing from needing managedby_host > >>> to needing write access to an entry, I am not sure I understand why that > >>> was changed. not saying it is necessarily wrong, but why the original > >>> check is not right anymore ? > >> > >> The original check is wrong, see > >> . > >> > >> The check in my patch allows SAN only if the requesting host has write > >> access to all of the SAN services. I'm not entirely sure if this is > >> right, but even if it is not, I think we should still check for write > >> access to the SAN services, so that access control can be (partially) > >> handled by ACIs. > > > > Right, I remembered that comment, but it just says to check the right > > object's managed-by, here instead you changed it to check if you can > > write the usercertificate. > > > > I guess it is the same *if* there is an ACI that gives write permission > > when the host is in the managed-by attribute, is that the reasoning ? > > Exactly. The ACIs that allow this by default are named "Hosts can manage > service Certificates and kerberos keys" and "Hosts can manage other host > Certificates and kerberos keys". > > I think the check can be extended to users as well, so that requesting > certificate with SAN is allowed only to users which have write access to > the SAN services. Sounds good to me then, thanks for explaining. The patches also look good, but I would like someone to give them a try for a formal ack. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed Jan 22 16:19:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 22 Jan 2014 17:19:48 +0100 Subject: [Freeipa-devel] [PATCH] 452 httpd should destroy all CCACHEs In-Reply-To: <1390405329.15404.57.camel@willson.li.ssimo.org> References: <52D7DBA3.3010206@redhat.com> <52DE7F13.7060509@redhat.com> <52DE9C62.8070307@redhat.com> <52DFAEA6.7000606@redhat.com> <1390401592.15404.39.camel@willson.li.ssimo.org> <52DFE04B.9000600@redhat.com> <1390405329.15404.57.camel@willson.li.ssimo.org> Message-ID: <52DFEFA4.5000801@redhat.com> On 01/22/2014 04:42 PM, Simo Sorce wrote: > On Wed, 2014-01-22 at 16:14 +0100, Martin Kosek wrote: >> On 01/22/2014 03:39 PM, Simo Sorce wrote: >>> On Wed, 2014-01-22 at 12:42 +0100, Petr Viktorin wrote: >>>> On 01/21/2014 05:12 PM, Martin Kosek wrote: >>>>> On 01/21/2014 03:07 PM, Petr Viktorin wrote: >>>>>> On 01/16/2014 02:16 PM, Martin Kosek wrote: >>>>>>> [freeipa-mkosek-448-add-runas-option-to-run-function.patch]: >>>>>>> >>>>>>> Run function can now run the specified command as different user by >>>>>>> setting the EUID and EGID for executed process. >>>>>> >>>>>> Please add the new argument to the docstring, otherwise ACK >>>>>> >>>>>>> [freeipa-mkosek-449-switch-httpd-to-use-default-ccache.patch]: >>>>>>> >>>>>>> Stock httpd no longer uses systemd EnvironmentFile option which is >>>>>>> making FreeIPA's KRB5CCNAME setting ineffective. This can lead in hard >>>>>>> to debug problems during subsequent ipa-server-install's where HTTP >>>>>>> may use a stale CCACHE in the default kernel keyring CCACHE. >>>>>>> >>>>>>> Avoid forcing custom CCACHE and switch to system one, just make sure >>>>>>> that it is properly cleaned by kdestroy run as "apache" user during >>>>>>> FreeIPA server installation process. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4084 >>>>>> >>>>>> This does not fix the issue for me. >>>>>> On a fresh f20 machine, I installed the server, uninstalled it, and installed >>>>>> again. The second installation failed with the ipa-client-install error >>>>>> described in the ticket. >>>>>> >>>>> >>>>> On your VM, I saw the method I use for running a command as different process >>>>> was indeed not effective. I had to change both effective and real UID/GID to >>>>> make the kdestroy function working. >>>>> >>>>> I also added the missing docstrings in 448, both for runas as well as other >>>>> missing options. >>>> >>>> Great, thank you! ACK, fixed a typo in the docstring and pushed to >>>> master: f49c26db2c38e5b60a6be990b95c2926ecfa6247 >>>> >>>> For the record, this problem appeared in an install-uninstall-install >>>> cycle with no reboot. It's unlikely to appear in the wild, but happens >>>> all the time in CI and on some developers' workflows. >>>> >>> >>> Arghh sorry to come in late, but the second patch is not sufficient :-( >>> >>> You should run kdestroy -A to remove all ccaches, even non primary ones, >>> so that non primary ones are not mistakenly picked up later. >>> kdestroy w/o -A will only destroy the primary one if any is selected. >>> >>> Simo. >> >> Ok, thanks for the warning. Current patch worked in my environment, but is >> better to do it correctly. Attaching a patch to fix that. > > Ack to the patch Pushed to master. > >> BTW, given you read this patch now - are you OK with the approach? Is it fine >> with you that we do not insist on FILE CCACHE for httpd but just use the default? > > Yeah, I see no problem, people can always change the system wide default > or add their own unit file if they really have an issue with this, so it > is not like a change that pins us down in any specifically bad way. > > Simo. > Ok. Thanks, Martin From rcritten at redhat.com Wed Jan 22 16:43:16 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 22 Jan 2014 11:43:16 -0500 Subject: [Freeipa-devel] [PATCH] 0336 rpcserver: Consolidate __call__ in xmlclient and jsonclient_kerb In-Reply-To: <52D53E07.3010006@redhat.com> References: <52A76915.8060007@redhat.com> <52D41032.5060801@redhat.com> <52D53E07.3010006@redhat.com> Message-ID: <52DFF524.7020403@redhat.com> Petr Viktorin wrote: > On 01/13/2014 05:11 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> See commit message & ticket. >>> >>> https://fedorahosted.org/freeipa/ticket/4069 >> >> Our handling of XML-RPC introspection is iffy as it is and this would >> remove those methods completely. Can you add them back into the >> xmlserver class? > > Not just iffy, it's non-existent. See > https://fedorahosted.org/freeipa/ticket/2937. > The patch removes the __system dict which has been unused since at least > Jason's web UI work in 2009, Git tells me. The patch did leave the > actual methods. > > > Well, actually it's not that hard to get these working again; see > attached patch (which can be reviewed separately). > Ack for both. As an aside, I noticed that we no longer display the server we're trying to contact in verbose mode (ipa -vv). This was often help in diagnosing problems, particularly with the fallback routines. Not related to these patches though. rob From jcholast at redhat.com Wed Jan 22 16:47:36 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 22 Jan 2014 17:47:36 +0100 Subject: [Freeipa-devel] [PATCHES] 225-230 Drop support for the legacy LDAP API In-Reply-To: <52DD0741.2040209@redhat.com> References: <52A72DA8.4090104@redhat.com> <52AB16B8.6050808@redhat.com> <52AEC654.5040602@redhat.com> <52AF03F2.2090904@redhat.com> <52CBF8FB.7090808@redhat.com> <52D00B84.1090804@redhat.com> <52D51218.1090304@redhat.com> <52DD0741.2040209@redhat.com> Message-ID: <52DFF628.2010906@redhat.com> On 20.1.2014 12:23, Petr Viktorin wrote: > On 01/14/2014 11:31 AM, Jan Cholasta wrote: >> On 10.1.2014 16:02, Petr Viktorin wrote: >>> On 01/07/2014 01:54 PM, Jan Cholasta wrote: >>>> On 16.12.2013 14:45, Petr Viktorin wrote: >>>>> On 12/16/2013 10:22 AM, Jan Cholasta wrote: >>>>>> On 13.12.2013 15:16, Petr Viktorin wrote: >>>>>>> On 12/10/2013 04:05 PM, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I believe the time has come to drop support for the legacy (dn, >>>>>>>> entry_attrs) tuple API and move to the new LDAPEntry API >>>>>>>> exclusively. >>>>>>>> The attached patches convert existing code which uses the old >>>>>>>> API to >>>>>>>> the >>>>>>>> new API and remove backward compatibility code from the ipaldap >>>>>>>> module. >>>>>>>> >>>>>>>> Note that there are still some functions/methods which accept >>>>>>>> separate >>>>>>>> dn and entry_attrs arguments, they will be adapted to LDAPEntry >>>>>>>> later. >>>>>>>> >>>>>>>> Honza >>>>>>> >>>>>>> The first N-1 patches can be tested,acked,pushed independently, >>>>>>> right? >>>>>> >>>>>> Yes. >>>>>> >>>>>>> If that's the case, ACK for 225 >>>>> >>>>> Pushed that one to master, 5 more to go. >>>>> bc3f3381c6bf0b4941889b775025a60f56318551 >>>>> >>> >>> 226 needs a rebase. >>> >>> 227: in install/tools/ipa-adtrust-install: >>> >>> + entry_attrs = conn.make_entry( >>> + dn, >>> + objectclass=['top', 'pkiuser', 'nscontainer'], >>> + usercertificate=cert) >>> + conn.add_entry(entry_attrs) >>> >>> Shouldn't it be `usercertificate=[cert]` now? Similarly in ra_cert, and >>> in ipa-server-install with ipacertificatesubjectbase >>> >>> Otherwise this looks good. >>> >>> 228: in ipaserver/install/plugins/update_idranges.py, again we should >>> use lists >>> >>> Otherwise it looks good >>> >>> 229: ACK >>> >> >> Rebased and fixed everything, updated patches attached. > > Here, patch 226 breaks tests for selinuxusermap_enable/disable, at > least. The EmptyModlist and AlreadyActive/AlreadyInactive error is no > longer raised, since the previous entry state is no longer retrieved. > Well, I forgot to test this patchset after patches for were pushed, sorry. Added new patch 235 which makes LDAPUpdate get old entry state from LDAP, it fixes most of the issues in *_mod commands. Fixed the rest of the issues in patches 226-230 and rebased them on top of patch 235. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-226.3-Convert-remaining-frontend-code-to-LDAPEntry-API.patch Type: text/x-patch Size: 103175 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-227.3-Convert-remaining-installer-code-to-LDAPEntry-API.patch Type: text/x-patch Size: 14635 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-228.3-Convert-remaining-update-code-to-LDAPEntry-API.patch Type: text/x-patch Size: 10421 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-229.3-Convert-remaining-test-code-to-LDAPEntry-API.patch Type: text/x-patch Size: 3334 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-230.3-Raise-an-exception-when-legacy-LDAP-API-is-used.patch Type: text/x-patch Size: 3254 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-235-Get-original-entry-state-from-LDAP-in-LDAPUpdate.patch Type: text/x-patch Size: 1106 bytes Desc: not available URL: From pviktori at redhat.com Wed Jan 22 18:34:24 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 22 Jan 2014 19:34:24 +0100 Subject: [Freeipa-devel] [PATCH] 0336 rpcserver: Consolidate __call__ in xmlclient and jsonclient_kerb In-Reply-To: <52DFF524.7020403@redhat.com> References: <52A76915.8060007@redhat.com> <52D41032.5060801@redhat.com> <52D53E07.3010006@redhat.com> <52DFF524.7020403@redhat.com> Message-ID: <52E00F30.8080907@redhat.com> On 01/22/2014 05:43 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 01/13/2014 05:11 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> See commit message & ticket. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4069 >>> >>> Our handling of XML-RPC introspection is iffy as it is and this would >>> remove those methods completely. Can you add them back into the >>> xmlserver class? >> >> Not just iffy, it's non-existent. See >> https://fedorahosted.org/freeipa/ticket/2937. >> The patch removes the __system dict which has been unused since at least >> Jason's web UI work in 2009, Git tells me. The patch did leave the >> actual methods. >> >> >> Well, actually it's not that hard to get these working again; see >> attached patch (which can be reviewed separately). >> > > Ack for both. Thanks! Pushed to master: 6bdc75ea24d0798c6779130451e47e569900ff4e Implement XML introspection 6a2b70946f2322a354ac7a4de256128d8a84ffd9 rpcserver: Consolidate __call__ in xmlclient and jsonclient_kerb > As an aside, I noticed that we no longer display the server we're trying > to contact in verbose mode (ipa -vv). This was often help in diagnosing > problems, particularly with the fallback routines. Not related to these > patches though. https://fedorahosted.org/freeipa/ticket/4135 -- Petr? From rcritten at redhat.com Wed Jan 22 19:00:51 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 22 Jan 2014 14:00:51 -0500 Subject: [Freeipa-devel] [PATCH] 0335 ipa-replica-install: Move check for existing host before DNS resolution check In-Reply-To: <52D7CA55.6030908@redhat.com> References: <52A71945.6040503@redhat.com> <52D41206.6000101@redhat.com> <52D5370D.5050101@redhat.com> <52D58904.6040509@redhat.com> <52D7CA55.6030908@redhat.com> Message-ID: <52E01563.3000406@redhat.com> Petr Viktorin wrote: > On 01/14/2014 07:59 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 01/13/2014 05:19 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> See commit message & ticket for details. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3889 >>>> >>>> If memory serves this was done so that both the replication and the >>>> host >>>> checks would be done so the admin wouldn't die a death of a thousand >>>> cuts. >>>> >>>> If a leftover agreement exists then the replica install will fail. You >>>> delete the agreement. The next install may fail too if the host exists. >>>> We should check for both before quitting. >>> >>> AFAIK nowadays ipa-replica-manage del should also remove the host entry, >>> so it's correct to suggest just that. >>> >> >> I couldn't find any place in the code the host is removed. This would >> have to be a pretty specialized case because you'd only remove the host >> if you were also deleting the last agreement. > > Well, `ipa-replica-manage del` does remove all agreements. So if we > suggest deleting the replica, it makes no sense to suggest running `ipa > host-del` after it. The replica_cleanup() function removes all principals associated to the master you're deleting, effectively deleting the host. That's what you saw in your reproduction (and why on a cursory look I couldn't find anywhere we explicitly delete the host). I still have the feeling one might see this two-step delete agreement, delete host, particularly when installs go sideways, but we're talking a rare case of running one extra command at worst. I wasn't able to force it to happen so my concerns are likely unwarranted. Given the patch fixes a real, rather that my potentially imaginary issue, ACK. We can always revisit it if needed. rob From rcritten at redhat.com Wed Jan 22 19:04:41 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 22 Jan 2014 14:04:41 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52DE3BCB.5030107@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> Message-ID: <52E01649.7060002@redhat.com> Petr Viktorin wrote: > On 01/20/2014 05:21 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 01/17/2014 10:24 PM, Rob Crittenden wrote: >>>> Implement an IPA RESTful Foreman-compatible smart proxy. This exposes >>>> hosts and hostgroups via an unauthenticated REST API. The idea is that >>>> this service runs on the Foreman server and only listens on local >>>> ports. >>>> >>>> It is a CherryPy-based server and that handles the majority of REST >>>> for us. >>>> >>>> I included some tests, they can be executed with: nosetests -v >>>> smartproxy/tests >>> >>> Why is it not a part of ipatests? >> >> I can move it if it's a show-stopper. It seemed specific to this one >> directory so I stuck it there. It isn't relevant for most testing and >> requires some manual configuration (though CI could handle it). > > Not strictly a show stopper, but please move it. At the very least it > should end up in the freeipa-tests package. Moved. > A lot of the tests (integration, webUI) need manual configuration, so > this would be no exception. Of course the tests should be skipped if the > configuration was not done, and the config instructions should be added > to/linked from http://www.freeipa.org/page/Testing Hmm, maybe. There are instructions to set up the environment in the man page. Testing beyond that consists of ./make-test tests/test_smartproxy I can add that testing bit once the patch is approved I suppose. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1106-2-rest.patch Type: text/x-diff Size: 42652 bytes Desc: not available URL: From npmccallum at redhat.com Wed Jan 22 20:59:17 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 22 Jan 2014 15:59:17 -0500 Subject: [Freeipa-devel] OTP Sync Client Message-ID: <1390424357.1984.104.camel@localhost.localdomain> In attempting to write an OTP synchronization client, I've noticed it doesn't fit into the framework very well. The job of the client is to perform the synchronization extended operation. The format of the request is this: OTPSyncRequestValue ::= SEQUENCE { userDN OCTET STRING, tokenDN [0] OCTET STRING OPTIONAL, firstFactor [1] OCTET STRING OPTIONAL, firstCode INTEGER, secondCode INTEGER } In all cases, the user MUST provide two token codes and MAY provide the DN of a token to sync. >From here two cases exist: bound and unbound. In the unbound case, both the userDN and firstFactor fields are required and authentication is performed internally. In the bound case, the client has already bound (usually via a kerberos ticket). In this case, the client must provide userDN only. There are two options here. First, the client can generate the userDN automatically from the kerberos ticket metadata. Second, the extop plugin can make the userDN field optional and simply rely on the internal bind DN. This is my preferred route, and will require a new revision of the otp sync patch (no problem). In this second case, if the user is bound, the DS plugin would ignore the values of userDN/firstFactor. Assuming the second case to be true, how do I write a command in the framework that will attempt a krb5 bind and then prompt for username/password if the bind fails? Also, how do I, on the client side, without any bind to LDAP translate the username to the userDN? The same is true for the token ID to DN translation? Would it be better to write this code independently of the FreeIPA client command framework? Nathaniel From rcritten at redhat.com Wed Jan 22 21:03:36 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 22 Jan 2014 16:03:36 -0500 Subject: [Freeipa-devel] OTP Sync Client In-Reply-To: <1390424357.1984.104.camel@localhost.localdomain> References: <1390424357.1984.104.camel@localhost.localdomain> Message-ID: <52E03228.9020002@redhat.com> Nathaniel McCallum wrote: > In attempting to write an OTP synchronization client, I've noticed it > doesn't fit into the framework very well. The job of the client is to > perform the synchronization extended operation. The format of the > request is this: > > OTPSyncRequestValue ::= SEQUENCE { > userDN OCTET STRING, > tokenDN [0] OCTET STRING OPTIONAL, > firstFactor [1] OCTET STRING OPTIONAL, > firstCode INTEGER, > secondCode INTEGER > } > > In all cases, the user MUST provide two token codes and MAY provide the > DN of a token to sync. > >>From here two cases exist: bound and unbound. > > In the unbound case, both the userDN and firstFactor fields are required > and authentication is performed internally. > > In the bound case, the client has already bound (usually via a kerberos > ticket). In this case, the client must provide userDN only. There are > two options here. First, the client can generate the userDN > automatically from the kerberos ticket metadata. Second, the extop > plugin can make the userDN field optional and simply rely on the > internal bind DN. This is my preferred route, and will require a new > revision of the otp sync patch (no problem). In this second case, if the > user is bound, the DS plugin would ignore the values of > userDN/firstFactor. > > Assuming the second case to be true, how do I write a command in the > framework that will attempt a krb5 bind and then prompt for > username/password if the bind fails? Also, how do I, on the client side, > without any bind to LDAP translate the username to the userDN? The same > is true for the token ID to DN translation? Would it be better to write > this code independently of the FreeIPA client command framework? You can override the forward() command in the plugin to do client-side work. There are a few examples, see service_show and automountlocation_import. I just wonder how this would work in the UI. rob From npmccallum at redhat.com Wed Jan 22 21:07:11 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 22 Jan 2014 16:07:11 -0500 Subject: [Freeipa-devel] OTP Sync Client In-Reply-To: <52E03228.9020002@redhat.com> References: <1390424357.1984.104.camel@localhost.localdomain> <52E03228.9020002@redhat.com> Message-ID: <1390424831.1984.106.camel@localhost.localdomain> On Wed, 2014-01-22 at 16:03 -0500, Rob Crittenden wrote: > Nathaniel McCallum wrote: > > In attempting to write an OTP synchronization client, I've noticed it > > doesn't fit into the framework very well. The job of the client is to > > perform the synchronization extended operation. The format of the > > request is this: > > > > OTPSyncRequestValue ::= SEQUENCE { > > userDN OCTET STRING, > > tokenDN [0] OCTET STRING OPTIONAL, > > firstFactor [1] OCTET STRING OPTIONAL, > > firstCode INTEGER, > > secondCode INTEGER > > } > > > > In all cases, the user MUST provide two token codes and MAY provide the > > DN of a token to sync. > > > >>From here two cases exist: bound and unbound. > > > > In the unbound case, both the userDN and firstFactor fields are required > > and authentication is performed internally. > > > > In the bound case, the client has already bound (usually via a kerberos > > ticket). In this case, the client must provide userDN only. There are > > two options here. First, the client can generate the userDN > > automatically from the kerberos ticket metadata. Second, the extop > > plugin can make the userDN field optional and simply rely on the > > internal bind DN. This is my preferred route, and will require a new > > revision of the otp sync patch (no problem). In this second case, if the > > user is bound, the DS plugin would ignore the values of > > userDN/firstFactor. > > > > Assuming the second case to be true, how do I write a command in the > > framework that will attempt a krb5 bind and then prompt for > > username/password if the bind fails? Also, how do I, on the client side, > > without any bind to LDAP translate the username to the userDN? The same > > is true for the token ID to DN translation? Would it be better to write > > this code independently of the FreeIPA client command framework? > > You can override the forward() command in the plugin to do client-side > work. There are a few examples, see service_show and > automountlocation_import. I just wonder how this would work in the UI. I believe the intention in the UI is to just handle the unbound case with no tokenDN option. It would essentially be a login screen that would look like this: Username: _______________ Password: _______________ First Token: _______________ Second Token: _______________ Nathaniel From rcritten at redhat.com Wed Jan 22 21:16:17 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 22 Jan 2014 16:16:17 -0500 Subject: [Freeipa-devel] OTP Sync Client In-Reply-To: <1390424831.1984.106.camel@localhost.localdomain> References: <1390424357.1984.104.camel@localhost.localdomain> <52E03228.9020002@redhat.com> <1390424831.1984.106.camel@localhost.localdomain> Message-ID: <52E03521.3060405@redhat.com> Nathaniel McCallum wrote: > On Wed, 2014-01-22 at 16:03 -0500, Rob Crittenden wrote: >> Nathaniel McCallum wrote: >>> In attempting to write an OTP synchronization client, I've noticed it >>> doesn't fit into the framework very well. The job of the client is to >>> perform the synchronization extended operation. The format of the >>> request is this: >>> >>> OTPSyncRequestValue ::= SEQUENCE { >>> userDN OCTET STRING, >>> tokenDN [0] OCTET STRING OPTIONAL, >>> firstFactor [1] OCTET STRING OPTIONAL, >>> firstCode INTEGER, >>> secondCode INTEGER >>> } >>> >>> In all cases, the user MUST provide two token codes and MAY provide the >>> DN of a token to sync. >>> >>> >From here two cases exist: bound and unbound. >>> >>> In the unbound case, both the userDN and firstFactor fields are required >>> and authentication is performed internally. >>> >>> In the bound case, the client has already bound (usually via a kerberos >>> ticket). In this case, the client must provide userDN only. There are >>> two options here. First, the client can generate the userDN >>> automatically from the kerberos ticket metadata. Second, the extop >>> plugin can make the userDN field optional and simply rely on the >>> internal bind DN. This is my preferred route, and will require a new >>> revision of the otp sync patch (no problem). In this second case, if the >>> user is bound, the DS plugin would ignore the values of >>> userDN/firstFactor. >>> >>> Assuming the second case to be true, how do I write a command in the >>> framework that will attempt a krb5 bind and then prompt for >>> username/password if the bind fails? Also, how do I, on the client side, >>> without any bind to LDAP translate the username to the userDN? The same >>> is true for the token ID to DN translation? Would it be better to write >>> this code independently of the FreeIPA client command framework? >> >> You can override the forward() command in the plugin to do client-side >> work. There are a few examples, see service_show and >> automountlocation_import. I just wonder how this would work in the UI. > > I believe the intention in the UI is to just handle the unbound case > with no tokenDN option. It would essentially be a login screen that > would look like this: > Username: _______________ > Password: _______________ > First Token: _______________ > Second Token: _______________ > > Nathaniel > There is also the concept of an interactive prompt. The DNS plugin makes fairly extensive use of this. It might be useful as well as it can perform actions during the prompting process letting you avoid too much complexity in forward(). rob From pviktori at redhat.com Thu Jan 23 09:00:22 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 23 Jan 2014 10:00:22 +0100 Subject: [Freeipa-devel] [PATCH] 0335 ipa-replica-install: Move check for existing host before DNS resolution check In-Reply-To: <52E01563.3000406@redhat.com> References: <52A71945.6040503@redhat.com> <52D41206.6000101@redhat.com> <52D5370D.5050101@redhat.com> <52D58904.6040509@redhat.com> <52D7CA55.6030908@redhat.com> <52E01563.3000406@redhat.com> Message-ID: <52E0DA26.9030008@redhat.com> On 01/22/2014 08:00 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 01/14/2014 07:59 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 01/13/2014 05:19 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> See commit message & ticket for details. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3889 >>>>> >>>>> If memory serves this was done so that both the replication and the >>>>> host >>>>> checks would be done so the admin wouldn't die a death of a thousand >>>>> cuts. >>>>> >>>>> If a leftover agreement exists then the replica install will fail. You >>>>> delete the agreement. The next install may fail too if the host >>>>> exists. >>>>> We should check for both before quitting. >>>> >>>> AFAIK nowadays ipa-replica-manage del should also remove the host >>>> entry, >>>> so it's correct to suggest just that. >>>> >>> >>> I couldn't find any place in the code the host is removed. This would >>> have to be a pretty specialized case because you'd only remove the host >>> if you were also deleting the last agreement. >> >> Well, `ipa-replica-manage del` does remove all agreements. So if we >> suggest deleting the replica, it makes no sense to suggest running `ipa >> host-del` after it. > > The replica_cleanup() function removes all principals associated to the > master you're deleting, effectively deleting the host. That's what you > saw in your reproduction (and why on a cursory look I couldn't find > anywhere we explicitly delete the host). > > I still have the feeling one might see this two-step delete agreement, > delete host, particularly when installs go sideways, but we're talking a > rare case of running one extra command at worst. I wasn't able to force > it to happen so my concerns are likely unwarranted. I'd like to see the situation where that happens. I'd consider it a bug in ipe-replica-manage. > Given the patch fixes a real, rather that my potentially imaginary > issue, ACK. We can always revisit it if needed. Thanks, pushed to master: b4401a17706176ed7a82d82ad559f30c78a37ab2 -- Petr? From pvoborni at redhat.com Thu Jan 23 09:28:47 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 23 Jan 2014 10:28:47 +0100 Subject: [Freeipa-devel] OTP Sync Client In-Reply-To: <1390424831.1984.106.camel@localhost.localdomain> References: <1390424357.1984.104.camel@localhost.localdomain> <52E03228.9020002@redhat.com> <1390424831.1984.106.camel@localhost.localdomain> Message-ID: <52E0E0CF.8090300@redhat.com> On 22.1.2014 22:07, Nathaniel McCallum wrote: > On Wed, 2014-01-22 at 16:03 -0500, Rob Crittenden wrote: >> Nathaniel McCallum wrote: >>> In attempting to write an OTP synchronization client, I've noticed it >>> doesn't fit into the framework very well. The job of the client is to >>> perform the synchronization extended operation. The format of the >>> request is this: >>> >>> OTPSyncRequestValue ::= SEQUENCE { >>> userDN OCTET STRING, >>> tokenDN [0] OCTET STRING OPTIONAL, >>> firstFactor [1] OCTET STRING OPTIONAL, >>> firstCode INTEGER, >>> secondCode INTEGER >>> } >>> >>> In all cases, the user MUST provide two token codes and MAY provide the >>> DN of a token to sync. >>> >>> >From here two cases exist: bound and unbound. >>> >>> In the unbound case, both the userDN and firstFactor fields are required >>> and authentication is performed internally. >>> >>> In the bound case, the client has already bound (usually via a kerberos >>> ticket). In this case, the client must provide userDN only. There are >>> two options here. First, the client can generate the userDN >>> automatically from the kerberos ticket metadata. Second, the extop >>> plugin can make the userDN field optional and simply rely on the >>> internal bind DN. This is my preferred route, and will require a new >>> revision of the otp sync patch (no problem). In this second case, if the >>> user is bound, the DS plugin would ignore the values of >>> userDN/firstFactor. >>> >>> Assuming the second case to be true, how do I write a command in the >>> framework that will attempt a krb5 bind and then prompt for >>> username/password if the bind fails? Also, how do I, on the client side, >>> without any bind to LDAP translate the username to the userDN? The same >>> is true for the token ID to DN translation? Would it be better to write >>> this code independently of the FreeIPA client command framework? Look at ipaserver.rpcserver.login_password class. IMO the code shares a lot of similarities with your intentions. >> >> You can override the forward() command in the plugin to do client-side >> work. There are a few examples, see service_show and >> automountlocation_import. I just wonder how this would work in the UI. > > I believe the intention in the UI is to just handle the unbound case > with no tokenDN option. It would essentially be a login screen that > would look like this: > Username: _______________ > Password: _______________ > First Token: _______________ > Second Token: _______________ > > Nathaniel > +1 It could be further extended to a simple "token portal" where one could login via first factor and then list tokens and sync a selected token. The only issue is that it's quite hard to achieve this without binding(sending psw) in each request - IPA framework is not designed for such task. The issue is getting a session. If we were able to get a session we could use the method described below. Second Web UI use case might be: When user is logged in - via other "working" token or different auth method (i.e., password auth is enabled), he can: - open OTP tokens page - open some token details - select 'sync' action - enter OTP1, OTP2, confirm This would require standard IPA command; something like `otptoken_sync ipatokenuniqueid --otp1=key1 --otp2=key2` -- Petr Vobornik From mkosek at redhat.com Thu Jan 23 11:24:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 23 Jan 2014 12:24:28 +0100 Subject: [Freeipa-devel] [PATCHES] 0447-0449 Add support for managed permissions In-Reply-To: <52DF8F0E.9020705@redhat.com> References: <52CD738A.40105@redhat.com> <52DF8F0E.9020705@redhat.com> Message-ID: <52E0FBEC.2020303@redhat.com> On 01/22/2014 10:27 AM, Petr Viktorin wrote: > On 01/08/2014 04:49 PM, Petr Viktorin wrote: >> Hello, >> This adds "managed" permissions, the framework that will make our >> default permissions merge IPA updates and user changes sanely. >> >> There is no updater yet, nor does this add any actual managed >> permissions, so there's no user-visible change (beyond help text and a >> disabled option). To test the patch you might need to touch LDAP directly. >> >> Ticket: https://fedorahosted.org/freeipa/ticket/4033 >> Design (no updater & plugin changes yet): >> http://www.freeipa.org/page/V3/Managed_Read_permissions >> >> 0447 - Minor fixes. >> 0448 - Since you can't create managed permissions through the API, I >> needed to get creative with the declarative tests. The tests will need a >> custom function that adds a managed perm. >> 0449 - The change itself. > > ping; any thoughts on this one? > > 1) 449, the comment: +Deleting or renaming a managed permission, as well as changing its target, +is not supported. +""") + _(""" I am not sure that the phrase "not supported" is the right one. It sounds to me like this is something we want to allow, just not implemented yet. IMO "is not allowed" would be better. 2) Can you add allow_mod_for_managed flag description to parameters.py? + flags={'no_create', 'allow_mod_for_managed'}, So far we try to add all flag descriptions there. 3) When I updated the test to not delete the testperm, I tried to show the managed permission and it is not entirely clear, see: # ipa permission-show testperm Permission name: testperm Permissions: write * Attributes: cn, o, sn * Excluded attributes: cn, sn Bind rule type: all Subtree: cn=users,cn=accounts,dc=example,dc=com ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com Type: user * Default attributes: l, o, cn * Effective attributes: l, o The "Attributes" mean actually attributes explicitly allowed by user, but it is not obvious from the output. Maybe it would be better to return only "Effective attributes" by default and return the 3 source lists only when --all is passed. But this would require us to let Command override LDAPObject's default_attributes, which framework cannot do. Alternatively, we may choose to use the attributes differently with managed permissions: - we add the new attributeType "ipaPermIncludedAttr". It would be used for the user-specified whitelist of attributes instead of ipaPermAllowedAttr - we do not use the ipaPermAllowedAttr with managed attributes at all or use it for the "Effective attributes" list My point is that the semantics of ipaPermAllowedAttr is different for managed and non-managed permission, so it may confuse people. For example, you may want to search for all permissions that allow attribute "sn": # ipa permission-find --attrs sn --------------------- 4 permissions matched --------------------- Permission name: anon Permissions: read Attributes: sn Bind rule type: anonymous Subtree: cn=users,cn=accounts,dc=example,dc=com ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com Type: user ... Permission name: testperm Permissions: write Attributes: cn, o, sn Excluded attributes: cn, sn Bind rule type: anonymous Subtree: cn=users,cn=accounts,dc=example,dc=com ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com Type: user Default attributes: l, o, cn Effective attributes: l, o ... As you see, it matched both testperm and anon even though testperm does not really allow sn as it excluded. Thoughts? Martin From pspacek at redhat.com Thu Jan 23 11:32:08 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 23 Jan 2014 12:32:08 +0100 Subject: [Freeipa-devel] [PATCH 0007] Limit memberOf and refInt DS plugins to main IPA suffix Message-ID: <52E0FDB8.2040806@redhat.com> Hello, this patch solves performance problems with retro change log trimming. It has to go to the same branches as Ana's patch 0079 Enable Retro Changelog and Content Synchronization DS plugins. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0007-Limit-memberOf-and-refInt-DS-plugins-to-main-IPA-suf.patch Type: text/x-patch Size: 2831 bytes Desc: not available URL: From pviktori at redhat.com Thu Jan 23 12:23:38 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 23 Jan 2014 13:23:38 +0100 Subject: [Freeipa-devel] [PATCHES] 0447-0449 Add support for managed permissions In-Reply-To: <52E0FBEC.2020303@redhat.com> References: <52CD738A.40105@redhat.com> <52DF8F0E.9020705@redhat.com> <52E0FBEC.2020303@redhat.com> Message-ID: <52E109CA.2020605@redhat.com> On 01/23/2014 12:24 PM, Martin Kosek wrote: > On 01/22/2014 10:27 AM, Petr Viktorin wrote: >> On 01/08/2014 04:49 PM, Petr Viktorin wrote: >>> Hello, >>> This adds "managed" permissions, the framework that will make our >>> default permissions merge IPA updates and user changes sanely. >>> >>> There is no updater yet, nor does this add any actual managed >>> permissions, so there's no user-visible change (beyond help text and a >>> disabled option). To test the patch you might need to touch LDAP directly. >>> >>> Ticket: https://fedorahosted.org/freeipa/ticket/4033 >>> Design (no updater & plugin changes yet): >>> http://www.freeipa.org/page/V3/Managed_Read_permissions >>> >>> 0447 - Minor fixes. >>> 0448 - Since you can't create managed permissions through the API, I >>> needed to get creative with the declarative tests. The tests will need a >>> custom function that adds a managed perm. >>> 0449 - The change itself. >> >> ping; any thoughts on this one? >> >> > > 1) 449, the comment: > > +Deleting or renaming a managed permission, as well as changing its target, > +is not supported. > +""") + _(""" > > I am not sure that the phrase "not supported" is the right one. It sounds to me > like this is something we want to allow, just not implemented yet. IMO "is not > allowed" would be better. Makes sense. > 2) Can you add allow_mod_for_managed flag description to parameters.py? > > + flags={'no_create', 'allow_mod_for_managed'}, > > So far we try to add all flag descriptions there. OK > 3) When I updated the test to not delete the testperm, I tried to show the > managed permission and it is not entirely clear, see: > > # ipa permission-show testperm > Permission name: testperm > Permissions: write > * Attributes: cn, o, sn > * Excluded attributes: cn, sn > Bind rule type: all > Subtree: cn=users,cn=accounts,dc=example,dc=com > ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com > Type: user > * Default attributes: l, o, cn > * Effective attributes: l, o Well, this is a tradeoff between presenting what's stored in LDAP and what's in the ACI. > The "Attributes" mean actually attributes explicitly allowed by user, but it is > not obvious from the output. > > Maybe it would be better to return only "Effective attributes" by default and > return the 3 source lists only when --all is passed. But this would require us > to let Command override LDAPObject's default_attributes, which framework cannot do. Modifying default_attributes would not work because the 3 lists need to be loaded from LDAP to determine the effective attributes. It's possible to remove the extra attributes in the post_callback, postprocess_result already does similar output manipulation. > Alternatively, we may choose to use the attributes differently with managed > permissions: > - we add the new attributeType "ipaPermIncludedAttr". It would be used for the > user-specified whitelist of attributes instead of ipaPermAllowedAttr > - we do not use the ipaPermAllowedAttr with managed attributes at all or use it > for the "Effective attributes" list > > My point is that the semantics of ipaPermAllowedAttr is different for managed > and non-managed permission, so it may confuse people. Well, the semantics are always the same (effective = (default | allowed) - excluded). I agree that it can be confusing; perhaps I'm in too deep to judge how it looks from the outside. > For example, you may want > to search for all permissions that allow attribute "sn": > > # ipa permission-find --attrs sn > --------------------- > 4 permissions matched > --------------------- > Permission name: anon > Permissions: read > Attributes: sn > Bind rule type: anonymous > Subtree: cn=users,cn=accounts,dc=example,dc=com > ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com > Type: user > ... > Permission name: testperm > Permissions: write > Attributes: cn, o, sn > Excluded attributes: cn, sn > Bind rule type: anonymous > Subtree: cn=users,cn=accounts,dc=example,dc=com > ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com > Type: user > Default attributes: l, o, cn > Effective attributes: l, o > ... > > As you see, it matched both testperm and anon even though testperm does not > really allow sn as it excluded. > > Thoughts? Well, we could have default, included, excluded attributes stored in LDAP as now (using the name "included" instead of "allowed"), and make effective attributes (--attrs) into an updatable virtual attribute: when setting it, IPA would consult the "default" attributes and update "included"/"excluded" accordingly. (With non-managed permissions "default" is empty, so only "included" would be updated.) And searching on --attrs would construct an appropriate filter. I thought about this approach earlier but thought that it obscured what's actually stored in LDAP. Given recent discussions I'm now thinking I shouldn't have rejected it. -- Petr? From sbose at redhat.com Thu Jan 23 12:50:02 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 23 Jan 2014 13:50:02 +0100 Subject: [Freeipa-devel] [PATCH] 126 CLDAP: generate NetBIOS name like ipa-adtrust-install does Message-ID: <20140123125002.GB2648@localhost.localdomain> Hi, here is another one for the CLDAP NetBIOS name issue. bye, Sumit -------------- next part -------------- From 744507e74055ffd8bf40f6b7d67ff094f975903e Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Thu, 23 Jan 2014 12:36:38 +0100 Subject: [PATCH] CLDAP: generate NetBIOS name like ipa-adtrust-install does Fixes https://fedorahosted.org/freeipa/ticket/4116 --- daemons/ipa-slapi-plugins/ipa-cldap/Makefile.am | 19 ++++++ daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.h | 2 + .../ipa-cldap/ipa_cldap_netlogon.c | 47 ++++++++++----- .../ipa-slapi-plugins/ipa-cldap/ipa_cldap_tests.c | 68 ++++++++++++++++++++++ 4 files changed, 122 insertions(+), 14 deletions(-) create mode 100644 daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_tests.c diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/Makefile.am b/daemons/ipa-slapi-plugins/ipa-cldap/Makefile.am index 70b08835e5629026c80c21c83e0c749a387b73a4..8e35cdbd4499582dd0e14562f05e4eda5bb3ec5b 100644 --- a/daemons/ipa-slapi-plugins/ipa-cldap/Makefile.am +++ b/daemons/ipa-slapi-plugins/ipa-cldap/Makefile.am @@ -35,6 +35,25 @@ libipa_cldap_la_LIBADD = \ $(NDRNBT_LIBS) \ $(NULL) +if HAVE_CMOCKA +TESTS = ipa_cldap_tests +check_PROGRAMS = ipa_cldap_tests +endif + +ipa_cldap_tests_SOURCES = \ + ipa_cldap_tests.c \ + ipa_cldap_netlogon.c \ + $(NULL) +ipa_cldap_tests_CFLAGS = $(CMOCKA_FLAGS) +ipa_cldap_tests_LDFLAGS = \ + -rpath $(shell pkg-config --libs-only-L dirsrv | sed -e 's/-L//') \ + $(NULL) +ipa_cldap_tests_LDADD = \ + $(CMOCKA_LIBS) \ + $(NDRNBT_LIBS) \ + $(DIRSRV_LIBS) \ + $(NULL) + appdir = $(IPA_DATA_DIR) app_DATA = \ ipa-cldap-conf.ldif \ diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.h b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.h index 3f420ff2c5acc7bd75bff7f042f76b9c61144461..5e963e3f8557d468d646e6343366921d17242e2d 100644 --- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.h +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.h @@ -51,6 +51,7 @@ #include #include #include +#include #include "util.h" #define IPA_CLDAP_PLUGIN_NAME "CLDAP Server" @@ -106,4 +107,5 @@ int ipa_cldap_netlogon(struct ipa_cldap_ctx *ctx, struct ipa_cldap_req *req, struct berval *reply); +char *make_netbios_name(TALLOC_CTX *mem_ctx, const char *s); #endif /* _IPA_CLDAP_H_ */ diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c index c03172d474589ddee84f1cfa5395c23fdba83bcb..1d16de7be09cf9675c2ee1a602ddfb800cd6e7af 100644 --- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c @@ -121,6 +121,38 @@ done: return ret; } +char *make_netbios_name(TALLOC_CTX *mem_ctx, const char *s) +{ + char *nb_name; + const char *p; + size_t c = 0; + + if (s == NULL) { + return NULL; + } + + nb_name = talloc_zero_size(mem_ctx, NETBIOS_NAME_MAX + 1); + if (nb_name == NULL) { + return NULL; + } + + for (p = s; *p && c < NETBIOS_NAME_MAX; p++) { + /* Create the NetBIOS name from the first segment of the hostname */ + if (*p == '.') { + break; + } else if (isalnum(*p)) { + nb_name[c++] = toupper(*p); + } + } + + if (*nb_name == '\0') { + talloc_free(nb_name); + return NULL; + } + + return nb_name; +} + #define NETLOGON_SAM_LOGON_RESPONSE_EX_pusher \ (ndr_push_flags_fn_t)ndr_push_NETLOGON_SAM_LOGON_RESPONSE_EX @@ -131,8 +163,6 @@ static int ipa_cldap_encode_netlogon(char *fq_hostname, char *domain, struct NETLOGON_SAM_LOGON_RESPONSE_EX *nlr; enum ndr_err_code ndr_err; DATA_BLOB blob; - char *pdc_name; - char *p; int ret; nlr = talloc_zero(NULL, struct NETLOGON_SAM_LOGON_RESPONSE_EX); @@ -162,18 +192,7 @@ static int ipa_cldap_encode_netlogon(char *fq_hostname, char *domain, nlr->pdc_dns_name = fq_hostname; nlr->domain_name = name; - /* copy the first 15 characters of the fully qualified hostname*/ - pdc_name = talloc_asprintf(nlr, "%.*s", NETBIOS_NAME_MAX, fq_hostname); - - for (p = pdc_name; *p; p++) { - /* Create the NetBIOS name from the first segment of the hostname */ - if (*p == '.') { - *p = '\0'; - break; - } - *p = toupper(*p); - } - nlr->pdc_name = pdc_name; + nlr->pdc_name = make_netbios_name(nlr, fq_hostname); nlr->user_name = ""; nlr->server_site = "Default-First-Site-Name"; nlr->client_site = "Default-First-Site-Name"; diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_tests.c b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_tests.c new file mode 100644 index 0000000000000000000000000000000000000000..8f579cb0c051551471a55273c4bce97717200ffd --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_tests.c @@ -0,0 +1,68 @@ +/* + Authors: + Sumit Bose + + Copyright (C) 2014 Red Hat + + Tests for FreeIPA CLDAP plugin + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . +*/ + +#include +#include +#include +#include + +#include "ipa_cldap.h" + +void test_make_netbios_name(void **state) +{ + char *r; + size_t c; + + struct test_data { + char *i; + char *o; + } d[] = { + {"abc", "ABC"}, + {"long-host-name-12345", "LONGHOSTNAME123"}, + {"abc.def.123", "ABC"}, + {"####", NULL}, + {NULL, NULL} + }; + + r = make_netbios_name(NULL, NULL); + assert_null(r); + + for (c = 0; d[c].i != NULL; c++) { + r = make_netbios_name(NULL, d[c].i); + if (d[c].o != NULL) { + assert_string_equal(r, d[c].o); + } else { + assert_null(r); + } + } +} + +int main(int argc, const char *argv[]) +{ + + const UnitTest tests[] = { + unit_test(test_make_netbios_name), + }; + + return run_tests(tests); +} + -- 1.8.1.4 From pviktori at redhat.com Thu Jan 23 12:54:58 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 23 Jan 2014 13:54:58 +0100 Subject: [Freeipa-devel] [PATCHES] 0453-0454 Test fixes Message-ID: <52E11122.3060401@redhat.com> Hello, RHEL 5 runs `clear` from /root/.bash_logout. The tests use a login session without an attached TTY. This makes `clear` complain about missing $TERM and fail the whole shell session. Rather than adding a special fix upstream, cleaning /root/.bash_logout will be a responsibility of whoever runs the tests. I've noted this on http://www.freeipa.org/page/Testing#Running_the_Tests. I'm of course willing to reconsider if any cutting-edge distros have problems. Patch 453 will make diagnosing situations like this easier. Related to: https://fedorahosted.org/freeipa/ticket/4109 Patch 454 changes the cert generation script for CA-less tests to use sequential serial numbers rather than random ones, to prevent collisions. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0453-test_integration-Run-true-before-any-other-commands.patch Type: text/x-patch Size: 1069 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0454-CA-less-tests-Use-sequential-certificate-serial-numb.patch Type: text/x-patch Size: 1431 bytes Desc: not available URL: From abokovoy at redhat.com Thu Jan 23 13:07:05 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 23 Jan 2014 15:07:05 +0200 Subject: [Freeipa-devel] [PATCH] 126 CLDAP: generate NetBIOS name like ipa-adtrust-install does In-Reply-To: <20140123125002.GB2648@localhost.localdomain> References: <20140123125002.GB2648@localhost.localdomain> Message-ID: <20140123130705.GH12003@redhat.com> On Thu, 23 Jan 2014, Sumit Bose wrote: >Hi, > >here is another one for the CLDAP NetBIOS name issue. ACK but could you please split the patch into two: - adding make_netbios_name() and using it - CMocka test for make_netbios_name() ? -- / Alexander Bokovoy From pviktori at redhat.com Thu Jan 23 13:17:47 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 23 Jan 2014 14:17:47 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52E01649.7060002@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> Message-ID: <52E1167B.9050605@redhat.com> On 01/22/2014 08:04 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 01/20/2014 05:21 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 01/17/2014 10:24 PM, Rob Crittenden wrote: >>>>> Implement an IPA RESTful Foreman-compatible smart proxy. This exposes >>>>> hosts and hostgroups via an unauthenticated REST API. The idea is that >>>>> this service runs on the Foreman server and only listens on local >>>>> ports. >>>>> >>>>> It is a CherryPy-based server and that handles the majority of REST >>>>> for us. >>>>> >>>>> I included some tests, they can be executed with: nosetests -v >>>>> smartproxy/tests >>>> >>>> Why is it not a part of ipatests? >>> >>> I can move it if it's a show-stopper. It seemed specific to this one >>> directory so I stuck it there. It isn't relevant for most testing and >>> requires some manual configuration (though CI could handle it). >> >> Not strictly a show stopper, but please move it. At the very least it >> should end up in the freeipa-tests package. > > Moved. Thanks! >> A lot of the tests (integration, webUI) need manual configuration, so >> this would be no exception. Of course the tests should be skipped if the >> configuration was not done, and the config instructions should be added >> to/linked from http://www.freeipa.org/page/Testing > > Hmm, maybe. There are instructions to set up the environment in the man > page. Testing beyond that consists of ./make-test tests/test_smartproxy > > I can add that testing bit once the patch is approved I suppose. > > rob Please add python-kerberos >= 1.1-13 to Requires and BuildRequires; pylint fails with lower versions. Are there plans to release python-kerberos-1.1-13.fc20, or will this be f21+ only? -- Petr? From jcholast at redhat.com Thu Jan 23 13:34:24 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 23 Jan 2014 14:34:24 +0100 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <1390405407.15404.58.camel@willson.li.ssimo.org> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> <52DF9201.6090806@redhat.com> <1390401263.15404.37.camel@willson.li.ssimo.org> <52DFDE4B.5090401@redhat.com> <1390405407.15404.58.camel@willson.li.ssimo.org> Message-ID: <52E11A60.10901@redhat.com> On 22.1.2014 16:43, Simo Sorce wrote: > On Wed, 2014-01-22 at 16:05 +0100, Jan Cholasta wrote: >> On 22.1.2014 15:34, Simo Sorce wrote: >>> On Wed, 2014-01-22 at 10:40 +0100, Jan Cholasta wrote: >>>> On 21.1.2014 17:12, Simo Sorce wrote: >>>>> Later in the patch you seem to be changing from needing managedby_host >>>>> to needing write access to an entry, I am not sure I understand why that >>>>> was changed. not saying it is necessarily wrong, but why the original >>>>> check is not right anymore ? >>>> >>>> The original check is wrong, see >>>> . >>>> >>>> The check in my patch allows SAN only if the requesting host has write >>>> access to all of the SAN services. I'm not entirely sure if this is >>>> right, but even if it is not, I think we should still check for write >>>> access to the SAN services, so that access control can be (partially) >>>> handled by ACIs. >>> >>> Right, I remembered that comment, but it just says to check the right >>> object's managed-by, here instead you changed it to check if you can >>> write the usercertificate. >>> >>> I guess it is the same *if* there is an ACI that gives write permission >>> when the host is in the managed-by attribute, is that the reasoning ? >> >> Exactly. The ACIs that allow this by default are named "Hosts can manage >> service Certificates and kerberos keys" and "Hosts can manage other host >> Certificates and kerberos keys". >> >> I think the check can be extended to users as well, so that requesting >> certificate with SAN is allowed only to users which have write access to >> the SAN services. I have done the modification, see attached patches. > > Sounds good to me then, thanks for explaining. > > The patches also look good, but I would like someone to give them a try > for a formal ack. OK, thanks. > > Simo. > -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-210.3-Allow-SAN-in-IPA-certificate-profile.patch Type: text/x-patch Size: 5005 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-234.3-Support-requests-with-SAN-in-cert-request.patch Type: text/x-patch Size: 7496 bytes Desc: not available URL: From simo at redhat.com Thu Jan 23 13:42:30 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 23 Jan 2014 08:42:30 -0500 Subject: [Freeipa-devel] [PATCHES] 0447-0449 Add support for managed permissions In-Reply-To: <52E109CA.2020605@redhat.com> References: <52CD738A.40105@redhat.com> <52DF8F0E.9020705@redhat.com> <52E0FBEC.2020303@redhat.com> <52E109CA.2020605@redhat.com> Message-ID: <1390484550.15404.79.camel@willson.li.ssimo.org> On Thu, 2014-01-23 at 13:23 +0100, Petr Viktorin wrote: > On 01/23/2014 12:24 PM, Martin Kosek wrote: > > On 01/22/2014 10:27 AM, Petr Viktorin wrote: > >> On 01/08/2014 04:49 PM, Petr Viktorin wrote: > >>> Hello, > >>> This adds "managed" permissions, the framework that will make our > >>> default permissions merge IPA updates and user changes sanely. > >>> > >>> There is no updater yet, nor does this add any actual managed > >>> permissions, so there's no user-visible change (beyond help text and a > >>> disabled option). To test the patch you might need to touch LDAP directly. > >>> > >>> Ticket: https://fedorahosted.org/freeipa/ticket/4033 > >>> Design (no updater & plugin changes yet): > >>> http://www.freeipa.org/page/V3/Managed_Read_permissions > >>> > >>> 0447 - Minor fixes. > >>> 0448 - Since you can't create managed permissions through the API, I > >>> needed to get creative with the declarative tests. The tests will need a > >>> custom function that adds a managed perm. > >>> 0449 - The change itself. > >> > >> ping; any thoughts on this one? > >> > >> > > > > 1) 449, the comment: > > > > +Deleting or renaming a managed permission, as well as changing its target, > > +is not supported. > > +""") + _(""" > > > > I am not sure that the phrase "not supported" is the right one. It sounds to me > > like this is something we want to allow, just not implemented yet. IMO "is not > > allowed" would be better. > > Makes sense. > > > 2) Can you add allow_mod_for_managed flag description to parameters.py? > > > > + flags={'no_create', 'allow_mod_for_managed'}, > > > > So far we try to add all flag descriptions there. > > OK > > > 3) When I updated the test to not delete the testperm, I tried to show the > > managed permission and it is not entirely clear, see: > > > > # ipa permission-show testperm > > Permission name: testperm > > Permissions: write > > * Attributes: cn, o, sn > > * Excluded attributes: cn, sn > > Bind rule type: all > > Subtree: cn=users,cn=accounts,dc=example,dc=com > > ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com > > Type: user > > * Default attributes: l, o, cn > > * Effective attributes: l, o > > Well, this is a tradeoff between presenting what's stored in LDAP and > what's in the ACI. > > > The "Attributes" mean actually attributes explicitly allowed by user, but it is > > not obvious from the output. > > > > Maybe it would be better to return only "Effective attributes" by default and > > return the 3 source lists only when --all is passed. But this would require us > > to let Command override LDAPObject's default_attributes, which framework cannot do. > > Modifying default_attributes would not work because the 3 lists need to > be loaded from LDAP to determine the effective attributes. > It's possible to remove the extra attributes in the post_callback, > postprocess_result already does similar output manipulation. > > > Alternatively, we may choose to use the attributes differently with managed > > permissions: > > - we add the new attributeType "ipaPermIncludedAttr". It would be used for the > > user-specified whitelist of attributes instead of ipaPermAllowedAttr > > - we do not use the ipaPermAllowedAttr with managed attributes at all or use it > > for the "Effective attributes" list > > > > My point is that the semantics of ipaPermAllowedAttr is different for managed > > and non-managed permission, so it may confuse people. > > Well, the semantics are always the same (effective = (default | allowed) > - excluded). I agree that it can be confusing; perhaps I'm in too deep > to judge how it looks from the outside. > > > For example, you may want > > to search for all permissions that allow attribute "sn": > > > > # ipa permission-find --attrs sn > > --------------------- > > 4 permissions matched > > --------------------- > > Permission name: anon > > Permissions: read > > Attributes: sn > > Bind rule type: anonymous > > Subtree: cn=users,cn=accounts,dc=example,dc=com > > ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com > > Type: user > > ... > > Permission name: testperm > > Permissions: write > > Attributes: cn, o, sn > > Excluded attributes: cn, sn > > Bind rule type: anonymous > > Subtree: cn=users,cn=accounts,dc=example,dc=com > > ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com > > Type: user > > Default attributes: l, o, cn > > Effective attributes: l, o > > ... > > > > As you see, it matched both testperm and anon even though testperm does not > > really allow sn as it excluded. > > > > Thoughts? > > Well, we could have default, included, excluded attributes stored in > LDAP as now (using the name "included" instead of "allowed"), and make > effective attributes (--attrs) into an updatable virtual attribute: when > setting it, IPA would consult the "default" attributes and update > "included"/"excluded" accordingly. (With non-managed permissions > "default" is empty, so only "included" would be updated.) And searching > on --attrs would construct an appropriate filter. > > I thought about this approach earlier but thought that it obscured > what's actually stored in LDAP. Given recent discussions I'm now > thinking I shouldn't have rejected it. I would take a consistent approach indeed. I do not much care for the virtual attribute part in LDAP, as long as our tool show prominently the effective list. And also as long as all permissions behave the same way in the general mechanism in LDAP. Simo. -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Thu Jan 23 14:09:03 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 23 Jan 2014 15:09:03 +0100 Subject: [Freeipa-devel] [PATCH] 126 CLDAP: generate NetBIOS name like ipa-adtrust-install does In-Reply-To: <20140123130705.GH12003@redhat.com> References: <20140123125002.GB2648@localhost.localdomain> <20140123130705.GH12003@redhat.com> Message-ID: <20140123140903.GC2648@localhost.localdomain> On Thu, Jan 23, 2014 at 03:07:05PM +0200, Alexander Bokovoy wrote: > On Thu, 23 Jan 2014, Sumit Bose wrote: > >Hi, > > > >here is another one for the CLDAP NetBIOS name issue. > > ACK but could you please split the patch into two: > - adding make_netbios_name() and using it > - CMocka test for make_netbios_name() > ? sure, new version attached. bye, Sumit > > -- > / Alexander Bokovoy -------------- next part -------------- From 6e2d4d3cfa77b3bd4ce08024b7251d51d6caed6c Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Thu, 23 Jan 2014 14:39:24 +0100 Subject: [PATCH 126/127] CLDAP: generate NetBIOS name like ipa-adtrust-install does Fixes https://fedorahosted.org/freeipa/ticket/4116 --- daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.h | 2 + .../ipa-cldap/ipa_cldap_netlogon.c | 47 +++++++++++++++------- 2 files changed, 35 insertions(+), 14 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.h b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.h index 3f420ff2c5acc7bd75bff7f042f76b9c61144461..5e963e3f8557d468d646e6343366921d17242e2d 100644 --- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.h +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.h @@ -51,6 +51,7 @@ #include #include #include +#include #include "util.h" #define IPA_CLDAP_PLUGIN_NAME "CLDAP Server" @@ -106,4 +107,5 @@ int ipa_cldap_netlogon(struct ipa_cldap_ctx *ctx, struct ipa_cldap_req *req, struct berval *reply); +char *make_netbios_name(TALLOC_CTX *mem_ctx, const char *s); #endif /* _IPA_CLDAP_H_ */ diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c index c03172d474589ddee84f1cfa5395c23fdba83bcb..1d16de7be09cf9675c2ee1a602ddfb800cd6e7af 100644 --- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c @@ -121,6 +121,38 @@ done: return ret; } +char *make_netbios_name(TALLOC_CTX *mem_ctx, const char *s) +{ + char *nb_name; + const char *p; + size_t c = 0; + + if (s == NULL) { + return NULL; + } + + nb_name = talloc_zero_size(mem_ctx, NETBIOS_NAME_MAX + 1); + if (nb_name == NULL) { + return NULL; + } + + for (p = s; *p && c < NETBIOS_NAME_MAX; p++) { + /* Create the NetBIOS name from the first segment of the hostname */ + if (*p == '.') { + break; + } else if (isalnum(*p)) { + nb_name[c++] = toupper(*p); + } + } + + if (*nb_name == '\0') { + talloc_free(nb_name); + return NULL; + } + + return nb_name; +} + #define NETLOGON_SAM_LOGON_RESPONSE_EX_pusher \ (ndr_push_flags_fn_t)ndr_push_NETLOGON_SAM_LOGON_RESPONSE_EX @@ -131,8 +163,6 @@ static int ipa_cldap_encode_netlogon(char *fq_hostname, char *domain, struct NETLOGON_SAM_LOGON_RESPONSE_EX *nlr; enum ndr_err_code ndr_err; DATA_BLOB blob; - char *pdc_name; - char *p; int ret; nlr = talloc_zero(NULL, struct NETLOGON_SAM_LOGON_RESPONSE_EX); @@ -162,18 +192,7 @@ static int ipa_cldap_encode_netlogon(char *fq_hostname, char *domain, nlr->pdc_dns_name = fq_hostname; nlr->domain_name = name; - /* copy the first 15 characters of the fully qualified hostname*/ - pdc_name = talloc_asprintf(nlr, "%.*s", NETBIOS_NAME_MAX, fq_hostname); - - for (p = pdc_name; *p; p++) { - /* Create the NetBIOS name from the first segment of the hostname */ - if (*p == '.') { - *p = '\0'; - break; - } - *p = toupper(*p); - } - nlr->pdc_name = pdc_name; + nlr->pdc_name = make_netbios_name(nlr, fq_hostname); nlr->user_name = ""; nlr->server_site = "Default-First-Site-Name"; nlr->client_site = "Default-First-Site-Name"; -- 1.8.1.4 -------------- next part -------------- From ab9d06b87f81187c6f6fcd3da941791f166d33fc Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Thu, 23 Jan 2014 14:44:08 +0100 Subject: [PATCH 127/127] CLDAP: add unit tests for make_netbios_name --- daemons/ipa-slapi-plugins/ipa-cldap/Makefile.am | 19 ++++++ .../ipa-slapi-plugins/ipa-cldap/ipa_cldap_tests.c | 68 ++++++++++++++++++++++ 2 files changed, 87 insertions(+) create mode 100644 daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_tests.c diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/Makefile.am b/daemons/ipa-slapi-plugins/ipa-cldap/Makefile.am index 70b08835e5629026c80c21c83e0c749a387b73a4..8e35cdbd4499582dd0e14562f05e4eda5bb3ec5b 100644 --- a/daemons/ipa-slapi-plugins/ipa-cldap/Makefile.am +++ b/daemons/ipa-slapi-plugins/ipa-cldap/Makefile.am @@ -35,6 +35,25 @@ libipa_cldap_la_LIBADD = \ $(NDRNBT_LIBS) \ $(NULL) +if HAVE_CMOCKA +TESTS = ipa_cldap_tests +check_PROGRAMS = ipa_cldap_tests +endif + +ipa_cldap_tests_SOURCES = \ + ipa_cldap_tests.c \ + ipa_cldap_netlogon.c \ + $(NULL) +ipa_cldap_tests_CFLAGS = $(CMOCKA_FLAGS) +ipa_cldap_tests_LDFLAGS = \ + -rpath $(shell pkg-config --libs-only-L dirsrv | sed -e 's/-L//') \ + $(NULL) +ipa_cldap_tests_LDADD = \ + $(CMOCKA_LIBS) \ + $(NDRNBT_LIBS) \ + $(DIRSRV_LIBS) \ + $(NULL) + appdir = $(IPA_DATA_DIR) app_DATA = \ ipa-cldap-conf.ldif \ diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_tests.c b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_tests.c new file mode 100644 index 0000000000000000000000000000000000000000..8f579cb0c051551471a55273c4bce97717200ffd --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_tests.c @@ -0,0 +1,68 @@ +/* + Authors: + Sumit Bose + + Copyright (C) 2014 Red Hat + + Tests for FreeIPA CLDAP plugin + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . +*/ + +#include +#include +#include +#include + +#include "ipa_cldap.h" + +void test_make_netbios_name(void **state) +{ + char *r; + size_t c; + + struct test_data { + char *i; + char *o; + } d[] = { + {"abc", "ABC"}, + {"long-host-name-12345", "LONGHOSTNAME123"}, + {"abc.def.123", "ABC"}, + {"####", NULL}, + {NULL, NULL} + }; + + r = make_netbios_name(NULL, NULL); + assert_null(r); + + for (c = 0; d[c].i != NULL; c++) { + r = make_netbios_name(NULL, d[c].i); + if (d[c].o != NULL) { + assert_string_equal(r, d[c].o); + } else { + assert_null(r); + } + } +} + +int main(int argc, const char *argv[]) +{ + + const UnitTest tests[] = { + unit_test(test_make_netbios_name), + }; + + return run_tests(tests); +} + -- 1.8.1.4 From npmccallum at redhat.com Thu Jan 23 14:41:00 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 23 Jan 2014 09:41:00 -0500 Subject: [Freeipa-devel] OTP Sync Client In-Reply-To: <52E0E0CF.8090300@redhat.com> References: <1390424357.1984.104.camel@localhost.localdomain> <52E03228.9020002@redhat.com> <1390424831.1984.106.camel@localhost.localdomain> <52E0E0CF.8090300@redhat.com> Message-ID: <1390488060.1984.110.camel@localhost.localdomain> On Thu, 2014-01-23 at 10:28 +0100, Petr Vobornik wrote: > On 22.1.2014 22:07, Nathaniel McCallum wrote: > > On Wed, 2014-01-22 at 16:03 -0500, Rob Crittenden wrote: > >> Nathaniel McCallum wrote: > >>> In attempting to write an OTP synchronization client, I've noticed it > >>> doesn't fit into the framework very well. The job of the client is to > >>> perform the synchronization extended operation. The format of the > >>> request is this: > >>> > >>> OTPSyncRequestValue ::= SEQUENCE { > >>> userDN OCTET STRING, > >>> tokenDN [0] OCTET STRING OPTIONAL, > >>> firstFactor [1] OCTET STRING OPTIONAL, > >>> firstCode INTEGER, > >>> secondCode INTEGER > >>> } > >>> > >>> In all cases, the user MUST provide two token codes and MAY provide the > >>> DN of a token to sync. > >>> > >>> >From here two cases exist: bound and unbound. > >>> > >>> In the unbound case, both the userDN and firstFactor fields are required > >>> and authentication is performed internally. > >>> > >>> In the bound case, the client has already bound (usually via a kerberos > >>> ticket). In this case, the client must provide userDN only. There are > >>> two options here. First, the client can generate the userDN > >>> automatically from the kerberos ticket metadata. Second, the extop > >>> plugin can make the userDN field optional and simply rely on the > >>> internal bind DN. This is my preferred route, and will require a new > >>> revision of the otp sync patch (no problem). In this second case, if the > >>> user is bound, the DS plugin would ignore the values of > >>> userDN/firstFactor. > >>> > >>> Assuming the second case to be true, how do I write a command in the > >>> framework that will attempt a krb5 bind and then prompt for > >>> username/password if the bind fails? Also, how do I, on the client side, > >>> without any bind to LDAP translate the username to the userDN? The same > >>> is true for the token ID to DN translation? Would it be better to write > >>> this code independently of the FreeIPA client command framework? > > Look at ipaserver.rpcserver.login_password class. IMO the code shares a > lot of similarities with your intentions. Thanks! > >> > >> You can override the forward() command in the plugin to do client-side > >> work. There are a few examples, see service_show and > >> automountlocation_import. I just wonder how this would work in the UI. > > > > > I believe the intention in the UI is to just handle the unbound case > > with no tokenDN option. It would essentially be a login screen that > > would look like this: > > Username: _______________ > > Password: _______________ > > First Token: _______________ > > Second Token: _______________ > > > > Nathaniel > > > > +1 It could be further extended to a simple "token portal" where one > could login via first factor and then list tokens and sync a selected > token. The only issue is that it's quite hard to achieve this without > binding(sending psw) in each request - IPA framework is not designed for > such task. The issue is getting a session. If we were able to get a > session we could use the method described below. > > > Second Web UI use case might be: > > When user is logged in - via other "working" token or different auth > method (i.e., password auth is enabled), he can: > - open OTP tokens page > - open some token details > - select 'sync' action > - enter OTP1, OTP2, confirm I'm not quite sure what the purpose of this is. Why do we have to bother the user with selecting which token to synchronize when we can easily do this algorithmicly? The user doesn't pick which token to use when logging in. I'm not sure why syncing should be any different. Nathaniel From jcholast at redhat.com Thu Jan 23 14:47:24 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 23 Jan 2014 15:47:24 +0100 Subject: [Freeipa-devel] [PATCH] 236 Log unhandled exceptions in certificate renewal scripts Message-ID: <52E12B7C.5020204@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-236-Log-unhandled-exceptions-in-certificate-renewal-scri.patch Type: text/x-patch Size: 24159 bytes Desc: not available URL: From npmccallum at redhat.com Thu Jan 23 15:03:51 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 23 Jan 2014 10:03:51 -0500 Subject: [Freeipa-devel] OTP Sync Client In-Reply-To: <1390424357.1984.104.camel@localhost.localdomain> References: <1390424357.1984.104.camel@localhost.localdomain> Message-ID: <1390489431.1984.112.camel@localhost.localdomain> On Wed, 2014-01-22 at 15:59 -0500, Nathaniel McCallum wrote: > In attempting to write an OTP synchronization client, I've noticed it > doesn't fit into the framework very well. The job of the client is to > perform the synchronization extended operation. The format of the > request is this: > > OTPSyncRequestValue ::= SEQUENCE { > userDN OCTET STRING, > tokenDN [0] OCTET STRING OPTIONAL, > firstFactor [1] OCTET STRING OPTIONAL, > firstCode INTEGER, > secondCode INTEGER > } > > In all cases, the user MUST provide two token codes and MAY provide the > DN of a token to sync. > > From here two cases exist: bound and unbound. > > In the unbound case, both the userDN and firstFactor fields are required > and authentication is performed internally. > > In the bound case, the client has already bound (usually via a kerberos > ticket). In this case, the client must provide userDN only. There are > two options here. First, the client can generate the userDN > automatically from the kerberos ticket metadata. Second, the extop > plugin can make the userDN field optional and simply rely on the > internal bind DN. This is my preferred route, and will require a new > revision of the otp sync patch (no problem). In this second case, if the > user is bound, the DS plugin would ignore the values of > userDN/firstFactor. > > Assuming the second case to be true, how do I write a command in the > framework that will attempt a krb5 bind and then prompt for > username/password if the bind fails? Also, how do I, on the client side, > without any bind to LDAP translate the username to the userDN? The same > is true for the token ID to DN translation? Would it be better to write > this code independently of the FreeIPA client command framework? > > Nathaniel Thanks for the responses so far! Does anyone have any suggestions on how to translate IDs to DNs? Should I just pass IDs to the directory server and do the translation internally? Thanks! Nathaniel From abokovoy at redhat.com Thu Jan 23 15:08:46 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 23 Jan 2014 17:08:46 +0200 Subject: [Freeipa-devel] [PATCH] 126 CLDAP: generate NetBIOS name like ipa-adtrust-install does In-Reply-To: <20140123140903.GC2648@localhost.localdomain> References: <20140123125002.GB2648@localhost.localdomain> <20140123130705.GH12003@redhat.com> <20140123140903.GC2648@localhost.localdomain> Message-ID: <20140123150846.GJ12003@redhat.com> On Thu, 23 Jan 2014, Sumit Bose wrote: >On Thu, Jan 23, 2014 at 03:07:05PM +0200, Alexander Bokovoy wrote: >> On Thu, 23 Jan 2014, Sumit Bose wrote: >> >Hi, >> > >> >here is another one for the CLDAP NetBIOS name issue. >> >> ACK but could you please split the patch into two: >> - adding make_netbios_name() and using it >> - CMocka test for make_netbios_name() >> ? > >sure, new version attached. ACK -- / Alexander Bokovoy From rcritten at redhat.com Thu Jan 23 15:19:27 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 23 Jan 2014 10:19:27 -0500 Subject: [Freeipa-devel] OTP Sync Client In-Reply-To: <1390489431.1984.112.camel@localhost.localdomain> References: <1390424357.1984.104.camel@localhost.localdomain> <1390489431.1984.112.camel@localhost.localdomain> Message-ID: <52E132FF.8020909@redhat.com> Nathaniel McCallum wrote: > On Wed, 2014-01-22 at 15:59 -0500, Nathaniel McCallum wrote: >> In attempting to write an OTP synchronization client, I've noticed it >> doesn't fit into the framework very well. The job of the client is to >> perform the synchronization extended operation. The format of the >> request is this: >> >> OTPSyncRequestValue ::= SEQUENCE { >> userDN OCTET STRING, >> tokenDN [0] OCTET STRING OPTIONAL, >> firstFactor [1] OCTET STRING OPTIONAL, >> firstCode INTEGER, >> secondCode INTEGER >> } >> >> In all cases, the user MUST provide two token codes and MAY provide the >> DN of a token to sync. >> >> From here two cases exist: bound and unbound. >> >> In the unbound case, both the userDN and firstFactor fields are required >> and authentication is performed internally. >> >> In the bound case, the client has already bound (usually via a kerberos >> ticket). In this case, the client must provide userDN only. There are >> two options here. First, the client can generate the userDN >> automatically from the kerberos ticket metadata. Second, the extop >> plugin can make the userDN field optional and simply rely on the >> internal bind DN. This is my preferred route, and will require a new >> revision of the otp sync patch (no problem). In this second case, if the >> user is bound, the DS plugin would ignore the values of >> userDN/firstFactor. >> >> Assuming the second case to be true, how do I write a command in the >> framework that will attempt a krb5 bind and then prompt for >> username/password if the bind fails? Also, how do I, on the client side, >> without any bind to LDAP translate the username to the userDN? The same >> is true for the token ID to DN translation? Would it be better to write >> this code independently of the FreeIPA client command framework? >> >> Nathaniel > > Thanks for the responses so far! > > Does anyone have any suggestions on how to translate IDs to DNs? Should > I just pass IDs to the directory server and do the translation > internally? Thanks! Each plugin defines a get_dn() method. I'm not sure I've ever called this on the client side though you probably need an LDAP connection for this to work. The call would look something like: api.Object['user'].get_dn('admin') rob From jcholast at redhat.com Thu Jan 23 15:27:03 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 23 Jan 2014 16:27:03 +0100 Subject: [Freeipa-devel] OTP Sync Client In-Reply-To: <52E132FF.8020909@redhat.com> References: <1390424357.1984.104.camel@localhost.localdomain> <1390489431.1984.112.camel@localhost.localdomain> <52E132FF.8020909@redhat.com> Message-ID: <52E134C7.4040700@redhat.com> Hi, On 23.1.2014 16:19, Rob Crittenden wrote: > Nathaniel McCallum wrote: >> On Wed, 2014-01-22 at 15:59 -0500, Nathaniel McCallum wrote: >>> In attempting to write an OTP synchronization client, I've noticed it >>> doesn't fit into the framework very well. The job of the client is to >>> perform the synchronization extended operation. The format of the >>> request is this: >>> >>> OTPSyncRequestValue ::= SEQUENCE { >>> userDN OCTET STRING, >>> tokenDN [0] OCTET STRING OPTIONAL, >>> firstFactor [1] OCTET STRING OPTIONAL, >>> firstCode INTEGER, >>> secondCode INTEGER >>> } >>> >>> In all cases, the user MUST provide two token codes and MAY provide the >>> DN of a token to sync. >>> >>> From here two cases exist: bound and unbound. >>> >>> In the unbound case, both the userDN and firstFactor fields are required >>> and authentication is performed internally. >>> >>> In the bound case, the client has already bound (usually via a kerberos >>> ticket). In this case, the client must provide userDN only. There are >>> two options here. First, the client can generate the userDN >>> automatically from the kerberos ticket metadata. Second, the extop >>> plugin can make the userDN field optional and simply rely on the >>> internal bind DN. This is my preferred route, and will require a new >>> revision of the otp sync patch (no problem). In this second case, if the >>> user is bound, the DS plugin would ignore the values of >>> userDN/firstFactor. >>> >>> Assuming the second case to be true, how do I write a command in the >>> framework that will attempt a krb5 bind and then prompt for >>> username/password if the bind fails? Also, how do I, on the client side, >>> without any bind to LDAP translate the username to the userDN? The same >>> is true for the token ID to DN translation? Would it be better to write >>> this code independently of the FreeIPA client command framework? >>> >>> Nathaniel >> >> Thanks for the responses so far! >> >> Does anyone have any suggestions on how to translate IDs to DNs? Should >> I just pass IDs to the directory server and do the translation >> internally? Thanks! > > Each plugin defines a get_dn() method. I'm not sure I've ever called > this on the client side though you probably need an LDAP connection for > this to work. > > The call would look something like: > > api.Object['user'].get_dn('admin') This returns "DN(('uid', 'admin'), api.env.container_user, api.env.basedn)" by default, you can use that if get_dn does not work for you. > > rob Honza -- Jan Cholasta From mkosek at redhat.com Thu Jan 23 17:17:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 23 Jan 2014 18:17:08 +0100 Subject: [Freeipa-devel] [PATCH] 126 CLDAP: generate NetBIOS name like ipa-adtrust-install does In-Reply-To: <20140123150846.GJ12003@redhat.com> References: <20140123125002.GB2648@localhost.localdomain> <20140123130705.GH12003@redhat.com> <20140123140903.GC2648@localhost.localdomain> <20140123150846.GJ12003@redhat.com> Message-ID: <52E14E94.6020603@redhat.com> On 01/23/2014 04:08 PM, Alexander Bokovoy wrote: > On Thu, 23 Jan 2014, Sumit Bose wrote: >> On Thu, Jan 23, 2014 at 03:07:05PM +0200, Alexander Bokovoy wrote: >>> On Thu, 23 Jan 2014, Sumit Bose wrote: >>> >Hi, >>> > >>> >here is another one for the CLDAP NetBIOS name issue. >>> >>> ACK but could you please split the patch into two: >>> - adding make_netbios_name() and using it >>> - CMocka test for make_netbios_name() >>> ? >> >> sure, new version attached. > > ACK > Pushed to master, ipa-3-3. Martin From npmccallum at redhat.com Thu Jan 23 18:33:18 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 23 Jan 2014 13:33:18 -0500 Subject: [Freeipa-devel] OTP Sync Client In-Reply-To: <52E134C7.4040700@redhat.com> References: <1390424357.1984.104.camel@localhost.localdomain> <1390489431.1984.112.camel@localhost.localdomain> <52E132FF.8020909@redhat.com> <52E134C7.4040700@redhat.com> Message-ID: <1390501998.1984.120.camel@localhost.localdomain> On Thu, 2014-01-23 at 16:27 +0100, Jan Cholasta wrote: > Hi, > > On 23.1.2014 16:19, Rob Crittenden wrote: > > Nathaniel McCallum wrote: > >> On Wed, 2014-01-22 at 15:59 -0500, Nathaniel McCallum wrote: > >>> In attempting to write an OTP synchronization client, I've noticed it > >>> doesn't fit into the framework very well. The job of the client is to > >>> perform the synchronization extended operation. The format of the > >>> request is this: > >>> > >>> OTPSyncRequestValue ::= SEQUENCE { > >>> userDN OCTET STRING, > >>> tokenDN [0] OCTET STRING OPTIONAL, > >>> firstFactor [1] OCTET STRING OPTIONAL, > >>> firstCode INTEGER, > >>> secondCode INTEGER > >>> } > >>> > >>> In all cases, the user MUST provide two token codes and MAY provide the > >>> DN of a token to sync. > >>> > >>> From here two cases exist: bound and unbound. > >>> > >>> In the unbound case, both the userDN and firstFactor fields are required > >>> and authentication is performed internally. > >>> > >>> In the bound case, the client has already bound (usually via a kerberos > >>> ticket). In this case, the client must provide userDN only. There are > >>> two options here. First, the client can generate the userDN > >>> automatically from the kerberos ticket metadata. Second, the extop > >>> plugin can make the userDN field optional and simply rely on the > >>> internal bind DN. This is my preferred route, and will require a new > >>> revision of the otp sync patch (no problem). In this second case, if the > >>> user is bound, the DS plugin would ignore the values of > >>> userDN/firstFactor. > >>> > >>> Assuming the second case to be true, how do I write a command in the > >>> framework that will attempt a krb5 bind and then prompt for > >>> username/password if the bind fails? Also, how do I, on the client side, > >>> without any bind to LDAP translate the username to the userDN? The same > >>> is true for the token ID to DN translation? Would it be better to write > >>> this code independently of the FreeIPA client command framework? > >>> > >>> Nathaniel > >> > >> Thanks for the responses so far! > >> > >> Does anyone have any suggestions on how to translate IDs to DNs? Should > >> I just pass IDs to the directory server and do the translation > >> internally? Thanks! > > > > Each plugin defines a get_dn() method. I'm not sure I've ever called > > this on the client side though you probably need an LDAP connection for > > this to work. > > > > The call would look something like: > > > > api.Object['user'].get_dn('admin') > > This returns "DN(('uid', 'admin'), api.env.container_user, > api.env.basedn)" by default, you can use that if get_dn does not work > for you. The problem is that we only need to convert the ID to DN when we *don't* have a connection to LDAP. Thoughts? Nathaniel From pviktori at redhat.com Thu Jan 23 19:00:20 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 23 Jan 2014 20:00:20 +0100 Subject: [Freeipa-devel] OTP Sync Client In-Reply-To: <1390501998.1984.120.camel@localhost.localdomain> References: <1390424357.1984.104.camel@localhost.localdomain> <1390489431.1984.112.camel@localhost.localdomain> <52E132FF.8020909@redhat.com> <52E134C7.4040700@redhat.com> <1390501998.1984.120.camel@localhost.localdomain> Message-ID: <52E166C4.7040809@redhat.com> On 01/23/2014 07:33 PM, Nathaniel McCallum wrote: > On Thu, 2014-01-23 at 16:27 +0100, Jan Cholasta wrote: >> Hi, >> >> On 23.1.2014 16:19, Rob Crittenden wrote: >>> Nathaniel McCallum wrote: >>>> On Wed, 2014-01-22 at 15:59 -0500, Nathaniel McCallum wrote: >>>>> In attempting to write an OTP synchronization client, I've noticed it >>>>> doesn't fit into the framework very well. The job of the client is to >>>>> perform the synchronization extended operation. The format of the >>>>> request is this: >>>>> >>>>> OTPSyncRequestValue ::= SEQUENCE { >>>>> userDN OCTET STRING, >>>>> tokenDN [0] OCTET STRING OPTIONAL, >>>>> firstFactor [1] OCTET STRING OPTIONAL, >>>>> firstCode INTEGER, >>>>> secondCode INTEGER >>>>> } >>>>> >>>>> In all cases, the user MUST provide two token codes and MAY provide the >>>>> DN of a token to sync. >>>>> >>>>> From here two cases exist: bound and unbound. >>>>> >>>>> In the unbound case, both the userDN and firstFactor fields are required >>>>> and authentication is performed internally. >>>>> >>>>> In the bound case, the client has already bound (usually via a kerberos >>>>> ticket). In this case, the client must provide userDN only. There are >>>>> two options here. First, the client can generate the userDN >>>>> automatically from the kerberos ticket metadata. Second, the extop >>>>> plugin can make the userDN field optional and simply rely on the >>>>> internal bind DN. This is my preferred route, and will require a new >>>>> revision of the otp sync patch (no problem). In this second case, if the >>>>> user is bound, the DS plugin would ignore the values of >>>>> userDN/firstFactor. >>>>> >>>>> Assuming the second case to be true, how do I write a command in the >>>>> framework that will attempt a krb5 bind and then prompt for >>>>> username/password if the bind fails? Also, how do I, on the client side, >>>>> without any bind to LDAP translate the username to the userDN? The same >>>>> is true for the token ID to DN translation? Would it be better to write >>>>> this code independently of the FreeIPA client command framework? >>>>> >>>>> Nathaniel >>>> >>>> Thanks for the responses so far! >>>> >>>> Does anyone have any suggestions on how to translate IDs to DNs? Should >>>> I just pass IDs to the directory server and do the translation >>>> internally? Thanks! >>> >>> Each plugin defines a get_dn() method. I'm not sure I've ever called >>> this on the client side though you probably need an LDAP connection for >>> this to work. >>> >>> The call would look something like: >>> >>> api.Object['user'].get_dn('admin') >> >> This returns "DN(('uid', 'admin'), api.env.container_user, >> api.env.basedn)" by default, you can use that if get_dn does not work >> for you. > > The problem is that we only need to convert the ID to DN when we *don't* > have a connection to LDAP. Thoughts? > > Nathaniel What Honza meant is that get_dn is preferable if you could use it, but since you can't, you can just use: DN(('ipatokenuniqueid', $TOKENID), api.env.container_otp, api.env.basedn) This works since ipatokenuniqueid is the attribute used in the RDN (it has primary_key=True, and the otptoken object has rdn_is_primary_key=True). -- Petr? From rcritten at redhat.com Thu Jan 23 19:10:10 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 23 Jan 2014 14:10:10 -0500 Subject: [Freeipa-devel] OTP Sync Client In-Reply-To: <1390501998.1984.120.camel@localhost.localdomain> References: <1390424357.1984.104.camel@localhost.localdomain> <1390489431.1984.112.camel@localhost.localdomain> <52E132FF.8020909@redhat.com> <52E134C7.4040700@redhat.com> <1390501998.1984.120.camel@localhost.localdomain> Message-ID: <52E16912.4050806@redhat.com> Nathaniel McCallum wrote: > On Thu, 2014-01-23 at 16:27 +0100, Jan Cholasta wrote: >> Hi, >> >> On 23.1.2014 16:19, Rob Crittenden wrote: >>> Nathaniel McCallum wrote: >>>> On Wed, 2014-01-22 at 15:59 -0500, Nathaniel McCallum wrote: >>>>> In attempting to write an OTP synchronization client, I've noticed it >>>>> doesn't fit into the framework very well. The job of the client is to >>>>> perform the synchronization extended operation. The format of the >>>>> request is this: >>>>> >>>>> OTPSyncRequestValue ::= SEQUENCE { >>>>> userDN OCTET STRING, >>>>> tokenDN [0] OCTET STRING OPTIONAL, >>>>> firstFactor [1] OCTET STRING OPTIONAL, >>>>> firstCode INTEGER, >>>>> secondCode INTEGER >>>>> } >>>>> >>>>> In all cases, the user MUST provide two token codes and MAY provide the >>>>> DN of a token to sync. >>>>> >>>>> From here two cases exist: bound and unbound. >>>>> >>>>> In the unbound case, both the userDN and firstFactor fields are required >>>>> and authentication is performed internally. >>>>> >>>>> In the bound case, the client has already bound (usually via a kerberos >>>>> ticket). In this case, the client must provide userDN only. There are >>>>> two options here. First, the client can generate the userDN >>>>> automatically from the kerberos ticket metadata. Second, the extop >>>>> plugin can make the userDN field optional and simply rely on the >>>>> internal bind DN. This is my preferred route, and will require a new >>>>> revision of the otp sync patch (no problem). In this second case, if the >>>>> user is bound, the DS plugin would ignore the values of >>>>> userDN/firstFactor. >>>>> >>>>> Assuming the second case to be true, how do I write a command in the >>>>> framework that will attempt a krb5 bind and then prompt for >>>>> username/password if the bind fails? Also, how do I, on the client side, >>>>> without any bind to LDAP translate the username to the userDN? The same >>>>> is true for the token ID to DN translation? Would it be better to write >>>>> this code independently of the FreeIPA client command framework? >>>>> >>>>> Nathaniel >>>> >>>> Thanks for the responses so far! >>>> >>>> Does anyone have any suggestions on how to translate IDs to DNs? Should >>>> I just pass IDs to the directory server and do the translation >>>> internally? Thanks! >>> >>> Each plugin defines a get_dn() method. I'm not sure I've ever called >>> this on the client side though you probably need an LDAP connection for >>> this to work. >>> >>> The call would look something like: >>> >>> api.Object['user'].get_dn('admin') >> >> This returns "DN(('uid', 'admin'), api.env.container_user, >> api.env.basedn)" by default, you can use that if get_dn does not work >> for you. > > The problem is that we only need to convert the ID to DN when we *don't* > have a connection to LDAP. Thoughts? You'd have to do it Honza's way which is a little less than ideal only in that it decentralizes DN creation, but we do that elsewhere so you wouldn't be plowing any new ground. rob From simo at redhat.com Thu Jan 23 19:23:25 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 23 Jan 2014 14:23:25 -0500 Subject: [Freeipa-devel] [PATCH 0030] Add OTP sync plugin In-Reply-To: <1389302896.1962.6.camel@localhost.localdomain> References: <1389302896.1962.6.camel@localhost.localdomain> Message-ID: <1390505005.15404.118.camel@willson.li.ssimo.org> On Thu, 2014-01-09 at 16:28 -0500, Nathaniel McCallum wrote: > This plugin adds an extended operation for synchronizing tokens. This > operation is availalbe both with and without bind. In the latter case, > the first factor is required. This operation can also be performed > on a per-token or per-user level. In the latter case, we will attempt > to find the token automatically. > > Thanks to Mark Reynolds for helping me with this patch. Huge NACK, otp_sync_request_authenticate() is not ok, it allows an attacker to do password bruteforcing without any check. This is the result of trying to re-implement what is basically a bind but w/o using the ind code. No checks to see if the user is enabled/disabled/locked No updates for locking account after N wrong tries, etc... It also duplicates the places to change should we wish to not depend on having userPassword as an actual password field anymore (which I considered multiple times as we already have kerberos keys against which we could test binds in theory). You should either extend the bind operation so all checks are used there and re-sync is done at last if all checks pass, and as a bonus you end up with an authenticated LDAP connection should you need it, or the bind code that does all the checks need to be abstracted into helper functions that can be reused by this plugin. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Thu Jan 23 19:41:09 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 23 Jan 2014 14:41:09 -0500 Subject: [Freeipa-devel] [PATCH 0030] Add OTP sync plugin In-Reply-To: <1390505005.15404.118.camel@willson.li.ssimo.org> References: <1389302896.1962.6.camel@localhost.localdomain> <1390505005.15404.118.camel@willson.li.ssimo.org> Message-ID: <1390506069.1984.124.camel@localhost.localdomain> On Thu, 2014-01-23 at 14:23 -0500, Simo Sorce wrote: > On Thu, 2014-01-09 at 16:28 -0500, Nathaniel McCallum wrote: > > This plugin adds an extended operation for synchronizing tokens. This > > operation is availalbe both with and without bind. In the latter case, > > the first factor is required. This operation can also be performed > > on a per-token or per-user level. In the latter case, we will attempt > > to find the token automatically. > > > > Thanks to Mark Reynolds for helping me with this patch. > > > Huge NACK, > > otp_sync_request_authenticate() is not ok, it allows an attacker to do > password bruteforcing without any check. > > This is the result of trying to re-implement what is basically a bind > but w/o using the ind code. > > No checks to see if the user is enabled/disabled/locked > No updates for locking account after N wrong tries, etc... > > It also duplicates the places to change should we wish to not depend on > having userPassword as an actual password field anymore (which I > considered multiple times as we already have kerberos keys against which > we could test binds in theory). > > You should either extend the bind operation so all checks are used there > and re-sync is done at last if all checks pass, and as a bonus you end > up with an authenticated LDAP connection should you need it, or the bind > code that does all the checks need to be abstracted into helper > functions that can be reused by this plugin. > > Simo. Is it possible to do a post-bind extop which rejects the bind? Because if synchronization fails, we MUST reject the authentication even if the first factor was validated correctly. Also, is it possible to add extended data to a bind operation? Because if not, this is going to get hairy fast. Nathaniel From abokovoy at redhat.com Thu Jan 23 20:12:51 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 23 Jan 2014 22:12:51 +0200 Subject: [Freeipa-devel] [PATCH 0030] Add OTP sync plugin In-Reply-To: <1390506069.1984.124.camel@localhost.localdomain> References: <1389302896.1962.6.camel@localhost.localdomain> <1390505005.15404.118.camel@willson.li.ssimo.org> <1390506069.1984.124.camel@localhost.localdomain> Message-ID: <20140123201251.GO12003@redhat.com> On Thu, 23 Jan 2014, Nathaniel McCallum wrote: >On Thu, 2014-01-23 at 14:23 -0500, Simo Sorce wrote: >> On Thu, 2014-01-09 at 16:28 -0500, Nathaniel McCallum wrote: >> > This plugin adds an extended operation for synchronizing tokens. This >> > operation is availalbe both with and without bind. In the latter case, >> > the first factor is required. This operation can also be performed >> > on a per-token or per-user level. In the latter case, we will attempt >> > to find the token automatically. >> > >> > Thanks to Mark Reynolds for helping me with this patch. >> >> >> Huge NACK, >> >> otp_sync_request_authenticate() is not ok, it allows an attacker to do >> password bruteforcing without any check. >> >> This is the result of trying to re-implement what is basically a bind >> but w/o using the ind code. >> >> No checks to see if the user is enabled/disabled/locked >> No updates for locking account after N wrong tries, etc... >> >> It also duplicates the places to change should we wish to not depend on >> having userPassword as an actual password field anymore (which I >> considered multiple times as we already have kerberos keys against which >> we could test binds in theory). >> >> You should either extend the bind operation so all checks are used there >> and re-sync is done at last if all checks pass, and as a bonus you end >> up with an authenticated LDAP connection should you need it, or the bind >> code that does all the checks need to be abstracted into helper >> functions that can be reused by this plugin. >> >> Simo. > >Is it possible to do a post-bind extop which rejects the bind? Because >if synchronization fails, we MUST reject the authentication even if the >first factor was validated correctly. Also, is it possible to add >extended data to a bind operation? Because if not, this is going to get >hairy fast. Extended data on the server side? You can set what you want in PB in pre-bind and pick it up in post-bind. However, the question is about successful binds -- when SIMPLE bind is successful DS code will send response to the client and will call post plugins. The response is sent unconditionally. May be we could add a condition that if a certain flag is set in PB after pre-bind plugins ran successfully, response is not sent and post-bind plugins then run. A post-bind plugin then is required to send out proper result. -- / Alexander Bokovoy From npmccallum at redhat.com Thu Jan 23 20:46:16 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 23 Jan 2014 15:46:16 -0500 Subject: [Freeipa-devel] [PATCH 0030] Add OTP sync plugin In-Reply-To: <20140123201251.GO12003@redhat.com> References: <1389302896.1962.6.camel@localhost.localdomain> <1390505005.15404.118.camel@willson.li.ssimo.org> <1390506069.1984.124.camel@localhost.localdomain> <20140123201251.GO12003@redhat.com> Message-ID: <1390509976.1984.134.camel@localhost.localdomain> On Thu, 2014-01-23 at 22:12 +0200, Alexander Bokovoy wrote: > On Thu, 23 Jan 2014, Nathaniel McCallum wrote: > >On Thu, 2014-01-23 at 14:23 -0500, Simo Sorce wrote: > >> On Thu, 2014-01-09 at 16:28 -0500, Nathaniel McCallum wrote: > >> > This plugin adds an extended operation for synchronizing tokens. This > >> > operation is availalbe both with and without bind. In the latter case, > >> > the first factor is required. This operation can also be performed > >> > on a per-token or per-user level. In the latter case, we will attempt > >> > to find the token automatically. > >> > > >> > Thanks to Mark Reynolds for helping me with this patch. > >> > >> > >> Huge NACK, > >> > >> otp_sync_request_authenticate() is not ok, it allows an attacker to do > >> password bruteforcing without any check. > >> > >> This is the result of trying to re-implement what is basically a bind > >> but w/o using the ind code. > >> > >> No checks to see if the user is enabled/disabled/locked > >> No updates for locking account after N wrong tries, etc... > >> > >> It also duplicates the places to change should we wish to not depend on > >> having userPassword as an actual password field anymore (which I > >> considered multiple times as we already have kerberos keys against which > >> we could test binds in theory). > >> > >> You should either extend the bind operation so all checks are used there > >> and re-sync is done at last if all checks pass, and as a bonus you end > >> up with an authenticated LDAP connection should you need it, or the bind > >> code that does all the checks need to be abstracted into helper > >> functions that can be reused by this plugin. > >> > >> Simo. > > > >Is it possible to do a post-bind extop which rejects the bind? Because > >if synchronization fails, we MUST reject the authentication even if the > >first factor was validated correctly. Also, is it possible to add > >extended data to a bind operation? Because if not, this is going to get > >hairy fast. > Extended data on the server side? You can set what you want in PB in > pre-bind and pick it up in post-bind. > > However, the question is about successful binds -- when SIMPLE bind is > successful DS code will send response to the client and will call post > plugins. The response is sent unconditionally. > > May be we could add a condition that if a certain flag is set in PB > after pre-bind plugins ran successfully, response is not sent and > post-bind plugins then run. A post-bind plugin then is required to > send out proper result. No, extended data from the client side. The client needs to somehow communicate to the server: 1. that it wants the server to resynchronize 2. two tokens codes in a row Ideally we need some sort of additional metadata in the bind request. Without this, doing all the tests are pretty much impossible. We could refactor the code in ipa-pwd-extop into a library, but ipa-pwd-extop doesn't contain all the tests. Some of them are built into 389ds. The ipa-pwd-extop plugin just performs additional work and then falls through to 389ds. What we need to do is this: bool bind_preop() { if (otp_configured() && !is_sync_request()) if (!validate_otp()) return false; // ... fall through to password validation ... } bool bind_postop() { return bind_successful() && (!is_sync_request() || perform_synchronization()); } At the least, however, we need extra metadata for is_sync_request(). So the question is: is it possible to get some extra metadata in a bind request? Nathaniel From npmccallum at redhat.com Thu Jan 23 20:57:00 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 23 Jan 2014 15:57:00 -0500 Subject: [Freeipa-devel] [PATCH 0030] Add OTP sync plugin In-Reply-To: <1390509976.1984.134.camel@localhost.localdomain> References: <1389302896.1962.6.camel@localhost.localdomain> <1390505005.15404.118.camel@willson.li.ssimo.org> <1390506069.1984.124.camel@localhost.localdomain> <20140123201251.GO12003@redhat.com> <1390509976.1984.134.camel@localhost.localdomain> Message-ID: <1390510620.1984.135.camel@localhost.localdomain> On Thu, 2014-01-23 at 15:46 -0500, Nathaniel McCallum wrote: > On Thu, 2014-01-23 at 22:12 +0200, Alexander Bokovoy wrote: > > On Thu, 23 Jan 2014, Nathaniel McCallum wrote: > > >On Thu, 2014-01-23 at 14:23 -0500, Simo Sorce wrote: > > >> On Thu, 2014-01-09 at 16:28 -0500, Nathaniel McCallum wrote: > > >> > This plugin adds an extended operation for synchronizing tokens. This > > >> > operation is availalbe both with and without bind. In the latter case, > > >> > the first factor is required. This operation can also be performed > > >> > on a per-token or per-user level. In the latter case, we will attempt > > >> > to find the token automatically. > > >> > > > >> > Thanks to Mark Reynolds for helping me with this patch. > > >> > > >> > > >> Huge NACK, > > >> > > >> otp_sync_request_authenticate() is not ok, it allows an attacker to do > > >> password bruteforcing without any check. > > >> > > >> This is the result of trying to re-implement what is basically a bind > > >> but w/o using the ind code. > > >> > > >> No checks to see if the user is enabled/disabled/locked > > >> No updates for locking account after N wrong tries, etc... > > >> > > >> It also duplicates the places to change should we wish to not depend on > > >> having userPassword as an actual password field anymore (which I > > >> considered multiple times as we already have kerberos keys against which > > >> we could test binds in theory). > > >> > > >> You should either extend the bind operation so all checks are used there > > >> and re-sync is done at last if all checks pass, and as a bonus you end > > >> up with an authenticated LDAP connection should you need it, or the bind > > >> code that does all the checks need to be abstracted into helper > > >> functions that can be reused by this plugin. > > >> > > >> Simo. > > > > > >Is it possible to do a post-bind extop which rejects the bind? Because > > >if synchronization fails, we MUST reject the authentication even if the > > >first factor was validated correctly. Also, is it possible to add > > >extended data to a bind operation? Because if not, this is going to get > > >hairy fast. > > Extended data on the server side? You can set what you want in PB in > > pre-bind and pick it up in post-bind. > > > > However, the question is about successful binds -- when SIMPLE bind is > > successful DS code will send response to the client and will call post > > plugins. The response is sent unconditionally. > > > > May be we could add a condition that if a certain flag is set in PB > > after pre-bind plugins ran successfully, response is not sent and > > post-bind plugins then run. A post-bind plugin then is required to > > send out proper result. > > No, extended data from the client side. The client needs to somehow > communicate to the server: > 1. that it wants the server to resynchronize > 2. two tokens codes in a row > > Ideally we need some sort of additional metadata in the bind request. > Without this, doing all the tests are pretty much impossible. We could > refactor the code in ipa-pwd-extop into a library, but ipa-pwd-extop > doesn't contain all the tests. Some of them are built into 389ds. The > ipa-pwd-extop plugin just performs additional work and then falls > through to 389ds. > > What we need to do is this: > > bool bind_preop() { > if (otp_configured() && !is_sync_request()) > if (!validate_otp()) > return false; > > // ... fall through to password validation ... > } > > bool bind_postop() { > return bind_successful() > && (!is_sync_request() > || perform_synchronization()); > } > > At the least, however, we need extra metadata for is_sync_request(). > > So the question is: is it possible to get some extra metadata in a bind > request? So from my initial reading it appears we can just embed the sync request in a control, is that correct? Nathaniel From abokovoy at redhat.com Thu Jan 23 20:59:12 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 23 Jan 2014 22:59:12 +0200 Subject: [Freeipa-devel] [PATCH 0030] Add OTP sync plugin In-Reply-To: <1390509976.1984.134.camel@localhost.localdomain> References: <1389302896.1962.6.camel@localhost.localdomain> <1390505005.15404.118.camel@willson.li.ssimo.org> <1390506069.1984.124.camel@localhost.localdomain> <20140123201251.GO12003@redhat.com> <1390509976.1984.134.camel@localhost.localdomain> Message-ID: <20140123205912.GQ12003@redhat.com> On Thu, 23 Jan 2014, Nathaniel McCallum wrote: >On Thu, 2014-01-23 at 22:12 +0200, Alexander Bokovoy wrote: >> On Thu, 23 Jan 2014, Nathaniel McCallum wrote: >> >On Thu, 2014-01-23 at 14:23 -0500, Simo Sorce wrote: >> >> On Thu, 2014-01-09 at 16:28 -0500, Nathaniel McCallum wrote: >> >> > This plugin adds an extended operation for synchronizing tokens. This >> >> > operation is availalbe both with and without bind. In the latter case, >> >> > the first factor is required. This operation can also be performed >> >> > on a per-token or per-user level. In the latter case, we will attempt >> >> > to find the token automatically. >> >> > >> >> > Thanks to Mark Reynolds for helping me with this patch. >> >> >> >> >> >> Huge NACK, >> >> >> >> otp_sync_request_authenticate() is not ok, it allows an attacker to do >> >> password bruteforcing without any check. >> >> >> >> This is the result of trying to re-implement what is basically a bind >> >> but w/o using the ind code. >> >> >> >> No checks to see if the user is enabled/disabled/locked >> >> No updates for locking account after N wrong tries, etc... >> >> >> >> It also duplicates the places to change should we wish to not depend on >> >> having userPassword as an actual password field anymore (which I >> >> considered multiple times as we already have kerberos keys against which >> >> we could test binds in theory). >> >> >> >> You should either extend the bind operation so all checks are used there >> >> and re-sync is done at last if all checks pass, and as a bonus you end >> >> up with an authenticated LDAP connection should you need it, or the bind >> >> code that does all the checks need to be abstracted into helper >> >> functions that can be reused by this plugin. >> >> >> >> Simo. >> > >> >Is it possible to do a post-bind extop which rejects the bind? Because >> >if synchronization fails, we MUST reject the authentication even if the >> >first factor was validated correctly. Also, is it possible to add >> >extended data to a bind operation? Because if not, this is going to get >> >hairy fast. >> Extended data on the server side? You can set what you want in PB in >> pre-bind and pick it up in post-bind. >> >> However, the question is about successful binds -- when SIMPLE bind is >> successful DS code will send response to the client and will call post >> plugins. The response is sent unconditionally. >> >> May be we could add a condition that if a certain flag is set in PB >> after pre-bind plugins ran successfully, response is not sent and >> post-bind plugins then run. A post-bind plugin then is required to >> send out proper result. > >No, extended data from the client side. The client needs to somehow >communicate to the server: >1. that it wants the server to resynchronize >2. two tokens codes in a row BIND operation is BindRequest ::= SEQUENCE { version INTEGER, -- version name DistinguishedName, -- dn authentication CHOICE { simple [0] OCTET STRING, -- passwd krbv42ldap [1] OCTET STRING, -- not used krbv42dsa [2] OCTET STRING, -- not used sasl [3] SaslCredentials -- v3 only } } And there could be messge controls attached. So, we have a choice of - embedding this information into passwd in LDAP_AUTH_SIMPLE and then announcing a special password scheme plugin that would split the password and sync codes. - embedding it in SASL mech name - attaching a control I'd suggest using a control, pretty much like we already do with extop/extdom. Checking the control is more or less trivial. >Ideally we need some sort of additional metadata in the bind request. >Without this, doing all the tests are pretty much impossible. We could >refactor the code in ipa-pwd-extop into a library, but ipa-pwd-extop >doesn't contain all the tests. Some of them are built into 389ds. The >ipa-pwd-extop plugin just performs additional work and then falls >through to 389ds. > >What we need to do is this: > >bool bind_preop() { > if (otp_configured() && !is_sync_request()) > if (!validate_otp()) > return false; > > // ... fall through to password validation ... >} > >bool bind_postop() { > return bind_successful() > && (!is_sync_request() > || perform_synchronization()); >} > >At the least, however, we need extra metadata for is_sync_request(). > >So the question is: is it possible to get some extra metadata in a bind >request? Yes, in LDAPv3 which is what we are supporting here anyway. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jan 23 21:17:44 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 23 Jan 2014 23:17:44 +0200 Subject: [Freeipa-devel] [PATCH 0030] Add OTP sync plugin In-Reply-To: <1390510620.1984.135.camel@localhost.localdomain> References: <1389302896.1962.6.camel@localhost.localdomain> <1390505005.15404.118.camel@willson.li.ssimo.org> <1390506069.1984.124.camel@localhost.localdomain> <20140123201251.GO12003@redhat.com> <1390509976.1984.134.camel@localhost.localdomain> <1390510620.1984.135.camel@localhost.localdomain> Message-ID: <20140123211744.GR12003@redhat.com> On Thu, 23 Jan 2014, Nathaniel McCallum wrote: >On Thu, 2014-01-23 at 15:46 -0500, Nathaniel McCallum wrote: >> On Thu, 2014-01-23 at 22:12 +0200, Alexander Bokovoy wrote: >> > On Thu, 23 Jan 2014, Nathaniel McCallum wrote: >> > >On Thu, 2014-01-23 at 14:23 -0500, Simo Sorce wrote: >> > >> On Thu, 2014-01-09 at 16:28 -0500, Nathaniel McCallum wrote: >> > >> > This plugin adds an extended operation for synchronizing tokens. This >> > >> > operation is availalbe both with and without bind. In the latter case, >> > >> > the first factor is required. This operation can also be performed >> > >> > on a per-token or per-user level. In the latter case, we will attempt >> > >> > to find the token automatically. >> > >> > >> > >> > Thanks to Mark Reynolds for helping me with this patch. >> > >> >> > >> >> > >> Huge NACK, >> > >> >> > >> otp_sync_request_authenticate() is not ok, it allows an attacker to do >> > >> password bruteforcing without any check. >> > >> >> > >> This is the result of trying to re-implement what is basically a bind >> > >> but w/o using the ind code. >> > >> >> > >> No checks to see if the user is enabled/disabled/locked >> > >> No updates for locking account after N wrong tries, etc... >> > >> >> > >> It also duplicates the places to change should we wish to not depend on >> > >> having userPassword as an actual password field anymore (which I >> > >> considered multiple times as we already have kerberos keys against which >> > >> we could test binds in theory). >> > >> >> > >> You should either extend the bind operation so all checks are used there >> > >> and re-sync is done at last if all checks pass, and as a bonus you end >> > >> up with an authenticated LDAP connection should you need it, or the bind >> > >> code that does all the checks need to be abstracted into helper >> > >> functions that can be reused by this plugin. >> > >> >> > >> Simo. >> > > >> > >Is it possible to do a post-bind extop which rejects the bind? Because >> > >if synchronization fails, we MUST reject the authentication even if the >> > >first factor was validated correctly. Also, is it possible to add >> > >extended data to a bind operation? Because if not, this is going to get >> > >hairy fast. >> > Extended data on the server side? You can set what you want in PB in >> > pre-bind and pick it up in post-bind. >> > >> > However, the question is about successful binds -- when SIMPLE bind is >> > successful DS code will send response to the client and will call post >> > plugins. The response is sent unconditionally. >> > >> > May be we could add a condition that if a certain flag is set in PB >> > after pre-bind plugins ran successfully, response is not sent and >> > post-bind plugins then run. A post-bind plugin then is required to >> > send out proper result. >> >> No, extended data from the client side. The client needs to somehow >> communicate to the server: >> 1. that it wants the server to resynchronize >> 2. two tokens codes in a row >> >> Ideally we need some sort of additional metadata in the bind request. >> Without this, doing all the tests are pretty much impossible. We could >> refactor the code in ipa-pwd-extop into a library, but ipa-pwd-extop >> doesn't contain all the tests. Some of them are built into 389ds. The >> ipa-pwd-extop plugin just performs additional work and then falls >> through to 389ds. >> >> What we need to do is this: >> >> bool bind_preop() { >> if (otp_configured() && !is_sync_request()) >> if (!validate_otp()) >> return false; >> >> // ... fall through to password validation ... >> } >> >> bool bind_postop() { >> return bind_successful() >> && (!is_sync_request() >> || perform_synchronization()); >> } >> >> At the least, however, we need extra metadata for is_sync_request(). >> >> So the question is: is it possible to get some extra metadata in a bind >> request? > >So from my initial reading it appears we can just embed the sync request >in a control, is that correct? Yes, you'd define a custom control and put the sync request data in it. You'd still need to change servers/slapd/bind.c:do_bind() around 815-830 to avoid sending successful response in case SLAPI_PLUGIN_PRE_BIND_FN activates some flag in PB. May be you can in that case move successful response past SLAPI_PLUGIN_POST_BIND_FN calls in case some SLAPI_PLUGIN_POST_BIND_FN function cleans it up signalling that actual operation did indeed succeed. -- / Alexander Bokovoy From simo at redhat.com Thu Jan 23 21:42:31 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 23 Jan 2014 16:42:31 -0500 Subject: [Freeipa-devel] [PATCH 0030] Add OTP sync plugin In-Reply-To: <1390510620.1984.135.camel@localhost.localdomain> References: <1389302896.1962.6.camel@localhost.localdomain> <1390505005.15404.118.camel@willson.li.ssimo.org> <1390506069.1984.124.camel@localhost.localdomain> <20140123201251.GO12003@redhat.com> <1390509976.1984.134.camel@localhost.localdomain> <1390510620.1984.135.camel@localhost.localdomain> Message-ID: <1390513351.15404.120.camel@willson.li.ssimo.org> On Thu, 2014-01-23 at 15:57 -0500, Nathaniel McCallum wrote: > On Thu, 2014-01-23 at 15:46 -0500, Nathaniel McCallum wrote: > > On Thu, 2014-01-23 at 22:12 +0200, Alexander Bokovoy wrote: > > > On Thu, 23 Jan 2014, Nathaniel McCallum wrote: > > > >On Thu, 2014-01-23 at 14:23 -0500, Simo Sorce wrote: > > > >> On Thu, 2014-01-09 at 16:28 -0500, Nathaniel McCallum wrote: > > > >> > This plugin adds an extended operation for synchronizing tokens. This > > > >> > operation is availalbe both with and without bind. In the latter case, > > > >> > the first factor is required. This operation can also be performed > > > >> > on a per-token or per-user level. In the latter case, we will attempt > > > >> > to find the token automatically. > > > >> > > > > >> > Thanks to Mark Reynolds for helping me with this patch. > > > >> > > > >> > > > >> Huge NACK, > > > >> > > > >> otp_sync_request_authenticate() is not ok, it allows an attacker to do > > > >> password bruteforcing without any check. > > > >> > > > >> This is the result of trying to re-implement what is basically a bind > > > >> but w/o using the ind code. > > > >> > > > >> No checks to see if the user is enabled/disabled/locked > > > >> No updates for locking account after N wrong tries, etc... > > > >> > > > >> It also duplicates the places to change should we wish to not depend on > > > >> having userPassword as an actual password field anymore (which I > > > >> considered multiple times as we already have kerberos keys against which > > > >> we could test binds in theory). > > > >> > > > >> You should either extend the bind operation so all checks are used there > > > >> and re-sync is done at last if all checks pass, and as a bonus you end > > > >> up with an authenticated LDAP connection should you need it, or the bind > > > >> code that does all the checks need to be abstracted into helper > > > >> functions that can be reused by this plugin. > > > >> > > > >> Simo. > > > > > > > >Is it possible to do a post-bind extop which rejects the bind? Because > > > >if synchronization fails, we MUST reject the authentication even if the > > > >first factor was validated correctly. Also, is it possible to add > > > >extended data to a bind operation? Because if not, this is going to get > > > >hairy fast. > > > Extended data on the server side? You can set what you want in PB in > > > pre-bind and pick it up in post-bind. > > > > > > However, the question is about successful binds -- when SIMPLE bind is > > > successful DS code will send response to the client and will call post > > > plugins. The response is sent unconditionally. > > > > > > May be we could add a condition that if a certain flag is set in PB > > > after pre-bind plugins ran successfully, response is not sent and > > > post-bind plugins then run. A post-bind plugin then is required to > > > send out proper result. > > > > No, extended data from the client side. The client needs to somehow > > communicate to the server: > > 1. that it wants the server to resynchronize > > 2. two tokens codes in a row > > > > Ideally we need some sort of additional metadata in the bind request. > > Without this, doing all the tests are pretty much impossible. We could > > refactor the code in ipa-pwd-extop into a library, but ipa-pwd-extop > > doesn't contain all the tests. Some of them are built into 389ds. The > > ipa-pwd-extop plugin just performs additional work and then falls > > through to 389ds. > > > > What we need to do is this: > > > > bool bind_preop() { > > if (otp_configured() && !is_sync_request()) > > if (!validate_otp()) > > return false; > > > > // ... fall through to password validation ... > > } > > > > bool bind_postop() { > > return bind_successful() > > && (!is_sync_request() > > || perform_synchronization()); > > } > > > > At the least, however, we need extra metadata for is_sync_request(). > > > > So the question is: is it possible to get some extra metadata in a bind > > request? > > So from my initial reading it appears we can just embed the sync request > in a control, is that correct? Yes, controls are made exactly for this kind of purpose. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Thu Jan 23 22:42:43 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 23 Jan 2014 17:42:43 -0500 Subject: [Freeipa-devel] [PATCH 0030] Add OTP sync plugin In-Reply-To: <1390505005.15404.118.camel@willson.li.ssimo.org> References: <1389302896.1962.6.camel@localhost.localdomain> <1390505005.15404.118.camel@willson.li.ssimo.org> Message-ID: <1390516963.1984.141.camel@localhost.localdomain> On Thu, 2014-01-23 at 14:23 -0500, Simo Sorce wrote: > On Thu, 2014-01-09 at 16:28 -0500, Nathaniel McCallum wrote: > > This plugin adds an extended operation for synchronizing tokens. This > > operation is availalbe both with and without bind. In the latter case, > > the first factor is required. This operation can also be performed > > on a per-token or per-user level. In the latter case, we will attempt > > to find the token automatically. > > > > Thanks to Mark Reynolds for helping me with this patch. > > > Huge NACK, > > otp_sync_request_authenticate() is not ok, it allows an attacker to do > password bruteforcing without any check. > > This is the result of trying to re-implement what is basically a bind > but w/o using the ind code. > > No checks to see if the user is enabled/disabled/locked > No updates for locking account after N wrong tries, etc... > > It also duplicates the places to change should we wish to not depend on > having userPassword as an actual password field anymore (which I > considered multiple times as we already have kerberos keys against which > we could test binds in theory). > > You should either extend the bind operation so all checks are used there > and re-sync is done at last if all checks pass, and as a bonus you end > up with an authenticated LDAP connection should you need it, or the bind > code that does all the checks need to be abstracted into helper > functions that can be reused by this plugin. After discussing the details with nkinder, we have three options here. 1. FreeIPA implements all of the bind operation from 389ds in ipa-pwd-extop. This is, I think, a bad idea. 2. 389DS needs to grow a new plugin type which hooks immediately after the password validation completes, but before any changes are made to the connection state/pblock. 3. Manually validate the password like we are doing now, but only for the synchronization operation. In this case, if the password doesn't match the normal bind process will fail and no synchronization will be performed. If the password does match, it will be validated twice: once for the synchronization operation and once for the bind. This could potentially allow a user who is locked out, for instance, to synchronize tokens. It would not, however, permit them to bind. Nor would it permit brute-forcing. Thoughts? Nathaniel From simo at redhat.com Fri Jan 24 02:43:05 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 23 Jan 2014 21:43:05 -0500 Subject: [Freeipa-devel] [PATCH 0030] Add OTP sync plugin In-Reply-To: <1390516963.1984.141.camel@localhost.localdomain> References: <1389302896.1962.6.camel@localhost.localdomain> <1390505005.15404.118.camel@willson.li.ssimo.org> <1390516963.1984.141.camel@localhost.localdomain> Message-ID: <1390531385.15404.128.camel@willson.li.ssimo.org> On Thu, 2014-01-23 at 17:42 -0500, Nathaniel McCallum wrote: > On Thu, 2014-01-23 at 14:23 -0500, Simo Sorce wrote: > > On Thu, 2014-01-09 at 16:28 -0500, Nathaniel McCallum wrote: > > > This plugin adds an extended operation for synchronizing tokens. This > > > operation is availalbe both with and without bind. In the latter case, > > > the first factor is required. This operation can also be performed > > > on a per-token or per-user level. In the latter case, we will attempt > > > to find the token automatically. > > > > > > Thanks to Mark Reynolds for helping me with this patch. > > > > > > Huge NACK, > > > > otp_sync_request_authenticate() is not ok, it allows an attacker to do > > password bruteforcing without any check. > > > > This is the result of trying to re-implement what is basically a bind > > but w/o using the ind code. > > > > No checks to see if the user is enabled/disabled/locked > > No updates for locking account after N wrong tries, etc... > > > > It also duplicates the places to change should we wish to not depend on > > having userPassword as an actual password field anymore (which I > > considered multiple times as we already have kerberos keys against which > > we could test binds in theory). > > > > You should either extend the bind operation so all checks are used there > > and re-sync is done at last if all checks pass, and as a bonus you end > > up with an authenticated LDAP connection should you need it, or the bind > > code that does all the checks need to be abstracted into helper > > functions that can be reused by this plugin. > > After discussing the details with nkinder, we have three options here. > > 1. FreeIPA implements all of the bind operation from 389ds in > ipa-pwd-extop. This is, I think, a bad idea. > > 2. 389DS needs to grow a new plugin type which hooks immediately after > the password validation completes, but before any changes are made to > the connection state/pblock. > > 3. Manually validate the password like we are doing now, but only for > the synchronization operation. In this case, if the password doesn't > match the normal bind process will fail and no synchronization will be > performed. If the password does match, it will be validated twice: once > for the synchronization operation and once for the bind. This could > potentially allow a user who is locked out, for instance, to synchronize > tokens. It would not, however, permit them to bind. Nor would it permit > brute-forcing. > > Thoughts? So the proposal in (3) is to check the manually for the password first (in case of synchronization), but then whether it matches or not keep going and let 389ds finish the bind operation so that all accounting is done ? I think this is an acceptable compromise, but I think we may want to open bugs to get (2) eventually, and then change the code. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Fri Jan 24 09:41:04 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 24 Jan 2014 10:41:04 +0100 Subject: [Freeipa-devel] [PATCH 0030] Add OTP sync plugin In-Reply-To: <1389302896.1962.6.camel@localhost.localdomain> References: <1389302896.1962.6.camel@localhost.localdomain> Message-ID: <52E23530.4030404@redhat.com> On 9.1.2014 22:28, Nathaniel McCallum wrote: > This plugin adds an extended operation for synchronizing tokens. This > operation is availalbe both with and without bind. In the latter case, > the first factor is required. This operation can also be performed > on a per-token or per-user level. In the latter case, we will attempt > to find the token automatically. > > Thanks to Mark Reynolds for helping me with this patch. Nitpick: AM_CPPFLAGS should not contain $(AM_CFLAGS), it leads to duplication, as AM_CFLAGS are included in the compiler command line automatically. -- Jan Cholasta From jcholast at redhat.com Fri Jan 24 11:08:27 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 24 Jan 2014 12:08:27 +0100 Subject: [Freeipa-devel] [PATCH] 237 Fix ntpd config on clients Message-ID: <52E249AB.5090700@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-237-Fix-ntpd-config-on-clients.patch Type: text/x-patch Size: 1606 bytes Desc: not available URL: From mkosek at redhat.com Fri Jan 24 12:07:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 24 Jan 2014 13:07:00 +0100 Subject: [Freeipa-devel] [PATCH] 237 Fix ntpd config on clients In-Reply-To: <52E249AB.5090700@redhat.com> References: <52E249AB.5090700@redhat.com> Message-ID: <52E25764.9040904@redhat.com> On 01/24/2014 12:08 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > ACK, works for me. Pushed to master, ipa-3-3. Martin From mkosek at redhat.com Fri Jan 24 15:30:51 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 24 Jan 2014 16:30:51 +0100 Subject: [Freeipa-devel] What is Changelog on wiki for? Message-ID: <52E2872B.6060304@redhat.com> When working on release, this question comes to my mind every time - what is the following page good for? :) http://www.freeipa.org/page/Changelog To me, it is usually just an annoyance of the release process. You can simply get all the data with "git log" derivatives, so I do not see a point of maintaining this page. I see benefits of having shortlog in Release pages like [1], but not with this one. I am thus proposing to deprecate it. [1] http://www.freeipa.org/page/Releases/3.3.3 Thanks. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From mkosek at redhat.com Fri Jan 24 15:31:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 24 Jan 2014 16:31:44 +0100 Subject: [Freeipa-devel] [PATCH] 453 ntpconf: remove redundant comment Message-ID: <52E28760.3010402@redhat.com> Removing redundant comment in ntpconf, as observed in https://bugzilla.redhat.com/show_bug.cgi?id=1049322#c9. Pushed to master, ipa-3-3 as one-liner. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-453-ntpconf-remove-redundant-comment.patch Type: text/x-patch Size: 870 bytes Desc: not available URL: From rcritten at redhat.com Fri Jan 24 15:39:24 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 24 Jan 2014 10:39:24 -0500 Subject: [Freeipa-devel] What is Changelog on wiki for? In-Reply-To: <52E2872B.6060304@redhat.com> References: <52E2872B.6060304@redhat.com> Message-ID: <52E2892C.6090004@redhat.com> Martin Kosek wrote: > When working on release, this question comes to my mind every time - what is > the following page good for? :) > > http://www.freeipa.org/page/Changelog > > To me, it is usually just an annoyance of the release process. You can simply > get all the data with "git log" derivatives, so I do not see a point of > maintaining this page. > > I see benefits of having shortlog in Release pages like [1], but not with this > one. I am thus proposing to deprecate it. > > [1] http://www.freeipa.org/page/Releases/3.3.3 > > Thanks. > I used to just cherry-pick the big things then figured that some people care about everything so switched to that instead. Yes, the data is in git, but if one doesn't know git well then it can be hard to tell where something was fixed. I won't yell if it's dropped, but it's just a cut-n-paste after all. rob From pviktori at redhat.com Fri Jan 24 15:48:52 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 24 Jan 2014 16:48:52 +0100 Subject: [Freeipa-devel] [PATCHES] 0455-0459 Add support for managed permissions In-Reply-To: <1390484550.15404.79.camel@willson.li.ssimo.org> References: <52CD738A.40105@redhat.com> <52DF8F0E.9020705@redhat.com> <52E0FBEC.2020303@redhat.com> <52E109CA.2020605@redhat.com> <1390484550.15404.79.camel@willson.li.ssimo.org> Message-ID: <52E28B64.9010403@redhat.com> On 01/23/2014 02:42 PM, Simo Sorce wrote: > On Thu, 2014-01-23 at 13:23 +0100, Petr Viktorin wrote: >> On 01/23/2014 12:24 PM, Martin Kosek wrote: >>> On 01/22/2014 10:27 AM, Petr Viktorin wrote: >>>> On 01/08/2014 04:49 PM, Petr Viktorin wrote: >>>>> Hello, >>>>> This adds "managed" permissions, the framework that will make our >>>>> default permissions merge IPA updates and user changes sanely. >>>>> >>>>> There is no updater yet, nor does this add any actual managed >>>>> permissions, so there's no user-visible change (beyond help text and a >>>>> disabled option). To test the patch you might need to touch LDAP directly. >>>>> >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4033 >>>>> Design (no updater & plugin changes yet): >>>>> http://www.freeipa.org/page/V3/Managed_Read_permissions >>>>> >>>>> 0447 - Minor fixes. >>>>> 0448 - Since you can't create managed permissions through the API, I >>>>> needed to get creative with the declarative tests. The tests will need a >>>>> custom function that adds a managed perm. >>>>> 0449 - The change itself. >>>> >>>> ping; any thoughts on this one? >>>> >>>> >>> >>> 1) 449, the comment: >>> >>> +Deleting or renaming a managed permission, as well as changing its target, >>> +is not supported. >>> +""") + _(""" >>> >>> I am not sure that the phrase "not supported" is the right one. It sounds to me >>> like this is something we want to allow, just not implemented yet. IMO "is not >>> allowed" would be better. >> >> Makes sense. >> >>> 2) Can you add allow_mod_for_managed flag description to parameters.py? >>> >>> + flags={'no_create', 'allow_mod_for_managed'}, >>> >>> So far we try to add all flag descriptions there. >> >> OK >> >>> 3) When I updated the test to not delete the testperm, I tried to show the >>> managed permission and it is not entirely clear, see: >>> >>> # ipa permission-show testperm >>> Permission name: testperm >>> Permissions: write >>> * Attributes: cn, o, sn >>> * Excluded attributes: cn, sn >>> Bind rule type: all >>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>> Type: user >>> * Default attributes: l, o, cn >>> * Effective attributes: l, o >> >> Well, this is a tradeoff between presenting what's stored in LDAP and >> what's in the ACI. >> >>> The "Attributes" mean actually attributes explicitly allowed by user, but it is >>> not obvious from the output. >>> >>> Maybe it would be better to return only "Effective attributes" by default and >>> return the 3 source lists only when --all is passed. But this would require us >>> to let Command override LDAPObject's default_attributes, which framework cannot do. >> >> Modifying default_attributes would not work because the 3 lists need to >> be loaded from LDAP to determine the effective attributes. >> It's possible to remove the extra attributes in the post_callback, >> postprocess_result already does similar output manipulation. >> >>> Alternatively, we may choose to use the attributes differently with managed >>> permissions: >>> - we add the new attributeType "ipaPermIncludedAttr". It would be used for the >>> user-specified whitelist of attributes instead of ipaPermAllowedAttr >>> - we do not use the ipaPermAllowedAttr with managed attributes at all or use it >>> for the "Effective attributes" list >>> >>> My point is that the semantics of ipaPermAllowedAttr is different for managed >>> and non-managed permission, so it may confuse people. >> >> Well, the semantics are always the same (effective = (default | allowed) >> - excluded). I agree that it can be confusing; perhaps I'm in too deep >> to judge how it looks from the outside. >> >>> For example, you may want >>> to search for all permissions that allow attribute "sn": >>> >>> # ipa permission-find --attrs sn >>> --------------------- >>> 4 permissions matched >>> --------------------- >>> Permission name: anon >>> Permissions: read >>> Attributes: sn >>> Bind rule type: anonymous >>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>> Type: user >>> ... >>> Permission name: testperm >>> Permissions: write >>> Attributes: cn, o, sn >>> Excluded attributes: cn, sn >>> Bind rule type: anonymous >>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>> Type: user >>> Default attributes: l, o, cn >>> Effective attributes: l, o >>> ... >>> >>> As you see, it matched both testperm and anon even though testperm does not >>> really allow sn as it excluded. >>> >>> Thoughts? >> >> Well, we could have default, included, excluded attributes stored in >> LDAP as now (using the name "included" instead of "allowed"), and make >> effective attributes (--attrs) into an updatable virtual attribute: when >> setting it, IPA would consult the "default" attributes and update >> "included"/"excluded" accordingly. (With non-managed permissions >> "default" is empty, so only "included" would be updated.) And searching >> on --attrs would construct an appropriate filter. >> >> I thought about this approach earlier but thought that it obscured >> what's actually stored in LDAP. Given recent discussions I'm now >> thinking I shouldn't have rejected it. > > > I would take a consistent approach indeed. > I do not much care for the virtual attribute part in LDAP, as long as > our tool show prominently the effective list. > And also as long as all permissions behave the same way in the general > mechanism in LDAP. > > Simo. > All right. Here are patches; I'll start updating the design page. **NOTE** This renames the 'ipaPermAllowedAttr' attribute to 'ipaPermIncludedAttr'. Upgrades from master will fail, so please install a new server. Of course no released versions of FreeIPA are affected. I assume there's no clean way to rename an attribute without changing the OID? Is it OK to break master this way? As before three source lists are stored in LDAP: - ipaPermDefaultAttr - ipaPermIncludedAttr (--includedattrs) - ipaPermExcludedAttr (--excludedattrs) Setting --attrs ("Effective Attributes") will set the included/excluded attributes based on the default set. For normal permissions, default & excluded will be empty, and in this case only effective attributes will be displayed on output (unless --all or --raw is given). I've added some preparatory patches for #4074 to this batch, mostly to prevent rebase conflicts with that work. Re-numbering for a sane order. Apply on top of my patch 0452 0455 - minor fixes, unchanged from 0447 0456 - converting options on the server it will allow us to consult the entry's existing state. Arguably it's also cleaner to use execute than args_options_2_params for this. 0457 - generate ACIs in the plugin. This is the next step in obsoleting the ACI class, which in the end should only be necessary for updating old-style ACIs. The one-way function should be easier to maintain and extend. 0458 - allow callables in declarative tests, unchanged from 0448 0459 - managed permissions Or: git pull https://github.com/encukou/freeipa 3566-managed-perms commit 51bb7f27516202a062ffa25fedae18d0e9f302b6 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0455-Permission-plugin-fixes.patch Type: text/x-patch Size: 3959 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0456-permission-plugin-Convert-options-in-execute-not-arg.patch Type: text/x-patch Size: 3198 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0457-permission-plugin-Generate-ACIs-in-the-plugin.patch Type: text/x-patch Size: 3125 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0458-Make-it-possible-to-call-custom-functions-in-Declara.patch Type: text/x-patch Size: 1798 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0459-Add-support-for-managed-permissions.patch Type: text/x-patch Size: 75372 bytes Desc: not available URL: From simo at redhat.com Fri Jan 24 15:57:10 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 24 Jan 2014 10:57:10 -0500 Subject: [Freeipa-devel] [PATCHES] 0455-0459 Add support for managed permissions In-Reply-To: <52E28B64.9010403@redhat.com> References: <52CD738A.40105@redhat.com> <52DF8F0E.9020705@redhat.com> <52E0FBEC.2020303@redhat.com> <52E109CA.2020605@redhat.com> <1390484550.15404.79.camel@willson.li.ssimo.org> <52E28B64.9010403@redhat.com> Message-ID: <1390579030.15404.140.camel@willson.li.ssimo.org> On Fri, 2014-01-24 at 16:48 +0100, Petr Viktorin wrote: > All right. Here are patches; I'll start updating the design page. > > **NOTE** > This renames the 'ipaPermAllowedAttr' attribute to > 'ipaPermIncludedAttr'. Upgrades from master will fail, so please install > a new server. Of course no released versions of FreeIPA are affected. > I assume there's no clean way to rename an attribute without changing > the OID? You do not need to change the OID in this case, these attributes have not been released in any production version so I think it is ok to just rename. > Is it OK to break master this way? I would prefer you didn't, what breaks master exactly ? The schema update ? Technically we could alias the name so the attribute can be called either way, but that is not necessarily a good option either. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Fri Jan 24 16:17:13 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 24 Jan 2014 17:17:13 +0100 Subject: [Freeipa-devel] [PATCHES] 0455-0459 Add support for managed permissions In-Reply-To: <1390579030.15404.140.camel@willson.li.ssimo.org> References: <52CD738A.40105@redhat.com> <52DF8F0E.9020705@redhat.com> <52E0FBEC.2020303@redhat.com> <52E109CA.2020605@redhat.com> <1390484550.15404.79.camel@willson.li.ssimo.org> <52E28B64.9010403@redhat.com> <1390579030.15404.140.camel@willson.li.ssimo.org> Message-ID: <52E29209.6040202@redhat.com> On 01/24/2014 04:57 PM, Simo Sorce wrote: > On Fri, 2014-01-24 at 16:48 +0100, Petr Viktorin wrote: > >> All right. Here are patches; I'll start updating the design page. >> >> **NOTE** >> This renames the 'ipaPermAllowedAttr' attribute to >> 'ipaPermIncludedAttr'. Upgrades from master will fail, so please install >> a new server. Of course no released versions of FreeIPA are affected. >> I assume there's no clean way to rename an attribute without changing >> the OID? > > You do not need to change the OID in this case, these attributes have > not been released in any production version so I think it is ok to just > rename. > >> Is it OK to break master this way? > > I would prefer you didn't, what breaks master exactly ? The schema > update ? Yes. The schema update fails when it tries to add a differently named attribute with the same OID. > Technically we could alias the name so the attribute can be called > either way, but that is not necessarily a good option either. If breaking master is unacceptable, we can use the old name instead. ipaPermIncludedAttr is more consistent but ipaPermAllowedAttr isn't downright wrong. -- Petr? From simo at redhat.com Fri Jan 24 16:23:17 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 24 Jan 2014 11:23:17 -0500 Subject: [Freeipa-devel] [PATCHES] 0455-0459 Add support for managed permissions In-Reply-To: <52E29209.6040202@redhat.com> References: <52CD738A.40105@redhat.com> <52DF8F0E.9020705@redhat.com> <52E0FBEC.2020303@redhat.com> <52E109CA.2020605@redhat.com> <1390484550.15404.79.camel@willson.li.ssimo.org> <52E28B64.9010403@redhat.com> <1390579030.15404.140.camel@willson.li.ssimo.org> <52E29209.6040202@redhat.com> Message-ID: <1390580597.15404.142.camel@willson.li.ssimo.org> On Fri, 2014-01-24 at 17:17 +0100, Petr Viktorin wrote: > On 01/24/2014 04:57 PM, Simo Sorce wrote: > > On Fri, 2014-01-24 at 16:48 +0100, Petr Viktorin wrote: > > > >> All right. Here are patches; I'll start updating the design page. > >> > >> **NOTE** > >> This renames the 'ipaPermAllowedAttr' attribute to > >> 'ipaPermIncludedAttr'. Upgrades from master will fail, so please install > >> a new server. Of course no released versions of FreeIPA are affected. > >> I assume there's no clean way to rename an attribute without changing > >> the OID? > > > > You do not need to change the OID in this case, these attributes have > > not been released in any production version so I think it is ok to just > > rename. > > > >> Is it OK to break master this way? > > > > I would prefer you didn't, what breaks master exactly ? The schema > > update ? > > Yes. The schema update fails when it tries to add a differently named > attribute with the same OID. ok. > > Technically we could alias the name so the attribute can be called > > either way, but that is not necessarily a good option either. > > If breaking master is unacceptable, we can use the old name instead. > ipaPermIncludedAttr is more consistent but ipaPermAllowedAttr isn't > downright wrong. Ok, let's hear other opinions, I see a lot f value in consistent naming, and not breaking a developer build is not that strong of a reason to have substandard naming I guess. What do others think ? Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Jan 24 17:34:54 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 24 Jan 2014 12:34:54 -0500 Subject: [Freeipa-devel] OTP Sync Client In-Reply-To: <1390488060.1984.110.camel@localhost.localdomain> References: <1390424357.1984.104.camel@localhost.localdomain> <52E03228.9020002@redhat.com> <1390424831.1984.106.camel@localhost.localdomain> <52E0E0CF.8090300@redhat.com> <1390488060.1984.110.camel@localhost.localdomain> Message-ID: <52E2A43E.3090905@redhat.com> On 01/23/2014 09:41 AM, Nathaniel McCallum wrote: > On Thu, 2014-01-23 at 10:28 +0100, Petr Vobornik wrote: >> On 22.1.2014 22:07, Nathaniel McCallum wrote: >>> On Wed, 2014-01-22 at 16:03 -0500, Rob Crittenden wrote: >>>> Nathaniel McCallum wrote: >>>>> In attempting to write an OTP synchronization client, I've noticed it >>>>> doesn't fit into the framework very well. The job of the client is to >>>>> perform the synchronization extended operation. The format of the >>>>> request is this: >>>>> >>>>> OTPSyncRequestValue ::= SEQUENCE { >>>>> userDN OCTET STRING, >>>>> tokenDN [0] OCTET STRING OPTIONAL, >>>>> firstFactor [1] OCTET STRING OPTIONAL, >>>>> firstCode INTEGER, >>>>> secondCode INTEGER >>>>> } >>>>> >>>>> In all cases, the user MUST provide two token codes and MAY provide the >>>>> DN of a token to sync. >>>>> >>>>> >From here two cases exist: bound and unbound. >>>>> >>>>> In the unbound case, both the userDN and firstFactor fields are required >>>>> and authentication is performed internally. >>>>> >>>>> In the bound case, the client has already bound (usually via a kerberos >>>>> ticket). In this case, the client must provide userDN only. There are >>>>> two options here. First, the client can generate the userDN >>>>> automatically from the kerberos ticket metadata. Second, the extop >>>>> plugin can make the userDN field optional and simply rely on the >>>>> internal bind DN. This is my preferred route, and will require a new >>>>> revision of the otp sync patch (no problem). In this second case, if the >>>>> user is bound, the DS plugin would ignore the values of >>>>> userDN/firstFactor. >>>>> >>>>> Assuming the second case to be true, how do I write a command in the >>>>> framework that will attempt a krb5 bind and then prompt for >>>>> username/password if the bind fails? Also, how do I, on the client side, >>>>> without any bind to LDAP translate the username to the userDN? The same >>>>> is true for the token ID to DN translation? Would it be better to write >>>>> this code independently of the FreeIPA client command framework? >> Look at ipaserver.rpcserver.login_password class. IMO the code shares a >> lot of similarities with your intentions. > Thanks! > >>>> You can override the forward() command in the plugin to do client-side >>>> work. There are a few examples, see service_show and >>>> automountlocation_import. I just wonder how this would work in the UI. >>> I believe the intention in the UI is to just handle the unbound case >>> with no tokenDN option. It would essentially be a login screen that >>> would look like this: >>> Username: _______________ >>> Password: _______________ >>> First Token: _______________ >>> Second Token: _______________ >>> >>> Nathaniel >>> >> +1 It could be further extended to a simple "token portal" where one >> could login via first factor and then list tokens and sync a selected >> token. The only issue is that it's quite hard to achieve this without >> binding(sending psw) in each request - IPA framework is not designed for >> such task. The issue is getting a session. If we were able to get a >> session we could use the method described below. >> >> >> Second Web UI use case might be: >> >> When user is logged in - via other "working" token or different auth >> method (i.e., password auth is enabled), he can: >> - open OTP tokens page >> - open some token details >> - select 'sync' action >> - enter OTP1, OTP2, confirm > I'm not quite sure what the purpose of this is. Why do we have to bother > the user with selecting which token to synchronize when we can easily do > this algorithmicly? The user doesn't pick which token to use when > logging in. I'm not sure why syncing should be any different. While I agree that we can it would be more intuitive to the user if he does it for a specific token. So in CLI the argument ipatokenuniqueid should be token id or user id > > Nathaniel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Jan 24 17:46:28 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 24 Jan 2014 12:46:28 -0500 Subject: [Freeipa-devel] What is Changelog on wiki for? In-Reply-To: <52E2892C.6090004@redhat.com> References: <52E2872B.6060304@redhat.com> <52E2892C.6090004@redhat.com> Message-ID: <52E2A6F4.9000908@redhat.com> On 01/24/2014 10:39 AM, Rob Crittenden wrote: > Martin Kosek wrote: >> When working on release, this question comes to my mind every time - >> what is >> the following page good for? :) >> >> http://www.freeipa.org/page/Changelog >> >> To me, it is usually just an annoyance of the release process. You >> can simply >> get all the data with "git log" derivatives, so I do not see a point of >> maintaining this page. >> >> I see benefits of having shortlog in Release pages like [1], but not >> with this >> one. I am thus proposing to deprecate it. >> >> [1] http://www.freeipa.org/page/Releases/3.3.3 >> >> Thanks. >> > > I used to just cherry-pick the big things then figured that some > people care about everything so switched to that instead. Yes, the > data is in git, but if one doesn't know git well then it can be hard > to tell where something was fixed. > > I won't yell if it's dropped, but it's just a cut-n-paste after all. It is internet search-able and can be easily pointed to in different follow up materials. I would rather keep it, but a wiki formatting script might be a good idea. > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pviktori at redhat.com Fri Jan 24 19:31:23 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 24 Jan 2014 20:31:23 +0100 Subject: [Freeipa-devel] [PATCHES] 225-230 Drop support for the legacy LDAP API In-Reply-To: <52DFF628.2010906@redhat.com> References: <52A72DA8.4090104@redhat.com> <52AB16B8.6050808@redhat.com> <52AEC654.5040602@redhat.com> <52AF03F2.2090904@redhat.com> <52CBF8FB.7090808@redhat.com> <52D00B84.1090804@redhat.com> <52D51218.1090304@redhat.com> <52DD0741.2040209@redhat.com> <52DFF628.2010906@redhat.com> Message-ID: <52E2BF8B.9090605@redhat.com> On 01/22/2014 05:47 PM, Jan Cholasta wrote: > On 20.1.2014 12:23, Petr Viktorin wrote: >> On 01/14/2014 11:31 AM, Jan Cholasta wrote: >>> On 10.1.2014 16:02, Petr Viktorin wrote: >>>> On 01/07/2014 01:54 PM, Jan Cholasta wrote: >>>>> On 16.12.2013 14:45, Petr Viktorin wrote: >>>>>> On 12/16/2013 10:22 AM, Jan Cholasta wrote: >>>>>>> On 13.12.2013 15:16, Petr Viktorin wrote: >>>>>>>> On 12/10/2013 04:05 PM, Jan Cholasta wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I believe the time has come to drop support for the legacy (dn, >>>>>>>>> entry_attrs) tuple API and move to the new LDAPEntry API >>>>>>>>> exclusively. >>>>>>>>> The attached patches convert existing code which uses the old >>>>>>>>> API to >>>>>>>>> the >>>>>>>>> new API and remove backward compatibility code from the ipaldap >>>>>>>>> module. >>>>>>>>> >>>>>>>>> Note that there are still some functions/methods which accept >>>>>>>>> separate >>>>>>>>> dn and entry_attrs arguments, they will be adapted to LDAPEntry >>>>>>>>> later. >>>>>>>>> >>>>>>>>> Honza >>>>>>>> >>>>>>>> The first N-1 patches can be tested,acked,pushed independently, >>>>>>>> right? >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>>> If that's the case, ACK for 225 >>>>>> >>>>>> Pushed that one to master, 5 more to go. >>>>>> bc3f3381c6bf0b4941889b775025a60f56318551 >>>>>> >>>> >>>> 226 needs a rebase. >>>> >>>> 227: in install/tools/ipa-adtrust-install: >>>> >>>> + entry_attrs = conn.make_entry( >>>> + dn, >>>> + objectclass=['top', 'pkiuser', 'nscontainer'], >>>> + usercertificate=cert) >>>> + conn.add_entry(entry_attrs) >>>> >>>> Shouldn't it be `usercertificate=[cert]` now? Similarly in ra_cert, >>>> and >>>> in ipa-server-install with ipacertificatesubjectbase >>>> >>>> Otherwise this looks good. >>>> >>>> 228: in ipaserver/install/plugins/update_idranges.py, again we should >>>> use lists >>>> >>>> Otherwise it looks good >>>> >>>> 229: ACK >>>> >>> >>> Rebased and fixed everything, updated patches attached. >> >> Here, patch 226 breaks tests for selinuxusermap_enable/disable, at >> least. The EmptyModlist and AlreadyActive/AlreadyInactive error is no >> longer raised, since the previous entry state is no longer retrieved. >> > > Well, I forgot to test this patchset after patches for > were pushed, sorry. > > Added new patch 235 which makes LDAPUpdate get old entry state from > LDAP, it fixes most of the issues in *_mod commands. If getting the entry is really always needed then I see no real reason why it's not done at the beginning of execute() and made available throughout the command's execution. It would be so much easier to do non-trivial work in the callbacks. And more efficient, too, compared to the current way of always asking LDAP when the original entry is needed. Ah well. One day we can rewrite the whole thing :/ For now, ACK > Fixed the rest of the issues in patches 226-230 and rebased them on top > of patch 235. ACK, pushed to master: 5737eaf1348ba101ae227fa79fb4451a2413fc84 -- Petr? From ayoung at redhat.com Fri Jan 24 22:24:27 2014 From: ayoung at redhat.com (Adam Young) Date: Fri, 24 Jan 2014 17:24:27 -0500 Subject: [Freeipa-devel] ANNOUNCE: kdcproxy 0.1.1 released In-Reply-To: <1390342768.1984.76.camel@localhost.localdomain> References: <1390342768.1984.76.camel@localhost.localdomain> Message-ID: <52E2E81B.8060007@redhat.com> Nicely done. What is the relationship to this and the Code Robby wrote last summer? I assume it was the basis for this effort? On 01/21/2014 05:19 PM, Nathaniel McCallum wrote: > kdcproxy contains a WSGI module for proxying KDC requests over HTTP by > following the MS-KKDCP protocol. It aims to be simple to deploy, with > minimal configuration. > > https://pypi.python.org/pypi/kdcproxy > https://github.com/npmccallum/kdcproxy > > One of the reasons I am announcing this on the freeipa-devel list is > that FreeIPA may have interest in having out-of-the-box > Kerberos-over-HTTPS support. > > I do need a pure python package review for Fedora, if anyone is > interested in doing it: > https://bugzilla.redhat.com/show_bug.cgi?id=1056291 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From npmccallum at redhat.com Fri Jan 24 22:36:45 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 24 Jan 2014 17:36:45 -0500 Subject: [Freeipa-devel] ANNOUNCE: kdcproxy 0.1.1 released In-Reply-To: <52E2E81B.8060007@redhat.com> References: <1390342768.1984.76.camel@localhost.localdomain> <52E2E81B.8060007@redhat.com> Message-ID: <1390603005.1984.144.camel@localhost.localdomain> He wrote the client-side code which Nalin is cleaning up for merger with MIT krb5. This is just the server-side piece which is written by Nalin and myself. Nathaniel On Fri, 2014-01-24 at 17:24 -0500, Adam Young wrote: > Nicely done. > > What is the relationship to this and the Code Robby wrote last summer? > I assume it was the basis for this effort? > > > On 01/21/2014 05:19 PM, Nathaniel McCallum wrote: > > kdcproxy contains a WSGI module for proxying KDC requests over HTTP by > > following the MS-KKDCP protocol. It aims to be simple to deploy, with > > minimal configuration. > > > > https://pypi.python.org/pypi/kdcproxy > > https://github.com/npmccallum/kdcproxy > > > > One of the reasons I am announcing this on the freeipa-devel list is > > that FreeIPA may have interest in having out-of-the-box > > Kerberos-over-HTTPS support. > > > > I do need a pure python package review for Fedora, if anyone is > > interested in doing it: > > https://bugzilla.redhat.com/show_bug.cgi?id=1056291 > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mkosek at redhat.com Mon Jan 27 07:07:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 27 Jan 2014 08:07:18 +0100 Subject: [Freeipa-devel] [PATCHES] 0455-0459 Add support for managed permissions In-Reply-To: <1390580597.15404.142.camel@willson.li.ssimo.org> References: <52CD738A.40105@redhat.com> <52DF8F0E.9020705@redhat.com> <52E0FBEC.2020303@redhat.com> <52E109CA.2020605@redhat.com> <1390484550.15404.79.camel@willson.li.ssimo.org> <52E28B64.9010403@redhat.com> <1390579030.15404.140.camel@willson.li.ssimo.org> <52E29209.6040202@redhat.com> <1390580597.15404.142.camel@willson.li.ssimo.org> Message-ID: <52E605A6.5080507@redhat.com> On 01/24/2014 05:23 PM, Simo Sorce wrote: > On Fri, 2014-01-24 at 17:17 +0100, Petr Viktorin wrote: >> On 01/24/2014 04:57 PM, Simo Sorce wrote: >>> On Fri, 2014-01-24 at 16:48 +0100, Petr Viktorin wrote: ... >>> Technically we could alias the name so the attribute can be called >>> either way, but that is not necessarily a good option either. >> >> If breaking master is unacceptable, we can use the old name instead. >> ipaPermIncludedAttr is more consistent but ipaPermAllowedAttr isn't >> downright wrong. > > Ok, let's hear other opinions, I see a lot f value in consistent naming, > and not breaking a developer build is not that strong of a reason to > have substandard naming I guess. What do others think ? > > Simo. Hmm, I obviously see things differently here. I would rather "break" the master and let developers running on the git version to reinstall the servers (including myself) than to have to live with suboptimal attribute name for ever or by adding unnecessary cruft to the code... Martin From jcholast at redhat.com Mon Jan 27 07:14:29 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 27 Jan 2014 08:14:29 +0100 Subject: [Freeipa-devel] [PATCHES] 225-230 Drop support for the legacy LDAP API In-Reply-To: <52E2BF8B.9090605@redhat.com> References: <52A72DA8.4090104@redhat.com> <52AB16B8.6050808@redhat.com> <52AEC654.5040602@redhat.com> <52AF03F2.2090904@redhat.com> <52CBF8FB.7090808@redhat.com> <52D00B84.1090804@redhat.com> <52D51218.1090304@redhat.com> <52DD0741.2040209@redhat.com> <52DFF628.2010906@redhat.com> <52E2BF8B.9090605@redhat.com> Message-ID: <52E60755.3050105@redhat.com> On 24.1.2014 20:31, Petr Viktorin wrote: > On 01/22/2014 05:47 PM, Jan Cholasta wrote: >> On 20.1.2014 12:23, Petr Viktorin wrote: >>> On 01/14/2014 11:31 AM, Jan Cholasta wrote: >>>> On 10.1.2014 16:02, Petr Viktorin wrote: >>>>> On 01/07/2014 01:54 PM, Jan Cholasta wrote: >>>>>> On 16.12.2013 14:45, Petr Viktorin wrote: >>>>>>> On 12/16/2013 10:22 AM, Jan Cholasta wrote: >>>>>>>> On 13.12.2013 15:16, Petr Viktorin wrote: >>>>>>>>> On 12/10/2013 04:05 PM, Jan Cholasta wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I believe the time has come to drop support for the legacy (dn, >>>>>>>>>> entry_attrs) tuple API and move to the new LDAPEntry API >>>>>>>>>> exclusively. >>>>>>>>>> The attached patches convert existing code which uses the old >>>>>>>>>> API to >>>>>>>>>> the >>>>>>>>>> new API and remove backward compatibility code from the ipaldap >>>>>>>>>> module. >>>>>>>>>> >>>>>>>>>> Note that there are still some functions/methods which accept >>>>>>>>>> separate >>>>>>>>>> dn and entry_attrs arguments, they will be adapted to LDAPEntry >>>>>>>>>> later. >>>>>>>>>> >>>>>>>>>> Honza >>>>>>>>> >>>>>>>>> The first N-1 patches can be tested,acked,pushed independently, >>>>>>>>> right? >>>>>>>> >>>>>>>> Yes. >>>>>>>> >>>>>>>>> If that's the case, ACK for 225 >>>>>>> >>>>>>> Pushed that one to master, 5 more to go. >>>>>>> bc3f3381c6bf0b4941889b775025a60f56318551 >>>>>>> >>>>> >>>>> 226 needs a rebase. >>>>> >>>>> 227: in install/tools/ipa-adtrust-install: >>>>> >>>>> + entry_attrs = conn.make_entry( >>>>> + dn, >>>>> + objectclass=['top', 'pkiuser', 'nscontainer'], >>>>> + usercertificate=cert) >>>>> + conn.add_entry(entry_attrs) >>>>> >>>>> Shouldn't it be `usercertificate=[cert]` now? Similarly in ra_cert, >>>>> and >>>>> in ipa-server-install with ipacertificatesubjectbase >>>>> >>>>> Otherwise this looks good. >>>>> >>>>> 228: in ipaserver/install/plugins/update_idranges.py, again we should >>>>> use lists >>>>> >>>>> Otherwise it looks good >>>>> >>>>> 229: ACK >>>>> >>>> >>>> Rebased and fixed everything, updated patches attached. >>> >>> Here, patch 226 breaks tests for selinuxusermap_enable/disable, at >>> least. The EmptyModlist and AlreadyActive/AlreadyInactive error is no >>> longer raised, since the previous entry state is no longer retrieved. >>> >> >> Well, I forgot to test this patchset after patches for >> were pushed, sorry. >> >> Added new patch 235 which makes LDAPUpdate get old entry state from >> LDAP, it fixes most of the issues in *_mod commands. > > If getting the entry is really always needed then I see no real reason > why it's not done at the beginning of execute() and made available > throughout the command's execution. It would be so much easier to do > non-trivial work in the callbacks. And more efficient, too, compared to > the current way of always asking LDAP when the original entry is needed. > Ah well. One day we can rewrite the whole thing :/ +1, I wish there was more time for this. > For now, ACK > >> Fixed the rest of the issues in patches 226-230 and rebased them on top >> of patch 235. > > ACK, pushed to master: 5737eaf1348ba101ae227fa79fb4451a2413fc84 > Thanks for the review. -- Jan Cholasta From pspacek at redhat.com Mon Jan 27 08:08:53 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 27 Jan 2014 09:08:53 +0100 Subject: [Freeipa-devel] What is Changelog on wiki for? In-Reply-To: <52E2A6F4.9000908@redhat.com> References: <52E2872B.6060304@redhat.com> <52E2892C.6090004@redhat.com> <52E2A6F4.9000908@redhat.com> Message-ID: <52E61415.5080907@redhat.com> On 24.1.2014 18:46, Dmitri Pal wrote: > On 01/24/2014 10:39 AM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> When working on release, this question comes to my mind every time - >>> what is >>> the following page good for? :) >>> >>> http://www.freeipa.org/page/Changelog >>> >>> To me, it is usually just an annoyance of the release process. You >>> can simply >>> get all the data with "git log" derivatives, so I do not see a point of >>> maintaining this page. >>> >>> I see benefits of having shortlog in Release pages like [1], but not >>> with this >>> one. I am thus proposing to deprecate it. >>> >>> [1] http://www.freeipa.org/page/Releases/3.3.3 >>> >>> Thanks. >>> >> >> I used to just cherry-pick the big things then figured that some >> people care about everything so switched to that instead. Yes, the >> data is in git, but if one doesn't know git well then it can be hard >> to tell where something was fixed. >> >> I won't yell if it's dropped, but it's just a cut-n-paste after all. > > It is internet search-able and can be easily pointed to in different > follow up materials. > I would rather keep it, but a wiki formatting script might be a good idea. Our git repo has nice and responsive web interface: https://git.fedorahosted.org/cgit/freeipa.git/ The advantage is that you can read full commit messages so you can see links to tickets in Trac which are not present in shortlog. Given that I think that Changelog wiki page is mostly annoyance, it could simply redirect to repo web interface (may be to listings for specific branches). -- Petr^2 Spacek From pspacek at redhat.com Mon Jan 27 08:17:24 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 27 Jan 2014 09:17:24 +0100 Subject: [Freeipa-devel] [PATCHES] 0455-0459 Add support for managed permissions In-Reply-To: <52E605A6.5080507@redhat.com> References: <52CD738A.40105@redhat.com> <52DF8F0E.9020705@redhat.com> <52E0FBEC.2020303@redhat.com> <52E109CA.2020605@redhat.com> <1390484550.15404.79.camel@willson.li.ssimo.org> <52E28B64.9010403@redhat.com> <1390579030.15404.140.camel@willson.li.ssimo.org> <52E29209.6040202@redhat.com> <1390580597.15404.142.camel@willson.li.ssimo.org> <52E605A6.5080507@redhat.com> Message-ID: <52E61614.1010701@redhat.com> On 27.1.2014 08:07, Martin Kosek wrote: > On 01/24/2014 05:23 PM, Simo Sorce wrote: >> On Fri, 2014-01-24 at 17:17 +0100, Petr Viktorin wrote: >>> On 01/24/2014 04:57 PM, Simo Sorce wrote: >>>> On Fri, 2014-01-24 at 16:48 +0100, Petr Viktorin wrote: > ... >>>> Technically we could alias the name so the attribute can be called >>>> either way, but that is not necessarily a good option either. >>> >>> If breaking master is unacceptable, we can use the old name instead. >>> ipaPermIncludedAttr is more consistent but ipaPermAllowedAttr isn't >>> downright wrong. >> >> Ok, let's hear other opinions, I see a lot f value in consistent naming, >> and not breaking a developer build is not that strong of a reason to >> have substandard naming I guess. What do others think ? >> >> Simo. > > Hmm, I obviously see things differently here. I would rather "break" the master > and let developers running on the git version to reinstall the servers > (including myself) than to have to live with suboptimal attribute name for ever > or by adding unnecessary cruft to the code... (Speaking as lab admin:) Please, break it! It will force people to finally reinstall years old VMs! :-) -- Petr^2 Spacek From pviktori at redhat.com Mon Jan 27 08:50:07 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 27 Jan 2014 09:50:07 +0100 Subject: [Freeipa-devel] [PATCHES] 0455-0459 Add support for managed permissions In-Reply-To: <52E61614.1010701@redhat.com> References: <52CD738A.40105@redhat.com> <52DF8F0E.9020705@redhat.com> <52E0FBEC.2020303@redhat.com> <52E109CA.2020605@redhat.com> <1390484550.15404.79.camel@willson.li.ssimo.org> <52E28B64.9010403@redhat.com> <1390579030.15404.140.camel@willson.li.ssimo.org> <52E29209.6040202@redhat.com> <1390580597.15404.142.camel@willson.li.ssimo.org> <52E605A6.5080507@redhat.com> <52E61614.1010701@redhat.com> Message-ID: <52E61DBF.20307@redhat.com> On 01/27/2014 09:17 AM, Petr Spacek wrote: > On 27.1.2014 08:07, Martin Kosek wrote: >> On 01/24/2014 05:23 PM, Simo Sorce wrote: >>> On Fri, 2014-01-24 at 17:17 +0100, Petr Viktorin wrote: >>>> On 01/24/2014 04:57 PM, Simo Sorce wrote: >>>>> On Fri, 2014-01-24 at 16:48 +0100, Petr Viktorin wrote: >> ... >>>>> Technically we could alias the name so the attribute can be called >>>>> either way, but that is not necessarily a good option either. >>>> >>>> If breaking master is unacceptable, we can use the old name instead. >>>> ipaPermIncludedAttr is more consistent but ipaPermAllowedAttr isn't >>>> downright wrong. >>> >>> Ok, let's hear other opinions, I see a lot f value in consistent naming, >>> and not breaking a developer build is not that strong of a reason to >>> have substandard naming I guess. What do others think ? >>> >>> Simo. >> >> Hmm, I obviously see things differently here. I would rather "break" >> the master >> and let developers running on the git version to reinstall the servers >> (including myself) than to have to live with suboptimal attribute name >> for ever >> or by adding unnecessary cruft to the code... I think you got lost in the "not"s. You and Simo agree. > > (Speaking as lab admin:) Please, break it! It will force people to > finally reinstall years old VMs! :-) > -- Petr? From mkosek at redhat.com Mon Jan 27 09:02:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 27 Jan 2014 10:02:43 +0100 Subject: [Freeipa-devel] [PATCHES] 0455-0459 Add support for managed permissions In-Reply-To: <52E61DBF.20307@redhat.com> References: <52CD738A.40105@redhat.com> <52DF8F0E.9020705@redhat.com> <52E0FBEC.2020303@redhat.com> <52E109CA.2020605@redhat.com> <1390484550.15404.79.camel@willson.li.ssimo.org> <52E28B64.9010403@redhat.com> <1390579030.15404.140.camel@willson.li.ssimo.org> <52E29209.6040202@redhat.com> <1390580597.15404.142.camel@willson.li.ssimo.org> <52E605A6.5080507@redhat.com> <52E61614.1010701@redhat.com> <52E61DBF.20307@redhat.com> Message-ID: <52E620B3.8020206@redhat.com> On 01/27/2014 09:50 AM, Petr Viktorin wrote: > On 01/27/2014 09:17 AM, Petr Spacek wrote: >> On 27.1.2014 08:07, Martin Kosek wrote: >>> On 01/24/2014 05:23 PM, Simo Sorce wrote: >>>> On Fri, 2014-01-24 at 17:17 +0100, Petr Viktorin wrote: >>>>> On 01/24/2014 04:57 PM, Simo Sorce wrote: >>>>>> On Fri, 2014-01-24 at 16:48 +0100, Petr Viktorin wrote: >>> ... >>>>>> Technically we could alias the name so the attribute can be called >>>>>> either way, but that is not necessarily a good option either. >>>>> >>>>> If breaking master is unacceptable, we can use the old name instead. >>>>> ipaPermIncludedAttr is more consistent but ipaPermAllowedAttr isn't >>>>> downright wrong. >>>> >>>> Ok, let's hear other opinions, I see a lot f value in consistent naming, >>>> and not breaking a developer build is not that strong of a reason to >>>> have substandard naming I guess. What do others think ? >>>> >>>> Simo. >>> >>> Hmm, I obviously see things differently here. I would rather "break" >>> the master >>> and let developers running on the git version to reinstall the servers >>> (including myself) than to have to live with suboptimal attribute name >>> for ever >>> or by adding unnecessary cruft to the code... > > I think you got lost in the "not"s. You and Simo agree. Ah, I see - you are right (indeed to many nots). Martin From mkosek at redhat.com Mon Jan 27 09:08:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 27 Jan 2014 10:08:02 +0100 Subject: [Freeipa-devel] What is Changelog on wiki for? In-Reply-To: <52E61415.5080907@redhat.com> References: <52E2872B.6060304@redhat.com> <52E2892C.6090004@redhat.com> <52E2A6F4.9000908@redhat.com> <52E61415.5080907@redhat.com> Message-ID: <52E621F2.9040700@redhat.com> On 01/27/2014 09:08 AM, Petr Spacek wrote: > On 24.1.2014 18:46, Dmitri Pal wrote: >> On 01/24/2014 10:39 AM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> When working on release, this question comes to my mind every time - >>>> what is >>>> the following page good for? :) >>>> >>>> http://www.freeipa.org/page/Changelog >>>> >>>> To me, it is usually just an annoyance of the release process. You >>>> can simply >>>> get all the data with "git log" derivatives, so I do not see a point of >>>> maintaining this page. >>>> >>>> I see benefits of having shortlog in Release pages like [1], but not >>>> with this >>>> one. I am thus proposing to deprecate it. >>>> >>>> [1] http://www.freeipa.org/page/Releases/3.3.3 >>>> >>>> Thanks. >>>> >>> >>> I used to just cherry-pick the big things then figured that some >>> people care about everything so switched to that instead. Yes, the >>> data is in git, but if one doesn't know git well then it can be hard >>> to tell where something was fixed. >>> >>> I won't yell if it's dropped, but it's just a cut-n-paste after all. >> >> It is internet search-able and can be easily pointed to in different >> follow up materials. >> I would rather keep it, but a wiki formatting script might be a good idea. > > Our git repo has nice and responsive web interface: > https://git.fedorahosted.org/cgit/freeipa.git/ > > The advantage is that you can read full commit messages so you can see links to > tickets in Trac which are not present in shortlog. > > Given that I think that Changelog wiki page is mostly annoyance, it could > simply redirect to repo web interface (may be to listings for specific branches). Right, that was my thinking as well. The Changelog just duplicates information that is already internet-searchable in: * cgit * Mails and patches on freeipa-devel mailing list archive * Release specific Changelog excerpt in Release page Thus, I still do not see a reason in maintaining the huge Changelog page. Martin From tjaalton at ubuntu.com Mon Jan 27 11:17:37 2014 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Mon, 27 Jan 2014 13:17:37 +0200 Subject: [Freeipa-devel] =?utf-8?q?=5BPATCH=5D=C2=A0Debian_client_support?= In-Reply-To: <20131128202617.GA867@mail.corp.redhat.com> References: <5225066B.3010003@ubuntu.com> <20130905212516.GB24203@mail.corp.redhat.com> <20131128202617.GA867@mail.corp.redhat.com> Message-ID: <52E64051.5020404@ubuntu.com> On 28.11.2013 22:26, Lukas Slebodnik wrote: > On (05/09/13 23:25), Lukas Slebodnik wrote: >> On (03/09/13 00:43), Timo Aaltonen wrote: >>> >>> This fixes https://fedorahosted.org/freeipa/ticket/1887 >>> and >>> https://fedorahosted.org/freeipa/ticket/2455 >>> >>> the first three patches fix some bugs in how python is used >>> fourth patch checks if dbus is already running before trying to start it >>> fifth fixes some compilation warnings >>> sixth finally adds the Debian platform module >>> >>> >>> >>> there are also distro patches that aren't upstreamable as-is, that do >>> stuff like >>> - give--install-layout=deb to setup.py >>> - disable make-testcert since it needs a server running >>> - fix hardcoded NFS related paths and a variable in ipa-client-automount >>> - fix ldap.conf path in ipa-client-install >>> - fix ntpdate options in ntpconf.py (Debian doesn't patch ntpdate like >>> Fedora) >>> - change nss includes in ipa_pwd.c ( not ) >> Solution is simple. Use pkg-config generated NSS_CFLAGS >> >> bash$ pkg-config --cflags nss >> -I/usr/include/nss -I/usr/include/nspr >> bash$ uname -a >> Linux positron 3.10-2-686-pae #1 SMP Debian 3.10.5-1 (2013-08-07) i686 GNU/Linux >> >> bash$pkg-config --cflags nss >> -I/usr/include/nss3 -I/usr/include/nspr4 >> bash$uname -a >> Linux unused-4-233.brq.redhat.com 3.10.10-200.fc19.x86_64 #1 SMP Thu Aug 29 19:05:45 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux >> >> It works in sssd. I can send a patch. >> >> LS >> > Attached patch should fix problem with compilation on different distros. > > debian: > http://anonscm.debian.org/gitweb/?p=pkg-freeipa/freeipa.git;a=blob;f=debian/patches/fix-nss-include.diff;h=1dac0709ed7344c7546c55225365c9434e6a930a;hb=HEAD > arch: > https://github.com/chenxiaolong/ArchLinux-Packages/blob/master/freeipa/0006_Fix_nss_includes.patch > > Timo can you test patch on debian/ubuntu? finally did last week, so Tested-by: Timo Aaltonen From mkosek at redhat.com Mon Jan 27 11:32:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 27 Jan 2014 12:32:31 +0100 Subject: [Freeipa-devel] [PATCH] 454 Migration does not add users to default group Message-ID: <52E643CF.30906@redhat.com> When users with missing default group were searched, IPA suffix was not passed so these users were searched in a wrong base DN. Thus, no user was detected and added to default group. https://fedorahosted.org/freeipa/ticket/4141 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-454-migration-does-not-add-users-to-default-group.patch Type: text/x-patch Size: 2311 bytes Desc: not available URL: From jcholast at redhat.com Mon Jan 27 12:06:50 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 27 Jan 2014 13:06:50 +0100 Subject: [Freeipa-devel] [PATCH 0007] Limit memberOf and refInt DS plugins to main IPA suffix In-Reply-To: <52E0FDB8.2040806@redhat.com> References: <52E0FDB8.2040806@redhat.com> Message-ID: <52E64BDA.8060104@redhat.com> Hi, On 23.1.2014 12:32, Petr Spacek wrote: > Hello, > > this patch solves performance problems with retro change log trimming. > > It has to go to the same branches as Ana's patch 0079 Enable Retro > Changelog and Content Synchronization DS plugins. Nitpicks: -Requires: 389-ds-base >= 1.3.1.3 +Requires: 389-ds-base >= 1.3.2.10 Why 1.3.2.10? According to 389-ds-base changelog, all the required enhancements should be available in 1.3.2.9: https://fedorahosted.org/389/ticket/47526 https://fedorahosted.org/389/ticket/47527 https://fedorahosted.org/389/ticket/47621 -# Enable Retro changelog +# Enable Retro changelog - is is necessary for SyncRepl s/is is/it is/ Otherwise ACK. Honza -- Jan Cholasta From pviktori at redhat.com Mon Jan 27 13:41:31 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 27 Jan 2014 14:41:31 +0100 Subject: [Freeipa-devel] [PATCH 0007] Limit memberOf and refInt DS plugins to main IPA suffix In-Reply-To: <52E64BDA.8060104@redhat.com> References: <52E0FDB8.2040806@redhat.com> <52E64BDA.8060104@redhat.com> Message-ID: <52E6620B.2000605@redhat.com> On 01/27/2014 01:06 PM, Jan Cholasta wrote: > Hi, > > On 23.1.2014 12:32, Petr Spacek wrote: >> Hello, >> >> this patch solves performance problems with retro change log trimming. >> >> It has to go to the same branches as Ana's patch 0079 Enable Retro >> Changelog and Content Synchronization DS plugins. > > Nitpicks: > > -Requires: 389-ds-base >= 1.3.1.3 > +Requires: 389-ds-base >= 1.3.2.10 > > Why 1.3.2.10? According to 389-ds-base changelog, all the required > enhancements should be available in 1.3.2.9: > > https://fedorahosted.org/389/ticket/47526 > https://fedorahosted.org/389/ticket/47527 > https://fedorahosted.org/389/ticket/47621 According to Petr ?pa?ek things were broken in .9 so we do need the .10 > > > -# Enable Retro changelog > +# Enable Retro changelog - is is necessary for SyncRepl > > s/is is/it is/ > > > Otherwise ACK. Fixed the typo and pushed to master: 04627b72d6d6cbf3a9dadc614a532505e31957f5 -- Petr? From pspacek at redhat.com Mon Jan 27 13:52:05 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 27 Jan 2014 14:52:05 +0100 Subject: [Freeipa-devel] [PATCH 0008] Remove working directory for bind-dyndb-ldap plugin Message-ID: <52E66485.2060301@redhat.com> Hello, The working directory will be provided directly by bind-dyndb-ldap package. I'm testing the patch right now but I don't expect any problems. Please review this as soon as possible so we can release 3.3.4 ... -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0008-Remove-working-directory-for-bind-dyndb-ldap-plugin.patch Type: text/x-patch Size: 3177 bytes Desc: not available URL: From rcritten at redhat.com Mon Jan 27 14:32:15 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 27 Jan 2014 09:32:15 -0500 Subject: [Freeipa-devel] What is Changelog on wiki for? In-Reply-To: <52E61415.5080907@redhat.com> References: <52E2872B.6060304@redhat.com> <52E2892C.6090004@redhat.com> <52E2A6F4.9000908@redhat.com> <52E61415.5080907@redhat.com> Message-ID: <52E66DEF.4050000@redhat.com> Petr Spacek wrote: > On 24.1.2014 18:46, Dmitri Pal wrote: >> On 01/24/2014 10:39 AM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> When working on release, this question comes to my mind every time - >>>> what is >>>> the following page good for? :) >>>> >>>> http://www.freeipa.org/page/Changelog >>>> >>>> To me, it is usually just an annoyance of the release process. You >>>> can simply >>>> get all the data with "git log" derivatives, so I do not see a point of >>>> maintaining this page. >>>> >>>> I see benefits of having shortlog in Release pages like [1], but not >>>> with this >>>> one. I am thus proposing to deprecate it. >>>> >>>> [1] http://www.freeipa.org/page/Releases/3.3.3 >>>> >>>> Thanks. >>>> >>> >>> I used to just cherry-pick the big things then figured that some >>> people care about everything so switched to that instead. Yes, the >>> data is in git, but if one doesn't know git well then it can be hard >>> to tell where something was fixed. >>> >>> I won't yell if it's dropped, but it's just a cut-n-paste after all. >> >> It is internet search-able and can be easily pointed to in different >> follow up materials. >> I would rather keep it, but a wiki formatting script might be a good >> idea. > > Our git repo has nice and responsive web interface: > https://git.fedorahosted.org/cgit/freeipa.git/ > > The advantage is that you can read full commit messages so you can see > links to tickets in Trac which are not present in shortlog. > > Given that I think that Changelog wiki page is mostly annoyance, it > could simply redirect to repo web interface (may be to listings for > specific branches). > It is useful because you can more easily see what made it into the particular dot release rather than finding the patch you want then knowing to search backwards for the Become xx.yy commit. I saw it as a poor-man's way of finding changes. It gets updated 3 or 4 times a year, so it is hardly a burden. It is certainly duplicated information and I won't fight any further for it. rob From mkosek at redhat.com Mon Jan 27 14:42:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 27 Jan 2014 15:42:00 +0100 Subject: [Freeipa-devel] What is Changelog on wiki for? In-Reply-To: <52E66DEF.4050000@redhat.com> References: <52E2872B.6060304@redhat.com> <52E2892C.6090004@redhat.com> <52E2A6F4.9000908@redhat.com> <52E61415.5080907@redhat.com> <52E66DEF.4050000@redhat.com> Message-ID: <52E67038.1070509@redhat.com> On 01/27/2014 03:32 PM, Rob Crittenden wrote: > Petr Spacek wrote: >> On 24.1.2014 18:46, Dmitri Pal wrote: >>> On 01/24/2014 10:39 AM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> When working on release, this question comes to my mind every time - >>>>> what is >>>>> the following page good for? :) >>>>> >>>>> http://www.freeipa.org/page/Changelog >>>>> >>>>> To me, it is usually just an annoyance of the release process. You >>>>> can simply >>>>> get all the data with "git log" derivatives, so I do not see a point of >>>>> maintaining this page. >>>>> >>>>> I see benefits of having shortlog in Release pages like [1], but not >>>>> with this >>>>> one. I am thus proposing to deprecate it. >>>>> >>>>> [1] http://www.freeipa.org/page/Releases/3.3.3 >>>>> >>>>> Thanks. >>>>> >>>> >>>> I used to just cherry-pick the big things then figured that some >>>> people care about everything so switched to that instead. Yes, the >>>> data is in git, but if one doesn't know git well then it can be hard >>>> to tell where something was fixed. >>>> >>>> I won't yell if it's dropped, but it's just a cut-n-paste after all. >>> >>> It is internet search-able and can be easily pointed to in different >>> follow up materials. >>> I would rather keep it, but a wiki formatting script might be a good >>> idea. >> >> Our git repo has nice and responsive web interface: >> https://git.fedorahosted.org/cgit/freeipa.git/ >> >> The advantage is that you can read full commit messages so you can see >> links to tickets in Trac which are not present in shortlog. >> >> Given that I think that Changelog wiki page is mostly annoyance, it >> could simply redirect to repo web interface (may be to listings for >> specific branches). >> > > It is useful because you can more easily see what made it into the particular > dot release rather than finding the patch you want then knowing to search > backwards for the Become xx.yy commit. I saw it as a poor-man's way of finding > changes. Ok, though I still think that git and cgit should be the authoritative source of searches like this... > It gets updated 3 or 4 times a year, so it is hardly a burden. 3-4 times? I see 19 updates happening in 2013 in this page. With each release (even a minor one) we do, we need to do prepare shortlog, apply wiki and the specific date format and paste it here. > > It is certainly duplicated information and I won't fight any further for it. > > rob Noted :) Martin From pviktori at redhat.com Mon Jan 27 15:02:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 27 Jan 2014 16:02:34 +0100 Subject: [Freeipa-devel] What is Changelog on wiki for? In-Reply-To: <52E66DEF.4050000@redhat.com> References: <52E2872B.6060304@redhat.com> <52E2892C.6090004@redhat.com> <52E2A6F4.9000908@redhat.com> <52E61415.5080907@redhat.com> <52E66DEF.4050000@redhat.com> Message-ID: <52E6750A.2020300@redhat.com> On 01/27/2014 03:32 PM, Rob Crittenden wrote: [...] > It is useful because you can more easily see what made it into the > particular dot release rather than finding the patch you want then > knowing to search backwards for the Become xx.yy commit. I saw it as a > poor-man's way of finding changes. I think a "poor man" can open up the individual Release notes and look there. And a "rich man" (who has the repo cloned) can just use Git. $ git log -i --grep 'drop selinux' commit ad6abdb576b2ebeb941eb99fd141bf78918143c1 Author: Martin Kosek Date: Thu Jun 13 14:40:52 2013 +0200 Drop SELinux subpackage All SELinux policy needed by FreeIPA server is now part of the global system SELinux policy which makes the subpackage redundant and slowing down the installation. This patch drops it. https://fedorahosted.org/freeipa/ticket/3683 https://fedorahosted.org/freeipa/ticket/3684 $ git tag --contains ad6abdb576b2ebeb941eb99fd141bf78918143c1 beta_1-3-3-0 beta_2-3-3-0 release-3-3-0 release-3-3-1 release-3-3-2 release-3-3-3 -- Petr? From pviktori at redhat.com Mon Jan 27 15:05:30 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 27 Jan 2014 16:05:30 +0100 Subject: [Freeipa-devel] [PATCH 0008] Remove working directory for bind-dyndb-ldap plugin In-Reply-To: <52E66485.2060301@redhat.com> References: <52E66485.2060301@redhat.com> Message-ID: <52E675BA.6030507@redhat.com> On 01/27/2014 02:52 PM, Petr Spacek wrote: > Hello, > > The working directory will be provided directly > by bind-dyndb-ldap package. > > I'm testing the patch right now but I don't expect any problems. Please > review this as soon as possible so we can release 3.3.4 ... ACK, pushed to master: c91936353865ecb03b06e2a558c370e6a50fa0dc -- Petr? From mkosek at redhat.com Mon Jan 27 15:53:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 27 Jan 2014 16:53:00 +0100 Subject: [Freeipa-devel] What is Changelog on wiki for? In-Reply-To: <52E6750A.2020300@redhat.com> References: <52E2872B.6060304@redhat.com> <52E2892C.6090004@redhat.com> <52E2A6F4.9000908@redhat.com> <52E61415.5080907@redhat.com> <52E66DEF.4050000@redhat.com> <52E6750A.2020300@redhat.com> Message-ID: <52E680DC.2090400@redhat.com> On 01/27/2014 04:02 PM, Petr Viktorin wrote: > On 01/27/2014 03:32 PM, Rob Crittenden wrote: > [...] >> It is useful because you can more easily see what made it into the >> particular dot release rather than finding the patch you want then >> knowing to search backwards for the Become xx.yy commit. I saw it as a >> poor-man's way of finding changes. > > I think a "poor man" can open up the individual Release notes and look there. > > > And a "rich man" (who has the repo cloned) can just use Git. > > $ git log -i --grep 'drop selinux' > commit ad6abdb576b2ebeb941eb99fd141bf78918143c1 > Author: Martin Kosek > Date: Thu Jun 13 14:40:52 2013 +0200 > > Drop SELinux subpackage > > All SELinux policy needed by FreeIPA server is now part of the global > system SELinux policy which makes the subpackage redundant and slowing > down the installation. This patch drops it. > > https://fedorahosted.org/freeipa/ticket/3683 > https://fedorahosted.org/freeipa/ticket/3684 > > $ git tag --contains ad6abdb576b2ebeb941eb99fd141bf78918143c1 > beta_1-3-3-0 > beta_2-3-3-0 > release-3-3-0 > release-3-3-1 > release-3-3-2 > release-3-3-3 I couldn't say it better. Let's drop the manual changelog and use some modern way to do it - case is closed. Martin From simo at redhat.com Mon Jan 27 16:23:54 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 27 Jan 2014 11:23:54 -0500 Subject: [Freeipa-devel] What is Changelog on wiki for? In-Reply-To: <52E680DC.2090400@redhat.com> References: <52E2872B.6060304@redhat.com> <52E2892C.6090004@redhat.com> <52E2A6F4.9000908@redhat.com> <52E61415.5080907@redhat.com> <52E66DEF.4050000@redhat.com> <52E6750A.2020300@redhat.com> <52E680DC.2090400@redhat.com> Message-ID: <1390839834.15404.267.camel@willson.li.ssimo.org> On Mon, 2014-01-27 at 16:53 +0100, Martin Kosek wrote: > On 01/27/2014 04:02 PM, Petr Viktorin wrote: > > On 01/27/2014 03:32 PM, Rob Crittenden wrote: > > [...] > >> It is useful because you can more easily see what made it into the > >> particular dot release rather than finding the patch you want then > >> knowing to search backwards for the Become xx.yy commit. I saw it as a > >> poor-man's way of finding changes. > > > > I think a "poor man" can open up the individual Release notes and look there. > > > > > > And a "rich man" (who has the repo cloned) can just use Git. > > > > $ git log -i --grep 'drop selinux' > > commit ad6abdb576b2ebeb941eb99fd141bf78918143c1 > > Author: Martin Kosek > > Date: Thu Jun 13 14:40:52 2013 +0200 > > > > Drop SELinux subpackage > > > > All SELinux policy needed by FreeIPA server is now part of the global > > system SELinux policy which makes the subpackage redundant and slowing > > down the installation. This patch drops it. > > > > https://fedorahosted.org/freeipa/ticket/3683 > > https://fedorahosted.org/freeipa/ticket/3684 > > > > $ git tag --contains ad6abdb576b2ebeb941eb99fd141bf78918143c1 > > beta_1-3-3-0 > > beta_2-3-3-0 > > release-3-3-0 > > release-3-3-1 > > release-3-3-2 > > release-3-3-3 > > I couldn't say it better. Let's drop the manual changelog and use some modern > way to do it - case is closed. May be you can stick into the Release notes page the actual query that gives you the changelog from cgit ? It should probably be https://git.fedorahosted.org/cgit/freeipa.git/log/?qt=range&q=release-3.3.2..release-3.3.3 But at the moment it returns an internal server error, I will ask on fedora-admin Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Mon Jan 27 16:30:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 27 Jan 2014 17:30:14 +0100 Subject: [Freeipa-devel] What is Changelog on wiki for? In-Reply-To: <1390839834.15404.267.camel@willson.li.ssimo.org> References: <52E2872B.6060304@redhat.com> <52E2892C.6090004@redhat.com> <52E2A6F4.9000908@redhat.com> <52E61415.5080907@redhat.com> <52E66DEF.4050000@redhat.com> <52E6750A.2020300@redhat.com> <52E680DC.2090400@redhat.com> <1390839834.15404.267.camel@willson.li.ssimo.org> Message-ID: <52E68996.5070300@redhat.com> On 01/27/2014 05:23 PM, Simo Sorce wrote: > On Mon, 2014-01-27 at 16:53 +0100, Martin Kosek wrote: >> On 01/27/2014 04:02 PM, Petr Viktorin wrote: >>> On 01/27/2014 03:32 PM, Rob Crittenden wrote: >>> [...] >>>> It is useful because you can more easily see what made it into the >>>> particular dot release rather than finding the patch you want then >>>> knowing to search backwards for the Become xx.yy commit. I saw it as a >>>> poor-man's way of finding changes. >>> >>> I think a "poor man" can open up the individual Release notes and look there. >>> >>> >>> And a "rich man" (who has the repo cloned) can just use Git. >>> >>> $ git log -i --grep 'drop selinux' >>> commit ad6abdb576b2ebeb941eb99fd141bf78918143c1 >>> Author: Martin Kosek >>> Date: Thu Jun 13 14:40:52 2013 +0200 >>> >>> Drop SELinux subpackage >>> >>> All SELinux policy needed by FreeIPA server is now part of the global >>> system SELinux policy which makes the subpackage redundant and slowing >>> down the installation. This patch drops it. >>> >>> https://fedorahosted.org/freeipa/ticket/3683 >>> https://fedorahosted.org/freeipa/ticket/3684 >>> >>> $ git tag --contains ad6abdb576b2ebeb941eb99fd141bf78918143c1 >>> beta_1-3-3-0 >>> beta_2-3-3-0 >>> release-3-3-0 >>> release-3-3-1 >>> release-3-3-2 >>> release-3-3-3 >> >> I couldn't say it better. Let's drop the manual changelog and use some modern >> way to do it - case is closed. > > May be you can stick into the Release notes page the actual query that > gives you the changelog from cgit ? > > It should probably be > https://git.fedorahosted.org/cgit/freeipa.git/log/?qt=range&q=release-3.3.2..release-3.3.3 > > But at the moment it returns an internal server error, I will ask on > fedora-admin > > Simo. I can do that. Just note that the between-versions diff changelog in Release notes stays, we are just discussing removing the global one [1]. Martin [1] http://www.freeipa.org/page/Changelog From pviktori at redhat.com Tue Jan 28 11:02:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 28 Jan 2014 12:02:34 +0100 Subject: [Freeipa-devel] [PATCHES] 0455-0459 Add support for managed permissions In-Reply-To: <52E28B64.9010403@redhat.com> References: <52CD738A.40105@redhat.com> <52DF8F0E.9020705@redhat.com> <52E0FBEC.2020303@redhat.com> <52E109CA.2020605@redhat.com> <1390484550.15404.79.camel@willson.li.ssimo.org> <52E28B64.9010403@redhat.com> Message-ID: <52E78E4A.2050001@redhat.com> On 01/24/2014 04:48 PM, Petr Viktorin wrote: > On 01/23/2014 02:42 PM, Simo Sorce wrote: >> On Thu, 2014-01-23 at 13:23 +0100, Petr Viktorin wrote: >>> On 01/23/2014 12:24 PM, Martin Kosek wrote: >>>> On 01/22/2014 10:27 AM, Petr Viktorin wrote: >>>>> On 01/08/2014 04:49 PM, Petr Viktorin wrote: >>>>>> Hello, >>>>>> This adds "managed" permissions, the framework that will make our >>>>>> default permissions merge IPA updates and user changes sanely. >>>>>> >>>>>> There is no updater yet, nor does this add any actual managed >>>>>> permissions, so there's no user-visible change (beyond help text >>>>>> and a >>>>>> disabled option). To test the patch you might need to touch LDAP >>>>>> directly. >>>>>> >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4033 >>>>>> Design (no updater & plugin changes yet): >>>>>> http://www.freeipa.org/page/V3/Managed_Read_permissions >>>>>> >>>>>> 0447 - Minor fixes. >>>>>> 0448 - Since you can't create managed permissions through the API, I >>>>>> needed to get creative with the declarative tests. The tests will >>>>>> need a >>>>>> custom function that adds a managed perm. >>>>>> 0449 - The change itself. >>>>> >>>>> ping; any thoughts on this one? >>>>> >>>>> >>>> >>>> 1) 449, the comment: >>>> >>>> +Deleting or renaming a managed permission, as well as changing its >>>> target, >>>> +is not supported. >>>> +""") + _(""" >>>> >>>> I am not sure that the phrase "not supported" is the right one. It >>>> sounds to me >>>> like this is something we want to allow, just not implemented yet. >>>> IMO "is not >>>> allowed" would be better. >>> >>> Makes sense. >>> >>>> 2) Can you add allow_mod_for_managed flag description to parameters.py? >>>> >>>> + flags={'no_create', 'allow_mod_for_managed'}, >>>> >>>> So far we try to add all flag descriptions there. >>> >>> OK >>> >>>> 3) When I updated the test to not delete the testperm, I tried to >>>> show the >>>> managed permission and it is not entirely clear, see: >>>> >>>> # ipa permission-show testperm >>>> Permission name: testperm >>>> Permissions: write >>>> * Attributes: cn, o, sn >>>> * Excluded attributes: cn, sn >>>> Bind rule type: all >>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>>> Type: user >>>> * Default attributes: l, o, cn >>>> * Effective attributes: l, o >>> >>> Well, this is a tradeoff between presenting what's stored in LDAP and >>> what's in the ACI. >>> >>>> The "Attributes" mean actually attributes explicitly allowed by >>>> user, but it is >>>> not obvious from the output. >>>> >>>> Maybe it would be better to return only "Effective attributes" by >>>> default and >>>> return the 3 source lists only when --all is passed. But this would >>>> require us >>>> to let Command override LDAPObject's default_attributes, which >>>> framework cannot do. >>> >>> Modifying default_attributes would not work because the 3 lists need to >>> be loaded from LDAP to determine the effective attributes. >>> It's possible to remove the extra attributes in the post_callback, >>> postprocess_result already does similar output manipulation. >>> >>>> Alternatively, we may choose to use the attributes differently with >>>> managed >>>> permissions: >>>> - we add the new attributeType "ipaPermIncludedAttr". It would be >>>> used for the >>>> user-specified whitelist of attributes instead of ipaPermAllowedAttr >>>> - we do not use the ipaPermAllowedAttr with managed attributes at >>>> all or use it >>>> for the "Effective attributes" list >>>> >>>> My point is that the semantics of ipaPermAllowedAttr is different >>>> for managed >>>> and non-managed permission, so it may confuse people. >>> >>> Well, the semantics are always the same (effective = (default | allowed) >>> - excluded). I agree that it can be confusing; perhaps I'm in too deep >>> to judge how it looks from the outside. >>> >>>> For example, you may want >>>> to search for all permissions that allow attribute "sn": >>>> >>>> # ipa permission-find --attrs sn >>>> --------------------- >>>> 4 permissions matched >>>> --------------------- >>>> Permission name: anon >>>> Permissions: read >>>> Attributes: sn >>>> Bind rule type: anonymous >>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>>> Type: user >>>> ... >>>> Permission name: testperm >>>> Permissions: write >>>> Attributes: cn, o, sn >>>> Excluded attributes: cn, sn >>>> Bind rule type: anonymous >>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>>> Type: user >>>> Default attributes: l, o, cn >>>> Effective attributes: l, o >>>> ... >>>> >>>> As you see, it matched both testperm and anon even though testperm >>>> does not >>>> really allow sn as it excluded. >>>> >>>> Thoughts? >>> >>> Well, we could have default, included, excluded attributes stored in >>> LDAP as now (using the name "included" instead of "allowed"), and make >>> effective attributes (--attrs) into an updatable virtual attribute: when >>> setting it, IPA would consult the "default" attributes and update >>> "included"/"excluded" accordingly. (With non-managed permissions >>> "default" is empty, so only "included" would be updated.) And searching >>> on --attrs would construct an appropriate filter. >>> >>> I thought about this approach earlier but thought that it obscured >>> what's actually stored in LDAP. Given recent discussions I'm now >>> thinking I shouldn't have rejected it. >> >> >> I would take a consistent approach indeed. >> I do not much care for the virtual attribute part in LDAP, as long as >> our tool show prominently the effective list. >> And also as long as all permissions behave the same way in the general >> mechanism in LDAP. >> >> Simo. >> > > All right. Here are patches; I'll start updating the design page. > > **NOTE** > This renames the 'ipaPermAllowedAttr' attribute to > 'ipaPermIncludedAttr'. Upgrades from master will fail, so please install > a new server. Of course no released versions of FreeIPA are affected. > I assume there's no clean way to rename an attribute without changing > the OID? Is it OK to break master this way? > > As before three source lists are stored in LDAP: > - ipaPermDefaultAttr > - ipaPermIncludedAttr (--includedattrs) > - ipaPermExcludedAttr (--excludedattrs) > > Setting --attrs ("Effective Attributes") will set the included/excluded > attributes based on the default set. > For normal permissions, default & excluded will be empty, and in this > case only effective attributes will be displayed on output (unless --all > or --raw is given). > > > > I've added some preparatory patches for #4074 to this batch, mostly to > prevent rebase conflicts with that work. Re-numbering for a sane order. > > Apply on top of my patch 0452 > > 0455 - minor fixes, unchanged from 0447 > > 0456 - converting options on the server it will allow us to consult the > entry's existing state. Arguably it's also cleaner to use execute than > args_options_2_params for this. > > 0457 - generate ACIs in the plugin. This is the next step in obsoleting > the ACI class, which in the end should only be necessary for updating > old-style ACIs. The one-way function should be easier to maintain and > extend. > > 0458 - allow callables in declarative tests, unchanged from 0448 > > 0459 - managed permissions > > > Or: git pull https://github.com/encukou/freeipa 3566-managed-perms > commit 51bb7f27516202a062ffa25fedae18d0e9f302b6 I've updated the design pages. http://www.freeipa.org/page/V3/Managed_Read_permissions http://www.freeipa.org/page/V3/Permissions_V2 http://www.freeipa.org/page/V3/Managed_Read_permissions/tests -- Petr? From pviktori at redhat.com Tue Jan 28 13:18:22 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 28 Jan 2014 14:18:22 +0100 Subject: [Freeipa-devel] [PATCH] 454 Migration does not add users to default group In-Reply-To: <52E643CF.30906@redhat.com> References: <52E643CF.30906@redhat.com> Message-ID: <52E7AE1E.8090508@redhat.com> On 01/27/2014 12:32 PM, Martin Kosek wrote: > When users with missing default group were searched, IPA suffix was > not passed so these users were searched in a wrong base DN. Thus, > no user was detected and added to default group. > > https://fedorahosted.org/freeipa/ticket/4141 This needs a rebase for the new LDAP API. I don't see the need for the second change, caching of len(new_members). On lists, len() is extremely fast. If you want to optimize, convert the list of existing members to a set before the for loop, instead of getting it from the entry and using the `in` operator (which is O(N) on lists) every time. Nitpicks: Instead of "if len(container) > 0:" you should just use "if container:" (see PEP8). Instead of: members = group_entry_attrs.get('member', []) ... group_entry_attrs['member'] = members you can use: members = group_entry_attrs.setdefault('member', []) ... -- Petr? From pviktori at redhat.com Tue Jan 28 13:44:32 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 28 Jan 2014 14:44:32 +0100 Subject: [Freeipa-devel] [PATCH] 236 Log unhandled exceptions in certificate renewal scripts In-Reply-To: <52E12B7C.5020204@redhat.com> References: <52E12B7C.5020204@redhat.com> Message-ID: <52E7B440.8070306@redhat.com> On 01/23/2014 03:47 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza This needs a rebase for the new LDAP API. -- Petr? From pviktori at redhat.com Tue Jan 28 14:35:03 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 28 Jan 2014 15:35:03 +0100 Subject: [Freeipa-devel] [PATCHES] 0453-0454 Test fixes In-Reply-To: <52E11122.3060401@redhat.com> References: <52E11122.3060401@redhat.com> Message-ID: <52E7C017.3090407@redhat.com> On 01/23/2014 01:54 PM, Petr Viktorin wrote: > Hello, > > RHEL 5 runs `clear` from /root/.bash_logout. The tests use a login > session without an attached TTY. This makes `clear` complain about > missing $TERM and fail the whole shell session. > Rather than adding a special fix upstream, cleaning /root/.bash_logout > will be a responsibility of whoever runs the tests. > I've noted this on http://www.freeipa.org/page/Testing#Running_the_Tests. > I'm of course willing to reconsider if any cutting-edge distros have > problems. > > Patch 453 will make diagnosing situations like this easier. > Related to: https://fedorahosted.org/freeipa/ticket/4109 Tom?? is working on a fix for [#4132] that will replace this patch, so I'm withdrawing it. [#4132] https://fedorahosted.org/freeipa/ticket/4132 > Patch 454 changes the cert generation script for CA-less tests to use > sequential serial numbers rather than random ones, to prevent collisions. This one is still useful though. -- Petr? From mkosek at redhat.com Tue Jan 28 15:31:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 28 Jan 2014 16:31:50 +0100 Subject: [Freeipa-devel] Announcing FreeIPA 3.3.4 Message-ID: <52E7CD66.4060706@redhat.com> The FreeIPA team is proud to announce FreeIPA v3.3.4! It can be downloaded from http://www.freeipa.org/page/Downloads. Fedora 19 and Fedora 20 builds are already on their way to updates-testing repo. == Highlights in 3.3.4 == === Enhancements === * New Web UI for trusted domain subdomain management * trustdomain-find now shows status (enabled/disabled) of trusted domain subdomains * group-show command now shows external user's name instead of raw SID * FreeIPA is now built with hardening enabled (PIE, RELRO) * Added support for kernel keyring CCACHEs === Bug fixes === * ipa-server-install no longer crashes when freeipa-server-trust-ad package is not installed on the system * ipa-replica-manage no longer crashes when winsync agreement is being created * CLDAP plugin now correctly handles long hostnames and does not create invalid NetBIOS name * FreeIPA now builds on PPC and s390 platforms * PKI subsystem certificate renewal no longer crash on FreeIPA replicas * hbac-test command works for external users again * sudoOrder attribute is now present in ou=sudoers LDAP tree * trust-fetch-domains command now creates ID ranges for child domains * Trust can be now re-established even when it contains subdomains * Default Kerberos password policy reference (krbpwdpolicyreference) is no longer added to new user's entry. The default policy is now rather hard coded in the Kerberos backend to achieve the same behavior for both standard FreeIPA users and winsync users * dnsrecord-mod no longer produces API version warning * ... and numerous other small fixes === Test improvements === * Support external names for hosts * Various small fixes related to legacy client feature testing === Interface changes === * trust-resolve command was hidden from CLI as internal, given that group-show command now shows external user's name instead of raw SID == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-upgradeconfig # ipa-ldap-updater --upgrade Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 2.2.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 3.3.3 == === Alexander Bokovoy (10) === * Guard import of adtrustinstance for case without trusts * Map NT_STATUS_INVALID_PARAMETER to most likely error cause: clock skew * subdomains: Use AD admin credentials when trust is being established * trust: fix get_dn() to distinguish creating and re-adding trusts * trust-fetch-domains: create ranges for new child domains * trustdomain-find: report status of the (sub)domain * ipaserver/install/installutils: clean up properly after yield * group-show: resolve external members of the groups * ipa-adtrust-install: configure host netbios name by default * ipasam: delete trusted child domains before removing the trust === Ana Krivokapic (1) === * Fix regression which prevents creating a winsync agreement === Jan Cholasta (9) === * Remove mod_ssl port workaround. * Use hardening flags for ipa-optd. * Own /usr/share/ipa/ui/js/ in the spec file. * Prevent garbage from readline on standard output of dogtag-ipa-retrieve-agent. * PKI service restart after CA renewal failed * Fix ipa-client-automount uninstall when fstore is empty. * Do not start the service in stopped_service if it was not running before. * Increase service startup timeout default. * Fix ntpd config on clients. === Krzysztof Klimonda (1) === * Fix -Wformat-security warnings === Martin Basti (1) === * Added warning if cert '/etc/ipa/ca.crt' exists === Martin Kosek (12) === * Server does not detect different server and IPA domain * Allow kernel keyring CCACHE when supported * Increase Java stack size on PPC platforms * Increase Java stack size on s390 platforms * Revert restart scripts file permissions change * hbactest does not work for external users * sudoOrder missing in sudoers * Add missing example to sudorule * Remove missing VERSION warning in dnsrecord-mod * Hide trust-resolve command * ntpconf: remove redundant comment * Become IPA 3.3.4 === Petr Viktorin (5) === * Revert "Remove mod_ssl port workaround." * test_integration: Support external names for hosts * test_integration: Log external hostname in Host.ldap_connect * test_webui: Allow False values in configuration for no_ca, no_dns, has_trusts * cli.print_attribute: Convert values to strings === Petr Vobornik (4) === * Fix license in some Web UI files * Increase stack size for Web UI builder * Remove SID resolve call from Web UI * Trust domains Web UI === Rob Crittenden (1) === * Change the way we determine if the host has a password set. === Simo Sorce (3) === * Fix license tag in python setup files * Harmonize policy discovery to kdb driver * Stop adding a default password policy reference === Sumit Bose (3) === * CLDAP: do not prepend \\ * CLDAP: generate NetBIOS name like ipa-adtrust-install does * CLDAP: add unit tests for make_netbios_name === Tomas Babej (6) === * trusts: Do not pass base-id to the subdomain ranges * trusts: Always stop and disable smb service on uninstall * ipa-client-install: Always pass hostname to the ipa-join * ipa-cldap: Cut NetBIOS name after 15 characters * ipatests: Remove sudo calls from tasks * ipatests: Check for legacy_client attribute presence if unapplying fixes From pspacek at redhat.com Tue Jan 28 15:37:47 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 28 Jan 2014 16:37:47 +0100 Subject: [Freeipa-devel] [PATCH 0219] Prevent crash if working directory for zone cannot be created Message-ID: <52E7CECB.1090609@redhat.com> Hello, Prevent crash if working directory for zone cannot be created. This patch should go to master branch before 4.0 release. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0219-Prevent-crash-if-working-directory-for-zone-cannot-b.patch Type: text/x-patch Size: 969 bytes Desc: not available URL: From pspacek at redhat.com Tue Jan 28 15:45:42 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 28 Jan 2014 16:45:42 +0100 Subject: [Freeipa-devel] [PATCH 0220] Move temporary files to /var/named/dyndb-ldap directory Message-ID: <52E7D0A6.7030300@redhat.com> Hello, Move temporary files to /var/named/dyndb-ldap directory. This should make RPM packaging easier. This patch should go to master branch before 4.0 release. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0220-Move-temporary-files-to-var-named-dyndb-ldap-directo.patch Type: text/x-patch Size: 5713 bytes Desc: not available URL: From lslebodn at redhat.com Tue Jan 28 19:56:57 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 28 Jan 2014 20:56:57 +0100 Subject: [Freeipa-devel] [PATCH] Fix linking ipa-otpd with broken hardened build Message-ID: <20140128195656.GA31235@mail.corp.redhat.com> ehlo, How to test: -remove line "%define _hardened_build 1" from spec file -build freeeipa package (it should fail) -apply patch -build freeeipa package (it should work ) simple patch attached. LS -------------- next part -------------- >From 0ae1582770706f5a88980c0a16d4c64ce58c98e2 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Tue, 28 Jan 2014 19:58:40 +0100 Subject: [PATCH] Fix linking ipa-otpd with broken hardened build If there is problem with _hardened_build in rpm extra flag will not be included into CLFAGS and LDFLAGS ("-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1" ) and it will cause problem with linking binary ipa-otpd. /usr/bin/ld: bind.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC bind.o: error adding symbols: Bad value ipa-otpd will be linked successfully with this patch even if there is problem with hardened build on fedora. Resolves: https://fedorahosted.org/freeipa/ticket/4142 --- daemons/ipa-otpd/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daemons/ipa-otpd/Makefile.am b/daemons/ipa-otpd/Makefile.am index f0b75284dbbd46265a6ff366a7846da63c935986..0716e75b72cb7fb3910350fc0f9439a23c0bcf29 100644 --- a/daemons/ipa-otpd/Makefile.am +++ b/daemons/ipa-otpd/Makefile.am @@ -1,4 +1,4 @@ -AM_CFLAGS := $(CFLAGS) @LDAP_CFLAGS@ @LIBVERTO_CFLAGS@ +AM_CFLAGS := $(CFLAGS) @LDAP_CFLAGS@ @LIBVERTO_CFLAGS@ -fPIE AM_LDFLAGS := $(LDFLAGS) @LDAP_LIBS@ @LIBVERTO_LIBS@ @KRAD_LIBS@ -pie -Wl,-z,relro -Wl,-z,now noinst_HEADERS = internal.h -- 1.8.5.3 From pviktori at redhat.com Tue Jan 28 19:57:33 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 28 Jan 2014 20:57:33 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52E1167B.9050605@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> Message-ID: <52E80BAD.7010400@redhat.com> On 01/23/2014 02:17 PM, Petr Viktorin wrote: > On 01/22/2014 08:04 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 01/20/2014 05:21 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 01/17/2014 10:24 PM, Rob Crittenden wrote: >>>>>> Implement an IPA RESTful Foreman-compatible smart proxy. This exposes >>>>>> hosts and hostgroups via an unauthenticated REST API. The idea is >>>>>> that >>>>>> this service runs on the Foreman server and only listens on local >>>>>> ports. >>>>>> >>>>>> It is a CherryPy-based server and that handles the majority of REST >>>>>> for us. >>>>>> >>>>>> I included some tests, they can be executed with: nosetests -v >>>>>> smartproxy/tests >>>>> >>>>> Why is it not a part of ipatests? >>>> >>>> I can move it if it's a show-stopper. It seemed specific to this one >>>> directory so I stuck it there. It isn't relevant for most testing and >>>> requires some manual configuration (though CI could handle it). >>> >>> Not strictly a show stopper, but please move it. At the very least it >>> should end up in the freeipa-tests package. >> >> Moved. > > Thanks! > >>> A lot of the tests (integration, webUI) need manual configuration, so >>> this would be no exception. Of course the tests should be skipped if the >>> configuration was not done, and the config instructions should be added >>> to/linked from http://www.freeipa.org/page/Testing >> >> Hmm, maybe. There are instructions to set up the environment in the man >> page. Testing beyond that consists of ./make-test tests/test_smartproxy >> >> I can add that testing bit once the patch is approved I suppose. >> >> rob > > Please add python-kerberos >= 1.1-13 to Requires and BuildRequires; > pylint fails with lower versions. > Are there plans to release python-kerberos-1.1-13.fc20, or will this be > f21+ only? > I've noticed gssproxy-0.3.1 is not available in rawhide (but it is in f20). I've sent a mail to G?nther; meanwhile I'll use the f20 package (may the releng gods be merciful). Here are my thoughts on the patch. The URL endpoint /ipa/rest suggests that if we implement a complete REST API for IPA it would live here. Is the API supposed to be future-compatible? (The API itself seems to be a good subset of a complete REST API, but can we easily add an frontend with authentication, i18n, etc. here later, and keep the limitations for unauthenticated access?) Perhaps /ipa/smartproxy would be a better choice? I assume we're in control of the REST API design. Is that correct? According to RFC 2616, the POST verb should create a sub-resource of what's at the given URI. In other words, it would be more correct to use: /ipa/rest/host POST Create a host entry {'hostname': ...} and same for hostgroup. Foreman's DHCP and DNS APIs seem to do this right. Is returning HTML for errors a Foreman requirement? I think it's a weird thing to do in an API. I don't think IPACommand should be a class. It has no state, and it looks to me like if one of GET/POST/DELETE happens to not be overridden in an exposed subclass, there's a potential security issue -- any IPA command can be called. Could you use simple functions instead? In IPACommand.Command, there's lot of duplicate error handling blocks. You can handle more error classes at once with: except (errors.DuplicateEntry, errors.DNSNotARecordError) as e: Instead of `str(e)`, please report the errors as "{e.__class__.__name__}: {e}" -- the message is sometimes unusable without the exception type (e.g. a KeyError from {}['result'] would only have 'result' as message). Passing *args, **options to Command closes the door for any (future) parametrization. Consider making the signature e.g. Command(self, command, args, options, success_stastus=200). Instead of `if fqdn == None:` use `if fqdn is None:`. It would be great if you passed `api` around explicitly, instead of relying on the global instance. Some import issues in test_smartproxy/resttest.py: resttest.py:24:8: Unused import 'sys' resttest.py:25:8: Unused import 'socket' resttest.py:26:8: Unused import 'nose' `requests` is a third-party library, python-requests in Fedora; it should be in the specfile. (Dogtag pulls it in for now, but when ipa-server-ca is a separate package things will break.) According to PEP8: > Imports should be grouped in the following order: > 1. standard library imports > 2. related third party imports > 3. local application/library specific imports [ipa* in our case] > You should put a blank line between each group of imports. Normally I'm not pedantic about this, but it does help spotting mistakes like the above. I'm not a fan of the test code copied from test_xmlrpc, but I guess we have better things to do than refactoring that :( But there should at least be a check that skips the tests if the smart proxy is not available. In the ipa-rest man page, "Add this to the top of the file, before any other services" doesn't specify what file should be edited. Also, maybe the page should mention that `systemd start ipa-rest.service` starts the server on port 8090. It's probably an error at my side, but I couldn't get a response from the server: I got: The server encountered an unexpected condition which prevented it from fulfilling the request. and in the log I see: CCacheError: did not receive Kerberos credentials I'm not familiar with gssproxy, but I don't see how it knows that it should authenticate as the "rest" user. Should /var/log/ipa-rest.errors be world-readable? What is gssproxy.conf.snippet for? The same info is in the man page. Also please fix: ./ipalib/util.py:61:56: E703 statement ends with a semicolon ./ipalib/util.py:63:54: E703 statement ends with a semicolon -- Petr? From lslebodn at redhat.com Tue Jan 28 19:59:22 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 28 Jan 2014 20:59:22 +0100 Subject: [Freeipa-devel] [PATCH] Fix linking ipa-otpd with broken hardened build In-Reply-To: <20140128195656.GA31235@mail.corp.redhat.com> References: <20140128195656.GA31235@mail.corp.redhat.com> Message-ID: <20140128195921.GB31235@mail.corp.redhat.com> On (28/01/14 20:56), Lukas Slebodnik wrote: >ehlo, > >How to test: > -remove line "%define _hardened_build 1" from spec file > -build freeeipa package (it should fail) > -apply patch > -build freeeipa package (it should work ) > >simple patch attached. > >LS >>From 0ae1582770706f5a88980c0a16d4c64ce58c98e2 Mon Sep 17 00:00:00 2001 >From: Lukas Slebodnik >Date: Tue, 28 Jan 2014 19:58:40 +0100 >Subject: [PATCH] Fix linking ipa-otpd with broken hardened build > >If there is problem with _hardened_build in rpm extra flag will not be included >into CLFAGS and LDFLAGS ("-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1" ) >and it will cause problem with linking binary ipa-otpd. > >/usr/bin/ld: bind.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be >used when making a shared object; recompile with -fPIC >bind.o: error adding symbols: Bad value > >ipa-otpd will be linked successfully with this patch even if there is problem >with hardened build on fedora. > >Resolves: >https://fedorahosted.org/freeipa/ticket/4142 >--- > daemons/ipa-otpd/Makefile.am | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/daemons/ipa-otpd/Makefile.am b/daemons/ipa-otpd/Makefile.am >index f0b75284dbbd46265a6ff366a7846da63c935986..0716e75b72cb7fb3910350fc0f9439a23c0bcf29 100644 >--- a/daemons/ipa-otpd/Makefile.am >+++ b/daemons/ipa-otpd/Makefile.am >@@ -1,4 +1,4 @@ >-AM_CFLAGS := $(CFLAGS) @LDAP_CFLAGS@ @LIBVERTO_CFLAGS@ >+AM_CFLAGS := $(CFLAGS) @LDAP_CFLAGS@ @LIBVERTO_CFLAGS@ -fPIE > AM_LDFLAGS := $(LDFLAGS) @LDAP_LIBS@ @LIBVERTO_LIBS@ @KRAD_LIBS@ -pie -Wl,-z,relro -Wl,-z,now > > noinst_HEADERS = internal.h >-- >1.8.5.3 > I forgot to mention; patch applies only on ipa-3-3 branch, because file daemons/ipa-otpd/Makefile.am is different on master. LS From rcritten at redhat.com Tue Jan 28 20:35:36 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 28 Jan 2014 15:35:36 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52E80BAD.7010400@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> Message-ID: <52E81498.7040204@redhat.com> Petr Viktorin wrote: > On 01/23/2014 02:17 PM, Petr Viktorin wrote: >> On 01/22/2014 08:04 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 01/20/2014 05:21 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 01/17/2014 10:24 PM, Rob Crittenden wrote: >>>>>>> Implement an IPA RESTful Foreman-compatible smart proxy. This >>>>>>> exposes >>>>>>> hosts and hostgroups via an unauthenticated REST API. The idea is >>>>>>> that >>>>>>> this service runs on the Foreman server and only listens on local >>>>>>> ports. >>>>>>> >>>>>>> It is a CherryPy-based server and that handles the majority of REST >>>>>>> for us. >>>>>>> >>>>>>> I included some tests, they can be executed with: nosetests -v >>>>>>> smartproxy/tests >>>>>> >>>>>> Why is it not a part of ipatests? >>>>> >>>>> I can move it if it's a show-stopper. It seemed specific to this one >>>>> directory so I stuck it there. It isn't relevant for most testing and >>>>> requires some manual configuration (though CI could handle it). >>>> >>>> Not strictly a show stopper, but please move it. At the very least it >>>> should end up in the freeipa-tests package. >>> >>> Moved. >> >> Thanks! >> >>>> A lot of the tests (integration, webUI) need manual configuration, so >>>> this would be no exception. Of course the tests should be skipped if >>>> the >>>> configuration was not done, and the config instructions should be added >>>> to/linked from http://www.freeipa.org/page/Testing >>> >>> Hmm, maybe. There are instructions to set up the environment in the man >>> page. Testing beyond that consists of ./make-test tests/test_smartproxy >>> >>> I can add that testing bit once the patch is approved I suppose. >>> >>> rob >> >> Please add python-kerberos >= 1.1-13 to Requires and BuildRequires; >> pylint fails with lower versions. >> Are there plans to release python-kerberos-1.1-13.fc20, or will this be >> f21+ only? >> > > > I've noticed gssproxy-0.3.1 is not available in rawhide (but it is in > f20). I've sent a mail to G?nther; meanwhile I'll use the f20 package > (may the releng gods be merciful). > > > Here are my thoughts on the patch. > > The URL endpoint /ipa/rest suggests that if we implement a complete REST > API for IPA it would live here. Is the API supposed to be > future-compatible? (The API itself seems to be a good subset of a > complete REST API, but can we easily add an frontend with > authentication, i18n, etc. here later, and keep the limitations for > unauthenticated access?) > Perhaps /ipa/smartproxy would be a better choice? It was future-proofing. I'm fine with changing the URI, it is probably a good thing to save that name. > > I assume we're in control of the REST API design. Is that correct? > According to RFC 2616, the POST verb should create a sub-resource of > what's at the given URI. In other words, it would be more correct to use: > /ipa/rest/host POST Create a host entry {'hostname': ...} > and same for hostgroup. > Foreman's DHCP and DNS APIs seem to do this right. Sure, mistake on my part. > Is returning HTML for errors a Foreman requirement? I think it's a weird > thing to do in an API. Yeah, beats me. I couldn't find anything defining the output format so I figured I'd return it in something renderable by a browser. I'm open to suggestions. I guess there is no reason it can't be json as well. > I don't think IPACommand should be a class. It has no state, and it > looks to me like if one of GET/POST/DELETE happens to not be overridden > in an exposed subclass, there's a potential security issue -- any IPA > command can be called. Could you use simple functions instead? I guess so. I don't see it as a security risk though, as it would require changing the module and we already specify that this is unauthenticated, so if someone can hack the binary, they can already call arbitrary commands, class or no class. Still, the user will be limited to what they can do on the IPA side. > In IPACommand.Command, there's lot of duplicate error handling blocks. > You can handle more error classes at once with: > except (errors.DuplicateEntry, errors.DNSNotARecordError) as e: > Instead of `str(e)`, please report the errors as > "{e.__class__.__name__}: {e}" -- the message is sometimes unusable > without the exception type (e.g. a KeyError from {}['result'] would only > have 'result' as message). I did that in an attempt of readability since there is so much overlap. I'll take another look and see what it looks like combined again. > Passing *args, **options to Command closes the door for any (future) > parametrization. Consider making the signature e.g. Command(self, > command, args, options, success_stastus=200). Not sure I follow but I'll take a look. > Instead of `if fqdn == None:` use `if fqdn is None:`. Arg! > It would be great if you passed `api` around explicitly, instead of > relying on the global instance. Sure. > > Some import issues in test_smartproxy/resttest.py: > resttest.py:24:8: Unused import 'sys' > resttest.py:25:8: Unused import 'socket' > resttest.py:26:8: Unused import 'nose' > > `requests` is a third-party library, python-requests in Fedora; it > should be in the specfile. (Dogtag pulls it in for now, but when > ipa-server-ca is a separate package things will break.) > According to PEP8: >> Imports should be grouped in the following order: >> 1. standard library imports >> 2. related third party imports >> 3. local application/library specific imports [ipa* in our case] >> You should put a blank line between each group of imports. > Normally I'm not pedantic about this, but it does help spotting mistakes > like the above. I don't know that I'd have caught the spec thing. I think the tests change was due to my moving things around, I just didn't re-run pylint against it before resubmitting. > I'm not a fan of the test code copied from test_xmlrpc, but I guess we > have better things to do than refactoring that :( I'll see if I can be less lazy. That code was copied when it was outside of ipatests, I can probably drop most if not all of that. > But there should at least be a check that skips the tests if the smart > proxy is not available. I figured that since this was run only when requested that sort of takes care of itself. I'll see about adding a test for the port or something. > > In the ipa-rest man page, "Add this to the top of the file, before any > other services" doesn't specify what file should be edited. > Also, maybe the page should mention that `systemd start > ipa-rest.service` starts the server on port 8090. Sure. > > It's probably an error at my side, but I couldn't get a response from > the server: I got: > The server encountered an unexpected condition which > prevented it from fulfilling the request. > and in the log I see: > CCacheError: did not receive Kerberos credentials > I'm not familiar with gssproxy, but I don't see how it knows that it > should authenticate as the "rest" user. > > Should /var/log/ipa-rest.errors be world-readable? > > What is gssproxy.conf.snippet for? The same info is in the man page. gssproxy is magic. Basically you configure a keytab with the credentials, then configure gssproxy to handle those credentials (e.g. the bits from the man page) then whenever there is a GSS need for those credentials, gssproxy steps in and handles everything for you. You'll notice that the smartproxy can't even read its own keytab. It doesn't need to! So just configure gssproxy, /etc/gssproxy/gssproxy.conf, per the map page, with 0.3.1 and restart both daemons and it should just work. > > Also please fix: > ./ipalib/util.py:61:56: E703 statement ends with a semicolon > ./ipalib/util.py:63:54: E703 statement ends with a semicolon Bleh, sure. thanks rob From mkosek at redhat.com Wed Jan 29 08:30:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 29 Jan 2014 09:30:00 +0100 Subject: [Freeipa-devel] =?iso-8859-1?q?=5BPATCH=5D=A0Debian_client_suppor?= =?iso-8859-1?q?t?= In-Reply-To: <52E64051.5020404@ubuntu.com> References: <5225066B.3010003@ubuntu.com> <20130905212516.GB24203@mail.corp.redhat.com> <20131128202617.GA867@mail.corp.redhat.com> <52E64051.5020404@ubuntu.com> Message-ID: <52E8BC08.4090003@redhat.com> On 01/27/2014 12:17 PM, Timo Aaltonen wrote: > On 28.11.2013 22:26, Lukas Slebodnik wrote: >> On (05/09/13 23:25), Lukas Slebodnik wrote: >>> On (03/09/13 00:43), Timo Aaltonen wrote: >>>> >>>> This fixes https://fedorahosted.org/freeipa/ticket/1887 >>>> and >>>> https://fedorahosted.org/freeipa/ticket/2455 >>>> >>>> the first three patches fix some bugs in how python is used >>>> fourth patch checks if dbus is already running before trying to start it >>>> fifth fixes some compilation warnings >>>> sixth finally adds the Debian platform module >>>> >>>> >>>> >>>> there are also distro patches that aren't upstreamable as-is, that do >>>> stuff like >>>> - give--install-layout=deb to setup.py >>>> - disable make-testcert since it needs a server running >>>> - fix hardcoded NFS related paths and a variable in ipa-client-automount >>>> - fix ldap.conf path in ipa-client-install >>>> - fix ntpdate options in ntpconf.py (Debian doesn't patch ntpdate like >>>> Fedora) >>>> - change nss includes in ipa_pwd.c ( not ) >>> Solution is simple. Use pkg-config generated NSS_CFLAGS >>> >>> bash$ pkg-config --cflags nss >>> -I/usr/include/nss -I/usr/include/nspr >>> bash$ uname -a >>> Linux positron 3.10-2-686-pae #1 SMP Debian 3.10.5-1 (2013-08-07) i686 GNU/Linux >>> >>> bash$pkg-config --cflags nss >>> -I/usr/include/nss3 -I/usr/include/nspr4 >>> bash$uname -a >>> Linux unused-4-233.brq.redhat.com 3.10.10-200.fc19.x86_64 #1 SMP Thu Aug 29 19:05:45 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux >>> >>> It works in sssd. I can send a patch. >>> >>> LS >>> >> Attached patch should fix problem with compilation on different distros. >> >> debian: >> http://anonscm.debian.org/gitweb/?p=pkg-freeipa/freeipa.git;a=blob;f=debian/patches/fix-nss-include.diff;h=1dac0709ed7344c7546c55225365c9434e6a930a;hb=HEAD >> arch: >> https://github.com/chenxiaolong/ArchLinux-Packages/blob/master/freeipa/0006_Fix_nss_includes.patch >> >> Timo can you test patch on debian/ubuntu? > > finally did last week, so > > Tested-by: Timo Aaltonen Thanks Timo. I did a mild rebase to current master, tested FreeIPA in Fedora still builds and pushed to master. Martin From mkosek at redhat.com Wed Jan 29 08:46:41 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 29 Jan 2014 09:46:41 +0100 Subject: [Freeipa-devel] [PATCH] Fix linking ipa-otpd with broken hardened build In-Reply-To: <20140128195921.GB31235@mail.corp.redhat.com> References: <20140128195656.GA31235@mail.corp.redhat.com> <20140128195921.GB31235@mail.corp.redhat.com> Message-ID: <52E8BFF1.4050102@redhat.com> On 01/28/2014 08:59 PM, Lukas Slebodnik wrote: > On (28/01/14 20:56), Lukas Slebodnik wrote: >> ehlo, >> >> How to test: >> -remove line "%define _hardened_build 1" from spec file >> -build freeeipa package (it should fail) >> -apply patch >> -build freeeipa package (it should work ) >> >> simple patch attached. >> >> LS > >> >From 0ae1582770706f5a88980c0a16d4c64ce58c98e2 Mon Sep 17 00:00:00 2001 >> From: Lukas Slebodnik >> Date: Tue, 28 Jan 2014 19:58:40 +0100 >> Subject: [PATCH] Fix linking ipa-otpd with broken hardened build >> >> If there is problem with _hardened_build in rpm extra flag will not be included >> into CLFAGS and LDFLAGS ("-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1" ) >> and it will cause problem with linking binary ipa-otpd. >> >> /usr/bin/ld: bind.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be >> used when making a shared object; recompile with -fPIC >> bind.o: error adding symbols: Bad value >> >> ipa-otpd will be linked successfully with this patch even if there is problem >> with hardened build on fedora. >> >> Resolves: >> https://fedorahosted.org/freeipa/ticket/4142 >> --- >> daemons/ipa-otpd/Makefile.am | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/daemons/ipa-otpd/Makefile.am b/daemons/ipa-otpd/Makefile.am >> index f0b75284dbbd46265a6ff366a7846da63c935986..0716e75b72cb7fb3910350fc0f9439a23c0bcf29 100644 >> --- a/daemons/ipa-otpd/Makefile.am >> +++ b/daemons/ipa-otpd/Makefile.am >> @@ -1,4 +1,4 @@ >> -AM_CFLAGS := $(CFLAGS) @LDAP_CFLAGS@ @LIBVERTO_CFLAGS@ >> +AM_CFLAGS := $(CFLAGS) @LDAP_CFLAGS@ @LIBVERTO_CFLAGS@ -fPIE >> AM_LDFLAGS := $(LDFLAGS) @LDAP_LIBS@ @LIBVERTO_LIBS@ @KRAD_LIBS@ -pie -Wl,-z,relro -Wl,-z,now >> >> noinst_HEADERS = internal.h >> -- >> 1.8.5.3 >> > > I forgot to mention; patch applies only on ipa-3-3 branch, because file > daemons/ipa-otpd/Makefile.am is different on master. > > LS Thanks Lukas, good investigation. This made me realize that the rawhide build was indeed crashing due to missing section switching _hardened_build to 1 in downstream repo. The build seems OK now. Do you still consider this patch as something that should be in git, given it was caused by missing _hardened_build? Martin From lslebodn at redhat.com Wed Jan 29 09:39:28 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 29 Jan 2014 10:39:28 +0100 Subject: [Freeipa-devel] [PATCH] Fix linking ipa-otpd with broken hardened build In-Reply-To: <52E8BFF1.4050102@redhat.com> References: <20140128195656.GA31235@mail.corp.redhat.com> <20140128195921.GB31235@mail.corp.redhat.com> <52E8BFF1.4050102@redhat.com> Message-ID: <20140129093927.GA31629@mail.corp.redhat.com> On (29/01/14 09:46), Martin Kosek wrote: >On 01/28/2014 08:59 PM, Lukas Slebodnik wrote: >> On (28/01/14 20:56), Lukas Slebodnik wrote: >>> ehlo, >>> >>> How to test: >>> -remove line "%define _hardened_build 1" from spec file >>> -build freeeipa package (it should fail) >>> -apply patch >>> -build freeeipa package (it should work ) >>> >>> simple patch attached. >>> >>> LS >> >>> >From 0ae1582770706f5a88980c0a16d4c64ce58c98e2 Mon Sep 17 00:00:00 2001 >>> From: Lukas Slebodnik >>> Date: Tue, 28 Jan 2014 19:58:40 +0100 >>> Subject: [PATCH] Fix linking ipa-otpd with broken hardened build >>> >>> If there is problem with _hardened_build in rpm extra flag will not be included >>> into CLFAGS and LDFLAGS ("-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1" ) >>> and it will cause problem with linking binary ipa-otpd. >>> >>> /usr/bin/ld: bind.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be >>> used when making a shared object; recompile with -fPIC >>> bind.o: error adding symbols: Bad value >>> >>> ipa-otpd will be linked successfully with this patch even if there is problem >>> with hardened build on fedora. >>> >>> Resolves: >>> https://fedorahosted.org/freeipa/ticket/4142 >>> --- >>> daemons/ipa-otpd/Makefile.am | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/daemons/ipa-otpd/Makefile.am b/daemons/ipa-otpd/Makefile.am >>> index f0b75284dbbd46265a6ff366a7846da63c935986..0716e75b72cb7fb3910350fc0f9439a23c0bcf29 100644 >>> --- a/daemons/ipa-otpd/Makefile.am >>> +++ b/daemons/ipa-otpd/Makefile.am >>> @@ -1,4 +1,4 @@ >>> -AM_CFLAGS := $(CFLAGS) @LDAP_CFLAGS@ @LIBVERTO_CFLAGS@ >>> +AM_CFLAGS := $(CFLAGS) @LDAP_CFLAGS@ @LIBVERTO_CFLAGS@ -fPIE >>> AM_LDFLAGS := $(LDFLAGS) @LDAP_LIBS@ @LIBVERTO_LIBS@ @KRAD_LIBS@ -pie -Wl,-z,relro -Wl,-z,now >>> >>> noinst_HEADERS = internal.h >>> -- >>> 1.8.5.3 >>> >> >> I forgot to mention; patch applies only on ipa-3-3 branch, because file >> daemons/ipa-otpd/Makefile.am is different on master. >> >> LS > >Thanks Lukas, good investigation. This made me realize that the rawhide build >was indeed crashing due to missing section switching _hardened_build to 1 in >downstream repo. The build seems OK now. > I used srpm from fedora 20 build and _hardened_build was available in spec file. I expected all builds(f19, f20, rawhide} use the same spec file. >Do you still consider this patch as something that should be in git, given it >was caused by missing _hardened_build? > There is condition in spec file %if (0%{?fedora} > 15 || 0%{?rhel} >= 7) %define _hardened_build 1 %endif So _hardened_build will not be defined on other platforms (e.g. opensuse) and there will be the same problem with linking ipa-otpd Other option is to remove "duplicated" hardened flags from AM_LDFLAGS -AM_LDFLAGS := $(LDFLAGS) @LDAP_LIBS@ @LIBVERTO_LIBS@ @KRAD_LIBS@ -pie -Wl,-z,relro -Wl,-z,now +AM_LDFLAGS := $(LDFLAGS) @LDAP_LIBS@ @LIBVERTO_LIBS@ @KRAD_LIBS@ LS From mkosek at redhat.com Wed Jan 29 12:55:09 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 29 Jan 2014 13:55:09 +0100 Subject: [Freeipa-devel] [PATCH] Fix linking ipa-otpd with broken hardened build In-Reply-To: <20140129093927.GA31629@mail.corp.redhat.com> References: <20140128195656.GA31235@mail.corp.redhat.com> <20140128195921.GB31235@mail.corp.redhat.com> <52E8BFF1.4050102@redhat.com> <20140129093927.GA31629@mail.corp.redhat.com> Message-ID: <52E8FA2D.50700@redhat.com> On 01/29/2014 10:39 AM, Lukas Slebodnik wrote: > On (29/01/14 09:46), Martin Kosek wrote: >> On 01/28/2014 08:59 PM, Lukas Slebodnik wrote: >>> On (28/01/14 20:56), Lukas Slebodnik wrote: >>>> ehlo, >>>> >>>> How to test: >>>> -remove line "%define _hardened_build 1" from spec file >>>> -build freeeipa package (it should fail) >>>> -apply patch >>>> -build freeeipa package (it should work ) >>>> >>>> simple patch attached. >>>> >>>> LS >>> >>>> >From 0ae1582770706f5a88980c0a16d4c64ce58c98e2 Mon Sep 17 00:00:00 2001 >>>> From: Lukas Slebodnik >>>> Date: Tue, 28 Jan 2014 19:58:40 +0100 >>>> Subject: [PATCH] Fix linking ipa-otpd with broken hardened build >>>> >>>> If there is problem with _hardened_build in rpm extra flag will not be included >>>> into CLFAGS and LDFLAGS ("-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1" ) >>>> and it will cause problem with linking binary ipa-otpd. >>>> >>>> /usr/bin/ld: bind.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be >>>> used when making a shared object; recompile with -fPIC >>>> bind.o: error adding symbols: Bad value >>>> >>>> ipa-otpd will be linked successfully with this patch even if there is problem >>>> with hardened build on fedora. >>>> >>>> Resolves: >>>> https://fedorahosted.org/freeipa/ticket/4142 >>>> --- >>>> daemons/ipa-otpd/Makefile.am | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/daemons/ipa-otpd/Makefile.am b/daemons/ipa-otpd/Makefile.am >>>> index f0b75284dbbd46265a6ff366a7846da63c935986..0716e75b72cb7fb3910350fc0f9439a23c0bcf29 100644 >>>> --- a/daemons/ipa-otpd/Makefile.am >>>> +++ b/daemons/ipa-otpd/Makefile.am >>>> @@ -1,4 +1,4 @@ >>>> -AM_CFLAGS := $(CFLAGS) @LDAP_CFLAGS@ @LIBVERTO_CFLAGS@ >>>> +AM_CFLAGS := $(CFLAGS) @LDAP_CFLAGS@ @LIBVERTO_CFLAGS@ -fPIE >>>> AM_LDFLAGS := $(LDFLAGS) @LDAP_LIBS@ @LIBVERTO_LIBS@ @KRAD_LIBS@ -pie -Wl,-z,relro -Wl,-z,now >>>> >>>> noinst_HEADERS = internal.h >>>> -- >>>> 1.8.5.3 >>>> >>> >>> I forgot to mention; patch applies only on ipa-3-3 branch, because file >>> daemons/ipa-otpd/Makefile.am is different on master. >>> >>> LS >> >> Thanks Lukas, good investigation. This made me realize that the rawhide build >> was indeed crashing due to missing section switching _hardened_build to 1 in >> downstream repo. The build seems OK now. >> > I used srpm from fedora 20 build and _hardened_build was available in spec > file. I expected all builds(f19, f20, rawhide} use the same spec file. > >> Do you still consider this patch as something that should be in git, given it >> was caused by missing _hardened_build? >> > There is condition in spec file > %if (0%{?fedora} > 15 || 0%{?rhel} >= 7) > %define _hardened_build 1 > %endif > > So _hardened_build will not be defined on other platforms (e.g. opensuse) > and there will be the same problem with linking ipa-otpd > > Other option is to remove "duplicated" hardened flags from AM_LDFLAGS > > -AM_LDFLAGS := $(LDFLAGS) @LDAP_LIBS@ @LIBVERTO_LIBS@ @KRAD_LIBS@ -pie -Wl,-z,relro -Wl,-z,now > +AM_LDFLAGS := $(LDFLAGS) @LDAP_LIBS@ @LIBVERTO_LIBS@ @KRAD_LIBS@ > > LS > I chose to do the second option as I see this is what Honza did in master branch. Thus, I cherry picked his patch pushed to ipa-3-3: 2d90c138ea63a74c90142e19d733e8c89ce81dab Martin From npmccallum at redhat.com Wed Jan 29 22:53:10 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 29 Jan 2014 17:53:10 -0500 Subject: [Freeipa-devel] [PATCH 0028] Add OTP last token plugin In-Reply-To: <1389302848.1962.5.camel@localhost.localdomain> References: <1387821395.18952.7.camel@localhost.localdomain> <1389302848.1962.5.camel@localhost.localdomain> Message-ID: <1391035990.20303.1.camel@localhost.localdomain> This new patch depends on patches: 0026 and 0029. On Thu, 2014-01-09 at 16:27 -0500, Nathaniel McCallum wrote: > This new version now depends on my patch 0029. Sorry for the reverse > ordering. > > On Mon, 2013-12-23 at 12:56 -0500, Nathaniel McCallum wrote: > > This plugin prevents the deletion or deactivation of the last valid > > token for a user. This prevents the user from migrating back to single > > factor authentication once OTP has been enabled. > > > > Thanks to Mark Reynolds for helping me with this patch. > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > _______________________________________________ > 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: freeipa-npmccallum-0028-3-Add-OTP-last-token-plugin.patch Type: text/x-patch Size: 13192 bytes Desc: not available URL: From npmccallum at redhat.com Wed Jan 29 22:54:05 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 29 Jan 2014 17:54:05 -0500 Subject: [Freeipa-devel] [PATCH 0029] Add libotp internal library for slapi plugins In-Reply-To: <1389302789.1962.4.camel@localhost.localdomain> References: <1389302789.1962.4.camel@localhost.localdomain> Message-ID: <1391036045.20303.2.camel@localhost.localdomain> This new version depends on patch 0026. On Thu, 2014-01-09 at 16:26 -0500, Nathaniel McCallum wrote: > Attached. > _______________________________________________ > 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: freeipa-npmccallum-0029-2-Add-libotp-internal-library-for-slapi-plugins.patch Type: text/x-patch Size: 33822 bytes Desc: not available URL: From npmccallum at redhat.com Wed Jan 29 23:06:39 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 29 Jan 2014 18:06:39 -0500 Subject: [Freeipa-devel] [PATCH 0030] Add OTP sync support to ipa-pwd-extop In-Reply-To: <1389302896.1962.6.camel@localhost.localdomain> References: <1389302896.1962.6.camel@localhost.localdomain> Message-ID: <1391036799.20303.13.camel@localhost.localdomain> This new version of the patch depends on patches 0026 and 0029. It has also been renamed. This should hopefully solve the problems that Simo raised about extended password validation, etc. In short, I've moved all of the token synchronization code into ipa-pwd-extop. The original code looked like this: 1. Validate OTP 2. Validate Password-only 3. 4. Write out kerberos keys if necessary 5. Fall through to 389ds for full password validation The code, after this patch now looks like this: 1. Validate OTP 2. Validate Password-only 3. Synchronize token 4. Write out kerberos keys if necessary 5. Fall through to 389ds for full password validation In both cases, if #2 fails we jump immediately to #5. If #3 fails the failure is reported to the user as INVALID_CREDENTIALS. If synchronization succeeds, we still fall through to #4 and #5. The only oddity of this choice is that a user could be locked out/etc and new #3 would succeed. In this case, #5 would still fail however and the bind would be unsuccessful. Hence, the user would never know if the tokens were synchronized. The new bind control is very simple: OTPSyncRequest ::= SEQUENCE { firstCode INTEGER, secondCode INTEGER, tokenDN OCTET STRING OPTIONAL } The OID is 2.16.840.1.113730.3.6.9. This was given to me by Mark, but I don't know who controls this or if we can use it. All of this is tested and working. Nathaniel On Thu, 2014-01-09 at 16:28 -0500, Nathaniel McCallum wrote: > This plugin adds an extended operation for synchronizing tokens. This > operation is availalbe both with and without bind. In the latter case, > the first factor is required. This operation can also be performed > on a per-token or per-user level. In the latter case, we will attempt > to find the token automatically. > > Thanks to Mark Reynolds for helping me with this patch. > _______________________________________________ > 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: freeipa-npmccallum-0030-2-Add-OTP-sync-support-to-ipa-pwd-extop.patch Type: text/x-patch Size: 56547 bytes Desc: not available URL: From npmccallum at redhat.com Wed Jan 29 23:07:17 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 29 Jan 2014 18:07:17 -0500 Subject: [Freeipa-devel] [PATCH 0031] Migrate ipa-pwd-extop to use libotp In-Reply-To: <1389302945.1962.7.camel@localhost.localdomain> References: <1389302945.1962.7.camel@localhost.localdomain> Message-ID: <1391036837.20303.14.camel@localhost.localdomain> This patch is now obsoleted by my new patch 0030. On Thu, 2014-01-09 at 16:29 -0500, Nathaniel McCallum wrote: > Attached. > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From npmccallum at redhat.com Wed Jan 29 23:11:14 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 29 Jan 2014 18:11:14 -0500 Subject: [Freeipa-devel] [PATCH 0033] Add HOTP token support In-Reply-To: <1389303394.1962.15.camel@localhost.localdomain> References: <1389303394.1962.15.camel@localhost.localdomain> Message-ID: <1391037074.20303.17.camel@localhost.localdomain> Updated version of this patch so it no longer depends (implicitly) on the now withdrawn patch 0032. On Thu, 2014-01-09 at 16:36 -0500, Nathaniel McCallum wrote: > This patch depends on my patch 0029. > > In the past we have talked about not adding HOTP support due to the > inability to guarantee timely updates to the counter across replication. > I went ahead and implemented HOTP support for two reasons: > > 1. Testing the OTP stack with TOTP tokens can be a bit frustrating > waiting for the tokens to generate. > > 2. Since we aren't implementing watermark support for TOTP, the HOTP > security guarantee seems very similar to me. > > Nathaniel > _______________________________________________ > 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: freeipa-npmccallum-0033-2-Add-HOTP-token-support.patch Type: text/x-patch Size: 20777 bytes Desc: not available URL: From ssorce at redhat.com Wed Jan 29 23:14:47 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 29 Jan 2014 18:14:47 -0500 (EST) Subject: [Freeipa-devel] [PATCH 0030] Add OTP sync support to ipa-pwd-extop In-Reply-To: <1391036799.20303.13.camel@localhost.localdomain> References: <1389302896.1962.6.camel@localhost.localdomain> <1391036799.20303.13.camel@localhost.localdomain> Message-ID: <1833121228.1490814.1391037287960.JavaMail.root@redhat.com> ----- Original Message ----- > This new version of the patch depends on patches 0026 and 0029. It has > also been renamed. > > This should hopefully solve the problems that Simo raised about extended > password validation, etc. In short, I've moved all of the token > synchronization code into ipa-pwd-extop. The original code looked like > this: > > 1. Validate OTP > 2. Validate Password-only > 3. > 4. Write out kerberos keys if necessary > 5. Fall through to 389ds for full password validation > > The code, after this patch now looks like this: > > 1. Validate OTP > 2. Validate Password-only > 3. Synchronize token > 4. Write out kerberos keys if necessary > 5. Fall through to 389ds for full password validation I assume step 4 is the special migration code step, right ? It is not something new part of the OTP code. > In both cases, if #2 fails we jump immediately to #5. If #3 fails the > failure is reported to the user as INVALID_CREDENTIALS. I wonder if we have a standard control to give more info, like we do for the password change operation ... > If > synchronization succeeds, we still fall through to #4 and #5. > > The only oddity of this choice is that a user could be locked out/etc > and new #3 would succeed. In this case, #5 would still fail however and > the bind would be unsuccessful. Hence, the user would never know if the > tokens were synchronized. > > The new bind control is very simple: > OTPSyncRequest ::= SEQUENCE { > firstCode INTEGER, > secondCode INTEGER, > tokenDN OCTET STRING OPTIONAL > } > > The OID is 2.16.840.1.113730.3.6.9. This was given to me by Mark, but I > don't know who controls this or if we can use it. prefix.3.6.x is the miscellaneous OIDs, but this is FreeIPA work, and should go in prefix.3.8.10.x I am assigning you 2.16.840.1.113730.3.8.10.6, please change your patches to use this OID. I will de-register the one Mark reserved for you in 3.6.x > All of this is tested and working. > > Nathaniel > > On Thu, 2014-01-09 at 16:28 -0500, Nathaniel McCallum wrote: > > This plugin adds an extended operation for synchronizing tokens. This > > operation is availalbe both with and without bind. In the latter case, > > the first factor is required. This operation can also be performed > > on a per-token or per-user level. In the latter case, we will attempt > > to find the token automatically. > > > > Thanks to Mark Reynolds for helping me with this patch. > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Simo Sorce * Red Hat, Inc. * New York From pspacek at redhat.com Thu Jan 30 12:11:10 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 30 Jan 2014 13:11:10 +0100 Subject: [Freeipa-devel] [PATCH 0009-0011] Replace existing domain names and non-private IP addresses in tests Message-ID: <52EA415E.7030603@redhat.com> Hello, now DNS tests behave like a good citizen of Internet. (... And it will simplify patches for bind-dyndb-ldap 4.0.) https://fedorahosted.org/freeipa/ticket/4139 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0009-Use-private-IPv4-addresses-for-tests.patch Type: text/x-patch Size: 18073 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0010-Rename-variables-in-test-xmlrpc-dns_plugin.patch Type: text/x-patch Size: 83934 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0011-Use-reserved-domain-names-for-tests.patch Type: text/x-patch Size: 12556 bytes Desc: not available URL: From pviktori at redhat.com Thu Jan 30 13:57:19 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 30 Jan 2014 14:57:19 +0100 Subject: [Freeipa-devel] [PATCH 0009-0011] Replace existing domain names and non-private IP addresses in tests In-Reply-To: <52EA415E.7030603@redhat.com> References: <52EA415E.7030603@redhat.com> Message-ID: <52EA5A3F.3070401@redhat.com> On 01/30/2014 01:11 PM, Petr Spacek wrote: > Hello, > > now DNS tests behave like a good citizen of Internet. (... And it will > simplify patches for bind-dyndb-ldap 4.0.) > > https://fedorahosted.org/freeipa/ticket/4139 Thanks for cleaning up! ACK, pushed to master: df3fa943abf58f2ad02919ecb1b199f3ff6d510b -- Petr? From npmccallum at redhat.com Thu Jan 30 15:46:22 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 30 Jan 2014 10:46:22 -0500 Subject: [Freeipa-devel] [PATCH 0030] Add OTP sync support to ipa-pwd-extop In-Reply-To: <1833121228.1490814.1391037287960.JavaMail.root@redhat.com> References: <1389302896.1962.6.camel@localhost.localdomain> <1391036799.20303.13.camel@localhost.localdomain> <1833121228.1490814.1391037287960.JavaMail.root@redhat.com> Message-ID: <1391096782.20303.23.camel@localhost.localdomain> On Wed, 2014-01-29 at 18:14 -0500, Simo Sorce wrote: > ----- Original Message ----- > > This new version of the patch depends on patches 0026 and 0029. It has > > also been renamed. > > > > This should hopefully solve the problems that Simo raised about extended > > password validation, etc. In short, I've moved all of the token > > synchronization code into ipa-pwd-extop. The original code looked like > > this: > > > > 1. Validate OTP > > 2. Validate Password-only > > 3. > > 4. Write out kerberos keys if necessary > > 5. Fall through to 389ds for full password validation > > > > The code, after this patch now looks like this: > > > > 1. Validate OTP > > 2. Validate Password-only > > 3. Synchronize token > > 4. Write out kerberos keys if necessary > > 5. Fall through to 389ds for full password validation > > I assume step 4 is the special migration code step, right ? > It is not something new part of the OTP code. That is correct. Steps #2, #4 and #5 are original to this plugin before OTP was ever involved. The only significant change I've made to this code is reordering of some of the checks so that password validation happened earlier. Before the OTP project it looked like this: 1. Preemptive checks related to kerberos keys 2. Validate password-only 3. Write out kerberos keys if necessary 4. Fall through to 389ds for full password validation So I merged #1 into #3, added OTP at the start and OTP sync in the middle. > > In both cases, if #2 fails we jump immediately to #5. If #3 fails the > > failure is reported to the user as INVALID_CREDENTIALS. > > I wonder if we have a standard control to give more info, like we do for > the password change operation ... > > > If > > synchronization succeeds, we still fall through to #4 and #5. > > > > The only oddity of this choice is that a user could be locked out/etc > > and new #3 would succeed. In this case, #5 would still fail however and > > the bind would be unsuccessful. Hence, the user would never know if the > > tokens were synchronized. > > > > The new bind control is very simple: > > OTPSyncRequest ::= SEQUENCE { > > firstCode INTEGER, > > secondCode INTEGER, > > tokenDN OCTET STRING OPTIONAL > > } > > > > The OID is 2.16.840.1.113730.3.6.9. This was given to me by Mark, but I > > don't know who controls this or if we can use it. > > prefix.3.6.x is the miscellaneous OIDs, but this is FreeIPA work, and should > go in prefix.3.8.10.x > > I am assigning you 2.16.840.1.113730.3.8.10.6, please change your patches to use this OID. > I will de-register the one Mark reserved for you in 3.6.x Fixed. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0030-3-Add-OTP-sync-support-to-ipa-pwd-extop.patch Type: text/x-patch Size: 56550 bytes Desc: not available URL: From mkosek at redhat.com Thu Jan 30 16:00:26 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 30 Jan 2014 17:00:26 +0100 Subject: [Freeipa-devel] [PATCH] 455 Fallback to global policy in ipa-lockout plugin Message-ID: <52EA771A.3080708@redhat.com> krbPwdPolicyReference is no longer filled default users. Instead, plugins fallback to hardcoded global policy reference. Fix ipa-lockout plugin to fallback to it instead of failing to apply the policy. https://fedorahosted.org/freeipa/ticket/4085 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-455-fallback-to-global-policy-in-ipa-lockout-plugin.patch Type: text/x-patch Size: 3194 bytes Desc: not available URL: From ilgrosso at apache.org Thu Jan 30 16:35:50 2014 From: ilgrosso at apache.org (=?ISO-8859-1?Q?Francesco_Chicchiricc=F2?=) Date: Thu, 30 Jan 2014 17:35:50 +0100 Subject: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope Message-ID: <52EA7F66.5040202@apache.org> Hi all, I am PMC chair at Apache Syncope [1], an Open Source system for managing digital identities in enterprise environments, implemented in JEE technology and released under Apache 2.0 license. Apache Syncope can be classified as provisioning engine, and its duty can be summarized as keeping synchronized account data across different identity datastores (RDBMS, LDAP, Active Directory, ....). For the actual communication with such external identity datastores, Apache Syncope relies upon ConnId [2], an Open Source fork of Sun Microsystem's Identity Connectors framework [3], left dead after Sun's acquisition by Oracle. I am also project owner at ConnId. My company Tirasa is about to start the development of a FreeIPA ConnId connector [4] that would allow the integration of FreeIPA into Apache Syncope-based IdM architectures. We are currently installing and testing FreeIPA in order to understand what is the better way to implement the communication with Syncope: do you have any suggestion about where to start from? Thanks. Best regards. [1] http://syncope.apache.org/ [2] http://tirasa.github.io/ConnId/ [3] http://java.net/projects/identityconnectors/ [4] https://github.com/Tirasa/ConnIdFreeIPABundle -- Francesco Chicchiricc? Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/ From rcritten at redhat.com Thu Jan 30 18:19:56 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 30 Jan 2014 13:19:56 -0500 Subject: [Freeipa-devel] [PATCH] 455 Fallback to global policy in ipa-lockout plugin In-Reply-To: <52EA771A.3080708@redhat.com> References: <52EA771A.3080708@redhat.com> Message-ID: <52EA97CC.8030203@redhat.com> Martin Kosek wrote: > krbPwdPolicyReference is no longer filled default users. Instead, plugins > fallback to hardcoded global policy reference. > > Fix ipa-lockout plugin to fallback to it instead of failing to apply > the policy. > > https://fedorahosted.org/freeipa/ticket/4085 NACK. I think you should include the value of krberr in error messages (we aren't exactly consistent in this elsewhere in the code but we need to start somewhere). You check the wrong value after the krb5_get_default_realm() call. It is probably better to use slapi_ch_free_string() than free(). At some point we'll need a common library where this sort of operation can be done. rob From dpal at redhat.com Thu Jan 30 18:25:20 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 30 Jan 2014 13:25:20 -0500 Subject: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope In-Reply-To: <52EA7F66.5040202@apache.org> References: <52EA7F66.5040202@apache.org> Message-ID: <52EA9910.7030704@redhat.com> On 01/30/2014 11:35 AM, Francesco Chicchiricc? wrote: > Hi all, > I am PMC chair at Apache Syncope [1], an Open Source system for > managing digital identities in enterprise environments, implemented in > JEE technology and released under Apache 2.0 license. > > Apache Syncope can be classified as provisioning engine, and its duty > can be summarized as keeping synchronized account data across > different identity datastores (RDBMS, LDAP, Active Directory, ....). > > For the actual communication with such external identity datastores, > Apache Syncope relies upon ConnId [2], an Open Source fork of Sun > Microsystem's Identity Connectors framework [3], left dead after Sun's > acquisition by Oracle. > I am also project owner at ConnId. > > My company Tirasa is about to start the development of a FreeIPA > ConnId connector [4] that would allow the integration of FreeIPA into > Apache Syncope-based IdM architectures. > > We are currently installing and testing FreeIPA in order to understand > what is the better way to implement the communication with Syncope: do > you have any suggestion about where to start from? > Thanks. > Can you please list provisioning use cases that you want to support? Add user? Edit user? Reset password? Keep in mind that after password is set for a user user needs to change it on the first login. This is done to make sure that no one can impersonate user and password is not know outside the system. So this is one of the first hurdles you need to deal with, i.e. fire and forget and not try to use password for anything else in IPA use case. To call into IPA you can use "ipa ..." command line or use out API from python client. Since you are using Java calling into "ipa" command is probably the best option. In future we plan to allow insertion of the users via an ldap command https://fedorahosted.org/freeipa/ticket/3911 it is on the roadmap for this spring. What are other use cases and workflows you have? Do you have a password reset self service? If you do it might be nice external addition to FreeIPA if it integrates into the UI seamlessly. > Best regards. > > [1] http://syncope.apache.org/ > [2] http://tirasa.github.io/ConnId/ > [3] http://java.net/projects/identityconnectors/ > [4] https://github.com/Tirasa/ConnIdFreeIPABundle > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Fri Jan 31 08:29:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 31 Jan 2014 09:29:02 +0100 Subject: [Freeipa-devel] [PATCH] 455 Fallback to global policy in ipa-lockout plugin In-Reply-To: <52EA97CC.8030203@redhat.com> References: <52EA771A.3080708@redhat.com> <52EA97CC.8030203@redhat.com> Message-ID: <52EB5ECE.2010500@redhat.com> On 01/30/2014 07:19 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> krbPwdPolicyReference is no longer filled default users. Instead, plugins >> fallback to hardcoded global policy reference. >> >> Fix ipa-lockout plugin to fallback to it instead of failing to apply >> the policy. >> >> https://fedorahosted.org/freeipa/ticket/4085 > > NACK. > > I think you should include the value of krberr in error messages (we aren't > exactly consistent in this elsewhere in the code but we need to start somewhere). > > You check the wrong value after the krb5_get_default_realm() call. > > It is probably better to use slapi_ch_free_string() than free(). > > At some point we'll need a common library where this sort of operation can be > done. > > rob Good catch, sending updated patch. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-455-2-fallback-to-global-policy-in-ipa-lockout-plugin.patch Type: text/x-patch Size: 3238 bytes Desc: not available URL: From mkosek at redhat.com Fri Jan 31 09:22:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 31 Jan 2014 10:22:58 +0100 Subject: [Freeipa-devel] [PATCH] 454 Migration does not add users to default group In-Reply-To: <52E7AE1E.8090508@redhat.com> References: <52E643CF.30906@redhat.com> <52E7AE1E.8090508@redhat.com> Message-ID: <52EB6B72.4060602@redhat.com> On 01/28/2014 02:18 PM, Petr Viktorin wrote: > On 01/27/2014 12:32 PM, Martin Kosek wrote: >> When users with missing default group were searched, IPA suffix was >> not passed so these users were searched in a wrong base DN. Thus, >> no user was detected and added to default group. >> >> https://fedorahosted.org/freeipa/ticket/4141 > > This needs a rebase for the new LDAP API. I tested primarily on ipa-3-3 branch, I will rebase when acked. > I don't see the need for the second change, caching of len(new_members). On > lists, len() is extremely fast. > If you want to optimize, convert the list of existing members to a set before > the for loop, instead of getting it from the entry and using the `in` operator > (which is O(N) on lists) every time. Makes sense, done. > > > Nitpicks: > > Instead of "if len(container) > 0:" you should just use "if container:" (see > PEP8). Fixed. > > Instead of: > members = group_entry_attrs.get('member', []) > ... > group_entry_attrs['member'] = members > you can use: > members = group_entry_attrs.setdefault('member', []) > ... Fixed. New patch attached (tested). Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-454-2-migration-does-not-add-users-to-default-group.patch Type: text/x-patch Size: 2531 bytes Desc: not available URL: From ilgrosso at apache.org Fri Jan 31 09:45:07 2014 From: ilgrosso at apache.org (=?ISO-8859-1?Q?Francesco_Chicchiricc=F2?=) Date: Fri, 31 Jan 2014 10:45:07 +0100 Subject: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope In-Reply-To: <52EA9910.7030704@redhat.com> References: <52EA7F66.5040202@apache.org> <52EA9910.7030704@redhat.com> Message-ID: <52EB70A3.4090606@apache.org> On 30/01/2014 19:25, Dmitri Pal wrote: > On 01/30/2014 11:35 AM, Francesco Chicchiricc? wrote: >> Hi all, >> I am PMC chair at Apache Syncope [1], an Open Source system for >> managing digital identities in enterprise environments, implemented in >> JEE technology and released under Apache 2.0 license. >> >> Apache Syncope can be classified as provisioning engine, and its duty >> can be summarized as keeping synchronized account data across >> different identity datastores (RDBMS, LDAP, Active Directory, ....). >> >> For the actual communication with such external identity datastores, >> Apache Syncope relies upon ConnId [2], an Open Source fork of Sun >> Microsystem's Identity Connectors framework [3], left dead after Sun's >> acquisition by Oracle. >> I am also project owner at ConnId. >> >> My company Tirasa is about to start the development of a FreeIPA >> ConnId connector [4] that would allow the integration of FreeIPA into >> Apache Syncope-based IdM architectures. >> >> We are currently installing and testing FreeIPA in order to understand >> what is the better way to implement the communication with Syncope: do >> you have any suggestion about where to start from? >> Thanks. > Can you please list provisioning use cases that you want to support? > Add user? > Edit user? > Reset password? Basically we are planning to implement all identity operations defined by the ConnId framework [5], e.g.: AUTHENTICATE CREATE UPDATE UPDATE_ATTRIBUTE_VALUES DELETE RESOLVE_USERNAME SCHEMA SEARCH SYNC TEST for ACCOUNTs and GROUPs; some of such operations (SYNC, for example) is usually more complex than others. It will be then Syncope's business to build high-level identity operations on top of these primitives, as it does with existing connectors, in a technology-agnostic way. > Keep in mind that after password is set for a user user needs to change > it on the first login. This is done to make sure that no one can > impersonate user and password is not know outside the system. So this is > one of the first hurdles you need to deal with, i.e. fire and forget and > not try to use password for anything else in IPA use case. This seems to be the first custom requirement of this connector, if compared with existing ones: good to know :-) > To call into IPA you can use "ipa ..." command line or use out API from > python client. Since you are using Java calling into "ipa" command is > probably the best option. Actually, a RESTful interface (HTTP/JSON) would better suit our development model and deployment scenarios. > In future we plan to allow insertion of the users via an ldap command > https://fedorahosted.org/freeipa/ticket/3911 it is on the roadmap for > this spring. > > What are other use cases and workflows you have? > Do you have a password reset self service? > If you do it might be nice external addition to FreeIPA if it integrates > into the UI seamlessly. The idea is to deploy the latest FreeIPA version in our lab, start playing with it and come to this list for asking for more information we are not able to find in the wiki (just to avoid some graceful RTFMs...). Then, every time we get something working, we will also check here whether we are heading into the right direction, if we are missing some important points, etc. Does it sound? Regards. > [1] http://syncope.apache.org/ > [2] http://tirasa.github.io/ConnId/ > [3] http://java.net/projects/identityconnectors/ > [4] https://github.com/Tirasa/ConnIdFreeIPABundle [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html -- Francesco Chicchiricc? Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/ From mkosek at redhat.com Fri Jan 31 10:03:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 31 Jan 2014 11:03:33 +0100 Subject: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope In-Reply-To: <52EB70A3.4090606@apache.org> References: <52EA7F66.5040202@apache.org> <52EA9910.7030704@redhat.com> <52EB70A3.4090606@apache.org> Message-ID: <52EB74F5.1010002@redhat.com> On 01/31/2014 10:45 AM, Francesco Chicchiricc? wrote: > On 30/01/2014 19:25, Dmitri Pal wrote: >> On 01/30/2014 11:35 AM, Francesco Chicchiricc? wrote: ... >> To call into IPA you can use "ipa ..." command line or use out API from >> python client. Since you are using Java calling into "ipa" command is >> probably the best option. > > Actually, a RESTful interface (HTTP/JSON) would better suit our development > model and deployment scenarios. FreeIPA does not have (currently) not RESTful interface (though it is being partially designed in [8]). However it has a Kerberos-protected JSON-RPC/XML-RPC interface used by clients or Web UI to communicate with the server. We do not, however, have a good (read "none") documentation of the interface, see related discussion in freeipa-users list [6]. >> In future we plan to allow insertion of the users via an ldap command >> https://fedorahosted.org/freeipa/ticket/3911 it is on the roadmap for >> this spring. >> >> What are other use cases and workflows you have? >> Do you have a password reset self service? >> If you do it might be nice external addition to FreeIPA if it integrates >> into the UI seamlessly. > > The idea is to deploy the latest FreeIPA version in our lab, start playing with > it and come to this list for asking for more information we are not able to > find in the wiki (just to avoid some graceful RTFMs...). > Then, every time we get something working, we will also check here whether we > are heading into the right direction, if we are missing some important points, > etc. > > Does it sound? Sounds good to me, you should be able to find all documentation links in [7]. > > Regards. > >> [1] http://syncope.apache.org/ >> [2] http://tirasa.github.io/ConnId/ >> [3] http://java.net/projects/identityconnectors/ >> [4] https://github.com/Tirasa/ConnIdFreeIPABundle > [5] > http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html [7] http://www.freeipa.org/page/Documentation [8] http://www.freeipa.org/page/V3/Smart_Proxy Martin From dpal at redhat.com Fri Jan 31 11:52:46 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 31 Jan 2014 06:52:46 -0500 Subject: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope In-Reply-To: <52EB74F5.1010002@redhat.com> References: <52EA7F66.5040202@apache.org> <52EA9910.7030704@redhat.com> <52EB70A3.4090606@apache.org> <52EB74F5.1010002@redhat.com> Message-ID: <52EB8E8E.4040903@redhat.com> On 01/31/2014 05:03 AM, Martin Kosek wrote: > On 01/31/2014 10:45 AM, Francesco Chicchiricc? wrote: >> On 30/01/2014 19:25, Dmitri Pal wrote: >>> On 01/30/2014 11:35 AM, Francesco Chicchiricc? wrote: > ... >>> To call into IPA you can use "ipa ..." command line or use out API from >>> python client. Since you are using Java calling into "ipa" command is >>> probably the best option. >> Actually, a RESTful interface (HTTP/JSON) would better suit our development >> model and deployment scenarios. > FreeIPA does not have (currently) not RESTful interface (though it is being > partially designed in [8]). However it has a Kerberos-protected > JSON-RPC/XML-RPC interface used by clients or Web UI to communicate with the > server. I suggest that you look at the implementation of [8] and create a user provisioning smart proxy similar to it. This proxy would expose the REST API that can be consumed by your connector or some other system and will be a part of IPA. Internally proxy will call JSON RPC against IPA and have all the "busyness logic". So the recommendation is to make your connector lightwight and leverage a proxy that can be reused by other systems. > We do not, however, have a good (read "none") documentation of the interface, > see related discussion in freeipa-users list [6]. And would appreciate if you start a wiki page to record it as you go so that we can start documenting it. > >>> In future we plan to allow insertion of the users via an ldap command >>> https://fedorahosted.org/freeipa/ticket/3911 it is on the roadmap for >>> this spring. >>> >>> What are other use cases and workflows you have? >>> Do you have a password reset self service? >>> If you do it might be nice external addition to FreeIPA if it integrates >>> into the UI seamlessly. >> The idea is to deploy the latest FreeIPA version in our lab, start playing with >> it and come to this list for asking for more information we are not able to >> find in the wiki (just to avoid some graceful RTFMs...). >> Then, every time we get something working, we will also check here whether we >> are heading into the right direction, if we are missing some important points, >> etc. >> >> Does it sound? > Sounds good to me, you should be able to find all documentation links in [7]. +1 > >> Regards. >> >>> [1] http://syncope.apache.org/ >>> [2] http://tirasa.github.io/ConnId/ >>> [3] http://java.net/projects/identityconnectors/ >>> [4] https://github.com/Tirasa/ConnIdFreeIPABundle >> [5] >> http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html > [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html > [7] http://www.freeipa.org/page/Documentation > [8] http://www.freeipa.org/page/V3/Smart_Proxy > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Fri Jan 31 12:43:47 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 31 Jan 2014 13:43:47 +0100 Subject: [Freeipa-devel] [PATCHES] 0455-0459 Add support for managed permissions In-Reply-To: <52E28B64.9010403@redhat.com> References: <52CD738A.40105@redhat.com> <52DF8F0E.9020705@redhat.com> <52E0FBEC.2020303@redhat.com> <52E109CA.2020605@redhat.com> <1390484550.15404.79.camel@willson.li.ssimo.org> <52E28B64.9010403@redhat.com> Message-ID: <52EB9A83.1040705@redhat.com> On 01/24/2014 04:48 PM, Petr Viktorin wrote: > On 01/23/2014 02:42 PM, Simo Sorce wrote: >> On Thu, 2014-01-23 at 13:23 +0100, Petr Viktorin wrote: >>> On 01/23/2014 12:24 PM, Martin Kosek wrote: >>>> On 01/22/2014 10:27 AM, Petr Viktorin wrote: >>>>> On 01/08/2014 04:49 PM, Petr Viktorin wrote: >>>>>> Hello, >>>>>> This adds "managed" permissions, the framework that will make our >>>>>> default permissions merge IPA updates and user changes sanely. >>>>>> >>>>>> There is no updater yet, nor does this add any actual managed >>>>>> permissions, so there's no user-visible change (beyond help text and a >>>>>> disabled option). To test the patch you might need to touch LDAP directly. >>>>>> >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4033 >>>>>> Design (no updater & plugin changes yet): >>>>>> http://www.freeipa.org/page/V3/Managed_Read_permissions >>>>>> >>>>>> 0447 - Minor fixes. >>>>>> 0448 - Since you can't create managed permissions through the API, I >>>>>> needed to get creative with the declarative tests. The tests will need a >>>>>> custom function that adds a managed perm. >>>>>> 0449 - The change itself. >>>>> >>>>> ping; any thoughts on this one? >>>>> >>>>> >>>> >>>> 1) 449, the comment: >>>> >>>> +Deleting or renaming a managed permission, as well as changing its target, >>>> +is not supported. >>>> +""") + _(""" >>>> >>>> I am not sure that the phrase "not supported" is the right one. It sounds >>>> to me >>>> like this is something we want to allow, just not implemented yet. IMO "is not >>>> allowed" would be better. >>> >>> Makes sense. >>> >>>> 2) Can you add allow_mod_for_managed flag description to parameters.py? >>>> >>>> + flags={'no_create', 'allow_mod_for_managed'}, >>>> >>>> So far we try to add all flag descriptions there. >>> >>> OK >>> >>>> 3) When I updated the test to not delete the testperm, I tried to show the >>>> managed permission and it is not entirely clear, see: >>>> >>>> # ipa permission-show testperm >>>> Permission name: testperm >>>> Permissions: write >>>> * Attributes: cn, o, sn >>>> * Excluded attributes: cn, sn >>>> Bind rule type: all >>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>>> Type: user >>>> * Default attributes: l, o, cn >>>> * Effective attributes: l, o >>> >>> Well, this is a tradeoff between presenting what's stored in LDAP and >>> what's in the ACI. >>> >>>> The "Attributes" mean actually attributes explicitly allowed by user, but >>>> it is >>>> not obvious from the output. >>>> >>>> Maybe it would be better to return only "Effective attributes" by default and >>>> return the 3 source lists only when --all is passed. But this would require us >>>> to let Command override LDAPObject's default_attributes, which framework >>>> cannot do. >>> >>> Modifying default_attributes would not work because the 3 lists need to >>> be loaded from LDAP to determine the effective attributes. >>> It's possible to remove the extra attributes in the post_callback, >>> postprocess_result already does similar output manipulation. >>> >>>> Alternatively, we may choose to use the attributes differently with managed >>>> permissions: >>>> - we add the new attributeType "ipaPermIncludedAttr". It would be used for the >>>> user-specified whitelist of attributes instead of ipaPermAllowedAttr >>>> - we do not use the ipaPermAllowedAttr with managed attributes at all or >>>> use it >>>> for the "Effective attributes" list >>>> >>>> My point is that the semantics of ipaPermAllowedAttr is different for managed >>>> and non-managed permission, so it may confuse people. >>> >>> Well, the semantics are always the same (effective = (default | allowed) >>> - excluded). I agree that it can be confusing; perhaps I'm in too deep >>> to judge how it looks from the outside. >>> >>>> For example, you may want >>>> to search for all permissions that allow attribute "sn": >>>> >>>> # ipa permission-find --attrs sn >>>> --------------------- >>>> 4 permissions matched >>>> --------------------- >>>> Permission name: anon >>>> Permissions: read >>>> Attributes: sn >>>> Bind rule type: anonymous >>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>>> Type: user >>>> ... >>>> Permission name: testperm >>>> Permissions: write >>>> Attributes: cn, o, sn >>>> Excluded attributes: cn, sn >>>> Bind rule type: anonymous >>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>>> Type: user >>>> Default attributes: l, o, cn >>>> Effective attributes: l, o >>>> ... >>>> >>>> As you see, it matched both testperm and anon even though testperm does not >>>> really allow sn as it excluded. >>>> >>>> Thoughts? >>> >>> Well, we could have default, included, excluded attributes stored in >>> LDAP as now (using the name "included" instead of "allowed"), and make >>> effective attributes (--attrs) into an updatable virtual attribute: when >>> setting it, IPA would consult the "default" attributes and update >>> "included"/"excluded" accordingly. (With non-managed permissions >>> "default" is empty, so only "included" would be updated.) And searching >>> on --attrs would construct an appropriate filter. >>> >>> I thought about this approach earlier but thought that it obscured >>> what's actually stored in LDAP. Given recent discussions I'm now >>> thinking I shouldn't have rejected it. >> >> >> I would take a consistent approach indeed. >> I do not much care for the virtual attribute part in LDAP, as long as >> our tool show prominently the effective list. >> And also as long as all permissions behave the same way in the general >> mechanism in LDAP. >> >> Simo. >> > > All right. Here are patches; I'll start updating the design page. > > **NOTE** > This renames the 'ipaPermAllowedAttr' attribute to 'ipaPermIncludedAttr'. > Upgrades from master will fail, so please install a new server. Of course no > released versions of FreeIPA are affected. > I assume there's no clean way to rename an attribute without changing the OID? > Is it OK to break master this way? > > As before three source lists are stored in LDAP: > - ipaPermDefaultAttr > - ipaPermIncludedAttr (--includedattrs) > - ipaPermExcludedAttr (--excludedattrs) > > Setting --attrs ("Effective Attributes") will set the included/excluded > attributes based on the default set. > For normal permissions, default & excluded will be empty, and in this case only > effective attributes will be displayed on output (unless --all or --raw is given). > > > > I've added some preparatory patches for #4074 to this batch, mostly to prevent > rebase conflicts with that work. Re-numbering for a sane order. > > Apply on top of my patch 0452 > > 0455 - minor fixes, unchanged from 0447 > > 0456 - converting options on the server it will allow us to consult the entry's > existing state. Arguably it's also cleaner to use execute than > args_options_2_params for this. > > 0457 - generate ACIs in the plugin. This is the next step in obsoleting the ACI > class, which in the end should only be necessary for updating old-style ACIs. > The one-way function should be easier to maintain and extend. > > 0458 - allow callables in declarative tests, unchanged from 0448 > > 0459 - managed permissions > > > Or: git pull https://github.com/encukou/freeipa 3566-managed-perms > commit 51bb7f27516202a062ffa25fedae18d0e9f302b6 > 1) (cosmetic) Wouldn't it better to move ipapermdefaultattr to takes_params with ['no_create', 'no_update'] flags to: a) Have better ordering of output params. Now it looks like: # ipa permission-show testperm Permission name: testperm Permissions: write Effective attributes: cn, l, o, sn Included attributes: sn Bind rule type: all Subtree: cn=users,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com ACI target DN: uid=*,cn=users,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com Type: user Default attributes: l, o, cn I think it would be better if all the "* attributes" parameters are together.: Effective attributes: bla, bla Included attributes: bla, bla Excluded attributes: bla, bla Default attributes: bla, bla so that it is easier to read the output. b) If ipapermdefaultattr is in takes_params, one would be able to do permission-search for default attributes. Even if we don't allow user to change them, we should allow him to search them. 2) (also cosmetic) Given we have ipapermincludedattr described as doc=_('User-specified attributes to which the permission applies'), shouldn't we also describe ipapermexcludedattr as doc=_('User-specified attributes to which the permission explicitly ' 'does not apply'), ? I think it would be more consistent. Besides these 2 cosmetic issues, I think the new patchset works pretty nice - good job! Martin From ilgrosso at apache.org Fri Jan 31 13:17:05 2014 From: ilgrosso at apache.org (=?ISO-8859-1?Q?Francesco_Chicchiricc=F2?=) Date: Fri, 31 Jan 2014 14:17:05 +0100 Subject: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope In-Reply-To: <52EB8E8E.4040903@redhat.com> References: <52EA7F66.5040202@apache.org> <52EA9910.7030704@redhat.com> <52EB70A3.4090606@apache.org> <52EB74F5.1010002@redhat.com> <52EB8E8E.4040903@redhat.com> Message-ID: <52EBA251.6070208@apache.org> On 31/01/2014 12:52, Dmitri Pal wrote: > On 01/31/2014 05:03 AM, Martin Kosek wrote: >> On 01/31/2014 10:45 AM, Francesco Chicchiricc? wrote: >>> On 30/01/2014 19:25, Dmitri Pal wrote: >>>> On 01/30/2014 11:35 AM, Francesco Chicchiricc? wrote: >> ... >>>> To call into IPA you can use "ipa ..." command line or use out API from >>>> python client. Since you are using Java calling into "ipa" command is >>>> probably the best option. >>> Actually, a RESTful interface (HTTP/JSON) would better suit our development >>> model and deployment scenarios. >> FreeIPA does not have (currently) not RESTful interface (though it is being >> partially designed in [8]). However it has a Kerberos-protected >> JSON-RPC/XML-RPC interface used by clients or Web UI to communicate with the >> server. > I suggest that you look at the implementation of [8] and create a user > provisioning smart proxy similar to it. > This proxy would expose the REST API that can be consumed by your > connector or some other system and will be a part of IPA. > Internally proxy will call JSON RPC against IPA and have all the > "busyness logic". > So the recommendation is to make your connector lightwight and leverage > a proxy that can be reused by other systems. Are you saying that we should split our development in two: (1) smart proxy, exposing the RESTful interface, developed on the basis of [8] (2) actual ConnId connector, dealing with the proxy above for implementing its own logic If so, could you please point to the source code of [8]? Will then this eventually become part of FreeIPA? I am actually not sure if it is "lightweight" connector could actually be better than a "loaded" connector (e.g. without proxy), from a deployment point of view, unless you are saying either that (a) a smart proxy is already available that can be reused or that (b) incorporating the smart proxy that we are going to develop into FreeIPA will easily happen. >> We do not, however, have a good (read "none") documentation of the interface, >> see related discussion in freeipa-users list [6]. > And would appreciate if you start a wiki page to record it as you go so > that we can start documenting it. > >>>> In future we plan to allow insertion of the users via an ldap command >>>> https://fedorahosted.org/freeipa/ticket/3911 it is on the roadmap for >>>> this spring. >>>> >>>> What are other use cases and workflows you have? >>>> Do you have a password reset self service? >>>> If you do it might be nice external addition to FreeIPA if it integrates >>>> into the UI seamlessly. >>> The idea is to deploy the latest FreeIPA version in our lab, start playing with >>> it and come to this list for asking for more information we are not able to >>> find in the wiki (just to avoid some graceful RTFMs...). >>> Then, every time we get something working, we will also check here whether we >>> are heading into the right direction, if we are missing some important points, >>> etc. >>> >>> Does it sound? >> Sounds good to me, you should be able to find all documentation links in [7]. > +1 > >>>> [1] http://syncope.apache.org/ >>>> [2] http://tirasa.github.io/ConnId/ >>>> [3] http://java.net/projects/identityconnectors/ >>>> [4] https://github.com/Tirasa/ConnIdFreeIPABundle >>> [5] >>> http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html >> [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html >> [7] http://www.freeipa.org/page/Documentation >> [8] http://www.freeipa.org/page/V3/Smart_Proxy -- Francesco Chicchiricc? Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/ From pspacek at redhat.com Fri Jan 31 13:43:47 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 31 Jan 2014 14:43:47 +0100 Subject: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope In-Reply-To: <52EBA251.6070208@apache.org> References: <52EA7F66.5040202@apache.org> <52EA9910.7030704@redhat.com> <52EB70A3.4090606@apache.org> <52EB74F5.1010002@redhat.com> <52EB8E8E.4040903@redhat.com> <52EBA251.6070208@apache.org> Message-ID: <52EBA893.7040703@redhat.com> On 31.1.2014 14:17, Francesco Chicchiricc? wrote: > On 31/01/2014 12:52, Dmitri Pal wrote: >> On 01/31/2014 05:03 AM, Martin Kosek wrote: >>> On 01/31/2014 10:45 AM, Francesco Chicchiricc? wrote: >>>> On 30/01/2014 19:25, Dmitri Pal wrote: >>>>> On 01/30/2014 11:35 AM, Francesco Chicchiricc? wrote: >>> ... >>>>> To call into IPA you can use "ipa ..." command line or use out API from >>>>> python client. Since you are using Java calling into "ipa" command is >>>>> probably the best option. >>>> Actually, a RESTful interface (HTTP/JSON) would better suit our development >>>> model and deployment scenarios. >>> FreeIPA does not have (currently) not RESTful interface (though it is being >>> partially designed in [8]). However it has a Kerberos-protected >>> JSON-RPC/XML-RPC interface used by clients or Web UI to communicate with the >>> server. >> I suggest that you look at the implementation of [8] and create a user >> provisioning smart proxy similar to it. >> This proxy would expose the REST API that can be consumed by your >> connector or some other system and will be a part of IPA. >> Internally proxy will call JSON RPC against IPA and have all the >> "busyness logic". >> So the recommendation is to make your connector lightwight and leverage >> a proxy that can be reused by other systems. > > Are you saying that we should split our development in two: > > (1) smart proxy, exposing the RESTful interface, developed on the basis of [8] > > (2) actual ConnId connector, dealing with the proxy above for implementing its > own logic > > If so, could you please point to the source code of [8]? > Will then this eventually become part of FreeIPA? > > I am actually not sure if it is "lightweight" connector could actually be > better than a "loaded" connector (e.g. without proxy), from a deployment point > of view, unless you are saying either that (a) a smart proxy is already > available that can be reused or that (b) incorporating the smart proxy that we > are going to develop into FreeIPA will easily happen. First patches with SmartProxy were posted to devel mailing list some time ago: https://www.redhat.com/archives/freeipa-devel/2014-January/msg00213.html We plan to integrate SmartProxy to the source main tree: See ticket https://fedorahosted.org/freeipa/ticket/4128 Petr^2 Spacek >>> We do not, however, have a good (read "none") documentation of the interface, >>> see related discussion in freeipa-users list [6]. >> And would appreciate if you start a wiki page to record it as you go so >> that we can start documenting it. >> >>>>> In future we plan to allow insertion of the users via an ldap command >>>>> https://fedorahosted.org/freeipa/ticket/3911 it is on the roadmap for >>>>> this spring. >>>>> >>>>> What are other use cases and workflows you have? >>>>> Do you have a password reset self service? >>>>> If you do it might be nice external addition to FreeIPA if it integrates >>>>> into the UI seamlessly. >>>> The idea is to deploy the latest FreeIPA version in our lab, start playing >>>> with >>>> it and come to this list for asking for more information we are not able to >>>> find in the wiki (just to avoid some graceful RTFMs...). >>>> Then, every time we get something working, we will also check here whether we >>>> are heading into the right direction, if we are missing some important >>>> points, >>>> etc. >>>> >>>> Does it sound? >>> Sounds good to me, you should be able to find all documentation links in [7]. >> +1 >> >>>>> [1] http://syncope.apache.org/ >>>>> [2] http://tirasa.github.io/ConnId/ >>>>> [3] http://java.net/projects/identityconnectors/ >>>>> [4] https://github.com/Tirasa/ConnIdFreeIPABundle >>>> [5] >>>> http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html >>>> >>> [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html >>> [7] http://www.freeipa.org/page/Documentation >>> [8] http://www.freeipa.org/page/V3/Smart_Proxy From mbasti at redhat.com Fri Jan 31 15:06:04 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 31 Jan 2014 16:06:04 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains Message-ID: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> Reverse domain names in form "0/28.0.10.10.in-addr.arpa." are now allowed. Ticket: https://fedorahosted.org/freeipa/ticket/4143 Patches attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0024-DNS-classless-support-for-reverse-domains.patch Type: text/x-patch Size: 9656 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0025-DNS-tests-for-classless-reverse-domains.patch Type: text/x-patch Size: 14149 bytes Desc: not available URL: From rcritten at redhat.com Fri Jan 31 15:39:05 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 31 Jan 2014 10:39:05 -0500 Subject: [Freeipa-devel] [PATCH] 455 Fallback to global policy in ipa-lockout plugin In-Reply-To: <52EB5ECE.2010500@redhat.com> References: <52EA771A.3080708@redhat.com> <52EA97CC.8030203@redhat.com> <52EB5ECE.2010500@redhat.com> Message-ID: <52EBC399.4030109@redhat.com> Martin Kosek wrote: > On 01/30/2014 07:19 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> krbPwdPolicyReference is no longer filled default users. Instead, plugins >>> fallback to hardcoded global policy reference. >>> >>> Fix ipa-lockout plugin to fallback to it instead of failing to apply >>> the policy. >>> >>> https://fedorahosted.org/freeipa/ticket/4085 >> >> NACK. >> >> I think you should include the value of krberr in error messages (we aren't >> exactly consistent in this elsewhere in the code but we need to start somewhere). >> >> You check the wrong value after the krb5_get_default_realm() call. >> >> It is probably better to use slapi_ch_free_string() than free(). >> >> At some point we'll need a common library where this sort of operation can be >> done. >> >> rob > > Good catch, sending updated patch. > > Martin > ACK From mbasti at redhat.com Fri Jan 31 15:41:52 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 31 Jan 2014 16:41:52 +0100 Subject: [Freeipa-devel] [PATCH 0026] PTR records can be added without specify FQDN zone name Message-ID: <1391182912.2394.6.camel@unused-4-145.brq.redhat.com> One liner. Ticket: https://fedorahosted.org/freeipa/ticket/4151 Patch attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0026-PTR-records-can-be-added-without-specify-FQDN-zone-n.patch Type: text/x-patch Size: 913 bytes Desc: not available URL: From dpal at redhat.com Fri Jan 31 17:57:17 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 31 Jan 2014 12:57:17 -0500 Subject: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope In-Reply-To: <52EBA251.6070208@apache.org> References: <52EA7F66.5040202@apache.org> <52EA9910.7030704@redhat.com> <52EB70A3.4090606@apache.org> <52EB74F5.1010002@redhat.com> <52EB8E8E.4040903@redhat.com> <52EBA251.6070208@apache.org> Message-ID: <52EBE3FD.3030709@redhat.com> On 01/31/2014 08:17 AM, Francesco Chicchiricc? wrote: > > Are you saying that we should split our development in two: > > (1) smart proxy, exposing the RESTful interface, developed on the > basis of [8] > > (2) actual ConnId connector, dealing with the proxy above for > implementing its own logic Correct > > If so, could you please point to the source code of [8]? > Will then this eventually become part of FreeIPA? > Quite soon. I would leave it to the team to suggest whether user and host provisioning smart proxies should be a same smart proxy or different so that they can be installed independently from each other but use the same approach. IMO haveing them separately but share the same code and approach will be more valuable to the project. But I am open to other ideas here. > I am actually not sure if it is "lightweight" connector could actually > be better than a "loaded" connector (e.g. without proxy), from a > deployment point of view, unless you are saying either that (a) a > smart proxy is already available that can be reused The idea can be reused as a starting point. IMO the easiest would be to look at the patches and use same machinery but implement different commands. > or that (b) incorporating the smart proxy that we are going to develop > into FreeIPA will easily happen. If done right: i.e. following process and style then yes. Please become familiar with the coding style [9] page on the wiki and other contributer guidelines [10]. Also having a design page created as a result of the preliminary investigation would go a long way towards acceptance and quality of the feature. We will gladly guide you on the way if you have specific questions [...] >>>>> [2] http://tirasa.github.io/ConnId/ >>>>> [3] http://java.net/projects/identityconnectors/ >>>>> [4] https://github.com/Tirasa/ConnIdFreeIPABundle >>>> [5] >>>> http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html >>>> >>> [6] >>> https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html >>> >>> [7] http://www.freeipa.org/page/Documentation >>> [8] http://www.freeipa.org/page/V3/Smart_Proxy > [1] http://syncope.apache.org/ > [9] http://www.freeipa.org/page/Coding_Style [10] http://www.freeipa.org/page/Contribute/Code -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From npmccallum at redhat.com Fri Jan 31 20:20:54 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 31 Jan 2014 15:20:54 -0500 Subject: [Freeipa-devel] [PATCH 0034] Teach ipa-pwd-extop to respect global ipaUserAuthType settings Message-ID: <1391199654.20303.31.camel@localhost.localdomain> This patch addresses bug #4105: https://fedorahosted.org/freeipa/ticket/4105 It depends on all my previous OTP patches. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0034-Teach-ipa-pwd-extop-to-respect-global-ipaUserAuthTyp.patch Type: text/x-patch Size: 34776 bytes Desc: not available URL: