[RFC] adding a fixed gid to the unix process token in smbd and other servers

[Uri Simchoni]

Hi Stefan,

Thanks for looking at this!

On Wed, Jul 22, 2015 at 12:24 AM, Stefan (metze) Metzmacher
<metze at samba.org> wrote:
> Hi Uri,
>
>
> I really don't understand why we want a new option in order to specify some
> by hand.
>

The winbindd option's purpose is that the default would remain the
same (i.e. not add any SID locally).
- I could just change winbindd's behavior to always add S-1-1-0 to the
SID list of a user, and rely on the SID->GID mapping to maintain
backward compatibility (i.e. if S-1-1-0->gid exists, add that gid,
otherwise result is like before). However I cannot be certain that
this has zero effect (e.g. in terms of latency - doing another
translation) and also if someone has a mapping he would get different
results by surprise. Hence the reason for making this configurable for
winbindd.
- Next, it could be just a boolean flag - "winbind add everyone". But
I figured that since smbd adds more SIDs it might be more useful to
specify a list of SIDs.

> I think this needs a bit more thinking and should also be useful on
> a domain controller.
>

It seems to me that the current behavior is to make the addition of
builtin/wellknown SIDs a local decision, at the file server. For
example, Windows DCs (and perhaps also Samba) return BUILTIN\Users and
optionally BUILTIN\Administrators in reply to the ldap tokenGroups
query, but we filter those locally (see sid_check_is_in_builtin() call
from lookup_usergroups(), winbindd_ads.c).

> I think this somehow needs to work without adding group mappings.
>

The goal here is to come up with a UNIX gid that we can add to the
smbd process token and to the result of getgrouplist(). We could just
define an "everyone gid" parameter, but this parameter would have no
accompanying SID and I don't know what the current and future
implications are. It seemed more streamlined to add a SID (which is
already done by smbd) and then to translate it like all other sids.

The local group mapping (net groupmap add) is the mechanism for
wellknown and builtin SID->gid translations in many configurations
(read: idmapping/pdb combinations). I may have been misleading by
saying that using group mapping is mandatory - This can certainly work
with other, more central mechanisms, as long as SID->gid works for
S-1-1-0 SID (see more on that below).

> How does that belong to pdb_is_responsible_for_wellknown() and
> pdb_is_responsible_for_everything_else()?
>

The connection is in the SID->gid mapping.
pdb_is_responsible_for_wellknown() is blocking the translation in many
code paths that could otherwise work:

1. idmap_find_domain_with_sid() may decide that this is domain should
be translated by PDB backend, and hand it over to passdb id-mapper. It
doesn't happen if pdb_is_responsible_for_wellknown() returns false.
2. For S-1-1-0, which has "" as its domain name, the default id mapper
is used if idmap_find_domain_with_sid() didn't divert this to passdb
already. That default id mapper may or may not successfully translate
S-1-1-0. The directory-based mappers are not in scope for my
application although they could work in other setups. Of the local
mappers (rid, tdb, passdb), passdb seem like best option because rid
is algorithmic (cannot freely assign unix gid to sids) and tdb can
allocate gids but not configure them. Passdb is db-based and can
configure the mapping.
3. But even if the default id-mapper is passdb, this still doesn't
work because pdb_is_responsible_for_wellknown() is consulted again
inside the passdb id mapper.

This explains why my specific application would want
pdb_is_responsible_for_wellknown() to return true. The reason I just
changed the default to accomplish that is that I it seems like a more
logical default to me - I see no reason why pdb would handle builtin
by default and would not handle wellknown (again, there may be some
reason I'm missing). For example, if we change the default to true,
then PDB's default SID->xid method (pdb_default_sid_to_id) is treating
wellknown and builtin in the same way.

> metze
>