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.
Hi. I've already had an experience of sharing wine prefix and in current condition it's a headache to set up. Once it's up and running it's okay most of time, but for not experienced user such task is way too complicated. So I vote with my both hands for having some handy tool in wine for this task. -- Igor
On Fri, Sep 25, 2009 at 3:35 PM, Paul Chitescu <paulc(a)voip.null.ro> wrote:
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
In my particular case, what I would like is in some ways actually simpler: - Define WINEPREFIX and WINEUSERPREFIX. - For all file accesses: - If accessing read-only: try reading from WINEUSERPREFIX; if it's not there, use WINEPREFIX instead. - If accessing read-write: try reading from WINEUSERPREFIX; if it's not there, copy from WINEPREFIX instead. If the admin updates WINEPREFIX, then I can just wipe out my personal WINEUSERPREFIX to see his changes. You might want to be configurable to have certain paths (the HKLM registry and Program Files folders, among others) not ever use the WINEUSERPREFIX, but I don't need that. I think this feature would be really handy for supporting shared installations. One big advantage of this method over others is that it should work even if multiple users are doing destructive things to the same files; they won't see each others' changes. This makes it great for test environments (which is one of the things I'd definitely use it for). Have fun, Avery
On Saturday 26 September 2009 02:19:53 Avery Pennarun wrote:
On Fri, Sep 25, 2009 at 3:35 PM, Paul Chitescu <paulc(a)voip.null.ro> wrote:
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
In my particular case, what I would like is in some ways actually simpler:
- Define WINEPREFIX and WINEUSERPREFIX.
- For all file accesses: - If accessing read-only: try reading from WINEUSERPREFIX; if it's not there, use WINEPREFIX instead. - If accessing read-write: try reading from WINEUSERPREFIX; if it's not there, copy from WINEPREFIX instead.
If the admin updates WINEPREFIX, then I can just wipe out my personal WINEUSERPREFIX to see his changes.
You might want to be configurable to have certain paths (the HKLM registry and Program Files folders, among others) not ever use the WINEUSERPREFIX, but I don't need that.
I think this feature would be really handy for supporting shared installations. One big advantage of this method over others is that it should work even if multiple users are doing destructive things to the same files; they won't see each others' changes. This makes it great for test environments (which is one of the things I'd definitely use it for).
Have fun,
Avery
What you're proposing here is essentially an overlay file system. The best would be to use a real overlay file system driver as: - Doesn't require complex coding in Wine - Can offer features not easy to implement like local deletion (file or directory exist in the main prefix but we don't want them in the "copy") - It offers an unified view between Wine and the host operating system - Can be tested outside Wine - The developers of the filesystem already banged their heads against the many ways such an overlay system may fail. You should also know that any such simplistic approach can fail in interesting and hardly to debug ways unless the user's prefix is wiped (which you already noted) which is unacceptable in most scenarios. Paul
On Sat, 26 Sep 2009, Paul Chitescu wrote: [...]
What you're proposing here is essentially an overlay file system. [...] You should also know that any such simplistic approach can fail in interesting and hardly to debug ways unless the user's prefix is wiped (which you already noted) which is unacceptable in most scenarios.
Here's a nice reference on the traps awaiting anyone who wants to write a union filesystem: http://lwn.net/Articles/324291/ Also note that in the case of Wine a union filesystem does not solve the problem of the registry since it would not know how to merge the content of the administrator's and the user's system.reg files. So to make the unioning complete we would need a union registry too (or make each registry key and value into its own directory/file!). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ La terre est une bêta...
Hi Paul, as usual admin of home PC server with few users sharing installed games, I'm really missing feature similar to this in Wine. You've got my vote and should you need testing, I'm glad to help. Regards Hark
participants (5)
-
Avery Pennarun -
Francois Gouget -
Igor Tarasov -
Paul Chitescu -
Vit Hrachovy