On 07/15/2016 03:11 PM, Simo Sorce wrote:
On Fri, 2016-07-15 at 14:29 +0200, Stanislav Laznicka wrote:
On 07/15/2016 02:10 PM, Simo Sorce wrote:
On Wed, 2016-05-18 at 15:28 +0200, Stanislav Laznicka wrote:
On 05/18/2016 02:19 PM, Alexander Bokovoy wrote:
On Wed, 18 May 2016, Stanislav Laznicka wrote:
when removal succeeds but addition fails for some reason?
operation is not atomic anymore.
We offline-discussed this with Honza. There should be a new
`ipa hbacrule-replace-accesstime rule_name --orig-
--new-time=icalstr2`. As it would be derived from LDAPQuery,
atomicity is kept. This may not be very nice for CLI but
well for WebUI. Both icalstr1 and icalstr2 need to be encoded
newlines that appear so often in iCalendar strings would only
Example of use:
ipa hbacrule-replace-accesstime rule_name
to add Tuesdays to the timespan defined by the rule.
I would really like to see a file input support here. It would
simpler to operate in CLI as you would anyway create vCal files
sane person is going to deal with these strings directly on the
That is correct and some basic file support is already in the
sent earlier, though replacing rules is not a part of it.
does not solve the problem as you would still need access to the
to work with the attributes and then change the files
However, we've had yet another brainstorm with Petr^2, Martin^2
Honza. We really don't want the above so we came up with some
I'm listing below. Note that we also do not want more than one
component in any of the time rules. So, the ideas:
1) Have the time rules as separate objects. This approach
support here. Adding Simo and Jakub to CC should they have any
2) Have the time rules stored as strings in the multi-
accesstime attribute at each rule. These would be referenced by
UID property of the VEVENT component of the iCalendar string
that pure hell above). As each of the strings can only contain
VEVENT which has to define a UID, the only problem would be to
uniqueness of UIDs consistent.
From my point of view, 1) seems rather better but your
be different. Don't hesitate to share your opinions, please.
Can you please give me an example ldif of a complete hbac rule
including time rules with the 2 different proposals ?
I do not really care a lot how the framework ends up managing the
objetcs, I care mostly about how the information is stored in LDAP
how efficient the storage will be for SSSD retrieval.
That's my evaluation pov.
Keep in mind that rules are modified rarely but downloaded much
frequently, so it is ok to have a slightly harder way to store them
gain efficiency in retrieving and downloading them.
Please find the ldif files attached, with some additional changes
only to hbac rules. It's from my current implementations.
OT: We had an offline discussion with Honza that to keep the
compatibility, it might be good to introduce v2 of HBAC rules so
what you see there. Perhaps accessTime should be in that v2 rule as
but that's even more off-topic here.
I really would like an example ldif of a set of objects created with an
actual time rule in effect, the schema tells me something but not all.
You have ipaHBACRulev2 defined twice in different way in the two files,
What is accessTime ?
Those two files show two different implementations - templates.ldif of
the template approach, objects.ldif of "time rules as objects" approach.
Should have probably mentioned that. Also, like I said, I should have
probably included "accessTime" in the objects.ldif ipaHBACRulev2, which
I believe is the only difference there that does not have to do anything
with how this works.
"accessTime" is an attributeType defined in some IPA 2.0 version or so
which should bear the time policy information. Each of the time rules
objects should bear one single-valued "accessTime" attribute.
"accessTime" is originally defined as multi-valued so we may want to
have a new attribute defined for that use.
Time rules would have their own container somewhere in LDAP, currently
working with it being in the realm tree. There, you would add the time
rule objects - objects with a name and the information of when such rule
would apply. These you would be able to add as members to an HBAC rule.
With templates, it's very similar, except that you are able to
rewrite/set the accessTime attribute value directly at the HBAC rule
object (as nothing is actually stored there because CoSTemplates), thus
saving the string directly within the HBAC rule object. This, however,
makes it very hard for the time rules to be worked with as you basically
lose the information about which of the time rules you want to change in
that multivalued HBAC attribute as you can probably imagine.
As for how the time policy string is stored - it's an iCalendar string.
Is it more clear now? I don't currently have ldifs of any interesting
use of either approach.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code