[Freeipa-devel] [PATCHES] 0016-17 Fixes for{add, set, del}attr with managed attributes

[Petr Viktorin]

On 03/16/2012 02:34 PM, Rob Crittenden wrote:
> Petr Viktorin wrote:
>> I may be taking things out of context, but I see this:
>>
>> On 03/16/2012 02:07 PM, Rob Crittenden wrote:
>>> Jan Cholasta wrote:
>>>> On 29.2.2012 15:50, Rob Crittenden wrote:
>>>>> Petr Viktorin wrote:
>>>>>> On 02/27/2012 11:03 PM, Rob Crittenden wrote:
>> .. snip ..
>>>>>>>>
>>>>>>>> Patch 17 makes these options honor params marked no_create and
>>>>>>>> no_update.
>>>>>>>>
>> .. snip ..
>>>>>>
>>>>>>> *attr is specifically made to be powerful. We don't want to
>>>>>>> arbitrarily
>>>>>>> block updating certain values.
>>
>> .. versus ..
>>
>>>>>>
>>>>>> I see the problem now: the certificate subject base is defined as a
>>>>>> multi-value attribute in the LDAP schema. If it's changed to
>>>>>> single-value the existing validation should catch it.
>>>>>>
>> .. snip ..
>>>>>
>>>>> The framework should be able to impose its own single-value will as
>>>>> well. If a Param is designated as single-value the *attr should honor
>>>>> it.
>>>>
>>>> Is that so? Isn't *attr supposed to allow the user to modify attributes
>>>> at LDAP level, i.e. skip the usual framework constraints?
>>>
>>> If we make rules around an attribute they should be honored. If we have
>>> not then all bets are off.
>>>
>>> *attr was never really made to manage those attributes that IPA knows
>>> about, despite most of the testing being around that. It was to provide
>>> a way to manage things we don't support yet.
>>
>>
>> which strikes me as inconsistent.
>>
>
> The original patch read to me that you were creating a new class of
> parameters that could not be updated via *attr. IMHO that was going too
> far.

Not creating a new class, just using what's already marked no_update.

> Some constraints are required. We don't want someone doing:
>
> ipa user-add --first=Super --last=Bad superbad --setattr uidnumber=0
>
> Similarly we impose a certain view of the data to fit our purposes.
>
> The right solution in this case is to change the schema of
> ipaCertificateSubjectBase. But think about it. What does it mean if
> someone can add multiple values to parameters that IPA otherwise
> considers single-value? Undefined. I don't think it is unreasonable to
> enforce the parameter's single value. A user can always use ldapmodify
> if they really need to set that second value.

I thought *attr was supposed to have the power of ldapmodify (for 
IPA-managed entries)?

Anyway, you're right that this should be changed in the schema.
But maybe since the checking should be done at the LDAP server, we 
shouldn't need to put another checking layer here (more code, more 
corner cases, more bugs).

Alternatively, just disable *attr for known attributes. The users can 
always use ldapmodify if they know what they're doing, and if it's not 
possible with normal IPA commands it's a case where they do need to know 
what they're doing (and by having to use ldapmodify, be warned that 
they're on their own).

-- 
Petr³