unpack_nt_owners fails with owner S-1-5-32-544

[tridge at samba.org]

Simo,

 > Yeah, the only solution to be able to access files is that you map that
 > SID to a group and store an ACE for that group, this is one of the
 > reasons I crazily talk of unifying the UID and GID spaces into the GID
 > space :-)

I keep wondering if I've understood the sidHistory problem properly ....

I don't see why sidHistory would make us change an ACL. It does make
us change what we pass to setgroups(), as we have to setup the posix
security context (primary uid/gid and list of supplementary groups) as
a best match to the supplied security token.

The problem scenario would be this:

1) there is a user: S-aa-bb-cc-dd

2) we have a file 'data1' in our filesystem owned by that user, stored
   with posix owner uid1. Doesn't matter if it has an ACL on it or
   not. Simplest situation is normal posix file permissions.

3) the domain gets migrated, S-aa-bb-cc-dd is now part of the
   sidHistory of a new user S-ee-ff-gg-hh

4) the new user tries to access file 'data1'. One of two things will
   happen:

   i) if we have been smart, and mapped S-ee-ff-gg-hh to the same
   posix user id (uid1) then the access will work fine, the kernel
   will do the right thing

   ii) if we have instead mapped S-ee-ff-gg-hh to a different posix
   uid (say uid2) then we are screwed. We'd have to do root-override
   of the file access (races and all) and do ACL interpretation in
   user space.

Where we get into real trouble is if S-ee-ff-gg-hh turns up on the
wire before we know that it is in fact a migrated version of
S-aa-bb-cc-dd. In that case we may have created uid2 before we know of
the sidHistory. Then we are in big trouble :-)

Cheers, Tridge