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:
- 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?
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.
How about adding a new objectClass in addition to nsContainer, and using
a negative targetfilter?
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
- 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
- allow reading "cn, member, objectclass" of "groupofnames" to authenticated
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.
Freeipa-devel mailing list