On Mon, 2002-09-23, 11.28, I wrote:
It seems it is better to ingegrate Wine with each protocol individually - implement PAM-like architecture inside Wine, but this architecture will provide much more information to Wine.
No, please - let's not reinvent the wheel!
I have been thinking about this a bit further - perhaps I was wrong in the first place.
There are two aspects I neglected:
* NT security and NETAPI have a broader scope than PAM + NSS combined. * Unicode.
What we discussed so far were user authentification and user/group/hostname lookups. Of course, this is only a small subset of the NETAPI interface.
winbindd itself can do more, for example lookup a user SID on the remote server. Even more functionality would be available by linking directly against the Samba library libsmbclient.so, but we can't do that due to license issues.
Perhaps we should think about an extended winbindd that would follow similar lines as the current Samba winbindd (talk to Unix Apps through a Unix domain socket), but offer even more functionality that isn't implemented in winbind because the information passed by such calls makes no sense to Unix applications.
AFAICS, winbind does not expect applications to pass Unicode strings for user names, domain names, etc., either. Our winbindd replacement would need to be able to handle that, too; otherwise we wouldn't be able to pass Unicode strings from a Windows application to a Windows server without corruption.
The winbindd replacement would need to be GPLd in order to link against Samba libraries.
That way wine would be able to use the existing samba functionality. If we had such a daemon, we could to reconsider the PAM and NSS routes because these probably won't be Unicode aware for some time to come (correct me if I'm wrong).
Of course, we might as well try to convince the Samba team to offer more functionality through winbindd itself, or submit patches for winbindd to them.
Martin