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

Michael Adam obnox at samba.org
Mon Jan 9 20:44:42 UTC 2017


On 2017-01-09 at 18:31 +0000, 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, it's fully correct.
Please read the explanations above.
This originated in the AD part of Samba, btw, because
we need to set groups as owning users and visa versa
because Windows does it. This has been implicitly in
the samba4 ad/dc from early days, iirc. But it may
not have shown up in nsswitch initially. By virtue
of the work in winbindd, it is now also properly
reflected in the output.

As Alexander explained, this just mimicks the pattern
where a unix user automatically gets its own primary
group of same name and numerical id when it is created...

So why is this so surprising and surprising?
Probably because in Windows or the AD database, this
object has an explicit classification as a user or
group object. True, but it can be used in places
where the corresponding mapped unix objct (user/group)
can NOT be used. So we needed to map a windows object
to both....

Hope this makes it more clear.

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/1bbcf80d/signature.sig>


More information about the samba-technical mailing list