Re: [Freeipa-devel] [PATCH 0155] ipatests: Kill winbindd process after uninstall
On 02/26/2014 12:40 PM, Alexander Bokovoy wrote: On Wed, 26 Feb 2014, Martin Kosek wrote: On 02/25/2014 07:15 PM, Alexander Bokovoy wrote: On Tue, 25 Feb 2014, Tomas Babej wrote: Hi, As a part of a better cleanup procedure in the integration tests, make sure that winbindd is not running after uninstalling the IPA server. Better patch 0140 attached. We simply need to stop and disable winbind in adtrustinstance.uninstall() Looks good to me (and a better approach than Tomas' 155 it seems). Since you are touching this section anyway, can you please also replace bare except with except Exception:? It will allow admin to CTRL+C the stopping process when needed. Sure, new patch is attached. There are two potentially long external processes executed in the uninstall() so I changed to 'except Exception:' in both. This is fine - ACK. I just removed the note about superseded Tomas' patch from your commit log, we do not need that note from git log history perspective. Pushed to master: e99fa380af7f257a319cbe6f8867bf258ab04e41 Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Fwd: access control in PCSC - does it apply to PKCS#11?
Hello list, Proposal for access control related to PC/SC smart cards follows. I have no idea if it applies to PKCS#11 or not but I think somebody knowledgeable in this area should look into it ... I'm sorry Honza :-) Petr^2 Spacek Original Message Subject: F21 System Wide Change: Access control in PCSC Date: Thu, 27 Feb 2014 16:59:14 +0100 From: Jaroslav Reznik jrez...@redhat.com Reply-To: de...@lists.fedoraproject.org Organization: Red Hat, Inc. To: devel-annou...@lists.fedoraproject.org = Proposed System Wide Change: Access control in PCSC = https://fedoraproject.org/wiki/Changes/PcscAccessControl Change owner(s): Nikos Mavrogiannopoulos n...@redhat.com Add access control to PC/SC smart cards available in the system. Adding access control would (a) prevent unauthorized processes/users from reading data on a smart card, (b) prevent unauthorized processes/users from erasing a smart card, (c) prevent unauthorized processes/users from talking to the smart card firmware. == Detailed Description == Add access control to PC/SC smart cards available in the system. Currently smart cards may provide their own access control for certain elements of a card such as a private key. Their access control method is typically a PIN, but can also be a biometric based one. That however, is not sufficient to prevent certain actions on the non-PIN protected elements. For example cards that provide a PKCS #15 filesystem can be modified by anyone that has access in the system (e.g., erased using pkcs15-init -E). The default settings allowed should be similar to the default settings for hard disks, i.e., root and the user in console should be able to access the smart card. Adding access control would * prevent unauthorized processes/users from reading data on a smart card * prevent unauthorized processes/users from erasing a smart card * prevent unauthorized processes/users from talking to the smart card firmware The way access control will be implemented is using polkit which is already being used to control access to hard disks. As smart cards share a lot with hard disks (e.g., a filesystem, and are inserted by the console user), sharing the same access control method is beneficial. == Scope == polkit support has to be added to PC/SC daemon. An initial version has already been developed and communicated upstream * Proposal owners: The polkit support has to be merged with the Fedora package. That requires changes to the pcsc daemon only, but indirectly all packages that potentially may use smart cards are affected (opensc, firefox, ...). * Other developers: Packages that use PC/SC smart cards must be checked that they work as expected after the access control change. * Release engineering: No coordination is required. * Policies and guidelines: If there is any security policy documentation should be updated to include the new policies on smart cards (I couldn't find any such documentation though) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0479 permission plugin: Allow multiple values for memberof
Hello,
Here is an additional part for the multivalued target filters: making
--memberof also multivalued.
http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions
https://fedorahosted.org/freeipa/ticket/4074
--
Petr³
From c5b08c920df97c49dc0e44124f735c7655d6186a Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Thu, 27 Feb 2014 14:38:16 +0100
Subject: [PATCH] permission plugin: Allow multiple values for memberof
Design: http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions
Additional fix for: https://fedorahosted.org/freeipa/ticket/4074
---
API.txt| 6 ++--
VERSION| 4 +--
ipalib/plugins/permission.py | 16 +++
ipatests/test_xmlrpc/test_permission_plugin.py | 40 ++
4 files changed, 55 insertions(+), 11 deletions(-)
diff --git a/API.txt b/API.txt
index 070134959dd2cfdd7a281b3e50d8bc92fe21cdeb..cbd44b848397b18df5e57be45b89856dec53e8cd 100644
--- a/API.txt
+++ b/API.txt
@@ -2335,7 +2335,7 @@ command: permission_add
option: StrEnum('ipapermright', attribute=True, cli_name='permissions', multivalue=True, required=False, values=(u'read', u'search', u'compare', u'write', u'add', u'delete', u'all'))
option: DNParam('ipapermtarget', attribute=True, cli_name='target', multivalue=False, required=False)
option: Str('ipapermtargetfilter', attribute=True, cli_name='filter', multivalue=True, required=False)
-option: Str('memberof', alwaysask=True, attribute=False, autofill=False, cli_name='memberof', multivalue=False, query=False, required=False)
+option: Str('memberof', alwaysask=True, attribute=False, autofill=False, cli_name='memberof', multivalue=True, query=False, required=False)
option: Flag('no_members', autofill=True, default=False, exclude='webui')
option: Str('permissions', attribute=False, cli_name='permissions', multivalue=True, required=False)
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
@@ -2393,7 +2393,7 @@ command: permission_find
option: StrEnum('ipapermright', attribute=True, autofill=False, cli_name='permissions', multivalue=True, query=True, required=False, values=(u'read', u'search', u'compare', u'write', u'add', u'delete', u'all'))
option: DNParam('ipapermtarget', attribute=True, autofill=False, cli_name='target', multivalue=False, query=True, required=False)
option: Str('ipapermtargetfilter', attribute=True, autofill=False, cli_name='filter', multivalue=True, query=True, required=False)
-option: Str('memberof', attribute=False, autofill=False, cli_name='memberof', multivalue=False, query=True, required=False)
+option: Str('memberof', attribute=False, autofill=False, cli_name='memberof', multivalue=True, query=True, required=False)
option: Flag('no_members', autofill=True, default=False, exclude='webui')
option: Str('permissions', attribute=False, autofill=False, cli_name='permissions', multivalue=True, query=True, required=False)
option: Flag('pkey_only?', autofill=True, default=False)
@@ -2423,7 +2423,7 @@ command: permission_mod
option: StrEnum('ipapermright', attribute=True, autofill=False, cli_name='permissions', multivalue=True, required=False, values=(u'read', u'search', u'compare', u'write', u'add', u'delete', u'all'))
option: DNParam('ipapermtarget', attribute=True, autofill=False, cli_name='target', multivalue=False, required=False)
option: Str('ipapermtargetfilter', attribute=True, autofill=False, cli_name='filter', multivalue=True, required=False)
-option: Str('memberof', attribute=False, autofill=False, cli_name='memberof', multivalue=False, required=False)
+option: Str('memberof', attribute=False, autofill=False, cli_name='memberof', multivalue=True, required=False)
option: Flag('no_members', autofill=True, default=False, exclude='webui')
option: Str('permissions', attribute=False, autofill=False, cli_name='permissions', multivalue=True, required=False)
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
diff --git a/VERSION b/VERSION
index b1dcb9c05416fb611f523c9c10599b5fc0e18045..59520541d8c0215e79e9cc16fd80142a5a4238de 100644
--- a/VERSION
+++ b/VERSION
@@ -89,5 +89,5 @@ IPA_DATA_VERSION=2010061412
# #
IPA_API_VERSION_MAJOR=2
-IPA_API_VERSION_MINOR=75
-# Last change: npmccallum - HOTP support
+IPA_API_VERSION_MINOR=76
+# Last change: pviktori - permissions: multivalued memberof
diff --git a/ipalib/plugins/permission.py b/ipalib/plugins/permission.py
index 670e3f1c65452fef26838558ad115ebc2aeda87a..fb57fded7efe464d7879c12042999369c7d63bc4 100644
--- a/ipalib/plugins/permission.py
+++ b/ipalib/plugins/permission.py
@@ -243,7 +243,7 @@ class permission(baseldap.LDAPObject):
flags={'no_option'}
),
-Str('memberof?',
+Str('memberof*',
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
On 02/27/2014 10:18 PM, Rob Crittenden wrote: Rob Crittenden wrote: [...] Ok, so try to summarize this long-running thread, I'll rename the subpackage to freeipa-server-foreman-smartproxy to make it clearer what it is/does. Right now it requires manual configuration so having the package installed should have no negative impacts (other than potentially pulling in additional dependencies). I'll leave it in smartproxy for now, it's just cleaner and better integrates with ipatests IMHO. Foreman supports SSL client auth which is great, by cherrypy does not yet. There is a pull request to add this, https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity . Foreman otherwise supports no other authentication method, so we're blocked with this. The certs for this would initially come out of Foreman/puppet. I'll submit a new patch with an updated spec but I think otherwise I've addressed the isuses Petr has raised. This thread has taken a lot of turns so it is very possible I missed something though :-) Updated patch based on feedback from Foreman team. I added a new URI, /features, which Foreman uses to determine what capabilities a proxy has. rob My review is blocked because 389-ds doesn't install on Rawhide due to https://fedorahosted.org/389/ticket/47700 Noriko, do you know of a Rawhide build that includes your fix? -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Client-side command in the IPA framework
On 28.2.2014 04:02, Rob Crittenden wrote: Alexander Bokovoy wrote: On Thu, 27 Feb 2014, Nathaniel McCallum wrote: So the recent discussion on importing tokens led me to write a script to parse RFC 6030 xml files into IPA token data. This all works well. But now I need to integrate it into the IPA framework. This command will parse one or more xml files, creating a set of tokens to be added. Given that we already have otptoken-add on the server-side, it seems to me that all work needs to be done on the client-side. How do I create a new client-side command that calls existing server-side API? subclass from frontend.Local, override run() or forward() method and perform batch operation of otptoken_add from there. See cli.help, for example. If you do an override, do forward() for cli-specific work. But you should do as little as possible for reasons you already stated: the UI. Anything you do in forward Petr will need to implement in the UI. Unfortunately we don't yet have a nice way to handle files. We have tickets open at https://fedorahosted.org/freeipa/ticket/1225 and https://fedorahosted.org/freeipa/ticket/2933 If this file is something that would be pasted into a big text field then you can probably handle it in a similarly clumsy way that we do CSRs in the cert plugin. rob +1 for parsing it on server. Otherwise every client, not just CLI or Web UI, would have to reimplement the same logic - having it on server will support better integration with third party products. Parsing on client would be understandable if there was some middle step which would require some action from user, i.e, pick only some tokens to import. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Fwd: access control in PCSC - does it apply to PKCS#11?
Hi, On 28.2.2014 10:11, Petr Spacek wrote: Hello list, Proposal for access control related to PC/SC smart cards follows. I have no idea if it applies to PKCS#11 or not but I think somebody knowledgeable in this area should look into it ... I'm sorry Honza :-) Don't be, this seems to be related to PKCS#15 and PC/SC daemon only, neither of which are we going to interact with whatsoever (correct me if I'm wrong). Petr^2 Spacek Original Message Subject: F21 System Wide Change: Access control in PCSC Date: Thu, 27 Feb 2014 16:59:14 +0100 From: Jaroslav Reznik jrez...@redhat.com Reply-To: de...@lists.fedoraproject.org Organization: Red Hat, Inc. To: devel-annou...@lists.fedoraproject.org = Proposed System Wide Change: Access control in PCSC = https://fedoraproject.org/wiki/Changes/PcscAccessControl Change owner(s): Nikos Mavrogiannopoulos n...@redhat.com Add access control to PC/SC smart cards available in the system. Adding access control would (a) prevent unauthorized processes/users from reading data on a smart card, (b) prevent unauthorized processes/users from erasing a smart card, (c) prevent unauthorized processes/users from talking to the smart card firmware. == Detailed Description == Add access control to PC/SC smart cards available in the system. Currently smart cards may provide their own access control for certain elements of a card such as a private key. Their access control method is typically a PIN, but can also be a biometric based one. That however, is not sufficient to prevent certain actions on the non-PIN protected elements. For example cards that provide a PKCS #15 filesystem can be modified by anyone that has access in the system (e.g., erased using pkcs15-init -E). The default settings allowed should be similar to the default settings for hard disks, i.e., root and the user in console should be able to access the smart card. Adding access control would * prevent unauthorized processes/users from reading data on a smart card * prevent unauthorized processes/users from erasing a smart card * prevent unauthorized processes/users from talking to the smart card firmware The way access control will be implemented is using polkit which is already being used to control access to hard disks. As smart cards share a lot with hard disks (e.g., a filesystem, and are inserted by the console user), sharing the same access control method is beneficial. == Scope == polkit support has to be added to PC/SC daemon. An initial version has already been developed and communicated upstream * Proposal owners: The polkit support has to be merged with the Fedora package. That requires changes to the pcsc daemon only, but indirectly all packages that potentially may use smart cards are affected (opensc, firefox, ...). * Other developers: Packages that use PC/SC smart cards must be checked that they work as expected after the access control change. * Release engineering: No coordination is required. * Policies and guidelines: If there is any security policy documentation should be updated to include the new policies on smart cards (I couldn't find any such documentation though) -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [389-devel] Design review (second): Access control on entries specified in MODDN operation (ticket 47553)
HI Ludwig, Thanks for catching that, I will update the doc. When the legacy server receives an aci with that new syntax, it does not recognize the new keywords (moddn, target_to, target_from) so the parser fails and the aci is simply ignored. In the implementation (__aclp__parse_ac) , 'target_to' and 'target_from' should be tested before 'target' because the way it is coded 'target_to'/'target_from' could be interpreted as 'target' keyword. regards thierry On 02/27/2014 05:36 PM, Ludwig Krispenz wrote: Hi, in the replication section you describe the behaviour when replicating to older versions of ds, but this is for n1, how about the new design ? Ludwig On 02/27/2014 04:46 PM, thierry bordaz wrote: Hello, Thanks to all your feedbacks, they helped me a lot and raised a severe limitation in the original design. I updated the design following the aci syntax proposed during the discussion. On the implementation side, it is a bit more complex but less than I expected. I have not yet investigated the impact of ger operations. I think a big work will be the test side as the ACI syntax provides many options. http://port389.org/wiki/Access_control_on_trees_specified_in_MODDN_operation Note: I kept for the moment the original design in 'alternative no1'. regards thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Entropy aka ipa-server-install failed
On 28.2.2014 11:53, Sumit Bose wrote: Hi, I just tried to install FreeIPA on a fresh F20 VM and 'ipa-server-install --setup-dns' failed to start FreeIPA finally after everything was configured. The reason was that starting named timed out because generate-rndc-key.sh was basically blocking because there was no entropy for /dev/random left to generate a proper key. I wonder if it would make sense to call generate-rndc-key.sh during ipa-server-install if --setup-dns is given to avoid this. We can do it but it will only shift the problem to different place. In the past the key was generated in RPM posttrans but it was removed from there because sometimes it blocked RPM for very very long time. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Entropy aka ipa-server-install failed
On Fri, Feb 28, 2014 at 11:59:57AM +0100, Petr Spacek wrote: On 28.2.2014 11:53, Sumit Bose wrote: Hi, I just tried to install FreeIPA on a fresh F20 VM and 'ipa-server-install --setup-dns' failed to start FreeIPA finally after everything was configured. The reason was that starting named timed out because generate-rndc-key.sh was basically blocking because there was no entropy for /dev/random left to generate a proper key. I wonder if it would make sense to call generate-rndc-key.sh during ipa-server-install if --setup-dns is given to avoid this. We can do it but it will only shift the problem to different place. yes, but if we do it during ipa-server-install we have it under control and can give a hint that this step needs entropy, might need a long time and the user might help by producing additional network or disk I/O. bye, Sumit In the past the key was generated in RPM posttrans but it was removed from there because sometimes it blocked RPM for very very long time. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Entropy aka ipa-server-install failed
On Fri, 28 Feb 2014, Sumit Bose wrote:
Hi,
I just tried to install FreeIPA on a fresh F20 VM and
'ipa-server-install --setup-dns' failed to start FreeIPA finally after
everything was configured.
The reason was that starting named timed out because
generate-rndc-key.sh was basically blocking because there was no entropy
for /dev/random left to generate a proper key. I wonder if it would make
sense to call generate-rndc-key.sh during ipa-server-install if
--setup-dns is given to avoid this.
Let the administrators solve this problem for their VMs. Qemu provides
virtualization for RNG already that allows you to push entropy from the
host system where you can use hardware generators like in new Intel
systems.
For example, I'm using following hook in oVirt to provide entropy for
my virtual machines:
$ cat /usr/libexec/vdsm/hooks/before_vm_start/99_hwrng
#!/usr/bin/python
import os
import sys
import traceback
import hooking
if True:
try:
domxml = hooking.read_domxml()
domain = domxml.getElementsByTagName('devices')[0]
# Add hugepages to libvirt xml
hwrng = domxml.createElement('rng')
hwrng.setAttribute('model', 'virtio')
rate = domxml.createElement('rate')
rate.setAttribute('period', '8192')
rate.setAttribute('bytes', '8192')
hwrng.appendChild(rate)
backend = domxml.createElement('backend')
backend.setAttribute('model', 'random')
hwrng.appendChild(backend)
domain.appendChild(hwrng)
hooking.write_domxml(domxml)
except:
sys.stderr.write('rng: [unexpected error]: %s\n' %
traceback.format_exc())
sys.exit(2)
See http://wiki.qemu-project.org/Features/VirtIORNG and
http://libvirt.org/formatdomain.html#elementsRng
--
/ Alexander Bokovoy
___
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/28/2014 10:47 AM, Petr Viktorin wrote: On 02/27/2014 10:18 PM, Rob Crittenden wrote: Rob Crittenden wrote: [...] Ok, so try to summarize this long-running thread, I'll rename the subpackage to freeipa-server-foreman-smartproxy to make it clearer what it is/does. Right now it requires manual configuration so having the package installed should have no negative impacts (other than potentially pulling in additional dependencies). I'll leave it in smartproxy for now, it's just cleaner and better integrates with ipatests IMHO. Foreman supports SSL client auth which is great, by cherrypy does not yet. There is a pull request to add this, https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity . Foreman otherwise supports no other authentication method, so we're blocked with this. The certs for this would initially come out of Foreman/puppet. I'll submit a new patch with an updated spec but I think otherwise I've addressed the isuses Petr has raised. This thread has taken a lot of turns so it is very possible I missed something though :-) Updated patch based on feedback from Foreman team. I added a new URI, /features, which Foreman uses to determine what capabilities a proxy has. rob My review is blocked because 389-ds doesn't install on Rawhide due to https://fedorahosted.org/389/ticket/47700 Noriko, do you know of a Rawhide build that includes your fix? Guys, if this patch still makes our master branch incompatible with F20, then it is a NACK from me. All developers run on F20, our CI runs on F20 and I do not think we can afford loosing that and forcing everyone to permanently switch to rawhide - it is too unstable. IMO the Requires and BuildRequires most be set so that RPMs are buildable and installable on F20. The only acceptable exception is when only freeipa-server-foreman-smartprox cannot be installed on F20, but otherwise everything else need to work. Thanks, Martin ___ 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/28/2014 12:41 PM, Martin Kosek wrote: On 02/28/2014 10:47 AM, Petr Viktorin wrote: On 02/27/2014 10:18 PM, Rob Crittenden wrote: Rob Crittenden wrote: [...] Ok, so try to summarize this long-running thread, I'll rename the subpackage to freeipa-server-foreman-smartproxy to make it clearer what it is/does. Right now it requires manual configuration so having the package installed should have no negative impacts (other than potentially pulling in additional dependencies). I'll leave it in smartproxy for now, it's just cleaner and better integrates with ipatests IMHO. Foreman supports SSL client auth which is great, by cherrypy does not yet. There is a pull request to add this, https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity . Foreman otherwise supports no other authentication method, so we're blocked with this. The certs for this would initially come out of Foreman/puppet. I'll submit a new patch with an updated spec but I think otherwise I've addressed the isuses Petr has raised. This thread has taken a lot of turns so it is very possible I missed something though :-) Updated patch based on feedback from Foreman team. I added a new URI, /features, which Foreman uses to determine what capabilities a proxy has. rob My review is blocked because 389-ds doesn't install on Rawhide due to https://fedorahosted.org/389/ticket/47700 Noriko, do you know of a Rawhide build that includes your fix? Guys, if this patch still makes our master branch incompatible with F20, then it is a NACK from me. All developers run on F20, our CI runs on F20 and I do not think we can afford loosing that and forcing everyone to permanently switch to rawhide - it is too unstable. IMO the Requires and BuildRequires most be set so that RPMs are buildable and installable on F20. The only acceptable exception is when only freeipa-server-foreman-smartprox cannot be installed on F20, but otherwise everything else need to work. Thanks, Martin Okay, it's not a BuildRequires; IPA doesn't build because of a lint failure: ipalib/util.py - Module 'kerberos' has no 'authGSSClientInquireCred' member I guess the new get_current_principal needs to be kept out of ipalib until we move to f21. Until then we can have a lint exception; after then we need to remove it, and add BuildRequires so lint passes. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0480
Hello,
This fixes https://fedorahosted.org/freeipa/ticket/4206
Apply on top of my patch 0479, to avoid a conflict in tests.
--
Petr³
From 286190d9374290acef301ca92279f3f729827cad Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Fri, 28 Feb 2014 12:23:17 +0100
Subject: [PATCH] permissions plugin: Don't crash with empty targetfilter
https://fedorahosted.org/freeipa/ticket/4206
---
ipalib/plugins/permission.py | 2 +-
ipatests/test_xmlrpc/test_permission_plugin.py | 47 ++
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/ipalib/plugins/permission.py b/ipalib/plugins/permission.py
index fb57fded7efe464d7879c12042999369c7d63bc4..2b2509ecbdfc7cd6b45f3c220188bee176679bf5 100644
--- a/ipalib/plugins/permission.py
+++ b/ipalib/plugins/permission.py
@@ -711,7 +711,7 @@ def preprocess_options(self, options, return_filter_ops=False):
return filter_ops
elif filter_ops['add']:
options['ipapermtargetfilter'] = list(options.get(
-'ipapermtargetfilter', [])) + filter_ops['add']
+'ipapermtargetfilter') or []) + filter_ops['add']
def validate_permission(self, entry):
ldap = self.Backend.ldap2
diff --git a/ipatests/test_xmlrpc/test_permission_plugin.py b/ipatests/test_xmlrpc/test_permission_plugin.py
index 2d214013995266412cf0cf4559537095ffcd633c..833071823752ece578c6d688cf8a0dbf78c18d2a 100644
--- a/ipatests/test_xmlrpc/test_permission_plugin.py
+++ b/ipatests/test_xmlrpc/test_permission_plugin.py
@@ -3260,4 +3260,51 @@ class test_permission_filters(Declarative):
'(version 3.0;acl permission:%s;' % permission1 +
'allow (write) groupdn = ldap:///%s;;)' % permission1_dn,
),
+
+dict(
+desc='Delete %r' % permission1,
+command=('permission_del', [permission1], {}),
+expected=dict(
+result=dict(failed=u''),
+value=permission1,
+summary=u'Deleted permission %s' % permission1,
+)
+),
+
+verify_permission_aci_missing(permission1, api.env.basedn),
+
+dict(
+desc='Create %r with empty filters [#4206]' % permission1,
+command=(
+'permission_add', [permission1], dict(
+type=u'user',
+ipapermright=u'write',
+ipapermtargetfilter=u'',
+)
+),
+expected=dict(
+value=permission1,
+summary=u'Added permission %s' % permission1,
+result=dict(
+dn=permission1_dn,
+cn=[permission1],
+objectclass=objectclasses.permission,
+type=[u'user'],
+ipapermright=[u'write'],
+ipapermbindruletype=[u'permission'],
+ipapermissiontype=[u'SYSTEM', u'V2'],
+ipapermlocation=[users_dn],
+ipapermtargetfilter=[
+u'(objectclass=posixaccount)',
+],
+),
+),
+),
+
+verify_permission_aci(
+permission1, users_dn,
+'(targetfilter = (objectclass=posixaccount))' +
+'(version 3.0;acl permission:%s;' % permission1 +
+'allow (write) groupdn = ldap:///%s;;)' % permission1_dn,
+),
]
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0480 permission plugin: Don't crash with empty targetfilter
Fixing the subject On 02/28/2014 01:11 PM, Petr Viktorin wrote: Hello, This fixes https://fedorahosted.org/freeipa/ticket/4206 Apply on top of my patch 0479, to avoid a conflict in tests. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Entropy aka ipa-server-install failed
On 28.2.2014 12:10, Sumit Bose wrote: On Fri, Feb 28, 2014 at 11:59:57AM +0100, Petr Spacek wrote: On 28.2.2014 11:53, Sumit Bose wrote: I just tried to install FreeIPA on a fresh F20 VM and 'ipa-server-install --setup-dns' failed to start FreeIPA finally after everything was configured. The reason was that starting named timed out because generate-rndc-key.sh was basically blocking because there was no entropy for /dev/random left to generate a proper key. I wonder if it would make sense to call generate-rndc-key.sh during ipa-server-install if --setup-dns is given to avoid this. We can do it but it will only shift the problem to different place. yes, but if we do it during ipa-server-install we have it under control and can give a hint that this step needs entropy, might need a long time and the user might help by producing additional network or disk I/O. That sounds reasonable. Please open a ticket or send a patch :-) -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Entropy aka ipa-server-install failed
On Fri, Feb 28, 2014 at 01:14:58PM +0100, Petr Spacek wrote: On 28.2.2014 12:10, Sumit Bose wrote: On Fri, Feb 28, 2014 at 11:59:57AM +0100, Petr Spacek wrote: On 28.2.2014 11:53, Sumit Bose wrote: I just tried to install FreeIPA on a fresh F20 VM and 'ipa-server-install --setup-dns' failed to start FreeIPA finally after everything was configured. The reason was that starting named timed out because generate-rndc-key.sh was basically blocking because there was no entropy for /dev/random left to generate a proper key. I wonder if it would make sense to call generate-rndc-key.sh during ipa-server-install if --setup-dns is given to avoid this. We can do it but it will only shift the problem to different place. yes, but if we do it during ipa-server-install we have it under control and can give a hint that this step needs entropy, might need a long time and the user might help by producing additional network or disk I/O. That sounds reasonable. Please open a ticket or send a patch :-) ok, I've opened https://fedorahosted.org/freeipa/ticket/4210 for the time being. bye, Sumit -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0473-0477 Managed permission updater, part 1
On 02/28/2014 02:12 PM, Martin Kosek wrote:
On 02/26/2014 10:44 AM, Petr Viktorin wrote:
Hello,
Here are a few fixes/improvements, and the first part of a managed permission
updater.
The patches should go in this order but don't need to be ACKed/pushed all at
once.
Design:
http://www.freeipa.org/page/V3/Managed_Read_permissions#Default_Permission_Updater
Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
This part is a preview of sorts, to get the basic mechanism and the metadata
format reviewed before I add all of the default read permissions.
It implements the first section of Default Permission Updater in the design;
Replacing legacy default permissions and Removing the global anonymous read
ACI is left for later.
Metadata is added for the netgroup plugin* for starters, so installing this
will give you two shiny new read permissions:
$ ipa permission-find ipa: --all
-
2 permissions matched
-
dn: cn=ipa:Read Netgroup Membership,cn=permissions,cn=pbac,$SUFFIX
Permission name: ipa:Read Netgroup Membership
Permissions: read, compare, search
Effective attributes: externalhost, member, memberof, memberuser
Default attributes: member, memberof, memberuser, externalhost
Bind rule type: all
Subtree: cn=ng,cn=alt,$SUFFIX
Target filter: (objectclass=ipanisnetgroup)
Type: netgroup
ipapermissiontype: V2, MANAGED, SYSTEM
objectclass: ipapermission, groupofnames, top, ipapermissionv2
dn: cn=ipa:Read Netgroups,cn=permissions,cn=pbac,$SUFFIX
Permission name: ipa:Read Netgroups
Permissions: read, compare, search
Effective attributes: cn, description, hostcategory, ipaenabledflag,
ipauniqueid, nisdomainname, usercategory
Default attributes: cn, usercategory, hostcategory, ipauniqueid,
ipaenabledflag, nisdomainname, description
Bind rule type: all
Subtree: cn=ng,cn=alt,$SUFFIX
Target filter: (objectclass=ipanisnetgroup)
Type: netgroup
ipapermissiontype: V2, MANAGED, SYSTEM
objectclass: ipapermission, groupofnames, top, ipapermissionv2
Number of entries returned 2
with corresponding ACIs at cn=ng,cn=alt,$SUFFIX:
(targetattr = externalhost || member || memberof || memberuser)(targetfilter
= (objectclass=ipanisnetgroup))(version 3.0;acl permission:ipa:Read Netgroup
Membership;allow (read,compare,search) userdn = ldap:///all;;)
(targetattr = cn || description || hostcategory || ipaenabledflag ||
ipauniqueid || nisdomainname || usercategory)(targetfilter =
(objectclass=ipanisnetgroup))(version 3.0;acl permission:ipa:Read
Netgroups;allow (read,compare,search) userdn = ldap:///all;;)
Patches:
0473: Enables refactoring that will make it more clear (to humans and machines)
what plugins code depends on.
https://fedorahosted.org/freeipa/ticket/4185
0474: Fix handling of the search term for legacy permissions
My code that's in master now handles the search term incorrectly. This does a
better job.
0475: Fix tests that relied on some assumptions I'll be breaking
0476: Allow modifying (but not creating) permissions with : in the name
0477: Permission updater sample metadata
1) 476: Typo in test name:
+desc='Search fo rnonexisting permission with : in the name',
Will fix.
2) 477: do we want to log anything when permission is up to date?
+try:
+ldap.update_entry(entry)
+except errors.EmptyModlist:
+return
I don't think that's needed, after all that's the expected behavior in
all but the first upgrade.
But I'll be happy to add it if you think it would be better.
3) I am not sure if this was initiated by this patch, but when I checked access
log for a permission-find --name ipa operation, it produced over 170 LDAP
operations, most of them asking for the same information many times. See
attached access log excerpt.
It's unrelated to this patch. I've started optimizing permission-find
with many legacy permissions, expect a patch soon.
4) I have been quite resilient to the prefixes for the permissions, but it
seems it is the easier possible approach to fix conflicts with user permissions
without having to check that later for every upgrade or doing more complex
stuff like multiple RDNs or different container for system and user permissions.
I am now just thinking about the prefixing. Now you use this name:
ipa:Read Netgroups
Would it be nicer to use:
IPA:Read Netgroups
or
IPA: Read Netgroups
or even
[IPA] Read Netgroups
? :-)
Bikeshedding time!
Everyone on the list, please chime in!
I don't really have a preference.
5) Are we sure we want to make our code Python 2.7 dependent?
+'ipapermright': {'read', 'search', 'compare'},
I did not test if we do not require some python 2.7 feature elsewhere already,
but this construct raised a warning for me.
That ship has sailed already.
Recently there was commit a8ba5e0 which explicitly
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
Petr Viktorin wrote: On 02/28/2014 12:41 PM, Martin Kosek wrote: On 02/28/2014 10:47 AM, Petr Viktorin wrote: On 02/27/2014 10:18 PM, Rob Crittenden wrote: Rob Crittenden wrote: [...] Ok, so try to summarize this long-running thread, I'll rename the subpackage to freeipa-server-foreman-smartproxy to make it clearer what it is/does. Right now it requires manual configuration so having the package installed should have no negative impacts (other than potentially pulling in additional dependencies). I'll leave it in smartproxy for now, it's just cleaner and better integrates with ipatests IMHO. Foreman supports SSL client auth which is great, by cherrypy does not yet. There is a pull request to add this, https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity . Foreman otherwise supports no other authentication method, so we're blocked with this. The certs for this would initially come out of Foreman/puppet. I'll submit a new patch with an updated spec but I think otherwise I've addressed the isuses Petr has raised. This thread has taken a lot of turns so it is very possible I missed something though :-) Updated patch based on feedback from Foreman team. I added a new URI, /features, which Foreman uses to determine what capabilities a proxy has. rob My review is blocked because 389-ds doesn't install on Rawhide due to https://fedorahosted.org/389/ticket/47700 Noriko, do you know of a Rawhide build that includes your fix? Guys, if this patch still makes our master branch incompatible with F20, then it is a NACK from me. All developers run on F20, our CI runs on F20 and I do not think we can afford loosing that and forcing everyone to permanently switch to rawhide - it is too unstable. IMO the Requires and BuildRequires most be set so that RPMs are buildable and installable on F20. The only acceptable exception is when only freeipa-server-foreman-smartprox cannot be installed on F20, but otherwise everything else need to work. Thanks, Martin Okay, it's not a BuildRequires; IPA doesn't build because of a lint failure: ipalib/util.py - Module 'kerberos' has no 'authGSSClientInquireCred' member I guess the new get_current_principal needs to be kept out of ipalib until we move to f21. Until then we can have a lint exception; after then we need to remove it, and add BuildRequires so lint passes. The other option is to locally rebuild python-kerberos from rawhide in F-20. Simo was a bit reluctant to put it into F-20 with the patch I added for authenticate_gss_client_inquire_cred(). We can also work on convincing him it is low risk. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0007][DOC] Tip on restoring admin account
On 02/26/2014 04:01 PM, Gabe Alford wrote: Hi all, I added a tip in the deleting users section on restoring admin account. Please review. https://fedorahosted.org/freeipa/ticket/2746 Hello, The new tip is added right under a Note about the same thing (or a very similar thing, from the user's POV). Would it be possible to merge those two into a single Note? Nowadays[0], ipa user-del and ipa group-remove-member will refuse to delete the last admin. I think this information should be added to the main docs. (Also, this reduces the importance of the recovery instructions.) [0] https://fedorahosted.org/freeipa/ticket/2564 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Client-side command in the IPA framework
On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: On 28.2.2014 04:02, Rob Crittenden wrote: Alexander Bokovoy wrote: On Thu, 27 Feb 2014, Nathaniel McCallum wrote: So the recent discussion on importing tokens led me to write a script to parse RFC 6030 xml files into IPA token data. This all works well. But now I need to integrate it into the IPA framework. This command will parse one or more xml files, creating a set of tokens to be added. Given that we already have otptoken-add on the server-side, it seems to me that all work needs to be done on the client-side. How do I create a new client-side command that calls existing server-side API? subclass from frontend.Local, override run() or forward() method and perform batch operation of otptoken_add from there. See cli.help, for example. If you do an override, do forward() for cli-specific work. But you should do as little as possible for reasons you already stated: the UI. Anything you do in forward Petr will need to implement in the UI. Unfortunately we don't yet have a nice way to handle files. We have tickets open at https://fedorahosted.org/freeipa/ticket/1225 and https://fedorahosted.org/freeipa/ticket/2933 If this file is something that would be pasted into a big text field then you can probably handle it in a similarly clumsy way that we do CSRs in the cert plugin. rob +1 for parsing it on server. Otherwise every client, not just CLI or Web UI, would have to reimplement the same logic - having it on server will support better integration with third party products. Parsing on client would be understandable if there was some middle step which would require some action from user, i.e, pick only some tokens to import. If we parse on the server side, how do we handle the long-running operation? Think of the case of importing hundreds or thousands of tokens... Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Entropy aka ipa-server-install failed
On Fri, 2014-02-28 at 11:53 +0100, Sumit Bose wrote: Hi, I just tried to install FreeIPA on a fresh F20 VM and 'ipa-server-install --setup-dns' failed to start FreeIPA finally after everything was configured. The reason was that starting named timed out because generate-rndc-key.sh was basically blocking because there was no entropy for /dev/random left to generate a proper key. I wonder if it would make sense to call generate-rndc-key.sh during ipa-server-install if --setup-dns is given to avoid this. +1 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] 1106 IPA REST smart proxy
On Fri, 2014-02-28 at 09:03 -0500, Rob Crittenden wrote: Petr Viktorin wrote: On 02/28/2014 12:41 PM, Martin Kosek wrote: On 02/28/2014 10:47 AM, Petr Viktorin wrote: On 02/27/2014 10:18 PM, Rob Crittenden wrote: Rob Crittenden wrote: [...] Ok, so try to summarize this long-running thread, I'll rename the subpackage to freeipa-server-foreman-smartproxy to make it clearer what it is/does. Right now it requires manual configuration so having the package installed should have no negative impacts (other than potentially pulling in additional dependencies). I'll leave it in smartproxy for now, it's just cleaner and better integrates with ipatests IMHO. Foreman supports SSL client auth which is great, by cherrypy does not yet. There is a pull request to add this, https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity . Foreman otherwise supports no other authentication method, so we're blocked with this. The certs for this would initially come out of Foreman/puppet. I'll submit a new patch with an updated spec but I think otherwise I've addressed the isuses Petr has raised. This thread has taken a lot of turns so it is very possible I missed something though :-) Updated patch based on feedback from Foreman team. I added a new URI, /features, which Foreman uses to determine what capabilities a proxy has. rob My review is blocked because 389-ds doesn't install on Rawhide due to https://fedorahosted.org/389/ticket/47700 Noriko, do you know of a Rawhide build that includes your fix? Guys, if this patch still makes our master branch incompatible with F20, then it is a NACK from me. All developers run on F20, our CI runs on F20 and I do not think we can afford loosing that and forcing everyone to permanently switch to rawhide - it is too unstable. IMO the Requires and BuildRequires most be set so that RPMs are buildable and installable on F20. The only acceptable exception is when only freeipa-server-foreman-smartprox cannot be installed on F20, but otherwise everything else need to work. Thanks, Martin Okay, it's not a BuildRequires; IPA doesn't build because of a lint failure: ipalib/util.py - Module 'kerberos' has no 'authGSSClientInquireCred' member I guess the new get_current_principal needs to be kept out of ipalib until we move to f21. Until then we can have a lint exception; after then we need to remove it, and add BuildRequires so lint passes. The other option is to locally rebuild python-kerberos from rawhide in F-20. Simo was a bit reluctant to put it into F-20 with the patch I added for authenticate_gss_client_inquire_cred(). We can also work on convincing him it is low risk. Or you can simply provide a copr repo with the new build for f20 for the time being ? 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] 1106 IPA REST smart proxy
Simo Sorce wrote: On Fri, 2014-02-28 at 09:03 -0500, Rob Crittenden wrote: Petr Viktorin wrote: On 02/28/2014 12:41 PM, Martin Kosek wrote: On 02/28/2014 10:47 AM, Petr Viktorin wrote: On 02/27/2014 10:18 PM, Rob Crittenden wrote: Rob Crittenden wrote: [...] Ok, so try to summarize this long-running thread, I'll rename the subpackage to freeipa-server-foreman-smartproxy to make it clearer what it is/does. Right now it requires manual configuration so having the package installed should have no negative impacts (other than potentially pulling in additional dependencies). I'll leave it in smartproxy for now, it's just cleaner and better integrates with ipatests IMHO. Foreman supports SSL client auth which is great, by cherrypy does not yet. There is a pull request to add this, https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity . Foreman otherwise supports no other authentication method, so we're blocked with this. The certs for this would initially come out of Foreman/puppet. I'll submit a new patch with an updated spec but I think otherwise I've addressed the isuses Petr has raised. This thread has taken a lot of turns so it is very possible I missed something though :-) Updated patch based on feedback from Foreman team. I added a new URI, /features, which Foreman uses to determine what capabilities a proxy has. rob My review is blocked because 389-ds doesn't install on Rawhide due to https://fedorahosted.org/389/ticket/47700 Noriko, do you know of a Rawhide build that includes your fix? Guys, if this patch still makes our master branch incompatible with F20, then it is a NACK from me. All developers run on F20, our CI runs on F20 and I do not think we can afford loosing that and forcing everyone to permanently switch to rawhide - it is too unstable. IMO the Requires and BuildRequires most be set so that RPMs are buildable and installable on F20. The only acceptable exception is when only freeipa-server-foreman-smartprox cannot be installed on F20, but otherwise everything else need to work. Thanks, Martin Okay, it's not a BuildRequires; IPA doesn't build because of a lint failure: ipalib/util.py - Module 'kerberos' has no 'authGSSClientInquireCred' member I guess the new get_current_principal needs to be kept out of ipalib until we move to f21. Until then we can have a lint exception; after then we need to remove it, and add BuildRequires so lint passes. The other option is to locally rebuild python-kerberos from rawhide in F-20. Simo was a bit reluctant to put it into F-20 with the patch I added for authenticate_gss_client_inquire_cred(). We can also work on convincing him it is low risk. Or you can simply provide a copr repo with the new build for f20 for the time being ? That doesn't deal with Martin's requirement that master build in F-20, and I presume by that no asterisks allowed (though we have made exceptions in the past). For a package this small, fetching from copr and rpmbuild are similar amounts of effort, IMHO. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Client-side command in the IPA framework
On 28.2.2014 15:25, Nathaniel McCallum wrote: On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: On 28.2.2014 04:02, Rob Crittenden wrote: Alexander Bokovoy wrote: On Thu, 27 Feb 2014, Nathaniel McCallum wrote: So the recent discussion on importing tokens led me to write a script to parse RFC 6030 xml files into IPA token data. This all works well. But now I need to integrate it into the IPA framework. This command will parse one or more xml files, creating a set of tokens to be added. Given that we already have otptoken-add on the server-side, it seems to me that all work needs to be done on the client-side. How do I create a new client-side command that calls existing server-side API? subclass from frontend.Local, override run() or forward() method and perform batch operation of otptoken_add from there. See cli.help, for example. If you do an override, do forward() for cli-specific work. But you should do as little as possible for reasons you already stated: the UI. Anything you do in forward Petr will need to implement in the UI. Unfortunately we don't yet have a nice way to handle files. We have tickets open at https://fedorahosted.org/freeipa/ticket/1225 and https://fedorahosted.org/freeipa/ticket/2933 If this file is something that would be pasted into a big text field then you can probably handle it in a similarly clumsy way that we do CSRs in the cert plugin. rob +1 for parsing it on server. Otherwise every client, not just CLI or Web UI, would have to reimplement the same logic - having it on server will support better integration with third party products. Parsing on client would be understandable if there was some middle step which would require some action from user, i.e, pick only some tokens to import. If we parse on the server side, how do we handle the long-running operation? Think of the case of importing hundreds or thousands of tokens... My experience is that operation on server side can run for (at least) few minutes without a problem. I haven't try longer periods but we can check that. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Client-side command in the IPA framework
On Fri, 28 Feb 2014, Nathaniel McCallum wrote: On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: On 28.2.2014 04:02, Rob Crittenden wrote: Alexander Bokovoy wrote: On Thu, 27 Feb 2014, Nathaniel McCallum wrote: So the recent discussion on importing tokens led me to write a script to parse RFC 6030 xml files into IPA token data. This all works well. But now I need to integrate it into the IPA framework. This command will parse one or more xml files, creating a set of tokens to be added. Given that we already have otptoken-add on the server-side, it seems to me that all work needs to be done on the client-side. How do I create a new client-side command that calls existing server-side API? subclass from frontend.Local, override run() or forward() method and perform batch operation of otptoken_add from there. See cli.help, for example. If you do an override, do forward() for cli-specific work. But you should do as little as possible for reasons you already stated: the UI. Anything you do in forward Petr will need to implement in the UI. Unfortunately we don't yet have a nice way to handle files. We have tickets open at https://fedorahosted.org/freeipa/ticket/1225 and https://fedorahosted.org/freeipa/ticket/2933 If this file is something that would be pasted into a big text field then you can probably handle it in a similarly clumsy way that we do CSRs in the cert plugin. rob +1 for parsing it on server. Otherwise every client, not just CLI or Web UI, would have to reimplement the same logic - having it on server will support better integration with third party products. Parsing on client would be understandable if there was some middle step which would require some action from user, i.e, pick only some tokens to import. If we parse on the server side, how do we handle the long-running operation? Think of the case of importing hundreds or thousands of tokens... Why then to do it as a IPA CLI command at all? This is an administrative task which can be done with a separate ipa-otp-import command, designated to run on IPA masters. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0481 permission-find: Cache the root entry for legacy permissions
Hello,
This reduces LDAP searches in permission-find when there are legacy
permissions. The root entry (which contains all legacy permission ACIs)
is only looked up once.
--
Petr³
From 34528e3fce17db1e4c2a23f091dc9d7fcd93b97f Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Fri, 28 Feb 2014 13:38:12 +0100
Subject: [PATCH] permission-find: Cache the root entry for legacy permissions
This makes searching faster if there are many legacy permissions present.
The root entry (which contains all legacy permission ACIs) is only
looked up once.
---
ipalib/plugins/permission.py | 31 +++
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/ipalib/plugins/permission.py b/ipalib/plugins/permission.py
index 670e3f1c65452fef26838558ad115ebc2aeda87a..31266adac0326d008f5c1e3f6a94d696edb0c489 100644
--- a/ipalib/plugins/permission.py
+++ b/ipalib/plugins/permission.py
@@ -518,13 +518,14 @@ def _replace_aci(self, permission_entry, old_name=None, new_acistring=None):
return acientry, acistring
def _get_aci_entry_and_string(self, permission_entry, name=None,
- notfound_ok=False):
+ notfound_ok=False, cached_acientry=None):
Get the entry and ACI corresponding to the permission entry
:param name: The name of the permission, or None for the cn
:param notfound_ok:
If true, (acientry, None) will be returned on missing ACI, rather
than raising exception
+:param cached_acientry: See upgrade_permission()
ldap = self.api.Backend.ldap2
if name is None:
@@ -533,10 +534,15 @@ def _get_aci_entry_and_string(self, permission_entry, name=None,
self.api.env.basedn)
wanted_aciname = 'permission:%s' % name
-try:
-acientry = ldap.get_entry(location, ['aci'])
-except errors.NotFound:
-acientry = ldap.make_entry(location)
+if (cached_acientry and
+cached_acientry.dn == location and
+'aci' in cached_acientry):
+acientry = cached_acientry
+else:
+try:
+acientry = ldap.get_entry(location, ['aci'])
+except errors.NotFound:
+acientry = ldap.make_entry(location)
acis = acientry.get('aci', ())
for acistring in acis:
aci = ACI(acistring)
@@ -550,7 +556,7 @@ def _get_aci_entry_and_string(self, permission_entry, name=None,
'in %(dn)s ') % {'name': name, 'dn': location})
def upgrade_permission(self, entry, target_entry=None,
- output_only=False):
+ output_only=False, cached_acientry=None):
Upgrade the given permission entry to V2, in-place
The entry is only upgraded if it is a plain old-style permission,
@@ -563,11 +569,16 @@ def upgrade_permission(self, entry, target_entry=None,
:param output_only:
If true, the flags are not updated to V2.
Used for the -find and -show commands.
+:param cached_acientry:
+Optional pre-retreived entry that contains the existing ACI.
+If it is None or its DN does not match the location DN,
+cached_acientry is ignored and the entry is retreived from LDAP.
if entry.get('ipapermissiontype'):
# Only convert old-style, non-SYSTEM permissions -- i.e. no flags
return
-base, acistring = self._get_aci_entry_and_string(entry)
+base, acistring = self._get_aci_entry_and_string(
+entry, cached_acientry=cached_acientry)
if not target_entry:
target_entry = entry
@@ -1071,8 +1082,11 @@ def post_callback(self, ldap, entries, truncated, *args, **options):
base_dn=DN(self.obj.container_dn, self.api.env.basedn),
filter=ldap.combine_filters(filters, rules=ldap.MATCH_ALL),
attrs_list=attrs_list)
+# Retrieve the root entry (with all legacy ACIs) at once
+root_entry = ldap.get_entry(DN(api.env.basedn), ['aci'])
except errors.NotFound:
legacy_entries = ()
+cached_root_entry = None
self.log.debug('potential legacy entries: %s', len(legacy_entries))
nonlegacy_names = {e.single_value['cn'] for e in entries}
for entry in legacy_entries:
@@ -1087,7 +1101,8 @@ def post_callback(self, ldap, entries, truncated, *args, **options):
entries.pop()
truncated = True
break
-self.obj.upgrade_permission(entry, output_only=True)
+self.obj.upgrade_permission(entry, output_only=True,
+
Re: [Freeipa-devel] Client-side command in the IPA framework
Petr Spacek wrote: On 28.2.2014 15:25, Nathaniel McCallum wrote: On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: On 28.2.2014 04:02, Rob Crittenden wrote: Alexander Bokovoy wrote: On Thu, 27 Feb 2014, Nathaniel McCallum wrote: So the recent discussion on importing tokens led me to write a script to parse RFC 6030 xml files into IPA token data. This all works well. But now I need to integrate it into the IPA framework. This command will parse one or more xml files, creating a set of tokens to be added. Given that we already have otptoken-add on the server-side, it seems to me that all work needs to be done on the client-side. How do I create a new client-side command that calls existing server-side API? subclass from frontend.Local, override run() or forward() method and perform batch operation of otptoken_add from there. See cli.help, for example. If you do an override, do forward() for cli-specific work. But you should do as little as possible for reasons you already stated: the UI. Anything you do in forward Petr will need to implement in the UI. Unfortunately we don't yet have a nice way to handle files. We have tickets open at https://fedorahosted.org/freeipa/ticket/1225 and https://fedorahosted.org/freeipa/ticket/2933 If this file is something that would be pasted into a big text field then you can probably handle it in a similarly clumsy way that we do CSRs in the cert plugin. rob +1 for parsing it on server. Otherwise every client, not just CLI or Web UI, would have to reimplement the same logic - having it on server will support better integration with third party products. Parsing on client would be understandable if there was some middle step which would require some action from user, i.e, pick only some tokens to import. If we parse on the server side, how do we handle the long-running operation? Think of the case of importing hundreds or thousands of tokens... My experience is that operation on server side can run for (at least) few minutes without a problem. I haven't try longer periods but we can check that. It can run for hours. Migration performance in IPA used to be rather pitiful and migrating several thousand users could easily take 5+ hours. IIRC sometimes the client would time out but the server side would still complete, you just got no feedback. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Client-side command in the IPA framework
On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: On Fri, 28 Feb 2014, Nathaniel McCallum wrote: On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: On 28.2.2014 04:02, Rob Crittenden wrote: Alexander Bokovoy wrote: On Thu, 27 Feb 2014, Nathaniel McCallum wrote: So the recent discussion on importing tokens led me to write a script to parse RFC 6030 xml files into IPA token data. This all works well. But now I need to integrate it into the IPA framework. This command will parse one or more xml files, creating a set of tokens to be added. Given that we already have otptoken-add on the server-side, it seems to me that all work needs to be done on the client-side. How do I create a new client-side command that calls existing server-side API? subclass from frontend.Local, override run() or forward() method and perform batch operation of otptoken_add from there. See cli.help, for example. If you do an override, do forward() for cli-specific work. But you should do as little as possible for reasons you already stated: the UI. Anything you do in forward Petr will need to implement in the UI. Unfortunately we don't yet have a nice way to handle files. We have tickets open at https://fedorahosted.org/freeipa/ticket/1225 and https://fedorahosted.org/freeipa/ticket/2933 If this file is something that would be pasted into a big text field then you can probably handle it in a similarly clumsy way that we do CSRs in the cert plugin. rob +1 for parsing it on server. Otherwise every client, not just CLI or Web UI, would have to reimplement the same logic - having it on server will support better integration with third party products. Parsing on client would be understandable if there was some middle step which would require some action from user, i.e, pick only some tokens to import. If we parse on the server side, how do we handle the long-running operation? Think of the case of importing hundreds or thousands of tokens... Why then to do it as a IPA CLI command at all? This is an administrative task which can be done with a separate ipa-otp-import command, designated to run on IPA masters. Agreed. 1. Is there a framework for this? Or should it just be an independent script? 2. How can I use the ipalib API? Specifically, I'd like to call otptoken-add and pass the --key parameter with a value (not possible from the command line). Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Client-side command in the IPA framework
On Fri, 28 Feb 2014, Nathaniel McCallum wrote: On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: On Fri, 28 Feb 2014, Nathaniel McCallum wrote: On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: On 28.2.2014 04:02, Rob Crittenden wrote: Alexander Bokovoy wrote: On Thu, 27 Feb 2014, Nathaniel McCallum wrote: So the recent discussion on importing tokens led me to write a script to parse RFC 6030 xml files into IPA token data. This all works well. But now I need to integrate it into the IPA framework. This command will parse one or more xml files, creating a set of tokens to be added. Given that we already have otptoken-add on the server-side, it seems to me that all work needs to be done on the client-side. How do I create a new client-side command that calls existing server-side API? subclass from frontend.Local, override run() or forward() method and perform batch operation of otptoken_add from there. See cli.help, for example. If you do an override, do forward() for cli-specific work. But you should do as little as possible for reasons you already stated: the UI. Anything you do in forward Petr will need to implement in the UI. Unfortunately we don't yet have a nice way to handle files. We have tickets open at https://fedorahosted.org/freeipa/ticket/1225 and https://fedorahosted.org/freeipa/ticket/2933 If this file is something that would be pasted into a big text field then you can probably handle it in a similarly clumsy way that we do CSRs in the cert plugin. rob +1 for parsing it on server. Otherwise every client, not just CLI or Web UI, would have to reimplement the same logic - having it on server will support better integration with third party products. Parsing on client would be understandable if there was some middle step which would require some action from user, i.e, pick only some tokens to import. If we parse on the server side, how do we handle the long-running operation? Think of the case of importing hundreds or thousands of tokens... Why then to do it as a IPA CLI command at all? This is an administrative task which can be done with a separate ipa-otp-import command, designated to run on IPA masters. Agreed. 1. Is there a framework for this? Or should it just be an independent script? We don't really have a framework for administrative tools. You may start with install/tools/ipa-adtrust-install, it is main part is relatively independent of the task (which is in ipaserver/install/adtrustinstance.py) 2. How can I use the ipalib API? Specifically, I'd like to call otptoken-add and pass the --key parameter with a value (not possible from the command line). Look in ipa-adtrust-install's main(): # Initialize the ipalib api cfg = dict( in_server=True, debug=options.debug, ) api.bootstrap(**cfg) api.finalize() ... try: ctx = krbV.default_context() ccache = ctx.default_ccache() principal = ccache.principal() except krbV.Krb5Error, e: sys.exit(Must have Kerberos credentials to setup AD trusts on server) try: api.Backend.ldap2.connect(ccache) except errors.ACIError, e: sys.exit(Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket) except errors.DatabaseError, e: sys.exit(Cannot connect to the LDAP database. Please check if IPA is running) try: user = api.Command.user_show(unicode(principal[0]))['result'] group = api.Command.group_show(u'admins')['result'] if not (user['uid'][0] in group['member_user'] and group['cn'][0] in user['memberof_group']): raise errors.RequirementError(name='admins group membership') except errors.RequirementError, e: sys.exit(Must have administrative privileges to setup AD trusts on server) except Exception, e: sys.exit(Unrecognized error during check of admin rights: %s % (str(e))) and so on. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Client-side command in the IPA framework
On Fri, 28 Feb 2014, Petr Viktorin wrote: On 02/28/2014 04:02 PM, Nathaniel McCallum wrote: On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: [...] Why then to do it as a IPA CLI command at all? This is an administrative task which can be done with a separate ipa-otp-import command, designated to run on IPA masters. Agreed. 1. Is there a framework for this? Or should it just be an independent script? There is: ipapython.admintool. Look at ipa-server-certinstall for a simple-ish example, ask if you have any questions. Right, forgot about that one. 2. How can I use the ipalib API? Specifically, I'd like to call otptoken-add and pass the --key parameter with a value (not possible from the command line). Finalize the API (see ipaserver.install.ServerCertInstall.run), and then call api.Command['otptoken-add'](key=...) Or you might think about moving the otptoken-add functionality into a function that you can call directly. I'd still prefer to do token addition through the common interface, i.e. not directly talking to ldap but rather using the CLI commands, maybe batched. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Client-side command in the IPA framework
On 02/28/2014 04:15 PM, Alexander Bokovoy wrote: On Fri, 28 Feb 2014, Nathaniel McCallum wrote: On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: On Fri, 28 Feb 2014, Nathaniel McCallum wrote: On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: On 28.2.2014 04:02, Rob Crittenden wrote: Alexander Bokovoy wrote: On Thu, 27 Feb 2014, Nathaniel McCallum wrote: So the recent discussion on importing tokens led me to write a script to parse RFC 6030 xml files into IPA token data. This all works well. But now I need to integrate it into the IPA framework. This command will parse one or more xml files, creating a set of tokens to be added. Given that we already have otptoken-add on the server-side, it seems to me that all work needs to be done on the client-side. How do I create a new client-side command that calls existing server-side API? subclass from frontend.Local, override run() or forward() method and perform batch operation of otptoken_add from there. See cli.help, for example. If you do an override, do forward() for cli-specific work. But you should do as little as possible for reasons you already stated: the UI. Anything you do in forward Petr will need to implement in the UI. Unfortunately we don't yet have a nice way to handle files. We have tickets open at https://fedorahosted.org/freeipa/ticket/1225 and https://fedorahosted.org/freeipa/ticket/2933 If this file is something that would be pasted into a big text field then you can probably handle it in a similarly clumsy way that we do CSRs in the cert plugin. rob +1 for parsing it on server. Otherwise every client, not just CLI or Web UI, would have to reimplement the same logic - having it on server will support better integration with third party products. Parsing on client would be understandable if there was some middle step which would require some action from user, i.e, pick only some tokens to import. If we parse on the server side, how do we handle the long-running operation? Think of the case of importing hundreds or thousands of tokens... Why then to do it as a IPA CLI command at all? This is an administrative task which can be done with a separate ipa-otp-import command, designated to run on IPA masters. Agreed. 1. Is there a framework for this? Or should it just be an independent script? We don't really have a framework for administrative tools. You may start with install/tools/ipa-adtrust-install, it is main part is relatively independent of the task (which is in ipaserver/install/adtrustinstance.py) The framework is there, new tools use it, and there's a ticket to convert old ones: https://fedorahosted.org/freeipa/ticket/2652 (it's low priority in Future Releases, so not much progress is there...) Also see http://www.freeipa.org/page/V3/Logging_and_output -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Client-side command in the IPA framework
On 02/28/2014 04:02 PM, Nathaniel McCallum wrote: On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: [...] Why then to do it as a IPA CLI command at all? This is an administrative task which can be done with a separate ipa-otp-import command, designated to run on IPA masters. Agreed. 1. Is there a framework for this? Or should it just be an independent script? There is: ipapython.admintool. Look at ipa-server-certinstall for a simple-ish example, ask if you have any questions. 2. How can I use the ipalib API? Specifically, I'd like to call otptoken-add and pass the --key parameter with a value (not possible from the command line). Finalize the API (see ipaserver.install.ServerCertInstall.run), and then call api.Command['otptoken-add'](key=...) Or you might think about moving the otptoken-add functionality into a function that you can call directly. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 238 Fix modlist generation code not to generate empty replace mods
On 02/04/2014 03:01 PM, Jan Cholasta wrote:
Hi,
the attached patch fixes https://fedorahosted.org/freeipa/ticket/4138.
Honza
Thanks, ACK. Here are some tests for this, do they look good?
--
Petr³
From ca10b6af63727f0ca7a008dccc9edbe594ca5467 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Fri, 28 Feb 2014 16:27:22 +0100
Subject: [PATCH] Test fixed modlist generation code
https://fedorahosted.org/freeipa/ticket/4138
---
ipatests/test_xmlrpc/test_attr.py | 6 ++
ipatests/test_xmlrpc/test_permission_plugin.py | 12 +++-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/ipatests/test_xmlrpc/test_attr.py b/ipatests/test_xmlrpc/test_attr.py
index d4671b9848baa90021dd77ae71009ea454798ec8..70e3d326c5e8085afe83a3b3742273266869aa46 100644
--- a/ipatests/test_xmlrpc/test_attr.py
+++ b/ipatests/test_xmlrpc/test_attr.py
@@ -279,6 +279,12 @@ class test_attr(Declarative):
),
dict(
+desc='Try to remove empty location from %r' % user1,
+command=('user_mod', [user1], dict(l=None)),
+expected=errors.EmptyModlist(),
+),
+
+dict(
desc='Lock %r using setattr' % user1,
command=(
'user_mod', [user1], dict(setattr=u'nsaccountlock=TrUe')
diff --git a/ipatests/test_xmlrpc/test_permission_plugin.py b/ipatests/test_xmlrpc/test_permission_plugin.py
index 4903bfae340dd8955a170bbb2c8121468bc47a18..6aa00f9f7de03486fb9304bb09ca7eee68142e52 100644
--- a/ipatests/test_xmlrpc/test_permission_plugin.py
+++ b/ipatests/test_xmlrpc/test_permission_plugin.py
@@ -271,6 +271,16 @@ class test_permission_negative(Declarative):
),
dict(
+desc='Try to remove empty memberof from %r' % permission1,
+command=(
+'permission_mod', [permission1], dict(
+memberof=None,
+)
+),
+expected=errors.EmptyModlist(),
+),
+
+dict(
desc='Try to remove targetfilter and memberof from %r' % permission1,
command=(
'permission_mod', [permission1], dict(
@@ -285,7 +295,7 @@ class test_permission_negative(Declarative):
),
dict(
-desc='Try to rename %r to invalid invalid %r' % (
+desc='Try to rename %r to invalid %r' % (
permission1, invalid_permission1),
command=('permission_mod', [permission1], dict(
rename=invalid_permission1,
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Client-side command in the IPA framework
On Fri, 2014-02-28 at 10:01 -0500, Rob Crittenden wrote: Petr Spacek wrote: On 28.2.2014 15:25, Nathaniel McCallum wrote: On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: On 28.2.2014 04:02, Rob Crittenden wrote: Alexander Bokovoy wrote: On Thu, 27 Feb 2014, Nathaniel McCallum wrote: So the recent discussion on importing tokens led me to write a script to parse RFC 6030 xml files into IPA token data. This all works well. But now I need to integrate it into the IPA framework. This command will parse one or more xml files, creating a set of tokens to be added. Given that we already have otptoken-add on the server-side, it seems to me that all work needs to be done on the client-side. How do I create a new client-side command that calls existing server-side API? subclass from frontend.Local, override run() or forward() method and perform batch operation of otptoken_add from there. See cli.help, for example. If you do an override, do forward() for cli-specific work. But you should do as little as possible for reasons you already stated: the UI. Anything you do in forward Petr will need to implement in the UI. Unfortunately we don't yet have a nice way to handle files. We have tickets open at https://fedorahosted.org/freeipa/ticket/1225 and https://fedorahosted.org/freeipa/ticket/2933 If this file is something that would be pasted into a big text field then you can probably handle it in a similarly clumsy way that we do CSRs in the cert plugin. rob +1 for parsing it on server. Otherwise every client, not just CLI or Web UI, would have to reimplement the same logic - having it on server will support better integration with third party products. Parsing on client would be understandable if there was some middle step which would require some action from user, i.e, pick only some tokens to import. If we parse on the server side, how do we handle the long-running operation? Think of the case of importing hundreds or thousands of tokens... My experience is that operation on server side can run for (at least) few minutes without a problem. I haven't try longer periods but we can check that. It can run for hours. Migration performance in IPA used to be rather pitiful and migrating several thousand users could easily take 5+ hours. IIRC sometimes the client would time out but the server side would still complete, you just got no feedback. In this case, feedback is pretty crucial. We will validate all the tokens before writing any of them, so this feedback could be pretty quick. However, if an error occurs during writing, we need to continue adding all the tokens and give an error report at the end of all the tokens that weren't added. Ideally, this report should be in the same import xml format that was provided. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] server install failing in F-20?
I'm seeing what looks like https://fedorahosted.org/freeipa/ticket/4084 in new F-20 install I stood up. I finally threw my hands up and configured system to use an environment file to work around it. Not sure if anyone else is seeing this. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] server install failing in F-20?
On Fri, 28 Feb 2014, Rob Crittenden wrote: I'm seeing what looks like https://fedorahosted.org/freeipa/ticket/4084 in new F-20 install I stood up. I finally threw my hands up and configured system to use an environment file to work around it. Not sure if anyone else is seeing this. One difference on F20 is that you are not supposed to see ccaches in /tmp -- they are in the kernel keyring. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
