RFC: Sharing a wineprefix

Paul Chitescu paulc at voip.null.ro
Fri Sep 25 14:35:32 CDT 2009


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.



More information about the wine-devel mailing list