Need a change to the ACL code

[Nadezhda Ivanova]

Hi Andrew,
It appears I need more help with this one...
I made the following test against win2008:
Created an OU with Administrator, gave a regular user permission to create
users in this OU, but denied permission to modify otherHomePhone - denied
WRITE_PROPERTY.
After that, logged as that regular user, created another user in that OU.
The user was successfully created, and the otherHomePhone was set to the
value provided.
I may still be doing something wrong, but filtering/checking per-attribute
rights on an add operation is not documented anywhere that I could find. Can
you tell me how to reproduce such issue, even using the MS management tools?

Regards,
Nadya

On Mon, Mar 8, 2010 at 2:09 AM, Nadezhda Ivanova <nivanova at samba.org> wrote:

> Hi Andrew,
> I still do not see this as a use case, because during object creation, no
> per-attribute access checks are performed, all we care about is whether we
> can add the new object or not, which is specified in the descriptor of the
> parent. Per-attribute access is only checked on modify and search
> operations. It does not make any sense to check on add, as we actually do
> not have the new object's security descriptor. I will, however, make some
> tests tomorrow to see what happens if a user is forbidden by an inheritable
> ACE to modify an attribute, and then create an object that has this
> attribute. It may be a case I have missed.
>
> Regards,
> Nadya
>
>
> On Mon, Mar 8, 2010 at 1:10 AM, Andrew Bartlett <abartlet at samba.org>wrote:
>
>> On Mon, 2010-03-08 at 00:16 +0200, Nadezhda Ivanova wrote:
>> > Sorry, still dont understand... an add fails an access check if the
>> > user does not have permission to create children under the new
>> > object's parent, We do not check any attributes. Perhaps I need an
>> > example on when such access check would fail...
>>
>> Presume you don't have the right to add an attribute 'attr2' to an
>> object.
>>
>> Then, you create:
>>
>> dn: attr2=foo,dc=bla,dc=com
>> objectclass: weird
>> objectclass: object
>> cn: bar
>>
>> Then, the rdn_name module translates this to:
>>
>> dn: attr2=foo,dc=bla,dc=com
>> objectclass: weird
>> objectclass: object
>> cn: bar
>> attr2: foo
>>
>> The ACL code needs to treat attr2 as if it was in the list of attributes
>> (not just a DN part), because it will soon be.
>>
>> Thank you for your patience on this,
>>
>> Andrew Bartlett
>>
>> --
>> Andrew Bartlett
>> http://samba.org/~abartlet/ <http://samba.org/%7Eabartlet/>
>> Authentication Developer, Samba Team           http://samba.org
>> Samba Developer, Cisco Inc.
>>
>>
>