RFC on Base Wine Config

[Paul TBBle Hampson]

On Sun, May 03, 2009 at 08:54:32PM +1000, Ben Klein wrote:
> 2009/5/3 Paul TBBle Hampson <Paul.Hampson at pobox.com>:
>> On Sun, May 03, 2009 at 03:07:35PM +1000, Ben Klein wrote:
>>> It's NOT a networked drive, is it? Drive mappings are the only way to
>>> tell Wine and apps running in Wine where your files are in your
>>> host-system (Unix-style) filesystem.

>> The discussion on wine-devel in April related to bug 15883 suggested the
>> implementation of \\?\unix\ which would in turn allow programs access to
>> things that aren't mapped in the DosDevices list, unless specifically
>> disallowed (which wasn't discussed at the time)

>> A quick look at [1] suggests that \\?\unix\etc/hostname would seem to be
>> a reasonable thing to expect to work under Wine.

> But that requires either
> 1) the app to be aware of \\?\unix, or

This would be rather badly broken. The point of \\?\ is that apps (and
in fact the Win32 API) doesn't parse such paths, but passes them on to
the filesystem.

> 2) Wine to map \\?\unix/foo/bar when no drive mapping to /foo/bar exists.

The _point_ is that if Wine sees a \\?\unix/foo/bar path, it operates
upon the file at /foo/bar, irrespective of the drive mappings.

> #2 would also require some way to be configured to allow the
> equivalent of removing the default Z: drive mapping for people who
> want it. However, it would not provide any additional functionality
> and could easily be considered a waste of time. Of course, that's not
> up to me ;)

The point of \\?\unix is not to add functionality, it's to allow
removal of current functionality, specifically the magic recognition of
"/x/y" as a unix path instead of "X:/x/y" with X as the drive of the
current working directory, in order to fix bug 15883.

>>> Note that it would be a breach of security to allow some method to
>>> access / without a direct mapping in dosdevices.

>> How so? I'm fairly sure this suggestion was dismissed in the
>> above-mentioned email discussions as well.

> AFAIK, the main reason people remove the Z: mapping is a security
> concern. It's not an issue for me, but some people like to restrict
> the files that win32 apps can access to a subdirectory in $HOME. If
> there's some workaround to access files outside the drive mapping
> (assuming pure win32 of course :D ), then unless it can be disabled by
> the user, it's a security breach.

The point made as I recall it in the earlier thread is that this is a
false sense of security, and that apps can already get outside the drive
mappings for filesystem access.

I don't know how, but that was the point that was made.

Off the top of my head, there's Win32 APIs that let you enumerate and
map physical disk devices to DOS drive letters. So you could just readd
Z:\ in your app if you wanted.

Frankly I would like to break that illusion of security by providing
\\?\unix, if I find the time. (The hard part is identifying all the
parts of Wine that use the '/' recognition to function)

-- 
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
Very-later-year Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson at Pobox.com

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Marcus Brigstocke
http://www.marcusbrigstocke.com/pacman.asp

License: http://creativecommons.org/licenses/by/2.5/au/
-----------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20090503/3f7b2ba1/attachment.pgp>