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?