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

[simo]

On Wed, 2006-10-25 at 07:21 +1000, tridge at samba.org wrote:
> Volker,
> 
>  > That's indeed a very good question, and in fact this is
>  > another argument for winbind to always allocate both a uid
>  > and a gid whenever a unix id is needed.
> 
> I've been thinking about doing this for sidmap in Samba4, and it
> certainly does make some thing easier, but doesn't completely solve
> the problem.
> 
> Say you allocate both a uid and a gid to a SID, and then create a ACL
> based on that. If you are using either posix ACLs or NFS4 ACLs then
> the ACL format on disk is different depending on whether the id is a
> gid or a uid. So you have to pick one or the other at the point at
> which you map the internal NT ACL to a on-disk ACL. If you later
> discover that you've picked the wrong type, then in theory you would
> need to scan the entire disk (and all backups!) for any file that has
> it wrong, and 'fix' it. Not very practical :(

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 still think the idea of creating both a uid and a gid for a SID of
> unknown type is worth considering, we just need to try to come up with
> something that minimises the impact of getting it wrong.
> 
> The best thing I have thought of so far is this:
> 
>  - create both a uid and a gid for SIDs of unknown type

What about creating them both always for all SIDs?

>  - when saving an ACL in a format that needs to know which it is, then
>    for owner_sid field pick uid, for group_sid field pick gid, and for
>    ACEs store both a uid based ACE and a gid based ACE, both of which
>    map to the same SID.

This is exactly what I'd like to see (and I can't think of anything
better).

>  - once we know which type the SID is, update the sidmap database to
>    flag which type it is, but also keep in the database the 'wrong'
>    mapping, keeping the incorrect gid or uid reserved.

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

>  - when reading in an ACL from disk and doing the reverse mapping
>    (uid/gid to SID) the mapping will look in the sidmap database, and
>    if it comes across an entry which has now been flagged to indicate
>    that the ACL had the wrong type then fix the ACL on disk by
>    removing the incorrect ACE.
> 
>  - for ACLs where we find that the 'owner' is really a group, or where
>    the 'group_sid' is really a user, then keep using the reserved
>    uid/gid of the wrong type. This isn't ideal, but I can't see a way
>    to avoid it. At least it allows us to correctly map to NT ACLs.
> 
> It's not ideal as incorrect ACLs are only fixed when Samba accesses
> them, but by keeping the incorrect uid or gid reserved we minimise the
> risk of incorrect behaviour. 

We could make uid==gid the rule and solve the problem (at least for
appliances and winbindd only consumers. We will have to support uid !=
gid for other uses (existing servers or users provided not by winbindd).

> The keys to this system are:
> 
>  - reserve both a uid and a gid for SIDs of unknown type
>  - keep them both reserved even after we know the real type
>  - use duplicate ACEs in mapped ACLs for posix and NFS4 ACLs where the
>    SID has an unknown type
>  - remove the duplicate ACE when we come across the file and we have
>    resolved what type the SID really is

The only problem I see in this schema is how to decide when to map an
unknown SID. We risk too much a DoS if we don't accept only verifiable
SIDs. 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.

Simo.

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