[Freeipa-devel] Time-based account policies

Jan Cholasta jcholast at redhat.com
Thu Mar 26 10:13:21 UTC 2015


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".

>
> 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


-- 
Jan Cholasta




More information about the Freeipa-devel mailing list