On Thu, 2008-05-01 at 06:45 +0200, Ove Kaaven wrote:
Maarten Lankhorst skrev:
Wine checks ownership of the socket and directory, so race conditions aren't really a problem. This means that despite being put in a public directory there is no chance of a race condition. I don't see a security risk here, if someone is evil they could create that directory so wine wouldn't run, but that harm is only restricted to 'wine does not start'.
Which is exactly what the OP was concerned about.
You are correct that that is my concern.
I just want to say a few additional things about this and then I'll leave it be since I think I've made my point.
I've thought a little bit about how multiple directories could be used as a way working around the DOS attack (as I mentioned in my initial post). I think it is really hard to address every possible race condition (wineserver just starting up or shutting down as a new wine process is trying do decide which directory to use and or whether to start a new wineserver). I think Maarten touched on these race condition concerns with his "The latter won't work ..." email in this thread. To add to the confusion the /tmp directory on most Linux systems is subject to a cron job that deletes old files.
I think the only perfectly robust way of doing this that isn't vulnerable to either DOS attacks or race conditions is have a permanent directory for each user that wants to use wine that is both owned by that user and is writable so that the socket file can be placed in it. At one time this was ~/.wine. So, what if the socket file was moved back under WINEPREFIX (defaults to ~/.wine) combined with the following requirements for users that don't have writable home directories the first time wine is run for that user: 1) Some new directory is created for the user. 2) The new writable directory is chown'd to the user. 3) WINEPREFIX is set to point to the directory. 4) wineperfixcreate is run. /etc/rc.d/init.d provides various examples of services that are run as users that don't have writable home directories but that do require a one time setup. For example, if "foo" is some service that uses wine then /etc/rc.d/init.d/foo would create /var/lib/foos-wine-dir if it didn't exist and then apply the above steps.
You can also consider the SSH example where the ssh-agent process (analogous to wineserver) is started, some tempnam() like API is used to pick a random place for the socket file and then an environment variable (SSH_AUTH_SOCK) points to the socket file that must be inherited by each shell where SSH clients that want to talk to ssh-agent are used. But I've always thought having to deal with SSH_AUTH_SOCK was a pain (I know most distros set it for you when you are logged in at the console, which helps).
Maybe I'm making some bad assumptions about why the socket file can't be placed in ~/.wine (that not all users have a writable home directory). I'm guessing based on the snippet from my original post that includes "Since that might not be possible" in reference to placing the socket file under ~/.wine.
This made me curious what happens when ~/.wine is not writable. I did a "chattr +i" on the ~/.wine directory of an ordinary user in order to make every file immutable. Things pretty much work except wineserver complains when it exits that it can't write the registry changes to the *.reg files. And as one might expect the registry actually does not get updated. But other than that it kinda works.