[Freeipa-devel] Time-based account policies

[Martin Kosek]

On 03/26/2015 04:26 PM, Jan Cholasta wrote:
> Dne 26.3.2015 v 14:55 Martin Kosek napsal(a):
>> On 03/26/2015 02:40 PM, Standa Láznička wrote:
>>> 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.
> 
> Ah, right. OK then.
> 
>>>> 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 don't see any point in storing time zone in the host object, if it's not used
> for anything meaningful and has to be manually synchronized with the host's
> actual configured time zone.

It would be mostly used for aiding the HBAC rule creation process, i.e. for the
UX. It would be optional. If you do not fill it, you would have to always
select the right time zone in when setting the UTC HBAC time,

If you fill the zone, UI could already select the right time zone for you.

>> Right. But UI could then offer:
>>
>> Warning, time zone is ambiguous. Please select the right time zone:
>> HostA time zone: Europe/Prague  [ ]
>> HostB time zone: Europe/London  [ ]
> 
> No, thanks. The whole point of "Local Time" is being able to use whatever time
> zone is configured on each host instead of having to specify one time zone for
> all of them, which is exactly what the above does.

Host's Local Time and UTC time are 2 different approaches how to set the time
for the HBAC rule. With Local Time type, you would of course not have to deal
with time zones. I thought this was already cleared out.

>>> 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).
>>
> 
> Can we please stop using the word "anchor" for time zone, rather than source of
> time zone information as I originally suggested?
>