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