[Freeipa-devel] Read access to container entries

[Martin Kosek]

On 03/31/2014 01:52 PM, Ludwig Krispenz wrote:
> 
> On 03/31/2014 12:32 PM, Martin Kosek wrote:
>> On 03/31/2014 10:41 AM, Ludwig Krispenz wrote:
...
>>> In general I think we should implement 1), there will be other scenarios where
>>> it could be useful. If something is needed imemdiately I would also prefer 3)
>> We need this feature for FreeIPA 4.0, so I am thinking waiting for 389 feature
>> is not an option unless it'd be done really fast.
> how fast does it have to be ? If we just can use the same  concept with
> targetscope=[base,one,sub]
> implementation should not take too much time, about a week or so, but we need
> to get it accepted by
> DS core.

As fast as a light :-) A week should be sufficient, though I am not convinced
that we are able to release that fast or that rushing ACI related
implementation is a good thing to do.

Question is if we want to go this way (adding ACI for all containers) or the
second way having ACI(s) for all containers in the tree described below.

> 
>>
>> Given Petr's findings, I am thinking that solution based on 3) seems like way
>> to go. We would of course only allow objectclass + cn attributes. I am not
>> convinced that objectclass like ipaPublicContainer is the right way to go, does
>> not sound to me as a standard solution and not something that people would
>> assume they need to do when they are adding a custom container.
>>
>> When I installed a fresh FreeIPA, I did a (cn=nsContainer) search (results
>> attached) and there were 61 results. Do we really want to update 61 LDAP
>> entries and add a custom ipaPublicContainer objectclass to all? Sounds a little
>> bit hackish to me.
>>
>> Would adding following ACIs work?
>>
>> dn: SUFFIX
>> aci: allow anonymous read for "(objectclass=nsContainer)" for cn, objectclass;
>> except cn=etc,SUFFIX
> how do you want to specify the "except" ?

(target != "ldap:///cn=etc,SUFFIX")

>> dn: cn=etc,SUFFIX
>> aci: allow authenticated read for "(objectclass=nsContainer)" for cn,
>> objectclass
>>
>> As I just checked, allowing whole cn=etc,SUFFIX for authenticated only is
>> something we agreed on during DevConf.
>>
>> With this approach, the only question is what should we do with nsContainer
>> based LDAP entries that contains sensitive information. I wonder - is this a
>> real situation? Are there many nsContainer LDAP entries with sensitive
>> information? Shouldn't we have a rule instead that would recommend using custom
>> (not nsContainer) objectclasses to store sensitive information based on cn?
>> Otherwise it seems to me a an abuse of nsContainer purpose.
>>
>> Martin
>