On 09/09/2016 02:58 PM, Simo Sorce wrote:
On Fri, 2016-09-09 at 13:14 +0200, Standa Laznicka wrote:
On 09/03/2016 06:25 PM, Jan Pazdziora wrote:
On Thu, Sep 01, 2016 at 11:18:45AM -0400, Simo Sorce wrote:
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 ?
You use host groups to serve the old rule to old clients and time-based
rule to new clients. Each client will apply the rule they see.
If you happen to serve the old rule to the new client, access will
be allowed no matter what the other, time-based rule says.
You do not use magic to interpret one rule differently, one way on
one version of client and other way on different client version.
How do you make sure a new client will enforce time restriction when it
looks up the old rule as well ?
You make sure the new client does not see the old rule.
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.
I agree that managing separate host group membership might be
and extra work. But it seems to be the only way to remove the ambiguity.
I also believe there's no way avoiding that (if we want to be somehow
backward compatible).
I would just love us to come to a consensus as I am growing weary of
this discussion and am willing to go with just anything as long as it's
somehow OK with most people. Could we therefore decide to go with
something, please?
As long as the tooling does not try to replace object classes I am ok
with the solution most people agree on.
Simo.
So, basically, we are back at accessRuleType usage, which I guess is
kind of ok? We may either use its multi-valueness (is that a word?) or
be setting it as flags (e.g. "tu" or "ut" for URI with time rules etc.).
In the multi-valued case, when someone adds "allow" amongst the values,
it will screw HBAC evaluation up (=> deny even if it's among allow rules
for the given host) but I guess that's something we could live with.
In the flag-case, the filters for obtaining the rules from IPA may seem
rather ridiculous (substring match) and may be a very bad decision for
future development. Also, anyone is able to add "allow" as another value
but that would just be their fault.
In both cases, "allow" as an only value may be the default which states
the rule may be evaluated even on older clients and SSSD just has to
guess what the rule is capable of (which is OK with time rules as if
there's none it means "always allow" should previous evaluation allow as
well).
Please note that I rather included the rather "naive" flag
implementation just to make sure to cover everything. We could just as
well of course add something like "capabilities" attribute to
ipaHBACRule object as another solution but that's starting to be an
overkill IMO.
Standa
--
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
