Am Mit, 2002-09-25 um 03.43 schrieb Steve Langasek:
Er, um... PAM and NSS will *never* be Unicode-aware. There's no reason for either of these APIs to care about the character set of the input values (though individual modules may have reasons to care).
Can't follow you: if some modules do care, the core PAM/NSS must handle the character sets somehow in order to pass strings right, or not?
And if you mean UCS2-capable, don't expect for that to happen, either: Unix already has a standard Unicode encoding, and it supports all 32-bits of the codepoint space and does so without breaking traditional C string handling, thankyouverymuch.
If these tools properly supported ISO10646, UTF-8, or equivalent, we'd be set.
Regardless, I agree that PAM and NSS are probably not what you're looking for. What you're probably *really* looking for is a complete DCE/RPC implementation for Unix, of the sort that dcerpc.org aims to provide. I know from talking with some of the Samba-TNG developers that they, at least, are eager for Wine to work with them to standardize on a common set of RPC implementations. :)
What I am _not_ looking for is Wine working around Unix security mechanisms. Even if Wine had a well-designed, well-tested internal security mechanism (which isn't the case AFAICT) this would mean running Wine on any Unix system would be dangerous. Thus proper use of PAM is IMO mandatory. If we loose out on character set support, bad luck for some environments, but no reason to have an independent security authority on a Unix system.
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.
Not what winbindd is meant for, really.
winbind makes a small subset of Windows RPC calls available to Unix applications. Windows applications running under Wine will make sense (and perhaps need) a larger subset of these calls. An interface like winbind's, using Samba libs internally, would be by far the easiest way for Wine to to offer this service to applications.
Certainly winbind wasn't written with Wine in mind. The question is not what winbind was meant for, but whether its authors would agree to widen its scope. If not, wine must go a different route, e.g. by writing a compatible replacement (aka "winebind" :-).
Martin