[Freeipa-devel] New ACIs for cn=etc

[Simo Sorce]

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.

> > 
> >>>    - 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.