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

[simo]

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

It is crazy indeed :)

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

Make sense indeed.

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

Well, on this, with regard to ACEs, I disagree.
Windows have SIDs, which have no "sex". it doesn't matter if they are
users or groups or something else at all, and this is the key difference
that bites us.

Said that, I want to see a decent solution of course, which I think can
even be to accept there is nothing we can do with some unknown SIDs.

>  > 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' !

I know that perfectly. Still you can't really have an ACL mapping
working perfectly if you don't know what a SID is (exp if there are DENY
ACEs involved).

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

Imho, this make sense only if the other program has the control of the
SID to UID/GID mapping, or at least shares the control with Samba.
In such a case I hope there will be a way to tell back samba what the
mapping is, or the two will not work well together at all.

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

This makes perfectly sense, I am not questioning the way ACL models work
or how to use them.

The problem I put on the table is: how do you avoid depletion of the
UID/GID space by malicious users?

If you can solve this problem I think what you described is the natural
way to solve the problem, and I'll support your plan 100%.
But each time we discussed this in the past we never got to the point of
solving the DoS problem.
That's why Samba 3 by default deny any mapping for unknown SIDs, and
this should not be changed until we solve the little nasty detail of the
DoS.

Simo.

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