On 05/28/2014 05:08 PM, Martin Kosek wrote:
On 05/28/2014 05:03 PM, Ludwig Krispenz wrote:
On 05/28/2014 04:56 PM, Martin Kosek wrote:
On 05/28/2014 04:50 PM, Simo Sorce wrote:
On Wed, 2014-05-28 at 16:27 +0200, Petr Viktorin wrote:
Simo, I hazily remember discussing that we should only allow specific
attributes on add, otherwise users can add entries with any extra
objectclasses and attributes. Did we come to a conclusion?
I might have confused targetattr with targetattrfilter in my notes;
since I see targetarr is ineffective.

Yes we need to restrict at least the allowed objectclasses I think.

Simo.

We do not have a support for targetattrfilter, I do not think this was ever
tested. This part of ACI is also not very well documented, I think Petr found
just one notice in the DS documentation about targetattrfilter.
It is in chapter 13.2.3.5 in
https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Creating_ACIs_Manually-Defining_Targets

and it is for unknown reasons: targattrfilters
Right, this is what I (and Petr) was talking about. The doc contain just this
single one line of information about targetattrfilters.
Well, it is not much, but more than one line :-)


        13.3.2.5. Targeting Attribute Values Using LDAP Filters

You can use access control to target specific attribute values. This means that you can grant or deny permissions on an attribute if that attribute's value meets the criteria defined in the ACI. An ACI that grants or denies access based on an attribute's value is called a value-based ACI. For example, you might grant all users in your organization permission to modify the /|nsroledn|/ attribute in their own entry. However, you would also want to ensure that they do not give themselves certain key roles, such as |Top Level Administrator|. LDAP filters are used to check that the conditions on attribute values are satisfied. To create a value-based ACI, you must use the |targattrfilters| keyword with the following syntax: (targattrfilters="add=attr1:F1 && attr2:F2... && attrn:Fn,del=attr1:F1 && /|attr2|/:/|F2|/ ... && /|attrn|/:/|Fn|/")

 *
    |add| represents the operation of creating an attribute.
 *
    |del| represents the operation of deleting an attribute.
 *
    /attrx/ represents the target attributes.
 *
    /Fx/ represents filters that apply only to the associated attribute.

When creating an entry, if a filter applies to an attribute in the new entry, then each instance of that attribute must satisfy the filter. When deleting an entry, if a filter applies to an attribute in the entry, then each instance of that attribute must also satisfy the filter. When modifying an entry, if the operation adds an attribute, then the add filter that applies to that attribute must be satisfied; if the operation deletes an attribute, then the delete filter that applies to that attribute must be satisfied. If individual values of an attribute already present in the entry are replaced, then both the add and delete filters must be satisfied.
For example, consider the following attribute filter:
(targattrfilters="add=nsroledn:(!(nsroledn=cn=superAdmin)) && telephoneNumber:(telephoneNumber=123*)") This filter can be used to allow users to add any role (/|nsroledn|/ attribute) to their own entry, except the |superAdmin| role. It also allows users to add a telephone number with a 123 prefix.

*
*

  Try googling that and
you won't get much more.

Just for completeness, posting one of the top findings:

Bug 1032767 - Examples of the targetattrfilters ACI keyword need to be 
documented

Martin

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

Reply via email to