[Freeipa-devel] Notes and questions for fine-grained read permissions

[Petr Viktorin]

On 09/09/2013 06:31 PM, Simo Sorce wrote:
> On Mon, 2013-09-09 at 16:40 +0200, Petr Viktorin wrote:
>> On 09/09/2013 03:46 PM, Simo Sorce wrote:
[...]
>>> How do you handle a case where we add 'read-only by admin' for an
>>> attribute that was not in the default ACI list at all previously, but
>>> the admin already added 'read by everyone' in the custom ACI ?
>>> This is the kind of thing that makes me dislike the 2 separate sets, now
>>> you need intra-set conflict resolution.
>>
>> There would be two permissions: "read by admin" and "read by everyone".
>> Both would now allow reading the attribute, so it would be readable by
>> anyone -- as the admin wanted.
>>
>> I don't see any need for intra-set conflict resolution. The algorithm is
>> simple -- take IPA defaults, add admin-added attributes, filter out
>> admin-excluded attributes, allow the resulting set. Recompute whenever
>> any of the lists changes.
>
> Actually this make sense, I was mostly thinking in terms of adding deny
> ACIs, but the most positive outcome here will happen if we finally
> remove the dreadful deny ACI, so I think we are mostly ok.
>
> I can still think of a scenario that may not be optimal.
>
> Admin adds attribute for read by admin only and IPA update adds a
> read-by-all permission.
>
> I think this is unlikely to happen, but probably we need to add a rule
> that any such change on IPA part must be reviewed by at least 2
> experienced members before it is approved, so that more than one head
> reviews and vets such a change.

Any time we add a new attribute to an existing object, there's a chance 
that some users were already using it. Especially with our configurable 
user/group objectclasses.

A reasonable review rule is fine. I think we should also add all 
permission changes to release notes.

>>>> If we mark a Permission as SYSTEM, old IPA versions won't try to locate
>>>> or touch its ACI, but they'll still be able to add it to privileges and
>>>> roles using the existing API/CLI/UI.
>>>
>>> I do not understand the nuances of this SYSTEM permission, can you
>>> explain why we want it, and why it should't "locate or touch its ACI"
>>> whatever it really means ?
>>
>> Permissions are IPA objects that encapsulate the underlying ACIs and
>> make them easier to manage. Permissions are less flexible than raw ACIs.
>> Sometimes they need more power than what the Permission UI exposes, so
>> we mark them as SYSTEM. The CLI/UI then doesn't read or update the
>> underlying ACI.
>> If we add permissions that work differently than the existing ones, we
>> can mark them SYSTEM so *old IPA* doesn't try to manipulate the
>> underlying ACIs.
>> (And we need to add some kind of permision versioning, in case the
>> functionality changes again.)
>
> Ok, now I get it, SYSTEM was your way to name 'low level ACIs we set
> directly'.

Yes and no. Users can still add SYSTEM permissions to privileges to 
grant them to specific users.

Currently we use them for replication management, where the ACIs are 
somewhere in cn=config as opposed to $SUFFIX, and for DNS read rights 
(permissions currently don't handle read rights).

ACIs we set directly, like hardcoded ACIs for the admins group, or the 
dreaded anonymous allow all rule, don't have an associated Permission 
object and aren't visible in the UI.

[...]
> And it will be really fun for you to find out how to upgrade from the
> current scheme to the final state here (which is critical, no 'start
> from scratch' strategies here ok ?) but I think it is quite doable.

Challenge accepted :)

-- 
Petr³