samba - Jun 2022 - protocol between pam/nss & winbindd

Hi!

Is the (local) protocol between pam_winbind, nss_winbind
and winbindd architecture-agnostic, like, using network
types and network byte order, or is it architecture-dependent?

I mean, for example, on a bi-arch machine (i386 & x86_64), will
single winbindd serve both 32 and 64 bit clients fine?

Will it work if I run, say, armhf binary with armhf nss_winbind
on the same machine with qemu-user-arm emulation, - will x86_64
winbindd understand armhf client and reply to it correctly?

Thanks,

/mjt

On Wed, 2022-06-01 at 12:11 +0300, Michael Tokarev via samba
wrote:
> Hi!
> 
> Is the (local) protocol between pam_winbind, nss_winbind
> and winbindd architecture-agnostic, like, using network
> types and network byte order, or is it architecture-dependent?
> 
> I mean, for example, on a bi-arch machine (i386 & x86_64), will
> single winbindd serve both 32 and 64 bit clients fine?
> 
> Will it work if I run, say, armhf binary with armhf nss_winbind
> on the same machine with qemu-user-arm emulation, - will x86_64
> winbindd understand armhf client and reply to it correctly?
> 
> Thanks,
> 
> /mjt
I take it that you mean, will a Linux x86_64 client work against a
Samba AD DC running on something like an rpi (or the other way around),
if so, then yes, it works.

Rowland

Hi Michael,

Your question is perfectly clear to me. I'm no expert, but I believe
the local winbind protocol is bitness-agnostic, but uses "host-native"
byte order. I took a look through the code, and this is what I found:

pam_winbind [1] links against libwbclient [2] (libwbclient.so.0 on
Debian). The winbind request protocol is defined by "struct
winbindd_request" [3] which has this big warning:

    This structure MUST be the same size in the 32bit and 64bit builds
    for compatibility between /lib64/libnss_winbind.so and
    /lib/libnss_winbind.so

    DO NOT CHANGE THIS STRUCTURE WITHOUT TESTING THE 32BIT NSS LIB
    AGAINST A 64BIT WINBINDD    --jerry

Jerry sounds pretty serious about 32 / 64 bit compatibility!

What I don't see, however, are any ntoh[sl] or hton[sl] calls, or
comments about byteorder. winbindd_init_request() sets integer fields
directly. [4]

This is not at all surprising; I'm not aware of any UNIX socket
protocols that bother with byte order, because it is assumed that
you'll always be talking to a process on the same host which must use
the same byte order -- except for your interesting, but somewhat
contrived example of emulating a processor that uses a different byte
order. Fortunately, ARMv7 and x86 are both little-endian, so that
shouldn't be a problem for you.

Good luck! Hope this helps.

Jonathon

[1]:
https://gitlab.com/samba-team/samba/-/blob/samba-4.9.5/nsswitch/pam_winbind.c
[2]: https://gitlab.com/samba-team/samba/-/tree/samba-4.9.5/nsswitch/libwbclient
[3]:
https://gitlab.com/samba-team/samba/-/blob/samba-4.9.5/nsswitch/winbind_struct_protocol.h#L236-244
[4]:
https://gitlab.com/samba-team/samba/-/blob/samba-4.9.5/nsswitch/wb_common.c#L59-62



On Wed, Jun 1, 2022 at 5:12 AM Michael Tokarev via samba
<samba at lists.samba.org> wrote:
>
> Hi!
>
> Is the (local) protocol between pam_winbind, nss_winbind
> and winbindd architecture-agnostic, like, using network
> types and network byte order, or is it architecture-dependent?
>
> I mean, for example, on a bi-arch machine (i386 & x86_64), will
> single winbindd serve both 32 and 64 bit clients fine?
>
> Will it work if I run, say, armhf binary with armhf nss_winbind
> on the same machine with qemu-user-arm emulation, - will x86_64
> winbindd understand armhf client and reply to it correctly?
>
> Thanks,
>
> /mjt
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba