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

[Michael Adam]

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 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170109/de468a93/signature.sig>