[Freeipa-devel] Other issues with HBAC calendar

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/24/2010 11:15 AM, Dmitri Pal wrote:
> 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?
> 

Dmitri, this simply cannot work, because time zones are not static. You
can't tell the administrator he is defining something in the Eastern
time zone from 09:00-17:00 EST and then store that value as UTC. Because
when DST happens, suddenly this will be equivalent to 08:00-16:00 EDT.
And the meaning of the rule is lost.

So if you want to define a timezone for a rule, it MUST be stored as
local time plus timezone identifier, so that when it is evaluated it
will use the appropriate offset for that moment in history.

You can't just send a UTC value down to SSSD.

After lunch, I'm going to write up the completely new proposal that Adam
and I are suggesting to avoid the future upgrade issue for SSSD as well.
It will account for the problem you're trying to solve here.



- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkztRXkACgkQeiVVYja6o6N4nwCeMQ5Rby7kGQADKbYj0EdEqfzi
JDYAnRBS+A3rY/dg7kQVMeEB8CEHIcSr
=G3lr
-----END PGP SIGNATURE-----