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

[Rob Crittenden]

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.

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.

rob