[Freeipa-devel] [SSSD] Proposed changes to the HBAC grammar

Dmitri Pal dpal at redhat.com
Wed Nov 17 21:21:18 UTC 2010


Stephen Gallagher wrote:
> During a discussion today about how to represent the HBAC grammar in the
> FreeIPA GUI, it became apparent that there was a limitation in the
> grammar. Specifically, it's not possible to describe in a non-ambiguous
> way "The first Wednesday of the month".
>
> Right now, this would be described by:
> accessTime: periodic monthly week 1 day 3 0800-1700
>
> However, this literally means "Wednesdays that appear as the first week
> on a wall calendar". Meaning that if the month began on a Thursday, this
> rule would not fire this month. Thus it's not behaving in a way that
> would be reasonably expected by a user.
>
> After extended discussion, Simo, Ben and I discussed replacing this
> week-of-the-month concept with a septet-of-the-month concept instead.
>
> This would be described by:
> accessTime: periodic monthly septet 1 day 3 0800-1700
>
> and would literally translate as "The wednesday that exists within the
> first septet of the month". The first septet being the range of day 1
> through day 7, the second septet being day 8 through 14, and so forth.
>
> We all feel that this would map closer to a user's expectation when
> describing "the Nth Wednesday of the month", since it's a guarantee that
> Wednesday will appear only once within a septet.
>
> This will require two changes to the HBAC schema. First of all, we plan
> to drop the week-of-the-month concept entirely and replace it with
> septet-of-the-month. This is being done to eliminate the ambiguity
> entirely. Secondly, we will need to describe day-of-the-septet in the
> grammar (where the day of the septet describes the name of the weekday,
> and not its numerical position within the septet, as that would be a
> useless and complex duplication of the day-of-the-month concept).
>
>
> In a related note, we also discussed how to handle describing activity
> windows that cross the midnight boundary. It's my recommendation that we
> should handle examples like the following by breaking them into two
> separate accessTime attributes, one that describes the portion preceding
> midnight and describes the set of days wherein the block starts, and a
> second accessTime attribute that is offset by one day and describes the
> portion taking place after midnight.
>
> Second-shift (17:00-01:59, M-S*) *starts Monday, ends Saturday morning
> becomes
> accessTime: periodic weekly day 1-5 1700-2359
> accessTime: periodic weekly day 2-6 0000-0159
>

I agree with the proposal the only issue I see is the issue of the time
zone of the user. When the user schedules the window it should be clear
what time zone he is using. If we in v2 use UTC for all I am fine but if
we allow user to enter window in the local time to his machine and then
rely on the client UI/CLI to convert it to UTC we can face a problem of
the local time window not crossing midnight while the  UTC window will
cross the boundary. We need to define how this case will be handled and
how we interpret the input.

Please add the clarification about this.

_______________________________________________
sssd-devel mailing list
sssd-devel at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the Freeipa-devel mailing list