Request for patch removal

[Federico Vecchiarelli]

As a workaround, I ended up creating an empty .wine folder on each of 
the users' home directory and then I did a symlink of the contents in my 
/home/wine/ but not of the folder itself.

I'm not deeply involved in wine and I don't know the reasons of this 
patch but it would seem reasonable for this behavior to be changed from 
a configuration file. Allowing the administrator to decide if he wants 
it On or Off. In the configuration file, the implications of that switch 
could be explained.

Maybe is not the best implementation but it might give you some ideas.


Fede


Steve Brown wrote:
> 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
>