Request for patch removal
Steve Brown
sbrown7 at umbc.edu
Wed Jan 16 10:01:55 CST 2008
On Wed, 16 Jan 2008, Dmitry Timoshkov wrote:
> "Federico Vecchiarelli" <fedev at gmx.net> wrote:
>
>> Ok, to the point. The patch mentioned below prohibits wine from running
>> any application which is inside someone else's folder, even if you have
>> access to it. In my case, I wanted to make one unique installation
>> available to several users. Because of this patch, there is no
>> workaround that could be implemented, forcing me to either run a script
>> changing the owner of the folders for every user as they want to use the
>> application or I have to make several copies of the software which will
>> put me in a difficult legal situation.
>
> All the details about this problem you can find here:
>
> http://bugs.winehq.org/show_bug.cgi?id=11112
>
> --
> Dmitry.
Allow me to add my voice on this subject. I also would like the Wine
developers to consider how to allow for this use case. In a centrally
administered environment, most users do not have write access to much of
the local disk, and the administrator of the machine (root) sets up the
environment for them (and normal users should not be allowed to muck with
it). I am administrator for a small group of folks here, and would switch
to Linux only -- but there are still Windows-only programs that are
critical for my users. Wine would be a wonderful solution, if only wine
could be installed in a central location (say, /usr/local) and the wine
"registry" files could be shared, somehow, by all users on the machine
(maybe by doing a union of ~/.wine and /usr/local/wine/whatever).
I see in the comments on this bug, that the concern is with multiple
instances of wineserver running on the machine at one time -- that's not a
major issue in the use case I envision. The multiple wineservers would
not be running at the same time (unless the install is on what Windows
would call a Terminal Services Server -- a normal multi-user *nix
machine). I think that even just allowing for multiple login users on a
local machine at different times would be sufficient for a lot of us. If,
say, ~/.wine was used as a replacement for HKLM\Current User and, say,
/usr/local/wine/whatever was for the other registry hives and group
policies, I think wine would be a lot closer to being a solution for those
of us maintaining multi-user machines.
Steve Brown
Systems Administrator
UMBC Imaging Research Center
sbrown7 at umbc.edu
More information about the wine-devel
mailing list