http://bugs.winehq.org/show_bug.cgi?id=25537
--- Comment #3 from Artem S. Tashkinov t.artem@mailcity.com 2010-12-16 15:13:45 CST --- (In reply to comment #2)
There has never been any such security measure.
Pardon me, Julliard, but Wine _used to_ allow access to filesystems via configured dosdevices and Z: was the only way for Wine applications to access root fs.
Right now Wine exports "/" right on the desktop, thus negating the ability of denying Windows applications access to /.
If it wasn't a security measure then I'm fine with it.
However I'm eager to get any substitute of what was once available.
(In reply to comment #1)
(In reply to comment #0)
Probably since 1.3.8 or 1.3.9 any Windows application can open (read/write/list/erase) any files in / (root) regardless user defined disk devices (under ~/.wine/dosdevices).
I can't reproduce this behavior for normal Win32 file accesses with a clean Wine prefix after running winetricks sandbox, which removes the z: symlink and a few others.
Yes, I'm sorry. Even though / link on the desktop exists Wine doesn't allow to read files from /. OK. However the fact that Windows application can even list files under / is still a security weakness.
It's a huge security issue, because in the past you could erase z: -> / symbolic link and safely run any software (including malware).
Removing the z: symlink provides only illusory security benefits, as http://wiki.winehq.org/FAQ#head-3cb8f054b33a63be30f98a1b6225d74e305a0459 discusses.
This security measure has been removed without any explanations how to harden your Wine PREFIX.
Wine wiki states that:
Consider removing the default Wine Z: drive, which maps to the unix root directory. This is only a weak defense, but it might help against some attacks.
However I don't see any explanation as to why it's a weak defense. It's a perfect defense, because unless wine server allows hijacking its own code via direct memory access, no Wine application can leave the limits of predefined desdevices.
OK, it seems like everyone disagrees with my arguments, so let's abandon this feature.