Shachar Shemesh wine-devel at
Thu Oct 24 03:29:47 CDT 2002

I think Wine should, and CAN, do without privelege escalation at all.

Let's look at some of the examples presented here. If we want to give a 
multi user Windows experience that is compatible with the multi-user 
Unix experience, our trust model must be comperable. My view of such a 
case is this:
Wine is installed on the system. This means that there is a directory 
called "/usr/wine", inside of which you can find "/usr/wine/windows", 
"/usr/wine/Program Files" etc. Permissions on this directory are set 
according to the unix standard - i.e. - only admins.

Then again (assuming W2K compatibility) - you get "/usr/wine/Documents 
and Settings/dimi", that is a symlink to "/home/dimi/wine". It goes 
without saying that, as far as the Windows applications, "C:\Documents 
and Settings\dimi" is the directory, writable to the proper user.

Now, you need to be administrator to install a new program. Nothing new 
about that. If the admin want's to change that, she can set a group to 
the entire /usr/wine directory structure, and give that group write 
permission. There are still some security issues with this model. The 
wine server probably needs to be SUID to server everyone, etc. But 
still, that is a model that works. Besides, the server does not need to 
be SUID root, it can have a special user for that purpose. This is 
probably also required for registry access, if we want to enforce 
registry ACLs - we can't have a malicious user by pass the wine 
permissions by simply accessing the file directly, so the system 
registry file must not be readable by normal users (hence the need for 
suid on the server).

As for printer drivers, and services at large - there is a major 
question here of whether we wish Wine services to be able to server 
non-wine processes. If the answer is "yes", as is probably the case with 
an Adobe PDF printer driver, or with a winmodem's driver, root must 
install them.

If the answer is "no", then there is no breaking of the model. With the 
directory structure as defined today, each user can install it, claiming 
full admin rights over the loca directory structure. Of course, the new 
adobe's printer driver only serves his programs.

There is one problem with this model that has to do with windows 
programs that require admin in order to RUN. I know of a few of those. 
Some of them simply require DirectX, and these don't seem like a problem 
in Wine. Others require file access, and I was considering writing a 
program for Windows that will work around that by API remapping. I think 
it will be possible to make these programs work without breaking 
permissions. If so, it will certanly be easier to implement in Wine than 
in Windows.


Greg Turner wrote:

>On Thursday 24 October 2002 12:30 am, Dimitrie O. Paun wrote:
>>On October 22, 2002 12:24 pm, Martin Wilck wrote:
>>>The fact that wine cannot change user personalities and is lacking most
>>>of the NT security concepts makes services pretty useless.
>>I was thinking, can't we somehow use stuff like sudo(8) to accomplish
>>that? I personally haven't used sudo(8), but if we do support services,
>>we have to integrate nicely with the Unix world, IMO.
Actually, I think PAM is a more apropriate answer to this. I am saying 
this without thorough knowledge of PAM, though.

>A system administrator already could do this.  Anyhow there's really no need
>to bring sudo into the picture.  If a sysadmin is crazy enough to want to run
>a wine "service" as root, they could just invoke their executable from an
>init script; that's more "service" like anyhow.
>OTOH, I guess sudo could be used like this: if we are going to go the 
>route of "being uncompromisingly unixey" then the services API should
>just manipulate init scripts.  So, for example:
>  Installing a service == create an init script
>  Set service as "automatic" == put the script in the default runlevel
>  Uninstall a service == remove from all runlevels & remove init script
>  ... etc.
>Now, we create "wineservices.exe", create sudo permissions on this
>for the appropriate users, and implment it very, very carefully.
>Needless to say, this is a very sketchy proposition.  It is "correct," 
>from a certain perspective; it's also very, very likely that people
>will use it to create huge gaping security holes in their system, like
>basically allowing themselves to run arbitrary scripts as root with
>very little effort, and then, inevitably, wine will get a bad rap as a result.
>I'm starting to lean towards the opinion that if these security and
>identity aspects start to be implemented, then wine should just have its
>own user database, kind of like samba.  So, for example, we create
>a database that maps unix users onto wine users, with flexible percieved
>windows permissions within the wine sandbox, or, in server environments,
>wine maps unix accounts onto domain accounts from the server.
>This way, a user could "be administrator" within wine, but not be root
>on their unix box.  If we just thunk wine security down to unix security,
>we are ignoring a very important difference between Windows and UNIX:
>the vast majority of unix users don't run as root; whereas the majority
>of Windows users /do/ run as Administrator or some equivalent.
>An example: wine users need to run installers.  Installers, as often as not,
>need Administrator permissions.  This isn't an issue right now because
>wine ignores security and tends to look like Windows 98 or lower,
>anyhow.  As we move towards a 2000/XP-like implementation (this is
>inevitable and unavoidable IMO if we want wine to remain useful),
>things start to get really awkward.  So, User X wants to run Adobe
>Acrobat installer (which more-or-less works with wine right now).
>But it's the future, and wine looks like W2K.  So when the installer
>gets to the stuff about installing printer drivers, it fails, forcing the user
>to become root to do the install.  But root doesn't even have a ~/.wine
>directory!  And if the user creates a symlink, all hell breaks loose because
>fake_windows becomes a mix of files owned by root and files owned by the
>user.  I could concoct tons of similar examples.  But I'll spare you the bandwidth.
>In short: wine has relied on unix security historically, and it's been good 
>enough, because wine security / permissions implementations have been
>nonexistant or exceedingly simple.  Once we start getting more sophisticated
>about W32 security (and it seems to me, based on recent discussion, that this
>time is coming sooner than later), it's going to be inappropriate to continue
>with this approach, because we don't want to encourage users to do wine
>stuff as root.

More information about the wine-devel mailing list