On 09/06/2013 10:11 AM, Petr Viktorin wrote:
> On 09/06/2013 03:59 PM, Rob Crittenden wrote:
>> 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?
> To be honest, I assumed some from the bug description. I'll test it.
> If it's not necessary there'll be one ACI per object type.
> [...]
>>>>>>> # 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.
> Good to know. Is it still the plan? Do I only need to change the
> update files?
>>>> 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.
> That is a question of checking the changes. Frankly I don't see that
> much difference between not checking after updates and not checking
> after copy+pasting.
> If nothing, the existence of an ACI.txt should remind us that security
> is at stake.
> Also, if the objectclasses change this will alert us that ACIs need
> changing as well.
We probably can add some sort of a check to a patch apply command that
if a file that does ACI part is added or modified in a patch and the
corresponding ACI.txt file is not updated the patch apply operation
would abort.

Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.

Looking to carve out IT costs?

Freeipa-devel mailing list

Reply via email to