wineserver socket file and DOS attacks

[Steven Elliott]

I have some concerns about the location of the socket file that
wineserver uses.  Since by default the current location is in /tmp my
concern is that anyone can stop anyone else from using wine just by
creating a directory named /tmp/.wine-500.  

As far as I know the only risk is denial of service in nature since wine
seems to be smart enough to make sure the /tmp/.wine-500 is owned by the
user invoking the wine application:
    > notepad 
    wineserver: /tmp/.wine-500 is not owned by you

Previously the socket file was under ~/.wine.  I found this which
briefly documents the change here:
    http://www.winehq.org/site/docs/winedev-guide/x2584
under section "7.3.2. The Wine server" it says:

"In earlier versions of Wine the master socket mentioned above was
actually created in the configuration directory; either your home
directory's /wine subdirectory or wherever the WINEPREFIX environment
variable points. Since that might not be possible the socket is actually
created within the /tmp directory with a name that reflects the
configuration directory."

/tmp/.wine-<user Id> is hard coded in libs/wine/config.c, so that aspect
of the socket file location is not configurable.

Anyway, have alternatives such as the following been considered?:

1) Create the socket file in ~/.wine (or wherever WINEPREFIX points)
like wine used to if the user's home directory exists and is writable.
Use /tmp/.wine-<user Id> as a fallback.

2) Append some additional integer to /tmp/.wine-<user Id> that is
incremented if that directory already exists and is owned by someone
else.  For example,  if /tmp/.wine-500 already exists for user 500 but
is owned by someone else then both wineserver and the wine application
would append "-1" and then keep incrementing:
    /tmp/.wine-500
    /tmp/.wine-500-1
    /tmp/.wine-500-2
until they each found a directory owned by the current user (or until
they are able to create one).  Hopefully they would pick the same
directory.  I need to think more about how robust this would be.

-- 
-----------------------------------------------------------------------
|          Steven Elliott          |      selliott4 at austin.rr.com     |
-----------------------------------------------------------------------