Wine and Sambe (was: Re: RFC: Wine and PAM integration)

[Steve Langasek]

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