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
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
