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