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

Rowland Penny repenny241155 at gmail.com
Mon Jan 9 18:31:45 UTC 2017


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 ;-)

> 
> If now (with some winbind changes) this one test suddenly
> succeeds (and it failed before), does that mean that the
> changes fixed something for the AD case? So *why* was the
> test failing before? And is the appearance of the Administrator
> group the reason for it not failing any more? Or is that
> unrelated and just confusing?
> 
> Cheers - Michael

I still think that what is being tested should be removed.

Rowland



More information about the samba-technical mailing list