"Federico Vecchiarelli" <fedev(a)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.
On Wed, 16 Jan 2008, Dmitry Timoshkov wrote:
"Federico Vecchiarelli" <fedev(a)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(a)umbc.edu
On Wednesday January 16 2008 16:01:55 Steve Brown wrote:
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).
In practice even if you have multiple wineservers running this isn't too big problem (however, it *is* a problem). In fact I have used this for my multiuser setup for years and never know about possibility of registry curruption. I even thought that there is no problems at all with multiple wineservers (in fact *noticeable* registry-related problems are quite rare in my case). Now I know that multiple wineservers don't work perfectly together and what was the cause of some registry-related problems in my setup. BTW, in my setup 3 users share some of WINE prefixes and some Windows programs work for all users simultaneously in one WINE prefix. Don't think that above means you can forget and ignore that bug! You cannot! It needs to be fixed and while it isn't fixed you may (and probably will) face with problems like overwriting the registry with older version. For example, one user may install program and then correctly shutdown wineserver (for example by closing all programs). This will write out registry files to disk. Then other user will do that too (without installing anything) and you (or user who installed a program) will lose all new registry keys created by the installer. Depending on the setup, wineserver can write to the registry and possibly overwrite changes made by other users - generally this can happen at any time. Technically this is very bad, but in practice it is possible to live with it if you and your users do not use registry very intensively and do not store there very important information. Especially this is true if your users rarely run wineservers simultaneously. However, if you and your users need 100% reliable setup don't even try! There is no locks of any kind so even if you think that your users will not run wineservers in WINE prefix at the same time - they still can do that, and this can lead to some loses in the registry. Theoretically you can create a lock by writing a wrapper script but use of locks is just another hack and will not solve the main problem anyway (use of multiple wineservers), it needs to be fixed properly. You can bypass the check by using symlinks if you *really* need this; if you unsure you can just try this and see if it works good enough for you and your users (feel free to ask me if you need more instructions or help with such setup). And of course don't forget to backup registry before trying... But remember that this is *strongly discouraged* practice for obvious reasons! This is exactly why the patch in question was committed. Therefore bypassing the security check is not recommended! We really need to fix that bug to allow reliable multiuser setups...
Am Mittwoch, 16. Januar 2008 19:57:52 schrieb L. Rahyen:
We really need to fix that bug to allow reliable multiuser setups... Maybe the proper solution is one wineserver running globally, as a special user("wine", "root" or whatever), started at system boot. A global registry and dosdevice setup somewhere in /etc/, the fake C drive global, just the user.reg in every user's home. The wine instances started by the user connect to wineserver then, etc.
However, if we do this, we'll have to care for security. We need authentication, secure IPC, secure resource handle access, provide security updates, etc. Currently, we do not care much about security, and as a consequence, we do not give any code of wine any special privileges, so Wine is not a security thread(Other than allowing Viruses to run, but that is inherent to its functionality). But dealing with security requires manpower. We have to implement all this, audit the code, etc. Wine is already a huge effort, and we're starving of manpower. I think the existing manpower is better spent at improving our Windows API implementation instead of diving into security hell. Patches are welcome though ;-) *** snip *** I once used the following setup: *) A shared C drive(/opt/windows), owned by a special user wine *) A shared ~/.wine in /etc/wine, owned by user wine. *) A private ~/.wine in each user's home *) dosdevices, system.reg and userdef.reg symlinked from /etc/wine to ~/.wine *) A private user.reg for each user *) C:\windows\profiles\($USER) symlinked to a folder in the user's home The shared files(/opt/windows, /etc/wine) were read-only for everyone except wine. This way, each user had his own HKEY_CURRENT_USER, and I shared HKEY_LOCAL_MACHINE and the application installation directory among all users. HKEY_LOCAL_MACHINE was even write protected for all but by administrator wine user. Every user could modify it, but wineserver would fail to write the changes to system.reg, so the changes weren't persistent. No overwriting of registry files across accounts was possible because the shared files were write protected, and user.reg was private for each user. For well-behaved apps this worked like a charm. Each user could safe his own preferences and was protected against accidentally messing up the installation. However, I eventually dropped that setup because it was a pain with games and many other apps, and I am in fact using my machines alone, so a multiuser setup was pointless. The catch compared to real multiuser support was that Windows processes belonging to different users could not see each other, and no IPC was possible across users. Furthermore the initial setting was tricky.
On Wednesday January 16 2008 19:47:03 Stefan Dösinger wrote:
Am Mittwoch, 16. Januar 2008 19:57:52 schrieb L. Rahyen:
We really need to fix that bug to allow reliable multiuser setups...
Maybe the proper solution is one wineserver running globally, as a special user("wine", "root" or whatever), started at system boot. A global registry and dosdevice setup somewhere in /etc/, the fake C drive global, just the user.reg in every user's home. The wine instances started by the user connect to wineserver then, etc.
This is probably good way to solve the problem. However it seems to me that it will require a lot of effort to implement this properly and reliably.
However, if we do this, we'll have to care for security. We need authentication, secure IPC, secure resource handle access, provide security updates, etc. Currently, we do not care much about security, and as a consequence, we do not give any code of wine any special privileges, so Wine is not a security thread(Other than allowing Viruses to run, but that is inherent to its functionality).
But dealing with security requires manpower. We have to implement all this, audit the code, etc. Wine is already a huge effort, and we're starving of manpower. I think the existing manpower is better spent at improving our Windows API implementation instead of diving into security hell. Patches are welcome though ;-)
I agree with you here. In fact this isn't too big problem (at least for me). But this bug probably should be solved for version 1.1 (for 1.0 we already have a lot of other bugs to fix).
On Wednesday 16 January 2008 20:47:03 Stefan Dösinger wrote:
Am Mittwoch, 16. Januar 2008 19:57:52 schrieb L. Rahyen:
We really need to fix that bug to allow reliable multiuser setups...
Maybe the proper solution is one wineserver running globally, as a special user("wine", "root" or whatever), started at system boot.
+1 :)
However, if we do this, we'll have to care for security. We need authentication, secure IPC, secure resource handle access, provide security updates, etc. Currently, we do not care much about security, and as a consequence, we do not give any code of wine any special privileges, so Wine is not a security thread(Other than allowing Viruses to run, but that is inherent to its functionality).
We can probably do this similar to Windows. IIRC you get a token at log-in time to identify yourself with. I think running as a special user is sufficient, I doubt running as root is necessary. I figure once Wine 1.0 is out, we'll have to provide security updates anyway.
But dealing with security requires manpower. We have to implement all this, audit the code, etc. Wine is already a huge effort, and we're starving of manpower. I think the existing manpower is better spent at improving our Windows API implementation instead of diving into security hell. Patches are welcome though ;-)
+100 ;) Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.
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(a)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(a)umbc.edu
participants (6)
-
Dmitry Timoshkov -
Federico Vecchiarelli -
Kai Blin -
L. Rahyen -
Stefan Dösinger -
Steve Brown