Major FUD (was Re: Add root drive mapping to default config file)B

[Todd Vierling]

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....

-- 
-- Todd Vierling <tv at pobox.com>