Just realised something ...

2009/2/10 Ben Klein <shackl...@gmail.com>:
> In the case of "sudo wine" whatever, $HOME is the originating user's
> home directory, and `id -u` is 0. So this means that root-owned files
> will appear in $HOME/.wine (assuming no WINEPREFIX is set).
>
> In the case that there is already a .wine owned by the original user
> before running "sudo wine" whatever,

wine will complain about ownership of .wine. It must be that the cases
I've seen, the user has changed the ownership of .wine, but not
recursively. With that correction in mind, the rest is a valid use
case, but obscure and more like user error than an issue with wine
itself.

> and that user then runs an
> application as normal user after the permissions have been stuffed
> with, it *can* (but probably won't) cause weird problems with some
> files (possibly including registry) not being correctly written to.
> The only reason why an existing .wine is required for this case is
> because of the UID owner test in wine.

<snip>

> Should we worry about this problem? Probably not, because a "chmod
> u-w" on a few files would have the same effect. The most important and
> useful thing to attempt is proper education. Essentially "don't run
> wine as root or using sudo" for all the various reasons.
>
> Also note that there is little-to-no reason to run wine as root, and
> that is even further reduced under kernel 2.6.24 and higher where
> POSIX File Capabilities were introduced. Should we prevent it? No,
> that's not in keeping with *nix style. Should we provide a warning?
> Couldn't hurt.
>
> Biggest problem I see at this stage with providing a warning for
> running as root is, should wine continue or stop on such a warning? In
> other words, if I trigger the "running as root" warning, should I have
> to confirm that it's what I want to do somehow, or should I get the
> warning but wine continue to run?


Reply via email to