ctdb in autobuild broken -- ctdb depends on winbind now????

[Alexander Bokovoy]

On ma, 09 tammi 2017, Rowland Penny wrote:
> On Mon, 9 Jan 2017 18:58:08 +0100
> Michael Adam <obnox at samba.org> wrote:
> 
> > On 2017-01-09 at 17:50 +0100, Andreas Schneider wrote:
> > > On Monday, 9 January 2017 17:30:52 CET Michael Adam wrote:
> > > > On 2017-01-09 at 14:08 +0100, Andreas Schneider wrote:
> > > > > On Friday, 6 January 2017 11:53:16 CET Volker Lendecke wrote:
> > > > > > Quick update: If I run
> > > > > > 
> > > > > > make test TESTS=samba.blackbox.wbinfo
> > > > > > 
> > > > > > locally, I get two unexpected successes.
> > > > > > 
> > > > > > Some tests are designed to fail and now succeed when running
> > > > > > isolated. Some tests are designed to succeed and now fail
> > > > > > when running in the full run.
> > > > > > 
> > > > > > If I look at selftest/knownfail, I see
> > > > > > 
> > > > > > # These do not work against winbindd in member mode for
> > > > > > unknown reasons
> > > > > 
> > > > > Yes, that the test running against the s4member target. I don't
> > > > > really know
> > > > > what a s4member is or means. However it seems to be broken!
> > > > > 
> > > > > $ bin/wbinfo --user-groups "SAMBADOMAIN/administrator"
> > > > > 3000000
> > > > > 3000001
> > > > > $ bin/wbinfo --gid-to-sid 3000000
> > > > > S-1-5-21-2767970802-1178991037-3063653489-500
> > > 
> > > Here is the gid to sid
> > 
> > Oh, ok, missed it. :-)
> > 
> > > > > $ bin/wbinfo --sid-to-name
> > > > > S-1-5-21-2767970802-1178991037-3063653489-500
> > > > > SAMBADOMAIN/administrator 1 $ bin/wbinfo -g
> > > > > SAMBADOMAIN/allowed rodc password replication group
> > > > > SAMBADOMAIN/enterprise read-only domain controllers
> > > > > SAMBADOMAIN/denied rodc password replication group
> > > > > SAMBADOMAIN/read-only domain controllers
> > > > > SAMBADOMAIN/group policy creator owners
> > > > > SAMBADOMAIN/ras and ias servers
> > > > > SAMBADOMAIN/domain controllers
> > > > > SAMBADOMAIN/enterprise admins
> > > > > SAMBADOMAIN/domain computers
> > > > > SAMBADOMAIN/cert publishers
> > > > > SAMBADOMAIN/dnsupdateproxy
> > > > > SAMBADOMAIN/domain admins
> > > > > SAMBADOMAIN/domain guests
> > > > > SAMBADOMAIN/schema admins
> > > > > SAMBADOMAIN/domain users
> > > > > SAMBADOMAIN/dnsadmins
> > > > > $ bin/wbinfo --name-to-sid "SAMBADOMAIN/administrator"
> > > > > S-1-5-21-2767970802-1178991037-3063653489-500 SID_USER (1)
> > > 
> > > 
> > > This sid is a user sid ...
> > 
> > Sure. No problem with that per se. (ID_TYPE_BOTH ...)
> > 
> > > > > $ bin/wbinfo --user-groups "SAMBADOMAIN/administrator"
> > > > > 
> > > > > lists 300000, which is the uid from Administrtor, as a gid!
> > > > 
> > > > Yes? I don't thing this per se is a problem...
> > > > 
> > > > The same numerical value can be used both for a UID
> > > > and a GID in a unix system. (On most Linux distros
> > > > you get a Group of the same nam and ID value as the
> > > > default group for a newly created user...)
> > > > 
> > > > Above you showed that the admin user (ID 300000) has a
> > > > group of GID 300000 in its unix group list. But this could
> > > > even resolve to one of the domain groups (like domain admins).
> > > > (WHat does "wbinfo --gid-to-sid 300000" give?
> > > 
> > > A USER_SID, see above ...
> > 
> > Sure. Not per se a problem (ID_TYPE_BOTH...)
> > 
> > > > This could also be sambadomain/administrator, viewed as
> > > > a group in the unix world. Wih the ID_TYPE_BOTH mapping
> > > > this can even be achieved in Samba. And i think this
> > > > may be quite normal in the AD/DC setup (with passdb_dsdb
> > > > and most id mapping going though passdb..).
> > > 
> > > 
> > > > Let me ask again: Is this a problem?
> > > 
> > > I dunno, the test tells us that before this test was expected to
> > > fail. Now the test returns the uid of Administrator and the GID of
> > > Domain Users. We do not have a Group name Administrator. At least I
> > > don't see one in 'wbinfo -g'
> > 
> > Well, with id_type_both in place, we may well virtually have a
> > group named administrator in place.
> > 
> > > > You pasted some output of wbinfo --user-groups that came
> > > > unexpected to you, but is it really breaking anything?
> > > > I think this is expected in the AD environment.
> > > 
> > > I do not expect a uid to be returned if I ask for gids ...
> > 
> > Well, in Samba, sometimes yo do. :-)
> > 
> > The reason for all this is that windows can set GROUPS as
> > owners (owning USER) on files. Unix can't do that. The second
> > case is SID history, where the user has more user SIDs in his
> > token. Converting User SIDs to UIDs for supplementary groups
> > fails. So for both cases, Samba can with the help of the
> > ID_TYPE_BOTH mode of mapping, create unix groups associated
> > to a USER SID (and visa versa). We implemented this for
> > source3 (idmap_rid/idmap_autorid) a few years ago.
> > And the passdb mapping for samba4 can also do it,
> > ID_TYPE_BOTH comes from the samba4 id mapping.
> > (Where it was important for the ACLS on the sysvol share
> > from day 1.)
> > 
> > This may be confusing if you were not aware, but there is
> > nothing wrong about it. It is also nicely integrated with
> > nsswitch: you'll see a group Administrator of the same
> > ID as the user Administrator, and the only member of this
> > group is the user Administrator. This is at least how it was
> > designed.
> 
> if you get a group called 'Administrator from 'getent group
> Administrator', you are doing something wrong ;-)
No, you are not. This is called 'user private groups' and is supported
by other software as well -- FreeIPA defaults to this mode, actually.
When new user is added, a corresponding group is added as well, visible
on the nss level as the group with the same name and the same gid as
user's uid.

-- 
/ Alexander Bokovoy