Request for patch removal

[Stefan Dösinger]

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.