Hi people!
I know this has been talked about again and again and no satisfactory solution (generic, safe, somehow simple) has been found for all.
This proposal aims to solve a common scenario with minimum of changes in Wine, in particular remaining compatible with existing installations. It doesn't solve all problems but a quite pressing one: have a bunch of programs installed just once and used by several users.
The idea is to have two categories of users: - The Administrator: - Is the owner of the WINEPREFIX, just like now - R/W access to the prefix - Can install and uninstall programs - Exclusive lock, no other user can run in the same prefix at the same time - All others are restricted users: - R/O access to the prefix (including the machine Registry) - They can only write to their profile (including the user Registry) - Can install programs only to their profile if the installer supports so - Cannot run wine in that prefix while the Administrator runs it - Multiple restricted users can run in the same prefix at once
UNIX access rights and/or symlinks will be used to: - Make sure other users cannot write to the prefix - Each user has a Wine visible path to his profile directory - Each user can create a new profile directory - or, subject to policy, the Administrator may create (but no need to populate) them in advance
Required changes I've identified so far: - The R/W lock to the prefix - wineserver -k as admin should terminate all users' instances - wineserver needs to be able to load Registry hives R/O - wineboot needs to be able to create just the user's profile and ignore pending renames for restricted users - Report to application the detected type of user: Administrator / Restricted - Some winecfg settings need to be migrated from HKCU to HKLM so the admin can enforce sane values or provide proper defaults or because they are logically per prefix - The user Registry hive and the temporary directory for the restricted users need to be stored in their profile directory
Advantages: - Not much coding required, less chances to introduce bugs - Will not break existing installations - No trust is required between users, only to Administrator - Each user runs its own wineserver, there is no communication between them - Solves the most common requests from users - Required step to a more complete (but dangerous) extension
Disadvantages: - Single admin user - The Administrator cannot run concurrently with other users - To install or remove programs all users need to shutdown their Wine - A restricted user cannot promote to Admin just to do one action (but of course he can su, wineserver -k others, run as Administrator) - Some programs (although not many, most need just to install) need to run as Administrator - After a Wine upgrade the Administrator needs to upgrade the prefix too - All users share the view of the dosdevices (can be moved to the profile dir if we really want to) - Users cannot install programs (except some) or fonts - Doesn't allow non-simultaneous usage of the prefix by different Admins
Opinions?
Comments?
Votes?
Although most changes are not complex there is much work and this needs some political decision to proceed to actual coding.