On 08/26/2016 12:39 PM, Martin Basti wrote: > > > On 26.08.2016 12:37, Petr Vobornik wrote: >> On 08/26/2016 12:23 PM, Martin Basti wrote: >>> >>> On 26.08.2016 12:20, Alexander Bokovoy wrote: >>>> On Fri, 26 Aug 2016, Jan Cholasta wrote: >>>>> On 26.8.2016 11:55, Martin Basti wrote: >>>>>> >>>>>> On 26.08.2016 11:43, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> 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. >>>>>>> 1) Please use the 'ipa' prefix for new attributes: memberTimeRule -> >>>>>>> ipaMemberTimeRule >>>>>>> >>>>>>> >>>>>>> 2) Source hosts are deprecated and thus should be removed from >>>>>>> ipaHBACRuleV2. >>>>>>> >>>>>>> >>>>>>> 3) Since time rules are defined by memberTimeRule, accessTime should >>>>>>> be removed from ipaHBACRuleV2. >>>>>> ad 2) 3) >>>>>> >>>>>> Because backward compatibility, ipaHBACRuleV2 must contain all >>>>>> attributes from ipaHBACRule as MAY >>>>> Not true. >>>>> >>>>>> With current approach, when timerule is added to HBAC, we just change >>>>>> objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all >>>>>> attributes that was defined in older HBAC. Removing any attrs from >>>>>> ipaHBACRuleV2 can cause schema violation. >>>>> Which is perfectly fine. >>>>> >>>>>> >>>>>> I'm not sure if want to handle this in code (removing deprecated >>>>>> attributes from HBAC entry when timerule is added) >>>>> We don't have to do anything. If any of the deprecated attributes are >>>>> present when you change the object class (which they shouldn't >>>>> anyway), you'll get schema violation, otherwise it will work just >>>>> fine. >>>>> >>>>>> I realized that AccessTime is MUST for 'ipahbacrule', so when >>>>>> timerule >>>>>> ('ipahbacrulev2') is removed and somebody deleted accesstime we >>>>>> have to >>>>>> add it back. >>>>> It is MAY. The only MUST attribute is accessRuleType, but that is >>>>> deprecated as well and should be removed from ipaHBACRuleV2. We only >>>>> support allow rules, so when timerule is removed, that's the value >>>>> you set accessRuleType to. >>>> SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter. >>>> Changing to ipaHBACRuleV2 means these rules will not be found by older >>>> SSSD versions and therefore people will experience problems with older >>>> clients not being able to use new rules even if they would lack time >>>> component. >>>> >>> Older client do not support timerules, so they should not search for >>> them. HBAC without timerules will be still have 'ipaHBACRule' >>> objectclass and will work with old clients. Only HBAC with timerules >>> will have assigned 'ipaHBACRuleV2' >>> >>> Martin^2 >> I miss "why" part of "To be able to handle backward compatibility with >> ease, a new object called ipaHBACRulev2 is introduced. " in the design >> page. If the reason is the above - old client's should ignore time rules >> then it has to be mentioned there. Otherwise I don't see a reason to >> introduce a new object type instead of extending the current. > > How do you want to enforce HBAC rule that have set time from 10 to 14 > everyday? With the same objectclass old clients will allow this HBAC for > all day. Isn't this CVE?
My point is that the design is missing the explanation. > >> >> >> 2. About API and CLI: wasn't there an idea to hide/not provide >> --icalfile=file.ics and --time=escaped_icalstring options in the first >> implementation. So that we can limit the support scope to only a subset >> of option(the OPTS part). If arbitrary ical is allowed since the >> beginning then we are asking for a lot of bugs filed. >> > -- Petr Vobornik -- 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