[Freeipa-devel] [RFE] Permissions V2

[Petr Viktorin]

On 11/11/2013 04:48 PM, Petr Viktorin wrote:
> On 11/11/2013 03:56 PM, Rob Crittenden wrote:
>> Petr Viktorin wrote:
>>> Hello,
>>> I'm splitting up ACI work into several designs to make it more
>>> manageable.
>>>
>>> This one is about
>>> - Moving ACIs out of $SUFFIX
>>> - Storing all ACI data in the permission entry
>>> - Permission flag system for ensuring backwards compatibility
>>>
>>> Summary of the backcompat story:
>>> - Attributes, rights, etc. of new permissions may not be modified or
>>> read on old servers (not possible since the ACIs aren't in $SUFFIX)
>>> - Old permissions convert to new ones when they're modified on a new
>>> server
>>> - Any server can assign (or remove) both old and new permissions to
>>> privileges
>>>
>>> There is a bit of shuffling in API/CLI option names, since the API
>>> option name needs to match the LDAP attributeTypes.
>>>
>>> The WIP design document is here:

>>> http://www.freeipa.org/page/V3/Permissions_V2

I've updated the design with
- updated schema (this time the OIDs are even reserved properly!)
- longer attribute descriptions with examples
- updated update algorithm based on discussion with Simo

Additionally, I've updated draft designs this one references [0, 1]. The 
CLI/API parts of those aren't finished but the LDAP should be ready for 
criticism.

For examples, I felt that anything I show as an example should also go 
in the test suite, so I added the tests. (If you're into wiki design I'd 
appreciate ideas about how to make that section better.)
If you need any more examples, or see some dangerous corner cases, tell 
me and I'll add them.

There is still a race condition when the subtree changes, e.g. when 
you'd move an ACI from $SUFFIX to cn=users,cn=accounts,$SUFFIX, the 
rights are revoked between the times the ACI is removed and re-added.
At this point I'd rather document it and file a bug (and possibly start 
working on it right after this) than redo the internals in yet another 
way in the same update.


[0] http://www.freeipa.org/page/V3/Anonymous_and_All_permissions
[1] http://www.freeipa.org/page/V3/Managed_Read_permissions


PS. the hack I used to generate the test plan for mediawiki is here: 
https://github.com/encukou/ipa-tools/blob/master/mw-format-tests.py


>> Data in the permission entry
>>
>> I think the schema needs to be described better. I'm assuming that
>> ipaPermTarget is the equivalent of current targetgroup option? And
>> targetfilter is the equivalent of current filter option?
>
> ipaPermTarget is the raw ACI target, i.e. the DN.
> targetgroup is just the name
>
> If the targetgroup option is specified, it effectively just finds the
> group and sets the ipaPermTarget option to its DN.
>
> And if ipaPermTarget contains a group DN, targetgroup will be populated
> with the cn on output (in addition to ipaPermTarget with the full DN).
>
> The next update will have examples.
>
>> If you are placing the ACI into the container based on type, then you
>> probably don't need the filter within the ACI (it is implicit).
>
> Sorry; that should have been target, not fiter.
> The target is a bit more explicit; it has e.g. "uid=*" in addition to
> the user container DN, so I'd like to keep both.
>
>> In general I think some examples would be helpful.
>
> I'll add some.
>
>> Modifying and Upgrading Permissions
>>
>> Under what conditions would there be an old or a new permission and no
>> associated ACI?
>
> If a command failed unexpectedly, and also failed to clean up.
> For example if the DS shuts down at the right time in the middle of a
> permission-mod.
>
>> Option/Attribute mapping
>>
>> Performing a search on the filter is a good idea but realize that it has
>> its limits. It is possible to create a legal filter that makes no (or
>> little) sense.
>
> Of course. This is just a syntax check.
>
>> If type is only going to specify the location of the ACI then perhaps it
>> shouldn't be in the mutually exclusive list.
>
> Yes.
> Martin just pointed out ticket 2355_ (Allow filter and subtree to be
> added in same permission) to me today. I'll redo the mutual exclusivity
> so more things are possible together.
>
>
> _2355 :https://fedorahosted.org/freeipa/ticket/2355


-- 
Petr³