On 13.11.2015 16:40, Simo Sorce wrote:
On 13/11/15 10:17, Martin Basti wrote:
On 13.11.2015 14:41, Simo Sorce wrote:
On 11/11/15 09:30, Martin Basti wrote:
On 11.11.2015 14:52, Martin Basti wrote:
Comments inline
Martin^2
On 11.11.2015 09:24, Stanislav Laznicka wrote:
On 11/05/2015 06:17 PM, Petr Spacek wrote:
On 4.11.2015 15:20, Martin Basti wrote:
Hello,
we (Standa and I) had offline discussion and I proposed following
idea:
1) create new entry in LDAP for "time rule" instead of adding the
time rule
string directly into HBACRule.
This will allow to reuse time rules among various HBAC Rules (and
maybe in
future with sudo rules, etc.)
HBACrule gets only reference to time rule entry stored in LDAP db.
Good idea! I can see time rule entry 'working hours in Brno
office' which is
linked to relevant HBAC rules.
This seems like a good idea. However, it might be a bit messy to
have
even the least significant rules stored in separate objects. But I
agree. It brings some questions, though.
Imo to have separate entry for time rule is cleaner than add it
directly to HBAC rule.
I really disagree, see below.
Where would be a good spot to store these time rules?
As I originally thought that we can share time rules between HBAC,
SUDO and everything else, I couldn't be wrong more.
Example: HBAC admin have permission to edit HBAC rule, but doesn't
have permission to edit SUDO rule. The HBAC admin should be able to
edit time rules for HBAC rules, and cannot be able to edit time rules
of SUDO rules. Thus time rules must be separated between HBAC, SUDO
and others, and privilege that give the permission to modify HBAC
rule, must give permission to modify only HBAC time rules.
I suggest to add HBAC time rules to HBAC container.
After IRC discussion with pspacek and jcholast:
We should just create separated privileges to time rules and allow
them
to be shared.
So they should be stored in new container in LDAP
I do not understand what this means.
And in general I am opposed to have a separate object on performance
grounds (for clients) and also on the fact that is becomes tricky to
keep objects in sync.
What exactly is the performance issue there? To download extra entry
from LDAP?
Yes because now you have to download rules, parse them, find out what
needs tro be downloaded and pull it, or wore just download all time rules
The SSSD do the same sync with users and groups, doesn't it?
No, by default we do not enumerate users and groups, and for HBAC
rules we download only those that apply to the machine.
All this exactly to reduce the amount of time taken, and load on the
server.
We then have to deal with cases where you delete a time object but an
HBAC still references it and also assuring you have permissions to
fully change an HBAC rule, you may end up in situations where you can
change the HBAC rule for everything but the times (or vice versa).
IMO this should solve referint plugin if the time policy is removed,
then it will be removed from HBAC rules as well.
This is *not* ok though, you do not want an HBAC rule that limits
users to a specific time to suddenly become "any time" because someone
removed a time rule and didn't know it was referenced by multiple rules.
These are exactly the type of issues you end up having when you split
the rule in multiple objects.
So please, explain carefully what would require a separate time object.
On privileges alone I see no value in a separate privilege for time
than for the HBAC object it applies to (preference for using the same
object). I also see no technical reason to store the time rules for
completely different stuff in the same tree.
Yes, there may be the odd case in which you want to have the same time
rule for a sudo rule and an HBAC rule, we can make that easy in the
interface by providing a "copy time rules from X" kind of interface.
My original suggestion was to have it separated, HBAC time policy under
HBAC container and sudo time policy under sudo container. So HBAC admin
will have access to the same subtree and the one can modify time policy
for HBAC. However pspacek and jcholast disagree I will let them to
explain the reasons.
Seriopusly, the HBAC time policy should be (on the HBAC rule object)
and I mean it as an additional object class with the policy embedded
in the specific HBAC rule. This is more efficient and avoid issues
like the one above.
Can you explain *why* you propose to have separate objects ? What's
the rationale ? What are the failure modes ?
The main purpose is to have time policies like "Work hours in Brno",
"Work hours in Brisbane" ... which can be associated with many HBAC
rules, instead of adding a separate time policy for each HBAC rule.
Martin
Simo.
--
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
