On 11/05/2015 06:17 PM, Petr Spacek wrote:
This seems like a good idea. However, it might be a bit messy to have
even the least significant rules stored in separate objects. But I
agree. It brings some questions, though.
Where would be a good spot to store these time rules? Should they be
able to form groups? Should such an object be able to hold more time
policies strings and exceptions, as it does now, or would it be better
to set that in the respective HBAC rule?
On 4.11.2015 15:20, Martin Basti wrote:
we (Standa and I) had offline discussion and I proposed following idea:
1) create new entry in LDAP for "time rule" instead of adding the time rule
string directly into HBACRule.
This will allow to reuse time rules among various HBAC Rules (and maybe in
future with sudo rules, etc.)
HBACrule gets only reference to time rule entry stored in LDAP db.
Good idea! I can see time rule entry 'working hours in Brno office' which is
linked to relevant HBAC rules.
I was thinking long and hard about actually using the iCalendar format
for this purpose, ever since the 'repeat' keyword was supposed to be
included in the language. However, as I mentioned some time ago, the
iCalendar format recurrences are OK when it comes to recurring events
but I am not sure about them being very suitable for describing time
2) Do not create a new time format, just reuse iCal (parts of iCal we need),
to store time rule in LDAP in "time rule" entry
(Or is possible to not store the values just as one string, we can use
different attributes to store separate values, iCal can be used as export and
I very much agree with re-using iCal! We have sufficient number of custom
parsers already ;-)
Speaking about custom LDAP format, I do not think that it is a good idea. It
would prevent us from using iCal parsers and generators and we would risk that
our custom LDAP format will not be flexible enough.
For these reasons I would go with 1 iCal string which can be fed into any
standard-compliant iCal library.
Let me do a comparison of the options. I will take in question only the
RRULE (and possibly PERIOD) part of the iCalendar format. Having the
whole iCalendar format involved along with its parsing C library seemed
to be a no-go for SSSD some 6 months ago and I can imagine such feelings
Some iCalendar cons:
1) It is hard to represent continuous time of a day ranges
There does not seem to be an easy equivalent to e.g. 'timeofday=
0730~1100, 1200~1615'. The easiest way to do this in iCalendar would be
to have 2 rules of the form:
RRULE: FREQ=DAILY; INTERVAL=1
RRULE: FREQ=DAILY; INTERVAL=1
If you were setting some more difficult policy, there would have to be a
lot of duplicity in each of such rules.
2) All iCalendar events have to have a fixed starting point
There must always be a check against the interval and the starting point.
3) There are no ranges
e.g. 'dayofyear=2-50, 100-125' would translate to
RRULE: FREQ=SECONDLY; INTERVAL=1;
4) There is no way to list specific years in which the HBAC rule should
5) COUNT parameter makes you generate all previous events before you are
able to tell if the current one actually applies.
Imagine COUNT being a big number and an event that hardly ever happens.
Imagine current time to fall into the last event.
6) The event descriptions are not so intuitive
There would probably have to be better conversion system at least for
CLI when user wants to set time ranges of access allowed times so that
we can consider it good UX.
I am not mentioning the lack of weekofmonth in iCal as I would rather
drop it from the current solution, too.
On the other hand, there are also some big pros for iCalendar.
1) It is a standard. It behaves in a known and described manner.
2) By proper use of BYSETPOS of RRULE, it is able to describe some
specific situations, e.g. last workday of a month. This is not possible
in the current language.
3) Easier setting of absolute time ranges using the PERIOD property
(although this could probably be easily solved by a minor addition to
the current solution).
4) A GUI for setting RRULEs already exists.
ad 4) The GUI, however, hides some of the features of the language (e.g.
the mentioned BYSETPOS) and is not suitable for setting time policies as
is. Try, for example, setting a policy "allow access from 7:00 to 16:00
(no break of the interval as iCalendar does not know it) every first
Monday through Friday of a month for the first half of every year".
In current language:
timeofday=0700~1600 dayofmonth=1~7 dayofweek=1~5 monthofyear=1~6
In iCalendar RRULE:
RRULE: FREQ=YEARLY; BYMONTH=1,2,3,4,5,6;BYDAY=1MO,1TU,1WE,1TH,1FR
Hopefully, this was a thorough walk-through of the pros and cons of both
approaches. I believe I stayed clear of any sentiment to the work I did
of which a big part could come in vain if we moved to iCalendar format.
Please correct me if I haven't.
I wonder if we want to have someone from SSSD in this discussion, too.
Please, see my comments on the GUI in ad 4). On the other hand to the
comments - there is at least something done in iCalendar GUI that we
could use rather than coining out a whole new GUI for time policies.
3) We may provide nice CLI and webUI to construct/show "time rule", this may
be more user friendly than just passing the string containing time data to
This is going to be the same as in any calendaring system. Just look to
Thunderbird "New Event" dialog.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code