[Freeipa-devel] Time-based account policies

[Standa Láznička]

On 3/26/2015 1:24 PM, Martin Kosek wrote:
> On 03/26/2015 01:08 PM, Standa Láznička wrote:
>> On 3/26/2015 11:13 AM, Jan Cholasta wrote:
>>> Dne 25.3.2015 v 18:25 Stanislav Láznička napsal(a):
>>>> On 03/25/2015 12:34 PM, Alexander Bokovoy wrote:
>>>>> When using hbactest command you just need to supply implied time zone
>>>>> as an option to the command itself. After all, you are simulating 
>>>>> rule
>>>>> execution so it does not matter where the value comes from.
>>>> Oh, good, I haven't thought of that. That certainly eases things up.
>>>>
>>>> Let me make a summary then, a short one this time, of what's been
>>>> discussed .
>>>>
>>>> It seems the best way to store time policies is indeed the format 
>>>> (time,
>>>> anchor) where anchor is either Olson database timezone or "Local Time"
>>>> for host local time. We are omitting users' local time because, after
>>>> all, we are talking HBAC Rules here (great point by Simo). If the 
>>>> admins
>>>> really needed that, there's a workaround Jan mentioned that should 
>>>> work
>>>> just fine.
>>> What I originally meant as anchor was a value specifying the time 
>>> offset
>>> (e.g. "utc" - access time uses UTC, "rule" - access time uses time zone
>>> specified in the HBAC rule, "host" - access time uses host's time 
>>> zone),
>>> rather than the time zone itself or "Local Time".
>>>
>> You're right, that's probably more descriptive than just "Local 
>> Time". Still, I
>> think that instead of "rule" a timezone might just as well appear on 
>> the anchor
>> part. I think "UTC" is also part of Olson's so it should be at the 
>> same spot as
>> the timezone.
> I am not little confused about all the places where we want to add the 
> time
> zone. I thought that it was originally meant for hosts objects, so 
> that we can
> HBAC rule is created, UI/CLI can already suggest the right time zone 
> for the
> HBAC rule. But it should have been only informative value serving 
> mostly UX,
> not something that SSSD would decide on.
>
> HBAC rule itself is always the authoritative source. We should also avoid
> having time zone in 2 places in the HBAC rule itself - if this is what 
> you are
> steering at. I thought the authoritative time zone would be only in 
> the HBAC
> time definition only, i.e. only in the anchor specifically.
I think the timezone still may be with the host object but only as the 
UI helper as you suggest. Although I would maybe rather not see it with 
the object at all and have the admin just set the right timezone for the 
HBAC rule themselves. After all, if there's a collision of host helper 
timezones, I think admin would have to do that anyway.

I agree that there should only be one timezone record for each HBAC and 
I wouldn't suggest differently. There was a confusion when Jan suggested 
to use "rule" as anchor in the (time, anchor) tuple to get the rule's 
timezone which, he suggested, should be stored elsewhere but in the 
tuple. I think there's no harm having the timezone/"host" keyword stored 
with this tuple and therefore nowhere else.
> Can we show specific examples of these tuples, to make sure we are in
> agreement? My take was:
>
> (Mon-Fri 08:00-17:00, UTC+1)
> (Mon-Fri 08:00-17:00, local)
>
> UTC+1 may not be ideal as it would not work for daylight saving, a 
> better way
> would indeed be the Olson time zone ID, i.e:
>
> (Mon-Fri 08:00-17:00, Europe/Prague)
> (Mon-Fri 08:00-17:00, local)
Definitely the second format ((Mon-Fri 08:00-17:00, Europe/Prague)), we 
want to use Olson's database names. If I understand it right, "UTC" is 
in Olson's and stands for UTC+0 offset. If not, we can have "UTC" 
keyword in the anchor part of the tuple mentioned above to signalize 
just that (UTC+0).