[Freeipa-devel] New ACIs for cn=etc
mkosek at redhat.com
Wed Apr 16 11:31:31 UTC 2014
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.
>>> - 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?
>>> - cn=masters,cn=ipa,cn=etc,SUFFIX
> This is the one I'd exclude with the target rule.
>>> - 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
More information about the Freeipa-devel