Wine and Sambe (was: Re: RFC: Wine and PAM integration)
Martin.Wilck at Fujitsu-Siemens.com
Thu Sep 26 07:30:31 CDT 2002
Am Don, 2002-09-26 um 00.01 schrieb Steve Langasek:
> 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.
Forgive me, I'm pretty dumb when it comes to character sets. If I
understand you right, UTF-8 will pass intact through a
non-character-set-aware communication layer (i.e. one that handles
strings with standard C library functions such as strlen()).
> 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.
I agree. Wine itself shouln't be able to change uid. Even if Wine
implemented a perfect authorization mechanism for the respective wine
"system calls", someone could build a winelib DLL with direct setuid()
calls that would succeed if the Wine process loading the DLL had the
SUID capability. Sounds evil.
> 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
That's not much better than having Wine suid root in the first place :)
> 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).
Most processes will be started from within wine by opening the file and
jumping to its entry point - suid bits on the files won't help a lot in
that context, unless wine is able to change personality.
Imagine some server that requires a user to log in and carries out
something on that user's behalf, with his credentials.
Honestly, I have no idea how something like that could be achieved
without severely compromising system security. Perhaps it would be
possible to design a small, easy-to-audit helper tool that would be
started by wine in such a case to check the credentials again and
start a new wine process; something in the spirit of sudo.
In any case, IMO wine should rather not support this at all than
compromise the host system.
> 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.
Thanks, I'll have a look into that.
Martin Wilck Phone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck at Fujitsu-Siemens.com
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
More information about the wine-devel