Why are we allocating ID_TYPE_BOTH on a user or machine SID type ?

[Jeremy Allison]

On Thu, Oct 17, 2013 at 02:04:04PM +1300, Andrew Bartlett wrote:
> On Wed, 2013-10-16 at 16:51 -0700, Jeremy Allison wrote:
> > 
> > I can probably fix this another way,
> > but it'll be ugly and it would be much
> > easier to have a SID_NAME_USER or SID_NAME_COMPUTER
> > SID type mapped solely to ID_TYPE_UID :-(.
> 
> It makes it deterministic no matter if we could verify if a SID a user
> or not,

As far as I can see we're only allocating the unix id if
the LookupRid query to the DC is successful, so we know at allocation
time if it's a uid or non-uid SID.

> and allows us to function when the domain is migrated and the
> user SID ends up in sidHistory, rather than being the user's SID.  

Why does this matter w.r.t. group or user SIDs ? Even when
moved to sidHistory a sid type isn't going to change from
one to the other.

> Also, as seen in the AD DC (but available generally), a group needs to
> be a UID when the group owns files. 

Oh sure, I understand that case fully - that's why
when a SID is not a SID_NAME_USER or a SID_NAME_COMPUTER
we need to alloc both a uid and a gid. When we're allocating
a non-user-type SID we need to return ID_TYPE_BOTH for sure.

But in the case where a SID *is* a SID_NAME_USER or a SID_NAME_COMPUTER,
then we can allocate both the uid and gid to keep the allocation
space equally assigned, but when we return from the allocation
we don't need to return ID_TYPE_BOTH, we can return ID_TYPE_UID,
which would make the code paths in smbd simpler - we only have
to do ACL tricks in the ID_TYPE_BOTH (grouup SID needing both
a uid and gid pair) case.

I have a patch sent to the user that does precisely this, let's
see if it fixes their specific case.

I cannot see any case where we need to return ID_TYPE_BOTH
when we're allocating what we know to be a uid-type SID,
can you ?

Jeremy.