http://bugs.winehq.org/show_bug.cgi?id=11112
Paul Chitescu paulc@voip.null.ro changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |paulc@voip.null.ro
--- Comment #29 from Paul Chitescu paulc@voip.null.ro 2012-02-08 12:12:52 CST --- (In reply to comment #28)
One way this could get fixed is if wineserver was overhauled a little to delay loading the HKCU registry key until each client connects. The HKCU key would be attached to each connection instead of being global. As the wine client connects it would first announce the username/sid and then wineserver could load the user.reg file from the users .wine folder. This means that wineserver would have to run as root to load other users files like a system service. wineserver -s, --service multi-user service
Running wineserver as root is a very complex problem by itself. It would mean that wineserver would need to reimplement many of the access rights normally provided by the operating system. The security implications are mindblowing.
Maybe we should focus on a slightly different problem that seems easier to implement since it doesn't seem that simultaneous access from different users is needed.
We could have a setuid wrapper that performs the equivalent of chown -R user once it locked the wineprefix and then switches back to the original user. This way the access rights will be correct.
A helpful touch would be to move user.reg inside c:\users%USERNAME% so each user will have its own HKCU.