[Freeipa-devel] Time-based account policies

[Standa Láznička]

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.
>>
>> That leaves us with 2 kinds of policies - UTC and Local Time (which is
>> enforced by hosts' /etc/localtime). Now with the (time, anchor) format
>> for time policies, the LDAP schema wouldn't have to change and we could
>> just use the AccessTime attribute of the HBAC Rule object that's already
>> there. That seems like a good solution to me.
>>
>> I hope we can agree on the above although any notes are, of course,
>> welcome. Now we would need to choose the right format for the time part
>> of (time, anchor) I guess. There's been a discussion some 2 weeks ago
>> about the need for event recurrence support in the format, the need for
>> exceptions support and the need for iCalendar import possibility. So
>> far, there are three possible languages to choose from - use the actual
>> iCalendar or just a part of it, use a reworked version of the old
>> language used in FreeIPA and SSSD, or use the language I proposed
>> earlier in this thread.
>>
>> I would be very keen on hearing your ideas and opinions on this one.
>>
>> Thanks!
>> Standa
>
>