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

.. snip ..

*attr is specifically made to be powerful. We don't want to
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

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.


Freeipa-devel mailing list

Reply via email to