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

[Simo Sorce]

On Wed, 2014-06-18 at 11:39 +0200, thierry bordaz wrote:
> 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.

A provisioning system should never have to contact 2 different servers,
what would be the point ?
And then on top of that generate the same UUID ?
Well don't do that, fix your provisioning tool.

> 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.

Right, don't do that.

> 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.

Sure, but who cares ? I mean there are *many* ways to whose a system,
the provisioning system can simply create 2 users accounts with the same
name on 2 servers and get them activated at the same time and you get
the same issue as uid is also unique. Just fix the malfunctioning
provisioning system.

> >> 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 ?

I think it can be part of this RFE, should we use the Relax Control for
this ? I think it may still valuable to enforce the rule in non-staging
cases.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York