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

[simo]

On Wed, 2006-10-25 at 09:45 +1000, tridge at samba.org wrote:
> 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.

What I mean here and above by "unifying the ID space" is that you end up
using only GIDs. So the ACLs does not double, the only drawback is that
you end up with half the ID space but I think that 2/4G IDs are enough
anyway if carefully used (and perhaps reused).

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

Well it's not _all_ the foreign SID, just the SIDs you can't verify.
During normal functioning you can always reach a domain controller (or
trusted domain) to verify a SID.
A second range will buy you that you don't have all your ID space sucked
up with a v. simple DoS. I think every admin can definitively leave with
a secondary range being exhausted, but would not accept the risk of
seeing the primary one being exhausted. Cleaning up the mess on a
secondary range can be done while the server is running and still
working normally for normal user activity.

If a safeguard is not worth the extra complexity than I think it is not
worth worrying about unknown SIDs. If the risk associated with dealing
with these SIDs is that of a DoS on the ID pool, I'd rather see refusing
a mapping for an unknown SID.

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.
The only problem you have trying to access a file would be in the case
of unknown SIDs in the user's token. Do we have a problem resolving
these SIDs?
If it is just a permission problem querying AD I'd say we should just
make sure the admins give enough access to the samba computer account so
that it can resolve them. If they are not willing to do so, well then
they will not get those SIDs.
Is there any other common case where we can find unknown SIDs in a user
token and that we cannot resolve?

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org