[Freeipa-devel] New ACIs for cn=etc

[Petr Viktorin]

On 04/16/2014 02:55 PM, Simo Sorce wrote:
> On Wed, 2014-04-16 at 13:31 +0200, Martin Kosek wrote:
>> On 04/16/2014 12:50 PM, Petr Viktorin wrote:
>>> On 04/14/2014 04:00 PM, Simo Sorce wrote:
>>>> On Mon, 2014-04-14 at 12:55 +0200, Martin Kosek wrote:
>>>>> When heading for a lunch today, I had a discussion with Petr3 about ACIs for
>>>>> cn=etc,SUFFIX. On our initial meeting back at DevConf.cz time, we said we will
>>>>> simply allow all attributes in cn=etc for authenticated users and will just
>>>>> exclude the blacklisted attributes (for context, see ticket #3566).
>>>>>
>>>>> I personally think it is not the best thing to do as it will just move the
>>>>> problem we had with all-allowing ACI one level down from SUFFIX to cn=etc. It
>>>>> would be better to add normal ACIs for cn=etc as well.
>>>>>
>>>>> I searched for nsContainer's in cn=etc and IMO the situation is not so bad, it
>>>>> seems straightforward what ACIs would be needed:
>>>>>
>>>>> ==========================================================================
>>>>> dn: cn=etc,SUFFIX
>>>>> - ADD aci allowing reading nsContainer for anonymous, EXCEPT:
>>>
>>> We can combine this with the general nsContainer read ACI. The problem is that
>>> we can only have one target-based exclusion rule.
>>
>> Right.
>>
>>>
>>>>>     - cn=virtual operations,cn=etc,SUFFIX
>>>
>>> Could we use a special objectClass rather than nsContainer for these?
>>
>> We would need to invent one, like ipaVirtualOperation with one MUST attribute
>> "cn" and then apply it to all virtual operations and replace nsContainer. It
>> should not be a problem though as we do not provide API to handle the virtual
>> operations. There are very static.
>>
>> Simo, Rob, would you be OK with changing virtual operation objectclass to our
>> own one to have a better control over it?
>
> No, in general I am not ok to change objects that already exist in IPA
> as it make upgrades with new and old replicas break the old replicas.
>
> Also we can add new auxiliray classes but removing structural classes is
> not possible, you would have to delete and recreate the object, and that
> would be racy too.

I see.
How about adding a new objectClass in addition to nsContainer, and using 
a negative targetfilter?

>>>>>     - cn=masters,cn=ipa,cn=etc,SUFFIX
>>>
>>> This is the one I'd exclude with the target rule.
>>
>> Ok.
>>
>>>
>>>>>     - cn=Managed Entries,cn=etc,SUFFIX
>>>
>>> Why exclude this one? Aren't the containers the same in all IPA installs?
>>
>> Hm, exclusion of this one is probably not needed. User would really only see
>> the containers for Definitions and Templates, not the real configuration (NGP/UGP).
>>
>>>>> dn: cn=sysaccounts,cn=etc,SUFFIX
>>>>> - ADD aci allowing reading all attributes but password attributes (people may
>>>>> add unstructured accounts following different objectclasses)
>>>
>>> I'd rather list the attributes and let people add custom attributes themselves.
>>
>> Makes sense. Right now, we have 2 types of objects here:
>>
>> 1) system users: simpleSecurityObject objectclass
>> 2) system groups: groupofnames objectclass
>>
>> We can make 2 ACIs, allowing those:
>>
>> - allow reading "uid, objectclass" of "simplesecurityobject" to authenticated users
>> - allow reading "cn, member, objectclass" of "groupofnames" to authenticated users
>
> Yeah we do not need fancy stuff, and we are planning (since forever ?)
> to  give a command to create these entities, so eventually the format
> will be clear.
>
> Simo.
>


-- 
Petr³