Hi!
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!
Standa
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
