[Freeipa-devel] Other issues with HBAC calendar

[Dmitri Pal]

Stephen Gallagher wrote:
> On 11/23/2010 04:32 PM, Simo Sorce wrote:
> > On Tue, 23 Nov 2010 16:07:47 -0500
> > Rob Crittenden <rcritten at redhat.com> wrote:
>
> >> I don't want to throw a wrench in, but what if you have multiple
> >> replicas in various distant locations, WHICH server is the time
> >> relative to?
> > By server I think Steve meant the machine currently evaluation the
> > access control decision. "Host" would have been a happier term.
>
>
> No, I was actually talking about the FreeIPA server in this situation,
> but Rob is right that there is no guarantee in a multi-master situation
> that the servers themselves are in the same timezone.
>
> Given this, I think the only sane thing to do here is to always use UTC
> (and state clearly that this is what is happening)
>

I was always saying that the time should be in the UTC only when it is
evaluated on the server . I do not think that "local" is a good solution.
But I think the whole idea  with the timezones have been misinterpreted
so let me try to explain one more time.
He is the workflow that I have in mind:

1) Admin creates a rule with time definition using UI and CLI
2) Rule is saved in the LDAP attribute
3) Rule gets replicated between IPA servers
4) SSSD fetches the rule from an IPA server
5) SSSD validates the rule

Let us say that the rule is entered, saved, transfered and interpreted
on the client as UTC. Sounds reasonable and not that complex from the
implementation POW. Good!
The only issue I see is that the admin during step 1 does not think in
terms of UTC as Ben pointed out. He thinks in user time or server time
i.e. tries to relate the rule to some reasonable time markers (start of
a shift, end of a working day, midnight at a special location etc.)
So  I was suggesting the following:
1) Allow admin to specify in what time zone he entered the time
2) Pass the time definition together with the time zone he selected to
the server
3) Before saving the rule the server would convert the rule into UTC and
stick the TZ info hint into the rule
4) When SSSD retrieves the attribute it will know that time is in UTC
and will ignore any TZ hints stored in the rule
5) The TZ hint only need for UI/CLI when admin fetches the rule and
looks at it. In this case the server will take attribute which is in
UTC, extract a TZ hint from the rule and use that TZ to convert UTC
value it has to the value in the specified TZ. This is what is sent to
the client and displayed in the UI/CLI.

So TZ is needed only for the administrative purposes and not for SSSD. I
hope it is clear now.
I was also suggesting to save offset together with the TZ hint but I
guess this can be dropped.
Can we agree to keep the TZ as hint for the management purposes in the rule?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/