[Freeipa-devel] [PATCH] 206 Improve password change error message

2012-02-02 Thread Martin Kosek 
User always receives the same error message if he changes his password
via ipa passwd command and the new password fails configured
password policy. He then has to investigate on his own the actual
reason why was the policy violated. This patch improves our SLAPI PWD
plugins to provide a better error message explaining the violation
reason.

https://fedorahosted.org/freeipa/ticket/2067

From eca1c4221c77139f0dafa2fb8d38f22b6c0481d9 Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Thu, 2 Feb 2012 11:55:14 +0100
Subject: [PATCH] Improve password change error message

User always receives the same error message if he changes his password
via ipa passwd command and the new password fails configured
password policy. He then has to investigate on his own the actual
reason why was the policy violated. This patch improves our SLAPI PWD
plugins to provide a better error message explaining the violation
reason.

https://fedorahosted.org/freeipa/ticket/2067
---
 .../ipa-pwd-extop/ipa_pwd_extop.c  |2 +-
 .../ipa-pwd-extop/ipapwd_prepost.c |4 ++--
 util/ipa_pwd.c |   20 
 util/ipa_pwd.h |6 ++
 4 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
index 65c5834595f89aee8502347311f247be058c3416..64b1f8c353de816ca7ef8ccece35b7313a18bfbe 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
@@ -461,7 +461,7 @@ parse_req_done:
 	/* check the policy */
 	ret = ipapwd_CheckPolicy(pwdata);
 	if (ret) {
-		errMesg = Password Fails to meet minimum strength criteria;
+		errMesg = ipapwd_error2string(ret);
 		if (ret == IPAPWD_POLICY_ERROR) {
 			errMesg = Internal error;
 			rc = ret;
diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
index 961678acb4f7a3265b5b221acedb96a63cea5855..8185aa047570f0b24dabf9d580bf2d6bcbf241a0 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
@@ -302,7 +302,7 @@ static int ipapwd_pre_add(Slapi_PBlock *pb)
 
 ret = ipapwd_CheckPolicy(pwdop-pwdata);
 if (ret) {
-errMesg = Password Fails to meet minimum strength criteria;
+errMesg = ipapwd_error2string(ret);
 rc = LDAP_CONSTRAINT_VIOLATION;
 goto done;
 }
@@ -740,7 +740,7 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb)
 if (has_krb_keys == 0) {
 ret = ipapwd_CheckPolicy(pwdop-pwdata);
 if (ret) {
-errMesg = Password Fails to meet minimum strength criteria;
+errMesg = ipapwd_error2string(ret);
 rc = LDAP_CONSTRAINT_VIOLATION;
 goto done;
 }
diff --git a/util/ipa_pwd.c b/util/ipa_pwd.c
index fda6cb34ef24059362207325db61aedb62d7b665..b6ed929b3761fbce8f0ce90e6555123848d0c88d 100644
--- a/util/ipa_pwd.c
+++ b/util/ipa_pwd.c
@@ -538,6 +538,26 @@ int ipapwd_check_policy(struct ipapwd_policy *policy,
 return IPAPWD_POLICY_OK;
 }
 
+char * IPAPWD_ERROR_STRINGS[] = {
+Password is OK,
+Account expired,
+Too soon to change password,
+Password is too short,
+Password reuse not permitted,
+Password is too simple
+};
+
+char * IPAPWD_ERROR_STRING_GENERAL = Password does not meet the policy requirements;
+
+char * ipapwd_error2string(enum ipapwd_error err) {
+   if (err  0 || err  IPAPWD_POLICY_PWD_COMPLEXITY) {
+   /* IPAPWD_POLICY_ERROR or out of boundary, return general error */
+   return IPAPWD_ERROR_STRING_GENERAL;
+   }
+
+   return IPAPWD_ERROR_STRINGS[err];
+}
+
 /**
 * @briefGenerate a new password history using the new password
 *
diff --git a/util/ipa_pwd.h b/util/ipa_pwd.h
index 7a00b7fc3652e75f69f6f936acfddc8b50867950..3c60f12bf3f4c8f08aae44753888c2535c764550 100644
--- a/util/ipa_pwd.h
+++ b/util/ipa_pwd.h
@@ -27,6 +27,10 @@
 #define IPAPWD_DEFAULT_PWDLIFE (90 * 24 *3600)
 #define IPAPWD_DEFAULT_MINLEN 0
 
+/*
+ * IMPORTANT: plese update error string table in ipa_pwd.c if you change this
+ * error code table.
+ */
 enum ipapwd_error {
 IPAPWD_POLICY_ERROR = -1,
 IPAPWD_POLICY_OK = 0,
@@ -55,6 +59,8 @@ int ipapwd_check_policy(struct ipapwd_policy *policy,
 time_t last_pwd_change,
 char **pwd_history);
 
+char * ipapwd_error2string(enum ipapwd_error err);
+
 int ipapwd_generate_new_history(char *password,
 time_t cur_time,
 int history_length,
-- 
1.7.7.6

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3

2012-02-02 Thread Sumit Bose 
On Wed, Feb 01, 2012 at 01:59:15PM -0500, Simo Sorce wrote:
 On Wed, 2012-02-01 at 12:00 -0500, Dmitri Pal wrote:
  On 01/31/2012 06:45 AM, Sumit Bose wrote:
   Hi,
  
   for the IPAv3 trust feature we have to add the objectclass
   ipaNTUserAttrs/ipaNTGroupAttrs to every user/group which should be
   visible on the Windows side of the trust. The only MUST attribute of
   both objectclasses is ipaNTSecurityIdentifier the SID or the user or
   group. We would like to manage the SIDS with the DNA plugin since they
   have to be unique in the IPA domain.
  
   The trust support will typically be added to a running IPA domain,
   because we do not plan to install it by default and we have to consider
   updated v2 environments as well. So the question arises what is the most
   preferred way to add a DNA configuration to an existing Directory Server
   setup with replication.
  
   Nathan suggested to create the configuration with the full range on the
   first master, configure the other master with no available values
   and let the DNA plugin transfer the ranges between the masters.
 
 This is the way to go.
 
   This will lead to the following steps:
  
   1. Check if there are already shared configuration entries in
  cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX
  
   2a. if not we can create the initial configuration on the current
   master:
  
   dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
   changetype: add
   objectclass: top
   objectclass: extensibleObject
   cn: SIDs
   dnaType: ipaNTSecurityIdentifier
   dnaNextValue: 1000
   dnaMaxValue: eval($SIDMAX)# Maybe 200k ?
   dnaMagicRegen: 999
   dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs))
   dnaScope: $SUFFIX
   dnaThreshold: 500
   dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX
  
   3a. Add ipaNTUserAttrs/ipaNTGroupAttrs to all users/groups with
   ipaNTSecurityIdentifier=999 on the current master
 
 This should be done as a task in Directory server.
 
   4a. Done on the first master
 
 I am not sure I understand what does this means.
 
   2b. if there are already entries we can create the configuration for an
   additional master:
  
   dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
   changetype: add
   objectclass: top
   objectclass: extensibleObject
   cn: SIDs
   dnaType: ipaNTSecurityIdentifier
   dnaNextValue: 1101
   dnaMaxValue: 1100
   dnaMagicRegen: 999
   dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs))
   dnaScope: $SUFFIX
   dnaThreshold: 500
   dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX
  
   3b. Done on the additional master, DNA plugin will sort out the rest
  
  
  
   Do these steps make sense?
 
 Yes.
 
   Is it necessary to add a lock to prevent a race condition btween step 1
   and 2a, i.e. two admins try to prepare IPA for trusts independently at
   the same time?
 
 No, if admins are so dumb not to coordinate on adding this
 infrastructure changing stuff and do it at the exact same moment it's
 really their problem. We will, of course, document that they should be
 careful.
 
   Do I understand it correctly that if dnaMaxValue is set to e.g. 2^32 on
   the first master, the range on the second master will start at 2^31? So
   the usage of the full range will be quite sparse if dnaMaxValue is set
   too high.
 
 True, ranges are always split in half for now.
 
   Step 3a on the first master might need some time to finish. Is it
   necessary to set some kind of lock to prevent the configuration of the
   DNA plugin on other masters while this task is running or is it safe to
   add another master at any time?
 
 safe, the task to add SIDs to users should be an explicit DS task set up
 only by the ipa-trust-install script.
 
   Are there other ways to introduce the DNA configuration? Nathan
   suggested also that the ranges can be configured manually without
   overlap, but if possible I would prefer the automatic way.
 
 Automatic is better, less error prone.
 
  Couple comments.
  1) What is the impact on the replication?
 
 If you have many users the first replication would take a long time.
 
  2) How we can prevent the case when in the distributed topology the
  change starts from two ends?
 
 By documenting that you do not run ipa-trust-install on 2 ends.
 
  3) What is the speed of the propagation of this configuration in a 20
  replica architecture?
 
 It depends on the replica topology and what master you run the install
 on.
 
  4) Would it be better to generate the SIDs on every replica? We already
  have UID/GID and GUIDs for the entries. If SID is derived from entry
  GUID the change can be made locally and does not require replication.
 
 SIDs cannot be derived from GUIDs.
 
  The GUIDs are already replicated so the SID can be generated locally
  like we do with the other non replicated attributes. In this case you
  just need to install a new plugin on your replicas and change

Re: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3

2012-02-02 Thread Alexander Bokovoy 
On Thu, 02 Feb 2012, Sumit Bose wrote:
 Simo, thank you for give detailed responses and explanations here. To
 make it - hopefully - even clearer I try to describe the step that are
 necessary to enable IPA for trust and to create trust to AD domains.
 
 I assume that we start from a running IPAv2 setup with replication:
 
 1. Update IPA to v3, install the new packages, run everything that is
 needed for the update. This step will not create anything related to
 trust (only the needed python code and config file templates are
 installed)
 
 2. Call ipa-adtrust-install to enable IPA to handle trust, this will
   - create the samba configuration
   - add cn=trust to the DIT
   - generate a domain SID and stores it in the DIT
   - add the well know administrator and admin group SIDs to the admin user
 and the admins group respectively
   - activate the CLDAP directory server plugin
   - add DNA configuration to automatically add SIDs to users and groups
 on the server where ipa-adtrust-install
At this point 'ipa trust ...' set of commands mentioned in (5) will be 
able to operate because we'll have enough information about our own 
domain to proceed with trusts to other domains.


 3. Now SIDs can be added to users and groups, this can be done
   - as Simo mentioned above with the help of a directory server task to
 generate them as fast a possible
   - but if there are concerns about the traffic caused by the
 replication, this can also be done by an external script, with a
 rate limitation or during non-office hours
 this process might take some time, but since it has to be done only once
 I think it is even acceptable if it needs some days to finish, as long
 as it is documented :-)
Agree. 

There are two separate phases here, actually:
- trust creation
- trust usage

Normal usage is possible after step (3), creating trusts is possible 
before (3), albeight it wouldn't be quite usable besides administrator 
account.
 
 4. Now ipa-adtrust-install can be called on other IPA servers which will
 now skip the configuration steps which can already be found in the
 replicated tree, some of the remaining ones are:
   - create the samba configuration
   - activate the CLDAP directory server plugin
   - add SID DNA configuration with an empty range
ACK. There is also need to add DNS records to get these IPA servers in 
use for AD discovery.

 
 5. Finally a trust to an AD domain can be created my calling 'net rpc
 trust create ...' (Alexander is working on the integration into the ipa
 utility so that it will be more like 'ipa adtrust-create' or similar).
Yep.

-- 
/ Alexander Bokovoy

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 207 Improve dnszone-add error message

2012-02-02 Thread Martin Kosek 
When a new DNS record is being added to DNS zone via command
  ipa dnsrecord-add ZONE @
and the target ZONE does not exist it returns ObjectclassViolation
which may confuse users. Make sure that standard DNS Zone NotFound
exception is returned.

https://fedorahosted.org/freeipa/ticket/2270

From eb32b50894390d366a4eaf36c51ad0b7568ea30c Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Thu, 2 Feb 2012 13:40:26 +0100
Subject: [PATCH] Improve dnszone-add error message

When a new DNS record is being added to DNS zone via command
  ipa dnsrecord-add ZONE @
and the target ZONE does not exist it returns ObjectclassViolation
which may confuse users. Make sure that standard DNS Zone NotFound
exception is returned.

https://fedorahosted.org/freeipa/ticket/2270
---
 ipalib/plugins/dns.py |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
index da4934fc971cb1cb8b2b930cad55b341b692cb5c..66edae5f307eb9e591c76c4eb66676496cfe1c6b 100644
--- a/ipalib/plugins/dns.py
+++ b/ipalib/plugins/dns.py
@@ -1464,7 +1464,13 @@ class dnsrecord(LDAPObject):
 
 def get_dn(self, *keys, **options):
 if self.is_pkey_zone_record(*keys):
-return self.api.Object[self.parent_object].get_dn(*keys[:-1], **options)
+dn = self.api.Object[self.parent_object].get_dn(*keys[:-1], **options)
+# zone must exist
+ldap = self.api.Backend.ldap2
+try:
+(dn_, zone) = ldap.get_entry(dn, [])
+except errors.NotFound:
+self.api.Object['dnszone'].handle_not_found(keys[-2])
 return super(dnsrecord, self).get_dn(*keys, **options)
 
 def attr_to_cli(self, attr):
-- 
1.7.7.6

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3

2012-02-02 Thread Simo Sorce 
On Thu, 2012-02-02 at 13:39 +0200, Alexander Bokovoy wrote:
 On Thu, 02 Feb 2012, Sumit Bose wrote:
  Simo, thank you for give detailed responses and explanations here. To
  make it - hopefully - even clearer I try to describe the step that are
  necessary to enable IPA for trust and to create trust to AD domains.
  
  I assume that we start from a running IPAv2 setup with replication:
  
  1. Update IPA to v3, install the new packages, run everything that is
  needed for the update. This step will not create anything related to
  trust (only the needed python code and config file templates are
  installed)
  
  2. Call ipa-adtrust-install to enable IPA to handle trust, this will
- create the samba configuration
- add cn=trust to the DIT
- generate a domain SID and stores it in the DIT
- add the well know administrator and admin group SIDs to the admin user
  and the admins group respectively
- activate the CLDAP directory server plugin
- add DNA configuration to automatically add SIDs to users and groups
  on the server where ipa-adtrust-install
 At this point 'ipa trust ...' set of commands mentioned in (5) will be 
 able to operate because we'll have enough information about our own 
 domain to proceed with trusts to other domains.
 
 
  3. Now SIDs can be added to users and groups, this can be done
- as Simo mentioned above with the help of a directory server task to
  generate them as fast a possible
- but if there are concerns about the traffic caused by the
  replication, this can also be done by an external script, with a
  rate limitation or during non-office hours
  this process might take some time, but since it has to be done only once
  I think it is even acceptable if it needs some days to finish, as long
  as it is documented :-)
 Agree. 
 
 There are two separate phases here, actually:
   - trust creation
   - trust usage
 
 Normal usage is possible after step (3), creating trusts is possible 
 before (3), albeight it wouldn't be quite usable besides administrator 
 account.
  
  4. Now ipa-adtrust-install can be called on other IPA servers which will
  now skip the configuration steps which can already be found in the
  replicated tree, some of the remaining ones are:
- create the samba configuration
- activate the CLDAP directory server plugin
- add SID DNA configuration with an empty range
 ACK. There is also need to add DNS records to get these IPA servers in 
 use for AD discovery.

This is actually critical, the other servers need to have the DNA plugin
properly configured, otherwise creating a user on another server will
not add the SID, and we will have some users missing them.

So I am thinking that we have 2 strategies here:

- Require we run a ipa-trust-prepare script on all masters before we
populate users

- Add a new plugin, enabled by default at upgrade time, that is able to
detect trust were activated, and when that happens it automatically adds
the CLDAP and DNA plugins needed configuration. There is also the
problem of the samba configuration (Still the server will need a restart
so it is not a complete solution I guess).

The second would be nice, but it seem a lot more complex than what we
can afford for a first release and still has some gotchas.

Also we need to consider that we may not want to make all servers expose
samba and cldap. In most cases admins would want to enable only servers
that are close to the AD domain they want to trust.

So we need the DNA plugin configured everywhere, because it works at
user creation, but we need to be able to *not* configure samba, cldap
(and _msdcs DNS records) where not wanted.

We will also need a way to show which servers are 'trust' enabled so
that admins can easily inspect their setup.

  5. Finally a trust to an AD domain can be created my calling 'net rpc
  trust create ...' (Alexander is working on the integration into the ipa
  utility so that it will be more like 'ipa adtrust-create' or similar).
 Yep.

ack to all the rest.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 074 Automember UI - default groups

2012-02-02 Thread Petr Vobornik 
In this patch was implemented and added a control for defining default 
automember groups.


There is a difference from UXD spec. In the spec the control was placed 
below table in the search facet. This was not working well with the 
combobox in the control. Open combobox requires some space below it. As 
it was placed at the bottom of the page it created unwanted blank space 
and forced showing scrollbars. Moving the control above the table solves 
the problem without rewriting combobox logic. It can be rewritten and 
moved down later.


https://fedorahosted.org/freeipa/ticket/2195
--
Petr Vobornik
From 4c1fd8ddb9151c8e461c80f6e940d88860d02e2f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Voborn=C3=ADk?= pvobo...@redhat.com
Date: Thu, 2 Feb 2012 17:55:36 +0100
Subject: [PATCH] Automember UI - default groups

In this patch was implemented and added a control for defining default automember groups.

There is a difference from UXD spec. In the spec the control was placed below table in the search facet. This was not working well with the combobox in the control. Open combobox requires some space below it. As it was placed at the bottom of the page it created unwanted blank space and forced showing scrollbars. Moving the control above the table solves the problem without rewriting combobox logic. It can be rewritten and moved down later.

https://fedorahosted.org/freeipa/ticket/2195
---
 install/ui/automember.js   |  217 
 install/ui/ipa.css |   34 +++
 .../data/automembergroup_default_group_remove.json |   14 ++
 .../data/automembergroup_default_group_set.json|   16 ++
 .../data/automembergroup_default_group_show.json   |   17 ++
 .../automemberhostgroup_default_group_remove.json  |   14 ++
 .../automemberhostgroup_default_group_set.json |   16 ++
 .../automemberhostgroup_default_group_show.json|   15 ++
 install/ui/widget.js   |5 +-
 9 files changed, 346 insertions(+), 2 deletions(-)
 create mode 100644 install/ui/test/data/automembergroup_default_group_remove.json
 create mode 100644 install/ui/test/data/automembergroup_default_group_set.json
 create mode 100644 install/ui/test/data/automembergroup_default_group_show.json
 create mode 100644 install/ui/test/data/automemberhostgroup_default_group_remove.json
 create mode 100644 install/ui/test/data/automemberhostgroup_default_group_set.json
 create mode 100644 install/ui/test/data/automemberhostgroup_default_group_show.json

diff --git a/install/ui/automember.js b/install/ui/automember.js
index d6c3c7ee730b7e2d260aadda179b867dbe12610c..f3010105c4b2cc637f24aed4dbcae93f6982d701 100644
--- a/install/ui/automember.js
+++ b/install/ui/automember.js
@@ -106,6 +106,21 @@ IPA.automember.rule_search_facet = function(spec) {
 
 that.group_type = spec.group_type;
 
+var init = function() {
+
+that.default_group_widget = IPA.automember.default_group_widget({
+entity: that.entity,
+group_type: that.group_type
+});
+};
+
+that.refresh = function() {
+
+that.search_facet_refresh();
+that.default_group_widget.refresh();
+};
+
+
 that.get_records_command_name = function() {
 return that.managed_entity.name + that.group_type+'_get_records';
 };
@@ -139,6 +154,23 @@ IPA.automember.rule_search_facet = function(spec) {
 return command;
 };
 
+that.create_content = function(container) {
+
+var header = $('div/', {
+'class': 'automember-header'
+}).appendTo(container);
+
+var content = $('div/', {
+'class': 'automember-content'
+}).appendTo(container);
+
+that.default_group_widget.create(header);
+that.table.create(content);
+
+};
+
+init();
+
 return that;
 };
 
@@ -458,4 +490,189 @@ IPA.automember.condition_widget = function(spec) {
 
 IPA.widget_factories['automember_condition'] = IPA.automember.condition_widget;
 
+IPA.automember.default_group_widget = function(spec) {
+
+spec = spec || {};
+
+var that = IPA.widget(spec);
+that.group_type = spec.group_type;
+that.group = '';
+
+var init = function() {
+
+var checkbox_name = IPA.html_util.get_next_id('enabled_');
+
+that.enable_checkbox = IPA.checkbox_widget({
+name: checkbox_name,
+label: IPA.messages.status.enable,
+tooltip: IPA.messages.status.enable,
+show_undo: false
+});
+
+that.enable_checkbox.value_changed.attach(that.enable_changed);
+
+that.group_select = IPA.entity_select_widget({
+name: 'automemberdefaultgroup',
+other_entity: that.group_type,
+other_field: 'cn',
+read_only: true,
+show_undo: false
+});
+
+that.group_select.value_changed.attach(that.group_changed);
+};
+
+that.get_group = function() {
+
+var

[Freeipa-devel] [PATCH] 208 Fix raw format for ACI commands

2012-02-02 Thread Martin Kosek 
ACI plugins (permission, selfservice and delegation) were not
prepared to serve ACIs in a raw format, i.e. raw aci attribute
taken from LDAP. This patch fixes all these plugins and their
commands to provide provide this format. Few ACI raw format unit
tests were added for all these plugins.

https://fedorahosted.org/freeipa/ticket/2010
https://fedorahosted.org/freeipa/ticket/2223
https://fedorahosted.org/freeipa/ticket/2228
https://fedorahosted.org/freeipa/ticket/2232

From 0e10d04873eb9d97f8eb02c284dc1b996b9cf2a0 Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Thu, 2 Feb 2012 21:28:15 +0100
Subject: [PATCH] Fix raw format for ACI commands

ACI plugins (permission, selfservice and delegation) were not
prepared to serve ACIs in a raw format, i.e. raw aci attribute
taken from LDAP. This patch fixes all these plugins and their
commands to provide provide this format. Few ACI raw format unit
tests were added for all these plugins.

https://fedorahosted.org/freeipa/ticket/2010
https://fedorahosted.org/freeipa/ticket/2223
https://fedorahosted.org/freeipa/ticket/2228
https://fedorahosted.org/freeipa/ticket/2232
---
 ipalib/plugins/delegation.py |   53 +++--
 ipalib/plugins/permission.py |   36 +++--
 ipalib/plugins/selfservice.py|   46 +++---
 tests/test_xmlrpc/test_delegation_plugin.py  |   29 ++
 tests/test_xmlrpc/test_permission_plugin.py  |   35 +
 tests/test_xmlrpc/test_selfservice_plugin.py |   29 ++
 6 files changed, 162 insertions(+), 66 deletions(-)

diff --git a/ipalib/plugins/delegation.py b/ipalib/plugins/delegation.py
index 660425013b6622a1b4f21c0cb72d761537641bf8..b707cd7855fd2722276ab2d094d715d95761a1c7 100644
--- a/ipalib/plugins/delegation.py
+++ b/ipalib/plugins/delegation.py
@@ -55,6 +55,12 @@ EXAMPLES:
 
 ACI_PREFIX=udelegation
 
+output_params = (
+Str('aci',
+label=_('ACI'),
+),
+)
+
 class delegation(Object):
 
 Delegation object.
@@ -112,6 +118,13 @@ class delegation(Object):
 json_dict['methods'] = [m for m in self.methods]
 return json_dict
 
+def postprocess_result(self, result):
+try:
+# do not include prefix in result
+del result['aciprefix']
+except KeyError:
+pass
+
 api.register(delegation)
 
 
@@ -119,19 +132,14 @@ class delegation_add(crud.Create):
 __doc__ = _('Add a new delegation.')
 
 msg_summary = _('Added delegation %(value)s')
+has_output_params = output_params
 
 def execute(self, aciname, **kw):
-ldap = self.api.Backend.ldap2
 if not 'permissions' in kw:
 kw['permissions'] = (u'write',)
 kw['aciprefix'] = ACI_PREFIX
 result = api.Command['aci_add'](aciname, **kw)['result']
-
-# do not include prefix in result
-try:
-del result['aciprefix']
-except KeyError:
-pass
+self.obj.postprocess_result(result)
 
 return dict(
 result=result,
@@ -150,6 +158,7 @@ class delegation_del(crud.Delete):
 def execute(self, aciname, **kw):
 kw['aciprefix'] = ACI_PREFIX
 result = api.Command['aci_del'](aciname, **kw)
+self.obj.postprocess_result(result)
 return dict(
 result=True,
 value=aciname,
@@ -162,16 +171,12 @@ class delegation_mod(crud.Update):
 __doc__ = _('Modify a delegation.')
 
 msg_summary = _('Modified delegation %(value)s')
+has_output_params = output_params
 
 def execute(self, aciname, **kw):
 kw['aciprefix'] = ACI_PREFIX
 result = api.Command['aci_mod'](aciname, **kw)['result']
-
-# do not include prefix in result
-try:
-del result['aciprefix']
-except KeyError:
-pass
+self.obj.postprocess_result(result)
 
 return dict(
 result=result,
@@ -189,18 +194,14 @@ class delegation_find(crud.Search):
 )
 
 takes_options = (gen_pkey_only_option(name),)
+has_output_params = output_params
 
 def execute(self, term, **kw):
-ldap = self.api.Backend.ldap2
 kw['aciprefix'] = ACI_PREFIX
 results = api.Command['aci_find'](term, **kw)['result']
 
 for aci in results:
-# do not include prefix in result
-try:
-del aci['aciprefix']
-except KeyError:
-pass
+self.obj.postprocess_result(aci)
 
 return dict(
 result=results,
@@ -214,19 +215,11 @@ api.register(delegation_find)
 class delegation_show(crud.Retrieve):
 __doc__ = _('Display information about a delegation.')
 
-has_output_params = (
-Str('aci',
-label=_('ACI'),
-),
-)
+has_output_params = output_params
 
 def execute(self, aciname, **kw):
-result = api.Command['aci_show'](aciname,