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:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy