-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 | necessarily.)
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 .wine/ directories.
| | 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.
See http://wiki.laptop.org/go/Rainbow
| | 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.
- --Ben