On 25.11.2015 18:46, Simo Sorce wrote:
On Wed, 2015-11-25 at 10:25 +0100, Jan Cholasta wrote:
On 20.11.2015 16:49, Jan Cholasta wrote:
On 19.11.2015 17:43, Simo Sorce wrote:
510:
- We should probably tightenup the ACI to allos host X to only add
memberPrincipal = X and no other value, also the host should not be
allowed to change the memberPrincipal attribute only the keys.
If we can't express this in ACIs we can live with the ones you propose
though.
I think this can be done.
Turns out this can be done only if member (or some other DN attribute)
is used instead of memberPrincipal.
So, to reiterate:
2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'?
If 'member' was used instead, we would gain referential integrity and
the ability to add ACIs based on the attribute (think
userattr="member#USERDN").
To avoid referential integrity and mixup with other group objects, it
was intentional.
Why is referential integrity a problem?
Because it will remove the member if the object it references goes away,
and I do not want an "orphaned" entry for custodia.
But without referential integrity you get an orphaned entry too, except
with an extra dangling reference. IMHO that's even worse than "plain"
orhpaned entry, because you can't spot it just by looking at the
attribute value.
Mixup with other group objects can be solved by using a different attribute.
There is also the fact in future we may want to use this with "external"
principals (like in IPA-IPA trusts or similar) so I didn't want to have
to come up with bogus DNs in that case.
IIRC Alexander was working on something like exposing external
principals in LDAP using the compat plugin, in order to allow external
users to run IPA commands.
Alternatively, it could do what groups do - use DN for internal
references and string (be it principal or something else) for external
references.
Anyway, either memberPrincipal is replaced with a member-like attribute,
or the ACI stays as it is. I would prefer a member-like attribute,
because I feel that's the way LDAP entries should reference each other,
but I will leave the decision to you.
--
Jan Cholasta
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
