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

[tridge at samba.org]

Simo,

 > What I mean here and above by "unifying the ID space" is that you end up
 > using only GIDs.

I sure hope I misunderstand you here!

Do you mean mean that a posix ACL for user 'simo' will have only an
ACE for a synthetic group, and no ACE at all for user 'simo' ? That's
absolutely crazy!

You would be throwing away the commonality we have between ACL
systems. With NFS4 ACLs, we have something that is very close to NT
ACLs. We can map them almost perfectly, and in a way that is utterly
obvious to viewers from both the NT world and the NFS4 world. To throw
that away because it is a bit tricky in some corner cases is just
madness.

Here's a new adage for you "don't let the crazy hacks take over". We
need some sort of hack for the corner cases, as otherwise the corner
cases won't work. The solution should involve only applying these
hacks to the corner cases and not to the far more common cases where
no hacks are needed.

POSIX systems have users and groups. Windows systems have users and
groups. The two sets of concepts are _very_ similar. Let's not ignore
the utterly obvious mapping of "a windows user is a posix user" and a
"windows group is a posix group".

 > If we still want to absolutely support unknown SIDs, then I'd suggest
 > saving such SID in a special user xattr (or directly in an NT ACL saved
 > in the user xattr). When we find out what it is we will change the
 > posix/NFS4 ACL.

we don't have xattrs on many systems, plus their performance is
horrible, plus putting it in an xattr gives the wrong semantics!

The dual ACE solution is perhaps a bit more subtle than you
realise. It works because at all times the ACL always behaves
correctly, even before it is 'fixed' !

Say some posix program (ie. not Samba) happens to know something about
the user/group associated with that SID. Say it knows that it really
is a user. If that program sets up a posix security context with the
right user/group then the kernel will immediately interpret all
accesses against that file completely correctly. The tidying up of
removing the extra ACE is just a neatness thing, allowing us to remove
the 'surprise' of a expanded ACL.

This works because in all 3 acl systems (NT, NFS4 and posix) an ACE
for a non-existant user/group has no effect on the interpretation of
the ACL. So we can add the extra ACEs, immediately get correct
behaviour from both the kernel and Samba, and as long as we reserve
that extra uid/gid we can even cope correctly with stuff restored from
backups.

Cheers, Tridge