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:
On 11.8.2016 12:34, Stanislav Laznicka wrote:
1) Please use the 'ipa' prefix for new attributes:
I updated the design of the Time-Based HBAC Policies according
discussion we led here earlier. Please check the design page
changes are in the Implementation and Feature Management
also added a short How to Use section.
2) Source hosts are deprecated and thus should be removed from
3) Since time rules are defined by memberTimeRule, accessTime
be removed from ipaHBACRuleV2.
ad 2) 3)
Because backward compatibility, ipaHBACRuleV2 must contain all
attributes from ipaHBACRule as MAY
With current approach, when timerule is added to HBAC, we just
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
I realized that AccessTime is MUST for 'ipahbacrule', so when
('ipahbacrulev2') is removed and somebody deleted accesstime we
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
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'
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.
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?
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.
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.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code