[Freeipa-devel] [PATCH] 0507 Allow anonymous read access to containers

[Petr Viktorin]

On 04/03/2014 03:28 PM, Simo Sorce wrote:
> On Thu, 2014-04-03 at 15:19 +0200, Petr Viktorin wrote:
>> On 04/03/2014 02:53 PM, Simo Sorce wrote:
>>> On Thu, 2014-04-03 at 13:34 +0200, Petr Viktorin wrote:
>>>> Hello,
>>>> This adds anonymous read access to containers, as discussed in this
>>>> thread:
>>>> https://www.redhat.com/archives/freeipa-devel/2014-March/msg00442.html
>>>>
>>>> Additionally access is granted for $SUFFIX itself with targetfilter
>>>> "(objectclass=domain)", and attributes objectclass, dc, info, nisDomain,
>>>> associatedDomain.
>>>>
>>>> These are raw ACIs, not permission-based ones.
>>>>
>>>
>>> Why is this not set in default-aci.ldif as well ?
>>>
>>> Simo.
>>
>> Because we don't want to duplicate information.
>
> So are we removing default-aci.ldif completely ?
> I think we already mentioned this, but I can hardly recall the
> discussion, sorry.
>
> Simo.
>

Sorry for the brief answer, I was just leaving for the day.

Storing the data in both the LDIFs and update files is unnecessary, and 
the two files will get out of sync so one would need to look at both of 
them to get the full picture anyway.
So now the plan is to put new data only in update files (except for 
schema which has a special LDIF-based updater).

default-aci.ldif might end up being removed completely but it doesn't 
really bring us anything except being "cleaner", so it's not a priority.

I found the discussion: 
http://www.redhat.com/archives/freeipa-devel/2013-September/msg00106.html; 
the relevant part is:

Rob:
> The plan at the time updates were added was to move absolutely everything out of ldif and into updates. It just never happened.
Petr:
> Good to know. Is it still the plan? Do I only need to change the update files?
Rob:
> It would be my preference. It goes beyond only changing one set of files. The existing ldif that duplicate things need to be deprecated. We can't get to a zero-ldif install, but it can be reduced significantly.

-- 
Petr³