On 09/01/2016 05:18 PM, Simo Sorce wrote:
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
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.


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

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.
Thank you for the explanation, I was actually really curious about this as I still don't have that much experience and I just don't get some implications.
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
If an admin wants the capabilities of time rules then they should just upgrade the clients. If that is a problem, it's their choice. They can either create a special host group for those clients that just won't upgrade or just revoke access to them if it's a problem of a stubborn user who does not want their system upgraded.

Having a single object would also be wrong - there's no way telling the older clients to ignore the objects you want them to ignore if you want them not to ignore some.

But all and all thank you for the explanation with the example, it made some of your previous points more clear.

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to