[Freeipa-devel] [PATCH 0066] Make ipatokenTOTPwatermark a required attribute

[Petr Vobornik]

On 19.9.2014 17:06, Simo Sorce wrote:
> On Fri, 19 Sep 2014 09:08:46 +0200
> Ludwig Krispenz <lkrispen at redhat.com> wrote:
>
>>
>> On 09/18/2014 08:27 PM, Simo Sorce wrote:
>>> On Thu, 18 Sep 2014 14:22:07 -0400
>>> Nathaniel McCallum <npmccallum at redhat.com> wrote:
>>>
>>>> On Thu, 2014-09-18 at 14:18 -0400, Simo Sorce wrote:
>>>>> On Thu, 18 Sep 2014 13:56:44 -0400
>>>>> Nathaniel McCallum <npmccallum at redhat.com> wrote:
>>>>>
snip
>>>>> NACK, you cannot move from MAY to MUST.
>>>> This is precisely what we have been discussing on IRC today. The
>>>> consensus was that this was acceptable because of the update plugin
>>>> and the rarity of the state in which a token would not have
>>>> ipatokenTOTPwatermark set (the token has to be created an never
>>>> used).
>>> Sorry I was not around, but it is never acceptable, as it may cause
>>> replication failures.
>> I agree that this shouldn't be done, although  replication should not
>> be  a problem, the consumer relies on the schema checking of the
>> server where the operation was originally applied.
>> But problems may show up for existing entries, if you have an an
>> entry without attr A, which now becomes MUST and then do any
>> modification on this entry, after the mod the entry will be schema
>> checked, the missing attribute detected and the mod rejected
>>>
>>> This has been a long (albeit perhaps unspoken) rule in changing
>>> schema in FreeIPA.
>> if you want to define the rules for schema change somewhere, you
>> should add this as well: never make a multivalued attribute
>> singlevalued
>
> Ok I added this new page: http://www.freeipa.org/page/Schema_Handling

Thanks for the page, very helpful.

>
> I would like to add a link to it in
> http://www.freeipa.org/page/Contribute/Code if I get a review and an
> ack for the page.
>
>>>
>>> Existing objectlasses can *never* gain new MUST attributes. This
>>> rule is rigid and is non-negotiable.
>>
>> If you want to ensure that every entry has a specific attribute, but
>> connot enforce this by the schema, an option would be to define a CoS
>> rule for this attr which defines a default and gives the real attr
>> precedence
>
> Yeah this is a good idea, should we add a section in that page with
> advice on how to handle situations where you'd like to change an
> objectclass/attribute but are not allowed by our rules ?
>

+1 Would be helpful as well.
-- 
Petr Vobornik