Rob Crittenden wrote:
> Dmitri Pal wrote:
>> Simo Sorce wrote:
>>> On Sun, 10 Oct 2010 23:27:33 -0400
>>> Dmitri Pal<d...@redhat.com>  wrote:
>>>
>>>
>>>> Actually the whole thing was inspired by the ACI UI from the LDAP book
>>>> that is based on Netscape DS.
>>>> Rob you say "What it lacks is a way to *output* an aci so it can be
>>>> easily represented in a UI or on the command line. That is where our
>>>> focus should be." But I do not understand what the problem is. You
>>>> either have to display a raw ACI or some abstraction. But how you map
>>>> the abstraction that you need to show to the raw ACI you have in the
>>>> system? I was trying to solve exactly this problem. And I really do
>>>> not see a way to do it differently. Do you?
>>>>
>>>
>>> The strongest objection is against creating a new LDAP object to hold a
>>> duplicate of the ACIs. And I fully agree with the objection we do not
>>> need duplicates in the Directory.
>>
>> I do not see it as duplicate. It is a helper. And it is a loose coupling
>> so there is really not harm for parts to get out of sync. But this all
>> does not matter if this is not the problem we are trying to solve.
>
> It is, by definition, duplicate. You're storing exactly the same data
> in two places in different formats.
>
>>
>> Simo you are talking about hash tables or sets of hash tables to
>> represent what?
>> The following rule does not decompose well to the set of hash tables:
>>
>> (targetattr = "streetAddress || postalCode || c || l ||
>> st")(targetfilter =
>> "(memberOf=cn=secretaries,cn=groups,cn=accounts,dc=example,dc=com)")(version
>>
>> 3.0;acl "Secretaries can write engineering addresses";allow (write)
>> groupdn =
>> "ldap:///cn=secretaries,cn=groups,cn=accounts,dc=example,dc=com";;)
>>
>> It is really a:
>> 1) Set of attributes (can be hash table, but rather just a list)
>> 2) Filter - a string but I am not sure one can formalize it
>> 3) Name - a string
>> 4) Right
>> 5) Bind DN - a string that is similar to a filter
>
> As I said, this is already done. Internally I represent ACIs as:
>
> name: string
> action: string (one of an enumeration)
> permssions: list
> target: hash table
> bindrule: hash table
>
> A bindrule is a hash of: keyword, operator, expression, e.g. groupdn
> != ldap:///cn=admins,...
>
> Targets are similar, with an operator and an expression, e.g.
> targetattr != "foo || bar". The targets supported are targetfilter,
> targetattr and target (e.g. a subtree).
>
> My parser probably doesn't support every possible kind of ACI but it
> does support those that are allowed in the aci plugin.
>
>> It seems that the biggest problem is: with filter and Bind DN. Those
>> correspond to an object in the system. We can replace the "groupdn =
>> "ldap:///cn=secretaries,cn=groups,cn=accounts,dc=example,dc=com"; with
>> more readable group=secretaries or user=someone or host=mycomputer etc.
>> Is this the abstraction that we are looking for? It is harder with the
>> target filter to do the similar simplification.
>> Can we a simplify it to things like?:
>> a) A member of a group
>> b) An object of the class
>> c) Its attribute has a specific value
>> If we can parse it out to one of these three (or may be some other case
>> that I missed) we can replace it with a much more readable
>> representation.
>> For example:
>> a) A member of a group will translate into: "a member of group
>> secretary", similarly with other groups "a member of hostgroup
>> lab-machines" etc
>> b) An object of the class will translate into: "a user" or "a group" or
>> "a host group"
>> c) Its attribute has a specific value "user.cn is 'blah' " or "host.fqdn
>> is 'host123' "
>
> Please take a look at the existing aci plugin. Most of this is already
> covered. Remember that ideally acis will grant access to taskgroups
> and not direct objects, so make them more generic. Granting access to
> hostgroups isn't supported right now. In fact, there is no way to
> grant access to hosts or hostgroups right now, just users and groups.
>
> If the problem here is how we do this via the UI then as I said, I
> need to enhance the output of the aci plugin to provide the data in a
> format that the UI can handle.
>
> rob

I feel that there is a disconnect. But I do not understand where it is.
If all of this already works than what is the problem? Why not just fix
the plugin to output whatever is needed. Based on Adam's questions I was
under the assumption that there is a bit design gap. Does not seem to be
based on this thread. So what are we trying to accomplish here? Fix the
plugin to return hash tables? Seems like a simple task. Do we have a
ticket? Is it clear what needs to be done there? Or there is more and
something needs to be sorted out. Can someone please define the scope of
the problem?

-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to