[Freeipa-devel] [PATCH] 0467 permission plugin: Do not assume attribute-level rights for new attributes are present
Hello,
This fixes https://fedorahosted.org/freeipa/ticket/4121
Apply on top of my patches 0464-0466.
--
Petr³
From 494c25e8a5409d66edc9651b6b5a9aba07917eb7 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Tue, 21 Jan 2014 12:13:47 +0100
Subject: [PATCH] permission plugin: Do not assume attribute-level rights for
new attributes are present
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.
Add a check that the data is present before using it.
https://fedorahosted.org/freeipa/ticket/4121
---
ipalib/plugins/permission.py | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/ipalib/plugins/permission.py b/ipalib/plugins/permission.py
index 947bdda975fc7f820dfaa80203febdee261e26fc..622f5118de44b1f3de65a6b329b231a3018959c0 100644
--- a/ipalib/plugins/permission.py
+++ b/ipalib/plugins/permission.py
@@ -337,13 +337,16 @@ def postprocess_result(self, entry, options):
rights = entry.get('attributelevelrights')
if rights:
-rights['memberof'] = rights['ipapermtargetfilter']
-rights['targetgroup'] = rights['ipapermtarget']
+if 'ipapermtarget' in rights:
+rights['targetgroup'] = rights['ipapermtarget']
+if 'ipapermtargetfilter' in rights:
+rights['memberof'] = rights['ipapermtargetfilter']
-type_rights = set(rights['ipapermtargetfilter'])
-type_rights.intersection_update(rights['ipapermlocation'])
-rights['type'] = ''.join(sorted(
-type_rights, key=rights['ipapermtargetfilter'].index))
+type_rights = set(rights['ipapermtargetfilter'])
+location_rights = set(rights.get('ipapermlocation', ''))
+type_rights.intersection_update(location_rights)
+rights['type'] = ''.join(sorted(
+type_rights, key=rights['ipapermtargetfilter'].index))
if 'ipapermincludedattr' in rights:
rights['attrs'] = ''.join(sorted(
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] OTP Patches
On Wed, 12 Feb 2014, Nathaniel McCallum wrote:
Through the review process, patches are getting shifted around, added,
deleted, etc. So I'm now just going to be posting all the patches as an
ordered set. The set attached is ordered according to my preferred merge
order. It also places easy to review patches up front. I hope this helps
reviewers. This format will definitely help me manage the patches.
The first three patches should be very easy reviews and can be merged
independently.
All current patch critiques have, to my knowledge, been addressed in
this latest series of patches.
I have tested all the patches altogether, including Web UI patches, and
everything works.
I have set up a COPR repo for others to try:
http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/
However, there is one issue which I was not yet able to pin-point in the
SLAPI plugins. During FreeIPA install and later on actual use I see
these in the dirsrv error log:
[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter
[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL
[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter
[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL
[13/Feb/2014:14:33:01 +0200] - SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN plugin
returned error code -1
[13/Feb/2014:14:33:11 +0200] - slapi_search_internal_set_pb: NULL parameter
[13/Feb/2014:14:33:11 +0200] - allow_operation: component identity is NULL
[13/Feb/2014:14:45:53 +0200] - slapi_search_internal_set_pb: NULL parameter
[13/Feb/2014:14:45:53 +0200] - allow_operation: component identity is NULL
Additionally, when slapi-nis is enabled, LDAP bind with identity from
compat tree fails for OTP use and succeeds for password authentication.
In compat tree we are doing this trick:
1731 /* Otherwise force rewrite of the SLAPI_BIND_TARGET_SDN
1732 * and let other plugins to handle it.
1733 * slapi-nis should have plugin ordering set below standard 50
to succeed */
1734 slapi_pblock_get(pb, SLAPI_BIND_TARGET_SDN, sdn);
1735 if (sdn != NULL) {
1736 slapi_sdn_free(sdn);
1737 }
1738 sdn = slapi_sdn_new_dn_byref(ndn);
1739 slapi_pblock_set(pb, SLAPI_BIND_TARGET_SDN, (void*)sdn);
1740 ret = 0;
1741 }
I tried to play with plugin precedence and it didn't really help.
There is definitely a bug (or more) in ipa-pwd-extop in handling
authentication cases.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH][DOC] 432 Add direct bug reporting links to Feedback section
On 11/08/2013 10:18 AM, Martin Kosek wrote: On 10/17/2013 12:04 PM, Martin Kosek wrote: On 10/17/2013 07:25 AM, Petr Spacek wrote: On 17.10.2013 03:06, Simo Sorce wrote: On Wed, 2013-10-16 at 21:59 +0200, Petr Spacek wrote: On 16.10.2013 15:31, Martin Kosek wrote: This change should enable faster and easier filing of new bugs. Patch also simplifies the section for both redhat and fedora variants. https://fedorahosted.org/freeipa/ticket/3754 Hmm, is there a way to add the Report a bug link to each page footer (in HTML output)? I think that people should see this option all the time. This recalls me another thing: Could we add TICKET_CREATE privilege to anonymous 'subject' in the Trac? This should allow anyone to create ticket even without registration/logging in, which lowers the barrier. Bad idea, you'll soon be submerge by the worst looking spam, seriously, don't do it. Besides you wouldn't be able to notify the reporter that you need more info and so on, its not worth to have fire-and-forget reports. There is an input box for reporter's e-mail... Yeah, I wonder who would fill it. I would personally leave it as is, when someone really does not not want to register to Fedora, he can send a mail to freeipa-users (and thus also give as a way to ask back). Martin I hope that this question was resolved. As for Report a bug link on each page footer, I am not sure if Publican can do that and I am also not sure if it would not be disturbing. I would rather like to let us review the requested change and provided patch. IMO the provided Trac/Bugzilla links makes the bug filing easier, which was the point of the ticket - please review. Let us review the change and continue with other doc improvements, there is a lot of those on our plate in this area. Martin This patch is stale - the doc patch is on the list, ready and waiting. Petr, if it is ok with you, let's ackpush it, if not and you have reasonable other proposal, let's do it. If you think the ticket does not make sense, let's close it. I just want to see some action and avoid having 4 months long thread for a minor improvement ticket. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] DNSSEC design page
Hello list, I would like to point you to design pages for DNSSEC feature: Zone signing: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC Automatic key rotation: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm You can ignore bind-dyndb-ldap specifics and think about interactions with FreeIPA and SSSD. - We need to design LDAP schema for key storage (Ludwig is looking into it). - We need to write PKCS#11 module on top of LDAP database. - We need to design key rotation on client side (SSSD? Certmonger?). - We need to design WebUI/CLI etc. Read sections 'External Impact' carefully :-) Have a nice day! -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] OTP Patches
On Wed, 12 Feb 2014, Nathaniel McCallum wrote: Through the review process, patches are getting shifted around, added, deleted, etc. So I'm now just going to be posting all the patches as an ordered set. The set attached is ordered according to my preferred merge order. It also places easy to review patches up front. I hope this helps reviewers. This format will definitely help me manage the patches. The first three patches should be very easy reviews and can be merged independently. All current patch critiques have, to my knowledge, been addressed in this latest series of patches. 0001-Fix-OTP-token-names-labels.patch - ACK 0002-Fix-generation-of-invalid-OTP-URIs.patch - ACK 0003-Update-ACIs-to-permit-users-to-add.patch - ACK -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] OTP Patches
On 02/13/2014 06:56 PM, Alexander Bokovoy wrote: On Wed, 12 Feb 2014, Nathaniel McCallum wrote: Through the review process, patches are getting shifted around, added, deleted, etc. So I'm now just going to be posting all the patches as an ordered set. The set attached is ordered according to my preferred merge order. It also places easy to review patches up front. I hope this helps reviewers. This format will definitely help me manage the patches. The first three patches should be very easy reviews and can be merged independently. All current patch critiques have, to my knowledge, been addressed in this latest series of patches. 0001-Fix-OTP-token-names-labels.patch - ACK 0002-Fix-generation-of-invalid-OTP-URIs.patch - ACK 0003-Update-ACIs-to-permit-users-to-add.patch - ACK Pushed to master: a91c0972b992dbd15e78f2ba6982768ac958e4bd -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH][DOC] 432 Add direct bug reporting links to Feedback section
On 13.2.2014 14:33, Martin Kosek wrote: On 11/08/2013 10:18 AM, Martin Kosek wrote: On 10/17/2013 12:04 PM, Martin Kosek wrote: On 10/17/2013 07:25 AM, Petr Spacek wrote: On 17.10.2013 03:06, Simo Sorce wrote: On Wed, 2013-10-16 at 21:59 +0200, Petr Spacek wrote: On 16.10.2013 15:31, Martin Kosek wrote: This change should enable faster and easier filing of new bugs. Patch also simplifies the section for both redhat and fedora variants. https://fedorahosted.org/freeipa/ticket/3754 Hmm, is there a way to add the Report a bug link to each page footer (in HTML output)? I think that people should see this option all the time. This recalls me another thing: Could we add TICKET_CREATE privilege to anonymous 'subject' in the Trac? This should allow anyone to create ticket even without registration/logging in, which lowers the barrier. Bad idea, you'll soon be submerge by the worst looking spam, seriously, don't do it. Besides you wouldn't be able to notify the reporter that you need more info and so on, its not worth to have fire-and-forget reports. There is an input box for reporter's e-mail... Yeah, I wonder who would fill it. I would personally leave it as is, when someone really does not not want to register to Fedora, he can send a mail to freeipa-users (and thus also give as a way to ask back). Martin I hope that this question was resolved. As for Report a bug link on each page footer, I am not sure if Publican can do that and I am also not sure if it would not be disturbing. I would rather like to let us review the requested change and provided patch. IMO the provided Trac/Bugzilla links makes the bug filing easier, which was the point of the ticket - please review. Let us review the change and continue with other doc improvements, there is a lot of those on our plate in this area. Martin This patch is stale - the doc patch is on the list, ready and waiting. Petr, if it is ok with you, let's ackpush it, if not and you have reasonable other proposal, let's do it. If you think the ticket does not make sense, let's close it. I just want to see some action and avoid having 4 months long thread for a minor improvement ticket. Sure, this have fallen through cracks. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
Martin Kosek wrote: On 01/28/2014 09:35 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 01/23/2014 02:17 PM, Petr Viktorin wrote: ... 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. +1 for moving to /ipa/smartproxy/rest, we will want a complete REST interface in ipa/rest/ in the future. I rather opened a ticket to track that: https://fedorahosted.org/freeipa/ticket/4168 Martin I think I've addressed most of Petr's suggestions with the exception of the global ipa handle and I stuck with *args, **options as this is pretty much standard in IPA calls. The gssproxy.conf.snippet just makes it easier to copy/paste. I can drop it if you want, I suppose it is duplication. Note that I ran this past the Foreman design again and as a result added another interface, /realm. It was my understanding that this Foreman design wasn't set into stone but a patch is working its way through their system that followed the spec so I went ahead and added it. It isn't a big deal, the Host() class handles it out of the box. I also updated the design page a bit to reflect some of the changes made. Right now there are no plans to backport python-kerberos to F20. rob From 9ef273d6ef13ff6fd420af6f3b673b69b20fa875 Mon Sep 17 00:00:00 2001 From: Rob Crittenden rcrit...@redhat.com Date: Tue, 3 Dec 2013 09:14:00 -0700 Subject: [PATCH] Implement an IPA REST server This currently server supports only host and hostgroup commands for retrieving, adding and deleting entries. The incoming requests are completely unauthenticated and by default requests must be local. Utilize GSS-Proxy to manage the TGT. Configuration information is in the ipa-rest man page. Design: http://www.freeipa.org/page/V3/Smart_Proxy --- Makefile | 5 +- freeipa.spec.in| 23 +++ ipalib/util.py | 13 +- ipatests/test_smartproxy/resttest.py | 170 + ipatests/test_smartproxy/test_host.py | 145 ++ ipatests/test_smartproxy/test_hostgroup.py | 97 ++ smartproxy/Makefile.am | 43 + smartproxy/configure.ac| 75 smartproxy/gssproxy.conf.snippet | 6 + smartproxy/ipa-rest| 293 + smartproxy/ipa-rest.conf | 15 ++ smartproxy/ipa-rest.logrotate | 11 ++ smartproxy/ipa-rest.service| 12 ++ smartproxy/man/Makefile.am | 19 ++ smartproxy/man/ipa-rest.1 | 78 smartproxy/man/ipa-rest.conf.5 | 72 +++ 16 files changed, 1071 insertions(+), 6 deletions(-) create mode 100644 ipatests/test_smartproxy/resttest.py create mode 100644 ipatests/test_smartproxy/test_host.py create mode 100644 ipatests/test_smartproxy/test_hostgroup.py create mode 100644 smartproxy/Makefile.am create mode 100644 smartproxy/configure.ac create mode 100644 smartproxy/gssproxy.conf.snippet create mode 100755 smartproxy/ipa-rest create mode 100644 smartproxy/ipa-rest.conf create mode 100644 smartproxy/ipa-rest.logrotate create mode 100644 smartproxy/ipa-rest.service create mode 100644 smartproxy/man/Makefile.am create mode 100644 smartproxy/man/ipa-rest.1 create mode 100644 smartproxy/man/ipa-rest.conf.5 diff --git a/Makefile b/Makefile index 0a300b4ba3a0706f85255d74ecc7030fe99b76e2..9d6d93ded9985052c2327adee9a206723671cb82 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,6 @@ include VERSION -SUBDIRS=daemons install ipapython ipa-client +SUBDIRS=daemons install ipapython ipa-client smartproxy CLIENTDIRS=ipapython ipa-client PRJ_PREFIX=freeipa @@ -74,6 +74,7 @@ bootstrap-autogen: version-update client-autogen @echo Building IPA $(IPA_VERSION) cd daemons; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=$(LIBDIR) --with-openldap; fi cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=$(LIBDIR); fi + cd smartproxy; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=$(LIBDIR); fi client-autogen: version-update cd ipa-client; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=$(LIBDIR); fi @@ -194,6 +195,7 @@ tarballs: local-archive cd dist/$(TARBALL_PREFIX)/ipa-client; ../autogen.sh --prefix=/usr --sysconfdir=/etc
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
On 02/13/2014 06:07 PM, Rob Crittenden wrote: Martin Kosek wrote: On 01/28/2014 09:35 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 01/23/2014 02:17 PM, Petr Viktorin wrote: ... 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. +1 for moving to /ipa/smartproxy/rest, we will want a complete REST interface in ipa/rest/ in the future. I rather opened a ticket to track that: https://fedorahosted.org/freeipa/ticket/4168 Martin I think I've addressed most of Petr's suggestions with the exception of the global ipa handle and I stuck with *args, **options as this is pretty much standard in IPA calls. The gssproxy.conf.snippet just makes it easier to copy/paste. I can drop it if you want, I suppose it is duplication. Note that I ran this past the Foreman design again and as a result added another interface, /realm. It was my understanding that this Foreman design wasn't set into stone but a patch is working its way through their system that followed the spec so I went ahead and added it. It isn't a big deal, the Host() class handles it out of the box. I also updated the design page a bit to reflect some of the changes made. Right now there are no plans to backport python-kerberos to F20. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Recently we had a ticket in SSSD https://fedorahosted.org/sssd/ticket/2217 Should we have a similar one for IPA client and especially for the proxy? Proxy will be a long term running process so dealing with the stale tickets becomes important for it if replica is re-installed. Is it something that is solved in API level or on the proxy level? Should we have a separate ticket for that? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
Dmitri Pal wrote: On 02/13/2014 06:07 PM, Rob Crittenden wrote: Martin Kosek wrote: On 01/28/2014 09:35 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 01/23/2014 02:17 PM, Petr Viktorin wrote: ... 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. +1 for moving to /ipa/smartproxy/rest, we will want a complete REST interface in ipa/rest/ in the future. I rather opened a ticket to track that: https://fedorahosted.org/freeipa/ticket/4168 Martin I think I've addressed most of Petr's suggestions with the exception of the global ipa handle and I stuck with *args, **options as this is pretty much standard in IPA calls. The gssproxy.conf.snippet just makes it easier to copy/paste. I can drop it if you want, I suppose it is duplication. Note that I ran this past the Foreman design again and as a result added another interface, /realm. It was my understanding that this Foreman design wasn't set into stone but a patch is working its way through their system that followed the spec so I went ahead and added it. It isn't a big deal, the Host() class handles it out of the box. I also updated the design page a bit to reflect some of the changes made. Right now there are no plans to backport python-kerberos to F20. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Recently we had a ticket in SSSD https://fedorahosted.org/sssd/ticket/2217 Should we have a similar one for IPA client and especially for the proxy? Proxy will be a long term running process so dealing with the stale tickets becomes important for it if replica is re-installed. Is it something that is solved in API level or on the proxy level? Should we have a separate ticket for that? Using gss-proxy so it's not our problem. We never touch tickets. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
On 02/13/2014 09:02 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/13/2014 06:07 PM, Rob Crittenden wrote: Martin Kosek wrote: On 01/28/2014 09:35 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 01/23/2014 02:17 PM, Petr Viktorin wrote: ... 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. +1 for moving to /ipa/smartproxy/rest, we will want a complete REST interface in ipa/rest/ in the future. I rather opened a ticket to track that: https://fedorahosted.org/freeipa/ticket/4168 Martin I think I've addressed most of Petr's suggestions with the exception of the global ipa handle and I stuck with *args, **options as this is pretty much standard in IPA calls. The gssproxy.conf.snippet just makes it easier to copy/paste. I can drop it if you want, I suppose it is duplication. Note that I ran this past the Foreman design again and as a result added another interface, /realm. It was my understanding that this Foreman design wasn't set into stone but a patch is working its way through their system that followed the spec so I went ahead and added it. It isn't a big deal, the Host() class handles it out of the box. I also updated the design page a bit to reflect some of the changes made. Right now there are no plans to backport python-kerberos to F20. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Recently we had a ticket in SSSD https://fedorahosted.org/sssd/ticket/2217 Should we have a similar one for IPA client and especially for the proxy? Proxy will be a long term running process so dealing with the stale tickets becomes important for it if replica is re-installed. Is it something that is solved in API level or on the proxy level? Should we have a separate ticket for that? Using gss-proxy so it's not our problem. We never touch tickets. rob Does gss proxy solve this problem? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
