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

[tridge at samba.org]

Simo,

 > I also proposed this a couple of times during the years, my idea has
 > always been that you set both the uid and the gid in the ACL.
 > Alternatively you always set only the gid (unless you are the user owner
 > of course) and make sure that setgroups always sets the gid for the user
 > as well as the uid. This way it doesn't matter what you are really,
 > basically you end up unifying the uid and the gid spaces in the gid
 > space.

I'm afraid I don't understand the above. When you say "set both the
uid and the gid in the ACL" can you explain what you mean in terms of
the fields in NT ACLs and NFS4 or POSIX ACLs ?

 > >  - create both a uid and a gid for SIDs of unknown type
 > 
 > What about creating them both always for all SIDs?

no, that is a bad idea :)

it wouild mean that for files that initially have posix or NFS4 ACLs,
we would be significantly altering the ACL for no reason. So a user
what makes some small change to a file with an existing NFS4 ACL on it
using Samba would end up with a double sized ACL, and that would be a
major surprise for them. So just using the principle of least surprise
should kill this idea.

It also eats up uid/gid space twice as fast, doubles the size of ACLs
on disk (whcih would definately show up in benchmarks! the xattr fetch
in NFS4 ACLs is slow enough as it is), and would mean that some ACLs
would overflow internal limits for ACL size when they don't need to.

The 'double ACE' idea is a nasty hack forced on us by the fact that it
is very difficult in some cases to determine the type of a SID. Let's
not needlessly force this nasty hack on every ACL that Samba comes
across.

 > If you unify the ID mapping you don't even need to do that.

yes, you do. See the reasons above for removing the duplicate ACE as
soon as you possibly can.

 > To solve this problem we should probably require a secondary
 > allocation range just for unknown SIDs so that at worst we fill up
 > the secondary range but still keep free the valid/verified SIDs
 > range for normal users and groups.

I don't think that is worth the extra complexity. 

What do you do when this secondary range fills due to a denial of
service attack? How does it help the hapless system administrator
faced with this problem? He will still have a bunch of files on disk
and in backups, some of which have real foreign SIDs and some of which
have fake SIDs. I don't see how having all the foreign SIDs mapped
into a secondary range really solves his problem.

Cheers, Tridge