On 08/26/2016 12:47 PM, Standa Laznicka wrote: > 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. >> > It's exactly that - I will mention it there, then.
Thanks >> 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? >> > Word. >>> >>> >>> 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. >>> >> > Why hide it if there's no real problem with it? The string/content only > has to be cut down to the restrictions of one event per VCALENDAR but I > do not see the problem there. > OK then. -- 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