Re: [Freeipa-devel] [PATCH] 543 Trust domains Web UI
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 543 Trust domains Web UI
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0137 ipasam: remove child domains before removing trust
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0137 ipasam: remove child domains before removing trust
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
From 75d9594d9388f92a57f5cb99b20e9f1950ab0a15 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy aboko...@redhat.com
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
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0137 ipasam: remove child domains before removing trust
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
From 4c58609f8e0e18f9fb4af82e176bad7cad2d20b4 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy aboko...@redhat.com
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
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0137 ipasam: remove child domains before removing trust
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 543 Trust domains Web UI
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 543 Trust domains Web UI
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0137 ipasam: remove child domains before removing trust
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0452 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.
Check that the data is present before using it.
https://fedorahosted.org/freeipa/ticket/4121
--
Petr³
From 3fb216a5ff1e69527eb6c349cafc6965f641c238 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.
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 16d5fc9cff7f3b40861db2c4623bc38c70d25692..e3c8dc6daf52c5dc78c73b4c94e309f3a251bd75 100644
--- a/ipalib/plugins/permission.py
+++ b/ipalib/plugins/permission.py
@@ -293,13 +293,16 @@ def postprocess_result(self, entry, options):
rights = entry.get('attributelevelrights')
if rights:
-rights['memberof'] = rights['ipapermtargetfilter']
-rights['targetgroup'] = rights['ipapermtarget']
+if 'ipapermtargetfilter' in rights:
+rights['memberof'] = rights['ipapermtargetfilter']
+if 'ipapermtarget' in rights:
+rights['targetgroup'] = rights['ipapermtarget']
-type_rights = set(rights['ipapermtarget'])
-type_rights.intersection_update(rights['ipapermlocation'])
-rights['type'] = ''.join(sorted(type_rights,
-key=rights['ipapermtarget'].index))
+type_rights = set(rights['ipapermtarget'])
+location_rights = set(rights.get('ipapermlocation', ''))
+type_rights.intersection_update(location_rights)
+rights['type'] = ''.join(sorted(
+type_rights, key=rights['ipapermtarget'].index))
if not client_has_capability(options['version'], 'permissions2'):
for old_name, new_name in _DEPRECATED_OPTION_ALIASES.items():
--
1.8.4.2
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile
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: simo 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 ? jcholast yep simo and what happens when I create other.ipa.net with altname two.ipa.net ? simo does HTTP/two.ipa.net now have 2 certificates anchored ? jcholast 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 From 8c0d512b077b1e62af1be5c11f786b8458856e3b Mon Sep 17 00:00:00 2001 From: Jan Cholasta jchol...@redhat.com Date: Thu, 5 Dec 2013 14:34:14 +0100 Subject: [PATCH 1/2] Allow SAN in IPA certificate profile. https://fedorahosted.org/freeipa/ticket/3977 --- install/tools/ipa-upgradeconfig | 7 +- ipaserver/install/cainstance.py | 51 + 2 files changed, 57
Re: [Freeipa-devel] [PATCH] 448-449 Switch httpd to use default CCACHE
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³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 448-449 Switch httpd to use default CCACHE
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
From 3b6683c7a3da885350542157aae2afa0b3cdd37e Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Thu, 16 Jan 2014 14:10:42 +0100
Subject: [PATCH 1/2] Add runas option to run function
Run function can now run the specified command as different user by
setting the both real and effective UID and GID for executed process.
Add both the missing run function attribute doc strings as well as
a doc string for the runas attribute.
---
ipapython/ipautil.py | 59 +---
1 file changed, 38 insertions(+), 21 deletions(-)
diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py
index a25dc358b9ddf9681925491ec1c4cd2de03d6b00..4ed32a6ad25daab2a606556cc0f532918abbfec1 100644
--- a/ipapython/ipautil.py
+++ b/ipapython/ipautil.py
@@ -42,6 +42,7 @@
import netaddr
import time
import krbV
+import pwd
from dns import resolver, rdatatype
from dns.exception import DNSException
@@ -246,29 +247,35 @@ def shell_quote(string):
return ' + string.replace(', '\\'') + '
def run(args, stdin=None, raiseonerr=True,
-nolog=(), env=None, capture_output=True, skip_output=False, cwd=None):
+nolog=(), env=None, capture_output=True, skip_output=False, cwd=None,
+runas=None):
Execute a command and return stdin, stdout and the process return code.
-args is a list of arguments for the command
-
-stdin is used if you want to pass input to the command
-
-raiseonerr raises an exception if the return code is not zero
-
-nolog is a tuple of strings that shouldn't be logged, like passwords.
-Each tuple consists of a string to be replaced by .
-
-For example, the command ['/usr/bin/setpasswd', '--password', 'Secret123', 'someuser']
-
-We don't want to log the password so nolog would be set to:
-('Secret123',)
-
-The resulting log output would be:
-
-/usr/bin/setpasswd --password someuser
-
-If an value isn't found in the list it is silently ignored.
+:param args: List of arguments for the command
+:param stdin: Optional input to the command
+:param: raiseonerr: If True, raises an exception if the return code is
+not zero
+:param nolog: Tuple of strings that shouldn't be logged, like passwords.
+Each tuple consists of a string to be replaced by .
+
+Example:
+We have a command
+['/usr/bin/setpasswd', '--password', 'Secret123', 'someuser']
+and we don't want to log the password so nolog would be set to:
+('Secret123',)
+The resulting log output would be:
+
+/usr/bin/setpasswd --password someuser
+
+If an value isn't found in the list it is silently ignored.
+:param env: Dictionary of environment variables passed to the command.
+When None, current environment is copied
+:param capture_output: Capture stderr and stdout
+:param skip_output: Redirect the output to /dev/null and do not capture it
+:param cwd: Current working directory
+:param runas: Name of a user that the command shold be run as. The spawned
+process will have both real and effective UID and GID set.
p_in = None
p_out = None
@@ -298,9 +305,19 @@ def run(args, stdin=None, raiseonerr=True,
root_logger.debug('Starting external process')
root_logger.debug('args=%s' % arg_string)
+preexec_fn = None
+if runas is not None:
+pent = pwd.getpwnam(runas)
+root_logger.debug('runas=%s (UID %d, GID %s)', runas,
+pent.pw_uid, pent.pw_gid)
[Freeipa-devel] ANNOUNCE: kdcproxy 0.1.1 released
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@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
