I went through the last week's thread on Time-Based Policies, discussed some parts I wasn't very sure about with Martin, and would like to make a summary of it, followed by some further questions on the topic. The mail is a bit longer than I thought it would be. Sorry about that. It seems I am very bad at fast and brief responses.

So to summarize - the best way to go seems to be to implement both UTC and client-side local time support. A very nice idea is to store it in the format (time, timezone). Now if I understand this right, the timezone here would be the Olson database timezone stored with the host/hostgroup, possibly overridden by service/servicegroup timezone. It would help the administrator decide the correct UTC time by adjusting the time displayed in UI/CLI. The administrator should also be able to set this timezone in the UI/CLI settings of the HBAC rule (or maybe they just set it instead of storing timezone info with host/hostgroup etc. objects?).

As for the local time - timezone in the tuple (time, timezone) would only say "Local Time", which can't be found in Olson's and it means the time record from the tuple should be compared to the client's time settings (/etc/localtime ?).

What would then be left to decide is whether to use the iCalendar time format as internal, or use some other own created format. Such a format should not only be suitable for reoccurring events, but should also be able to handle exceptions in those events, such as holidays. It should also be easy to import iCalendar events to this format to support events from other sources.

The iCalendar format is rather heavy and if we wanted to use it as a whole, it may be necessary to include third party libraries in the SSSD project along with their possible vulnerabilities. There is a possibility of using only part of the iCalendar format that handles reoccurring events and exceptions. Example from Alexander to be found here: https://github.com/libical/libical/blob/master/src/test/icalrecur_test.c. That may or may not work perfectly well, given the libical library is a complex thing and we'd be taking just a part of it.

The other time format option is to simplify/edit the language that was used in the past (described with regular expressions here: https://git.fedorahosted.org/cgit/sssd.git/commit/?id=1ce240367a2144500187ccd3c0d32c975d8d346a). There was probably a reason to step out of the language (the possibility of parsing those iCalendar events, I guess) and it may or may not be possible to fix the language so that the problems with it are dealt with.

I was also inspired by the language of the time part of Bind Rules from 389 Directory Server and created a possible language that might be usable. I don't have yet the regular expression describing the language in a human-friendly form but I got a finite automaton picture that describes it (see https://www.debuggex.com/i/_Pg9KOp2TgXuus8K.png). Basically, you have the parentheses form of rules from Bind Rules, separated with either "and/or" or "except" keyword. "except" should only appear once. You would set the time ranges with the "-" operator, e.g. timeofday=0800-1545 (this operator is not shown in the picture). The parenthesis could also be nested but that can't of course be described by a finite automaton. The "except" keyword should still appear only once, though. If any time-describing part is missing, it means that access is allowed (e.g. (timeofday=0800-1600 dayofweek=Mon-Fri) allows access from 8:00 to 16:00 Monday through Friday any week in the month, any month in the year). This language should be able to do everything the old language did, supports reoccurring events nicely and also allows exceptions, so importing iCalendar events might be possible. However, its downfall is that it's not very space-efficient and absolute time ranges may not be so easily be described (e.g. time from 18:00 20.3.2015 to 23:00 24.12.2015 would be quite a string).

MY QUESTIONS: Do we store the timezone information with the host/hostgroup, service/servicegroup object or do we just have the admin pick the timezone themselves? Which time format would be best for both FreeIPA and SSSD?

Thank you very much for you insights!

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to