This is a discussion on Re: samba pipe? - Samba ; Volker, > Agreed. But doing the ntlm(2?) bind with the machine account is ok? IIRC this > can't be done in the windows world, but I think samba could implement this > without the need for kerberos I think. I'll ...
> Agreed. But doing the ntlm(2?) bind with the machine account is ok? IIRC this
> can't be done in the windows world, but I think samba could implement this
> without the need for kerberos I think.
I'll leave it up to abartlet and you to work out - I'm just flagging
that allowing anonymous access to this is not good.
> Better. But for the uid2sid I would like to use a pointer to be able to return
> NULL in case of an error.
for [out] parameters that makes total sense. My comments applied to
[in] parameters where a NULL input makes no sense.
> > Next, what about systems with uids larger than 32 bits? I'd suggest using a
> > hyper now, so that if two systems with large uid_t are talking to each other
> > we don't lose information.
> What should be the semantics of this? sid2uid returns >2^32, what should the
> client do? Return an error? Include another level of mapping? The whole point
> of this pipe is to avoid this kind of mapping.
if we went by your argument you better make it 16 bit, as many systems
have 16 bit uid_t :-)
Interfaces like these should not decide how the client will handle
things if the server gives something beyond its capabilities. The
interface should be capable of handling the largest reasonable size
(in this case 64 bit), and the client consumer code should worry about
the details of what to do if its out of range.
The obvious thing a client would do is to return an nss error for
those users that are out of its capabilities. But for those clients
that _do_ support 64 bit uids, it would all work well.
> After getting that right I can see obvious optimizations, like metze's
> suggestion. Or remoting getpwent/getgrent.
this interface seems like the perfect way to solve the long standing
problem of not getting the primary group right in getpwent() when
using the RPC backend in winbindd. There is no RPC call that can do
that efficiently at the moment (you'd need 1 rpc call per
user). Something that takes an array of uid's and returns an array of
gid's (the primary group ids) would be good.