[Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server

[thierry bordaz]

On 06/17/2014 09:42 PM, Simo Sorce wrote:
> On Tue, 2014-06-17 at 21:36 +0200, thierry bordaz wrote:
>> On 06/17/2014 09:29 PM, Simo Sorce wrote:
>>> On Tue, 2014-06-17 at 15:23 -0400, Rob Crittenden wrote:
>>>> Simo Sorce wrote:
>>>>> On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote:
>>>>>>             * ipa stageuser-add <login> --from-delete
>>>>>>
>>>>>>               It moves a deleted entry to staging container where
>>>>>>
>>>>>>                   uidNumber: <unchanged, so it is preserved from the
>>>>>>                   prevous active account>
>>>>>>                   gidNumber: <unchanged, so it is preserved from the
>>>>>>                   prevous active account>
>>>>>>                   ipaUniqueID: autogenerate (reset to autogenerate)
>>>>> Why are you resetting the unique id ?
>>>> Read back a few in the thread. I suggested, perhaps incorrectly, that
>>>> given that there should be no more references to the user once they go
>>>> into deleted or staged, it may be ok to reset this value.
>>> Well, let me reiterate, the deleted bucket is for those environments
>>> where they have a mandate (regulation, law, policy, etc..) to never
>>> delete users and reinstate users if they are deleted.
>>> So all uniquely identifying information should be preserved in case the
>>> object is revived. This means we need to do our best to preserve all
>>> these attributes if we can.
>> This is what is done when an Active user is deleted.
>> uidNumber/gidNumber/ipaUniqueID are preserved.
>> When activating a user, currently UUID plugin prevents to set a value.
>> Should it be relaxed.. I feel not. It is a sensitive info and
>> provisioning system should not define it.
> Why is it sensitive ? A ipaUniqueID is not really sensitive, it just
> needs to be unique.

Ok.  I believed it was :-)

I have a concern, if a provisioning system is free to define this value, 
I wonder if it can create problem for replication.
For example a provisioning system creates two staging entries on 
different servers but with the same ipaUniqueID value.
If the entries are activated at the same time, the ADDs operation 
(activation)  will not be replicated because the attribute uniqueness 
plugin will reject it.

This case existed before if two  IPA uuid plugins generated identical 
value on different replica. But the probability was less than if the 
provisioning system is free to set it.

>
>> When undelete a user (move Delete->Staging), ipaUniqueID can be
>> preserved but as the purpose of Staging entry is to become active I
>> thought it would be better to wipe the value also at this time.
> I understand that (and I noted before that I think deleted->staged is a
> bad idea IMO :-) ), but you are wiping it only as a workaround, because
> the plugin prevents you from adding it. Would have you wiped it if it
> were not the case ? And if so, why ?

That is correct. I thought to wipe it because the plugin rejected values 
others than 'autogenerate'.

To relax the control that rejects values other than 'autogenerate', I 
need to modify the plugin. Should it be done under an other ticket or 
can it be part of this RFE ?

thanks
thierry

>
> Simo.
>
>