On Wed, Sep 25, 2002 at 02:34:34PM +0200, Martin Wilck wrote:
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?
Example: nss_ldap and pam_ldap talk to servers which specify UTF-8 as the wire encoding. However, this doesn't require either PAM or NSS to care about encodings: we should either agree that all input strings are UTF-8, or that they're in the encoding of the current locale. I happen to favor using UTF-8 for everything, but it doesn't matter a whole lot: there just needs to be a convention. And if we say "strings use the current locale encoding", then anyone who needs to handle large chunks of Unicode from within Wine needs to be using a UTF-8 locale. This seems like a reasonable compromise to me, really: for Unix apps, it will definitely be the case that user input will be in the encoding of the current locale, and if they need more flexibility than that from Wine, all they need to do is change to a locale that supports what they want to do!
Most other PAM and NSS backends are not charset-aware, so for the most part having charset-aware APIs around them doesn't help you any, because you don't know what you have to change the encoding to for it to be useful! This is the case with NIS, password files, Kerberos (unfortunately!), and pretty much everything else except for LDAP and winbind.
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.
Since UTF-8 behaves exactly like any 8-bit locale wrt string handling, it's a complete pass-through for almost anything related to authentication. Again, the only things I know of that will need to deal with encodings at all are LDAP backends, winbind, and Wine itself.
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.
I happen to think that the suggestion tendered in this thread to give Wine suid capabilities is a much more serious case of "working around Unix security mechanisms" than not requiring Windows apps to use Unix authentication APIs would be. Giving Wine itself the capabilities to switch security contexts is equivalent to having an suid jvm: suid binaries should be small, carefully audited pieces of code, and I just don't see that as being realistic in the case of something as complex as a virtual machine. The more a user can ask an suid application to do for them, the greater the danger of a compromise -- and there are many things you can ask Wine to do for you! If Windows applications really need to be able to change security contexts, they should gain this privilege the same way as everything else: either you start the application as root, or you set the Windows binary itself suid root and you make sure the Linux kernel has the necessary hooks to confirm this when the application starts (binfmt_misc support should already imply this).
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" :-).
As noted in the thread on samba-technical, what you're really asking for is access to arbitrary DCE/RPC services; and you need to communicate with those services across pipes or sockets, because of the GPL. Cramming all of that into winbind really mucks up what winbind was written for in the first place. There is already a project underway at dcerpc.org that hopes to achieve what you're asking for. Samba's first and foremost goal is to provide file sharing and printer services, and everything else necessarily takes a back seat to that. I'm told Samba is moving away from its current monolithic architecture, but I expect it will be quite a while yet before this bears fruit. In contrast, the dcerpc.org developers have been hard at work for a couple of years now implementing stand-alone daemons for many of the RPC services Wine would use -- lsarpc, winreg, and spoolss among them.
Steve Langasek postmodern programmer