[Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Alexander Bokovoy]

On Tue, 16 Aug 2016, Stanislav Laznicka wrote:
>On 08/12/2016 06:48 PM, Petr Spacek wrote:
>>On 11.8.2016 12:34, Stanislav Laznicka wrote:
>>>Hello,
>>>
>>>I updated the design of the Time-Based HBAC Policies according to the
>>>discussion we led here earlier. Please check the design page
>>>http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest
>>>changes are in the Implementation and Feature Management sections. I also
>>>added a short How to Use section.
>Thank you for the review! I will add some comments inline.
>>Nice page!
>>
>>On the high level it all makes sense.
>>
>>ad LDAP schema
>>==============
>>1) Why accessTime attribute is MAY in ipaTimeRule object class?
>>Does it make sense to have the object without accessTime? I do not think so.
>My idea was that we allow users prepare a few time rule objects before 
>filling them with the actual times.
>>Also, it could be good to add description attribute to the object class and
>>incorporate it into commands (including find).
>>
>Definitely a good idea, I will work that in.
>>2) Besides all this, I spent few minutes in dark history of IPA. The
>>accessTime attribute was introduced back in 2009 in commit
>>"55ba300c7cb59cf05b16cc01281f51d93eb25acf" aka "Incorporate new schema for IPAv2".
>>
>>The commit does not contain any reasoning for the change but I can see that
>>the attribute is already used as MAY in old object classes ipaHBACRule and
>>ipaSELinuxUserMap.
>>
>>Is any of these a problem?
>I believe that the accessTime attribute was originally brought to IPA 
>when there was an implementation of time policies for HBAC objects and 
>it's been rotting there ever since those capabilities were removed. We 
>may eventually use a new attribute for storage of the time strings as 
>accessTime by definition is multi-valued which is not what's currently 
>desired (although we may end up with it some day in the future). 
>However, I don't think any other use of accessTime should be a problem 
>as it's been obsoleted for a long time.
If the attribute can be used, let's use it. We can limit multiple values
in the framework and actively complain about multi-valued accessTime.

>>Why is it even in ipaSELinuxUserMap object class?
>I'm sorry to say I have no idea. I used it for what it originally was 
>- a means for storing time strings at HBAC rules.
accessTime was part of HBAC rule but when SELinuxUserMap support was
added, HBAC lost accessTime functionality --- that's why
ipaSELinuxUserMap object class carries accessTime attribute, to specify
the time when associated HBAC rule applies.

This is one more argument to re-use accessTime attribute.


-- 
/ Alexander Bokovoy