Wine on OLPC

Ove Kaaven ovek at arcticnet.no
Sat Apr 12 10:19:37 CDT 2008


Benjamin M. Schwartz skrev:
> I'm particularly surprised because I cannot imagine any reasonable
> scenario in which allowing non-root users to run in .wine/ directories
> that they do not own is a security risk.  There is no privilege escalation
> here; the non-root user is still required by the kernel to operate within
> the bounds of posix permissions.

That's not quite correct. If user B can run user A's installation of 
Wine, then user B can easily install some script or program that gets 
executed automatically (wineboot) the next time user A runs Wine; from 
there, user B can gain unlimited access to user A's account. (Or, 
perhaps, vice versa.)

I think that's not really the point of the check, though. Perhaps more 
problematic is probably that if user B runs user A's Wine, then files 
written (registry included) might become owned by B, with the result 
that next time user A wants to start Wine, it can't access them. (The 
most frequent problem here is the one when user B called "root", but not 
necessarily.)

And of course, if user A and user B happens to run Wine 
*simultaneously*, they're going to overwrite each other's files and end 
up with a broken Wine installation.

> I need the ability to run in profiles as a user who is not the "owner" of
> the files on disk.  I am doing this quite specifically because, in my
> case, this greatly _increases_ the security of the system.

You have a poor understanding of Unix security if you think it's good 
that files and whatever uses them are on different accounts, and if you 
think making a (fake) Windows installation publicly accessible (and 
modifiable) by every other user on the system can possibly be called secure.

I'm not sure why you even need to. If you're running Wine as a different 
user, why shouldn't that different user own its own .wine/ directory?





More information about the wine-devel mailing list