On Tue, 3 Jun 2003, Jeff Smith wrote:
: BTW, Todd, I hope when I posted the URL to the article puoti had : mentioned, that you did not think the opinions expressed in that article : were by any means my own. Perhaps I should have made a disclaimer. :-/
Heh, I didn't imply that at all. When I referred to the article writer as a "poor sap" for allowing random foreign machine code to execute (thus inviting in trojans), it meant nothing towards you. 8-)
: As for using it in the wine config tool, I thought it was going to be a : winelib app, as opposed to pure win32. With a winelib app, wouldn't you be : able to read the file in with *nix calls?
Well, yes, but winelib + native libc is its own ball of hair, because not all the world's a glibc2. In other words, when using native libc plus winelib, you have to deal with host Unix OS dependencies again, *and* ensure that those dependencies don't somehow hose Wine too.
Either 100% native or 100% msvcrt seem better to me, so as not to try to do the funny walk by mixing them. (I'm not in charge of such an app, though, so it's not my call to make.)
: Finally, on the security (non) issue, a virus designed with wine in mind (that : phrase is fun to say) could get privileges to / if ${HOME} is already mapped. : Try this: 'notepad "F:.wine\config"', where F is what ${HOME} is mapped to, : and then use your imagination.
Not just that. A virus could easily do direct traps to invoke i386 syscalls, for which at least open(2), read(2), and write(2) have very similar semantics (and syscall numbers!) between the available x86 Unix implementations. Even execve(2) is the same between a couple different types of Unix-like host OS's.
All this doesn't even address the fact that Winelib apps (say, a virus), can access native system shared libraries. A quick call to dlopen(3) followed by dlsym(3) and....