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.
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 126.96.36.199 in
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 :-)
188.8.131.52. 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
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:
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
Freeipa-devel mailing list