getpwnam/uid for group with ID_TYPE_BOTH

Stefan Metzmacher metze at samba.org
Mon Sep 23 21:43:35 UTC 2019


Hi Christof,

> The behavior of winbindd changed in regards to whether a group with
> ID_TYPE_BOTH returns a fake user structure. This surfaced during a test
> of creating files from a SMB client and then checking the ownership
> directly on the file system.
> 
> make testenv SELFTEST_TESTENV=ad_member_idmap_rid
> is an environment that provides ID_TYPE_BOTH for testing.
> 
> 4-5-test returns fake passwd information for the group:
> 
> $ getent passwd "$DOMAIN/Domain Users"
> ADDOMAIN/domain users:*:2000513:2000513::/home/ADDOMAIN/domain
> users:/bin/false
> $ echo $?
> 0
> 
> $ getent passwd 2000513
> ADDOMAIN/domain users:*:2000513:2000513::/home/ADDOMAIN/domain
> users:/bin/false
> $ echo $?
> 0
> 
> $ ls -l testfile
> -rw-rw-r--. 1 ADDOMAIN/domain users ADDOMAIN/domain admins 0 Sep 23
> 12:24 testfile
> 
> 
> 4-6-test no longer does this:
> 
> $ getent passwd "$DOMAIN/Domain Users"
> $ echo $?
> 2
> 
> $ getent passwd 2000513
> $ echo $?
> 2
> 
> $ ls -l testfile
> -rw-r--r--. 1 2000513 ADDOMAIN/domain admins 0 Sep 23 12:30 testfile
> 
> It looks like the behavior was introduced for Samba 4.5 through commit
> 394622ef8c916cf361f8596dba4664dc8d6bfc9e
>     s3:winbindd: change getpwsid() to return a passwd struct for a group
> sid id-mapped with ID_TYPE_BOTH
> 
> and then changed for Samba 4.6 through the patches around
> bce19a6efe11980933531f0349c8f5212419366a
>     winbind: Restructure wb_getpwsid
> 
> What is the intended behavior here? Returning a fake passwd for the
> group makes the "ls -l" output nicer as no manual lookup of the uid to
> the group is required. On the other hand, creating fake user information
> might cause problems elsewhere.
> 
> What are other's opinions around this? I am planning to add a testcase
> to ensure that this does not change again, but i would like to
> understand first whether winbindd should behave as in Samba 4.5 or in
> the newer releases.

The 4.5 behavior is what we want,
see also https://gitlab.com/samba-team/samba/merge_requests/621

We should fix merge that, could you come up with a simple testcase
to that we don't regress on this again?

Then we need a bug report for backports.

Thanks
metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20190923/0a005af5/signature.sig>


More information about the samba-technical mailing list