Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)
Paul Chitescu paulc@voip.null.ro 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.
On Monday 30 November 2009 04:02:03 pm you wrote:
Paul Chitescu paulc@voip.null.ro 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 julliard@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
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 paulc@voip.null.ro 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 julliard@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.
Paul Chitescu paulc@voip.null.ro 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 -
Paul Chitescu