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.