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

Martin Wilck 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

-- 
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 mailing list