On Thu, 2016-09-01 at 16:35 +0200, Standa Laznicka wrote: > On 09/01/2016 03:06 PM, Simo Sorce wrote: > > On Thu, 2016-09-01 at 14:09 +0200, Standa Laznicka wrote: > >> The class ipaHBACRuleV2 is dynamically switched to from ipaHBACRule > >> upon > >> addition of a time rule to a certain HBAC rule. > > Honestly I am against this. > > > > If you really want the two objects to be incompatible then you tell the > > admin he can't add time rules to old objects. > > The new object type should clearly identified as a new rule type and the > > admin will have to create a new rule of the correct type and > > remove/disable or retain the old rule as he prefers. > > > > I do not think we should ever try to switch objectclasses dynamically. > > > > Simo. > > > A child's question: why not? > > Also, should it come to life like you propose, what would you expect the > user interface to be like?
LDAPv3 does not allow changing structural classes, 389ds allows it but it is a non-standard feature. I do not want to create issues to people that create solutions that do things like synchronizing our LDAP tree to another LDAP server, for caching, proxying or anything else. It is one thing to allow to do something illegal in the LDAP protocol, it is *entirely* different to rely on an illegal feature in day to day operations. Furthermore when you change a rule this way old clients will suddenly see a rule disappear as it will not match their queries anymore. If you silently do this change in the framework an admin may not realize this is the case and break access to his legacy clients. If the admin has to delete and recreate a rule instead it will be much clear to the admin that this is the case. So the above is for why I am pretty against switching objectclass. Please do not do that, it is a NACK from me. But below find additional things I have been thinking: The thing is we (and admins) will be stuck with old client s for a loong time, so we need to make it clear to them what works for what. We need to allow admins to create rules that work for both new and old client w/o interfering with each other. In your scheme there must be a way to create a set of rule such that old clients can login at any time while newer clients use time rules. that was easy to accomplish by adding an auxiliary class and simply defining a new type. Old clients would see old stuff only, new clients would add time rules if present. If we have 2 completely different objects because the admin has to create both, then old clients still care only for the old rule, new clients instead have an interesting challenge, what rule do they apply ? How do you make sure a new client will enforce time restriction when it looks up the old rule as well ? After all the old rule grants access at "all times". Of course admins can always create very barrow host groups and apply rules only to them, but this is burdensome if you have a *lot* of clients and some other people are tasked to slowly upgrade them. It is possible though, so having 2 separate objects that new clients know about is potentially ok. I would prefer a scheme where they could be combined though for maximum flexibility with as little as possible ambiguity. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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
