[Freeipa-devel] Time-based account policies

Jan Cholasta jcholast at redhat.com
Tue Mar 24 06:16:41 UTC 2015


Dne 23.3.2015 v 20:17 Standa Láznička napsal(a):
> On 3/23/2015 10:10 AM, Jan Cholasta wrote:
>> Hi,
>>
>> Dne 20.3.2015 v 13:30 Stanislav Láznička napsal(a):
>>> ...
>>>
>>> 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 ?).
>>
>> Let me just do a braindump here:
>>
>> I would think timezone, or rather location (timezone + holidays)
>> should be stored with user objects (but not in group objects, as users
>> can be members of multiple groups, which could cause conflicts). When
>> a user goes on a bussiness trip etc., an administrator/manager would
>> need to change their location accordingly to reflect that.
>>
>> For hosts, timezone information is already available on the host
>> (/etc/localtime). I'm not sure if there is a 1-1 mapping between
>> timezone and holidays, but if there is not, we probably need to store
>> location with host objects as well. If we do that, maybe we can make
>> SSSD update local timezone on the host using the information stored
>> with the host object to allow roaming (think user laptops).
>>
> I'm not sure about storing the holiday information with any objects.
> Holidays are a good example for exceptions in time rules but I'm not
> sure that this information should be really stored with each user/host.
> There might be cases where you want the holidays to apply and then
> sometimes you may not want them to apply. Storing time exceptions with
> the specific HBAC rules would solve that, I think.

I'm not saying we should store them directly with any object, but rather 
store a reference to an object defining them, so that you don't have to 
define them over and over again when you need to use them in multiple 
places.

>> It might be a good idea to store optional owner information with
>> hosts, so that when the owner moves to a different location, the host
>> is assumed to be at that location as well (again think user laptops).
>>
>> Given the above, HBAC rules could contain (time, anchor), where anchor
>> is "UTC", "user local time" or "host local time".
> Truth is, it was not really clear to me from the last week's discussion
> whose "Local Time" to use - do we use host's or do we use user's?  It
> would make sense to me to use the user's local time. But then you would
> need to really store at least the timezone information with each user
> object. And that information should probably change with user moving
> between different timezones. That's quite a pickle I am in right here.

IMO whether to use user or host local time depends on organization local 
policy, hence my suggestion to support both.

Yes, timezone would need to be stored with the user, and someone or 
something (not the user, so they can't cheat) would need to change it 
when the user moves.

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


-- 
Jan Cholasta




More information about the Freeipa-devel mailing list