[Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions

[Ludwig Krispenz]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140528/62033b16/attachment.htm>