Wine on OLPC
Benjamin M. Schwartz
bmschwar at fas.harvard.edu
Sat Apr 12 10:37:07 CDT 2008
-----BEGIN PGP SIGNED MESSAGE-----
Ove Kaaven wrote:
| 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.)
My home directory is not world-writable. Is yours?
| 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
This only works if one user is root; otherwise (under any normal unix
permissions setup) multiple users do not have write access to each other's
| 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.
That is definitely an interesting problem, as noted in the very
comprehensive bug #11112. The suggested solution of introducing a
lockfile does seem appropriate; it's how every other unix application
solves this problem. In my case, I have external mechanisms to ensure
that multiple instances of wine are never running simultaneously.
|> 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 afraid there is not space here to describe the Rainbow security
system. However, I am operating in a special environment in which the
system has a single human user, and unix uid's have been repurposed to
provide software isolation. I am not, in fact, suggesting making .wine/
publicly accessible. I am actually using "chmod g+rwx" to make .wine/
available to a particular application, because each application has a
unique gid. Also, Rainbow uses namespaced bindmounts in such a way that
applications not running with the gid in question cannot even determine
that this .wine/ directory exists.
| 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?
Rainbow works by generating a new uid every time an application is
launched. Therefore, the second time the same human runs a wine-based
program, it runs under a different uid. In order to provide continuity of
state, I need to be able to run in a permanent .wine/ despite having a uid
that is constantly changing.
Bug #11112 suggests that it may be possible to solve this problem using
dynamically generated symlinks. I will try that.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the wine-devel