Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)
Paul Chitescu writes: > In the filesystem we use as backend for Registry all we can tell is if we can > write to it or not so in the end one bit is all that's relevant (except if > it's completely unreadable when wine should abort). > > No matter what an user does it cannot change that. We don't want a wine > service running as root trying to replicate Windows access rights on the > native system, do we? Yes, the right approach to multiuser is to have wineserver and system processes run as root, and normal processes run as different users. -- Alexandre Julliard julli...@winehq.org
Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)
On Monday 30 November 2009 05:16:34 pm Paul Chitescu wrote: > On Monday 30 November 2009 04:02:03 pm you wrote: > > Paul Chitescu writes: > > > > > Changelog: > > > wineserver: Added support for read/only Registry, similar to > > > unprivileged users > > > > > > Rationale: > > > This is a first step towards implementing shared wine prefixes > with > > > most users being unprivileged and a single Administrator (power user, > etc.) > > > capable of installing programs. > > > > I don't think it's a step in the right direction. What you need is > > proper access control with security descriptors, like we have for other > > objects. A single read-only bit cannot be extended to support this. > > > > -- > > Alexandre Julliard > > julli...@winehq.org > > > In the filesystem we use as backend for Registry all we can tell is if we can > write to it or not so in the end one bit is all that's relevant (except if > it's completely unreadable when wine should abort). > > No matter what an user does it cannot change that. We don't want a wine > service running as root trying to replicate Windows access rights on the > native system, do we? > > ACLs would require at least some mapping between wine users and native system > users. And anyway, even SYSTEM or NT AUTHORITY would be unable to write to > Registry if it's read only so that one bit should suffice. > > > Paul I should add that we can emulate the behavior of a non-admin user by including it in the Administrators group only if it can open for writing HKLM\Software or similar. This will make programs happier even if they still can't write to the Registry.
Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)
On Monday 30 November 2009 04:02:03 pm you wrote: > Paul Chitescu writes: > > > Changelog: > > wineserver: Added support for read/only Registry, similar to > > unprivileged users > > > > Rationale: > > This is a first step towards implementing shared wine prefixes with > > most users being unprivileged and a single Administrator (power user, etc.) > > capable of installing programs. > > I don't think it's a step in the right direction. What you need is > proper access control with security descriptors, like we have for other > objects. A single read-only bit cannot be extended to support this. > > -- > Alexandre Julliard > julli...@winehq.org In the filesystem we use as backend for Registry all we can tell is if we can write to it or not so in the end one bit is all that's relevant (except if it's completely unreadable when wine should abort). No matter what an user does it cannot change that. We don't want a wine service running as root trying to replicate Windows access rights on the native system, do we? ACLs would require at least some mapping between wine users and native system users. And anyway, even SYSTEM or NT AUTHORITY would be unable to write to Registry if it's read only so that one bit should suffice. Paul
Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)
Paul Chitescu writes: > Changelog: > wineserver: Added support for read/only Registry, similar to > unprivileged users > > Rationale: > This is a first step towards implementing shared wine prefixes with > most users being unprivileged and a single Administrator (power user, etc.) > capable of installing programs. I don't think it's a step in the right direction. What you need is proper access control with security descriptors, like we have for other objects. A single read-only bit cannot be extended to support this. -- Alexandre Julliard julli...@winehq.org
