Re: [Freeipa-devel] [PATCHES] 0508-0509 Add support for "non-object" managed permissions

2014-04-09 Thread Petr Viktorin 

On 04/09/2014 10:31 AM, Martin Kosek wrote:

On 04/08/2014 05:17 PM, Petr Viktorin wrote:

On 04/08/2014 04:39 PM, Martin Kosek wrote:

On 04/08/2014 01:14 PM, Petr Viktorin wrote:

On 04/08/2014 12:53 PM, Martin Kosek wrote:

On 04/08/2014 11:03 AM, Petr Viktorin wrote:

...

The patch is functional, but I am not really a big fan of placing it in the
plugin. I would prefer if the ACI definition is also in the sudo plugin
together with other definition. It would be then much easier to audit all
sudo-related ACIs.

Why can't we add this ACI to sudorule object managed permissions and just
override the location and target?


I can do that. Most of the changes make this overriding possible, where the
permission is actually defined is a detail.


I am not insisting on a specific format, I would simply prefer to have all
plugin object related ACIs close together.


My reasoning is that finding the definition would not be straightforward. All
the object-specific permissions so far are defined in "their" plugins, as
determined by --type. This one won't have --type, and it's not clear if it
should be in sudorule, sudocmd or sudocmdgroup.

But, I don't have a strong preference. A `git grep` will always show the
definition.



IMO sudorule is fine, I personally see it as an overarching plugin for sudo,
sudocmds and sudocmdgroups are just part of the sudorule.

We may just want to somehow differentiate the non--type ACIs from the regular
--type ones. Whether it is a different attribute in the Object or a setting in
managed permission is something I will leave up to you.


I went with a "non_object" key in the managed permission info.

Attaching new patches.


This looks good to me, ACK.

Martin



Thanks, pushed to master: c58d6b2689acbfa36aec362b7de1ec7512d5f82a

--
Petr³

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

Re: [Freeipa-devel] [PATCHES] 0508-0509 Add support for "non-object" managed permissions

2014-04-09 Thread Martin Kosek 
On 04/08/2014 05:17 PM, Petr Viktorin wrote:
> On 04/08/2014 04:39 PM, Martin Kosek wrote:
>> On 04/08/2014 01:14 PM, Petr Viktorin wrote:
>>> On 04/08/2014 12:53 PM, Martin Kosek wrote:
 On 04/08/2014 11:03 AM, Petr Viktorin wrote:
>> ...
 The patch is functional, but I am not really a big fan of placing it in the
 plugin. I would prefer if the ACI definition is also in the sudo plugin
 together with other definition. It would be then much easier to audit all
 sudo-related ACIs.

 Why can't we add this ACI to sudorule object managed permissions and just
 override the location and target?
>>>
>>> I can do that. Most of the changes make this overriding possible, where the
>>> permission is actually defined is a detail.
>>>
 I am not insisting on a specific format, I would simply prefer to have all
 plugin object related ACIs close together.
>>>
>>> My reasoning is that finding the definition would not be straightforward. 
>>> All
>>> the object-specific permissions so far are defined in "their" plugins, as
>>> determined by --type. This one won't have --type, and it's not clear if it
>>> should be in sudorule, sudocmd or sudocmdgroup.
>>>
>>> But, I don't have a strong preference. A `git grep` will always show the
>>> definition.
>>>
>>
>> IMO sudorule is fine, I personally see it as an overarching plugin for sudo,
>> sudocmds and sudocmdgroups are just part of the sudorule.
>>
>> We may just want to somehow differentiate the non--type ACIs from the regular
>> --type ones. Whether it is a different attribute in the Object or a setting 
>> in
>> managed permission is something I will leave up to you.
> 
> I went with a "non_object" key in the managed permission info.
> 
> Attaching new patches.

This looks good to me, ACK.

Martin

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

Re: [Freeipa-devel] [PATCHES] 0508-0509 Add support for "non-object" managed permissions

2014-04-08 Thread Petr Viktorin 

On 04/08/2014 04:39 PM, Martin Kosek wrote:

On 04/08/2014 01:14 PM, Petr Viktorin wrote:

On 04/08/2014 12:53 PM, Martin Kosek wrote:

On 04/08/2014 11:03 AM, Petr Viktorin wrote:

...

The patch is functional, but I am not really a big fan of placing it in the
plugin. I would prefer if the ACI definition is also in the sudo plugin
together with other definition. It would be then much easier to audit all
sudo-related ACIs.

Why can't we add this ACI to sudorule object managed permissions and just
override the location and target?


I can do that. Most of the changes make this overriding possible, where the
permission is actually defined is a detail.


I am not insisting on a specific format, I would simply prefer to have all
plugin object related ACIs close together.


My reasoning is that finding the definition would not be straightforward. All
the object-specific permissions so far are defined in "their" plugins, as
determined by --type. This one won't have --type, and it's not clear if it
should be in sudorule, sudocmd or sudocmdgroup.

But, I don't have a strong preference. A `git grep` will always show the
definition.



IMO sudorule is fine, I personally see it as an overarching plugin for sudo,
sudocmds and sudocmdgroups are just part of the sudorule.

We may just want to somehow differentiate the non--type ACIs from the regular
--type ones. Whether it is a different attribute in the Object or a setting in
managed permission is something I will leave up to you.


I went with a "non_object" key in the managed permission info.

Attaching new patches.

--
Petr³

From bc05ca06c450e6782d3a2e8becd80fd620fbb66a Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Thu, 27 Mar 2014 12:17:37 +0100
Subject: [PATCH] Document the managed permission updater operation

The method was explained on the [Design] page, but as the updater
is extended the design page would become obsolete.
Document the operation in the docstring of the plugin itself.

Design: http://www.freeipa.org/page/V3/Managed_Read_permissions#Default_Permission_Updater
---
 .../install/plugins/update_managed_permissions.py  | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/ipaserver/install/plugins/update_managed_permissions.py b/ipaserver/install/plugins/update_managed_permissions.py
index 603f3f0b74c97b14be0992d2c110f5bb6cd0e0e6..b2548f4f12aab2ae05c3c4a63e38eb8ca2b65ad6 100644
--- a/ipaserver/install/plugins/update_managed_permissions.py
+++ b/ipaserver/install/plugins/update_managed_permissions.py
@@ -17,6 +17,40 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see .
 
+"""
+Plugin for updating managed permissions.
+
+The permissions are declared in Object plugins in the "managed_permissions"
+attribute, which is a dictionary mapping permission names to a "template"
+for the updater.
+For example, an entry could look like this:
+
+managed_permissions = {
+'System: Read Object A': {
+'ipapermbindruletype': 'all',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {'cn', 'description'},
+'replaces_global_anonymous_aci': True,
+},
+}
+
+The permission name must start with the "System:" prefix.
+
+The template dictionary can have the following keys:
+* ipapermbindruletype, ipapermright
+  - Directly used as attributes on the permission.
+  - Replaced when upgrading an existing permission
+* ipapermdefaultattr
+  - Used as attribute of the permission.
+  - When upgrading, only new values are added; all old values are kept.
+* replaces_global_anonymous_aci
+  - If true, any attributes specified (denied) in the legacy global anonymous
+read ACI will be added to excluded_attributes of the new permission.
+  - Has no effect when existing permissions are updated.
+
+No other keys are allowed in the template
+"""
+
 from ipalib import errors
 from ipapython.dn import DN
 from ipalib.plugable import Registry
-- 
1.9.0

From 70f1788534ff1821faad3a5c10e23bbf363dc03d Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Thu, 27 Mar 2014 15:36:54 +0100
Subject: [PATCH] Allow overriding all attributes of default permissions

Allow overriding ipapermtarget, ipapermtargetfilter, ipapermlocation,
objectclass of default managed permissions.
This allows defining permissions that are not tied to an object type.
Default values are same as before.

Also, do not reset ipapermbindruletype when updating an existing
managed permission.
---
 .../install/plugins/update_managed_permissions.py  | 50 +-
 1 file changed, 39 insertions(+), 11 deletions(-)

diff --git a/ipaserver/install/plugins/update_managed_permissions.py b/ipaserver/install/plugins/update_managed_permissions.py
index b2548f4f12aab2ae05c3c4a63e38eb8ca2b65ad6..d938eecf175867f3a6a61a68d5f384bf9e79c055 100644
--- a/ipaserver/install/plugins/update_managed_permissions.py
+++ b/ipaserver/in

Re: [Freeipa-devel] [PATCHES] 0508-0509 Add support for "non-object" managed permissions

2014-04-08 Thread Martin Kosek 
On 04/08/2014 01:14 PM, Petr Viktorin wrote:
> On 04/08/2014 12:53 PM, Martin Kosek wrote:
>> On 04/08/2014 11:03 AM, Petr Viktorin wrote:
...
>> The patch is functional, but I am not really a big fan of placing it in the
>> plugin. I would prefer if the ACI definition is also in the sudo plugin
>> together with other definition. It would be then much easier to audit all
>> sudo-related ACIs.
>>
>> Why can't we add this ACI to sudorule object managed permissions and just
>> override the location and target?
> 
> I can do that. Most of the changes make this overriding possible, where the
> permission is actually defined is a detail.
> 
>> I am not insisting on a specific format, I would simply prefer to have all
>> plugin object related ACIs close together.
> 
> My reasoning is that finding the definition would not be straightforward. All
> the object-specific permissions so far are defined in "their" plugins, as
> determined by --type. This one won't have --type, and it's not clear if it
> should be in sudorule, sudocmd or sudocmdgroup.
> 
> But, I don't have a strong preference. A `git grep` will always show the
> definition.
> 

IMO sudorule is fine, I personally see it as an overarching plugin for sudo,
sudocmds and sudocmdgroups are just part of the sudorule.

We may just want to somehow differentiate the non--type ACIs from the regular
--type ones. Whether it is a different attribute in the Object or a setting in
managed permission is something I will leave up to you.

Martin

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

Re: [Freeipa-devel] [PATCHES] 0508-0509 Add support for "non-object" managed permissions

2014-04-08 Thread Petr Viktorin 

On 04/08/2014 12:53 PM, Martin Kosek wrote:

On 04/08/2014 11:03 AM, Petr Viktorin wrote:


Patch 0508:
This documents the inputs for the permission updater in the module itself. This
is taken from the design page. I expect it'll need an addition now and then, so
I think it's better to have this near the code it corresponds to.


Patch 0509:
So far the new default permissions have been tied to an Object plugin, and took
the ACI location and objectclass filter from the object. However there are some
permissions that are not tied to an IPA object, for instance ones dealing with
a compat tree. However, these permissions should behave similarly to the
Object-based ones, so it makes sense to use the same updater with them.

A question is where the non-Object permissions should be stored. I can think of
several alternatives:
a) in a special data file, like .update files
b) in a new plugin type
c) somewhere in the code

I went for c) for simplicity, but feel free to discuss. (CCing Rob since he had
some strong opinions in this area.)

This patch makes ipapermlocation, ipapermtargetfilter and other Permission
attributes overridable, and adds a central list of non-object permissions to
the updater module. (For now, the list is empty).


My patch 0504.2 (Default read ACIs for Sudo objects) will add a non-object
permission for ou=sudoers.


The patch is functional, but I am not really a big fan of placing it in the
plugin. I would prefer if the ACI definition is also in the sudo plugin
together with other definition. It would be then much easier to audit all
sudo-related ACIs.

Why can't we add this ACI to sudorule object managed permissions and just
override the location and target?


I can do that. Most of the changes make this overriding possible, where 
the permission is actually defined is a detail.



I am not insisting on a specific format, I would simply prefer to have all
plugin object related ACIs close together.


My reasoning is that finding the definition would not be 
straightforward. All the object-specific permissions so far are defined 
in "their" plugins, as determined by --type. This one won't have --type, 
and it's not clear if it should be in sudorule, sudocmd or sudocmdgroup.


But, I don't have a strong preference. A `git grep` will always show the 
definition.


--
Petr³

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

Re: [Freeipa-devel] [PATCHES] 0508-0509 Add support for "non-object" managed permissions

2014-04-08 Thread Martin Kosek 
On 04/08/2014 11:03 AM, Petr Viktorin wrote:
> 
> Patch 0508:
> This documents the inputs for the permission updater in the module itself. 
> This
> is taken from the design page. I expect it'll need an addition now and then, 
> so
> I think it's better to have this near the code it corresponds to.
> 
> 
> Patch 0509:
> So far the new default permissions have been tied to an Object plugin, and 
> took
> the ACI location and objectclass filter from the object. However there are 
> some
> permissions that are not tied to an IPA object, for instance ones dealing with
> a compat tree. However, these permissions should behave similarly to the
> Object-based ones, so it makes sense to use the same updater with them.
> 
> A question is where the non-Object permissions should be stored. I can think 
> of
> several alternatives:
> a) in a special data file, like .update files
> b) in a new plugin type
> c) somewhere in the code
> 
> I went for c) for simplicity, but feel free to discuss. (CCing Rob since he 
> had
> some strong opinions in this area.)
> 
> This patch makes ipapermlocation, ipapermtargetfilter and other Permission
> attributes overridable, and adds a central list of non-object permissions to
> the updater module. (For now, the list is empty).
> 
> 
> My patch 0504.2 (Default read ACIs for Sudo objects) will add a non-object
> permission for ou=sudoers.

The patch is functional, but I am not really a big fan of placing it in the
plugin. I would prefer if the ACI definition is also in the sudo plugin
together with other definition. It would be then much easier to audit all
sudo-related ACIs.

Why can't we add this ACI to sudorule object managed permissions and just
override the location and target?

I am not insisting on a specific format, I would simply prefer to have all
plugin object related ACIs close together.

Martin

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