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

[Rob Crittenden]

Petr Viktorin wrote:
> On 09/06/2013 02:46 PM, Rob Crittenden wrote:
>> Martin Kosek wrote:
>>> On 09/05/2013 07:48 PM, Rob Crittenden wrote:
>>>> Petr Viktorin wrote:
>>>>> Hello,
>>>>> I have some notes and questions on
>>>>> https://fedorahosted.org/freeipa/ticket/3566 (Control access of user
>>>>> roles to server functions).
> [...]
>> Right, I just want to know why it was proposed to add 2 ACIs for every
>> container.
>
> One for the container itself, one for the objects beneath it.
>
> I don't see a straightforward way to allow access to both in a single
> permission. (Currently, permissions need to be at $SUFFIX, so their
> subtrees are specified by target.)
>
> [...]

Right. I'm not sure you need to grant read,search,compare to the 
container. Have you tested that?

>>>>> # Combining read rights
>>>>>
>>>>> I think (read, search, compare) should be exposed in permission
>>>>> objects
>>>>> as a single right. Or is there a reason to keep it split?
>>>>
>>>> Yes, they are separate for a reason. Using only search and compare
>>>> isn't
>>>> common, but it isn't unheard of either. For example, to be able to
>>>> detect the
>>>> presence of an attribute you can provide just the search permission.
>>>
>>> Wouldn't most users use the (read, search, compare) triple? It would
>>> lower our
>>> number of ACIs significantly if we do not have 3 permissions per each
>>> object.
>>
>> There is nothing to prevent an ACI from containing multiple permissions.
>> I wasn't proposing that. But rolling these three logically into the same
>> thing in IPA I think is short-sighted.
>
> See my other e-mail with my reasoning. I don't particularly care about
> this issue, though.
>
>>
>>>>
>>>>>
>>>>> # P.S.
>>>>>
>>>>> I believe that we should strive to put our info about default
>>>>> permissions, containers, settings, and the schema for each plugin in
>>>>> the
>>>>> actual plugin module, rather than it all being split across several
>>>>> ldif/update files. This would make this data more manageable,
>>>>> introspectable and consistent, expose dependencies between plugins,
>>>>> and
>>>>> make it possible to actually write self-contained plugins.
>>>>> This should be done when the time comes for a new version of the
>>>>> ldap-updater.
> [...]
>>
>> Well, my alarm bells are going off. This would require some significant
>> review each and every time any object is updated. Consider how many
>> times API.txt is overlooked, and it has no security implications.
>
> Consider how many times the ldif or update files were overlooked.
> API.txt is checked during every build, whereas ldif/update files not,
> and are tedious to check.
>
> We can of course add a similar file for ACIs, in fact I was planning to
> do so. Any changes can be then reviewed both in the source and (like
> now) in the resulting ldif. Also, the information would be in one place,
> rather than in ldif (which doesn't apply on upgrades) and in update files.
> I believe it would actually be better for security.

The plan at the time updates were added was to move absolutely 
everything out of ldif and into updates. It just never happened.

>> I can't say I'm a fan of programmatic ACI generation.
>
> Well, I'm sure not going to write the ACIs for this feature by hand. It
> would help I could actually polish, commit and integrate the script that
> generates them.
> In my book, programmatic generation is much better than copy+paste.
>

On the other hand, it becomes very easy to just rely on it and not 
closely examine the output.

rob