Wine is open source software that allows you to run Windows applications on the Linux operating system. While this is very handy, Wine runs under your own user account by default, which means that it (and the Windows software it hosts) has full access to your home directory and personal files. The aim of this article is to force Wine to run under a separate user account, so that it doesn't have such access.
While there's no reason to suspect Wine of any malicious behaviour, nor most Windows applications, I still don't like the idea of Windows software running under a user account that is permitted to read and modify my personal files. There are a huge number of viruses and trojans ready-made for Windows, so I want to keep Wine as segregated as possible. Running Wine in its own user account won't cut it off completely, but it ought to reduce the damage that can be caused if Wine encounters rogue software, or if legitimate software gets hacked.
I'm using the Ubuntu 9.04 [if you're planning on using Ubuntu 9.10 then see the Updates at the bottom of this page first] flavour of Linux, and the excellent Spotify as the Windows software that I want to run on Wine. But the steps described in this article should work with other Windows applications that run on Wine, and will probably work on other flavours of Linux (though some steps may vary depending on your distribution).
IMPORTANT: This document should be considered experimental, and the steps described below mostly involve editing core configuration files that are critical to the Linux operating system. So please don't attempt anything in this article unless you're experienced with making changes to your system, you know how to fix your system when things go wrong, and you've recently done a full backup of your files.
If you don't already have Wine installed, do so now and test that it works as normal (under your own user account). Installing Wine is easy in Ubuntu. Just open the Synaptic Package Manager, search for Wine, and install the wine package.
Simply enough, the new user account for Wine will be called wine (lowercase). To create a new user account called wine type the following into a command terminal:
sudo adduser --disabled-login --shell /forbid/login wine
This should create a new account called wine which is not permitted to be used to login, but does have a home directory.
We need this account to have access to the audio device, and in Ubuntu this means that the wine account needs to be added to the audio group. That's easily done by typing into a terminal:
sudo usermod --append --groups audio wine
And you can check which groups the wine account is a member of by typing groups wine in the terminal. To run Spotify, we just need wine to be a member of the wine and audio groups, but some applications may give you reason to add wine to other groups, such as cdrom, floppy, and so on.
The command sudo lets you run commands with another user account. Usually sudo is used to run a program with root access (as we've done twice in the previous section). But you can also use sudo with the -u switch to run the command as another user account. Normally, doing so will require that you type in your password, but by editing the /etc/sudoers file, you can give your own user account permission to run commands under the wine account without having to type a password.
To safely edit the /etc/sudoers file, you must use the visudo command (don't edit /etc/sudoers without this command). Unfortunately, by default visudo uses vi (which I described in my notes as the worst editor ever created
, simply because I couldn't make any sense of it in less than five minutes). If you're not a vi guru, then you can specify a simple, graphical text editor by calling visudo with the VISUAL environment variable changed to suit you. I opted for gedit, so the command to run visudo was:
sudo env VISUAL=/usr/bin/gedit visudo
Once you're editing /etc/sudoers, you need to add a new line to the end of the file. I want to be able to run commands as user wine from my own account which is called bob. So I added the following line to /etc/sudoers:
bob ALL=(wine) NOPASSWD: ALLMake sure to change bob to the name of your own user account, though.
You should now be able to run commands under the wine account without needing a password. Test this by typing
sudo -u wine ps -Fe | grep wine
into the terminal (note that it's a pipe symbol before "grep", not an alphabetic character). You should see a line that begins with "wine" and ends with "ps -Fe" which shows that the "ps -Fe" command was run by the user account wine. (Note that the "grep wine" command was not run by the wine account, though.) Most importantly, you should not have been asked for your password to perform the "sudo -u wine" part.
Because we want to make sure that Wine can't be run deliberately or accidentally by any user account other than our wine account, we need to change the permissions on any Wine files and directories on the machine.
If you've used Wine before under your own user account, you'll probably have a .wine directory in your home directory. To stop you running anything in this directory tree, it's easy to mark it as being owned by the wine account. Just change the owner and group to wine by typing the following into the terminal:
sudo chown -R wine:wine ~/.wine
and then stop any user that is not the owner or in the wine group (which should rule out every account except the wine account) from doing anything to the files or directories in this tree:
sudo chmod -R o-rwx ~/.wine
Note: once you run Wine under the user account wine, a .wine directory will also be created in /home/wine, so you'll need to run the above commands for /home/wine/.wine too.
Note: if you're sure you don't need anything in the .wine directory in your home directory, you can delete it completely. But make sure not to delete the .wine directory within /home/wine because this is where we want Wine to install software to.
More important than the home directories are the Wine program files that live in /usr/bin. By default these are owned by root and can be executed by anyone. We want to limit their use to just the wine account, so we need to change their owner and group to wine and then remove permissions for other users. Similar to the commands above, but this time we're targeting all files in /usr/bin that begins with wine:
sudo chown root:wine /usr/bin/wine* sudo chmod o-x /usr/bin/wine*
Be very careful when using wildcard matches like this. A typo could lead to changes being made to a huge number of files you didn't intend to target.
NOTE: For some reason, I found the owner and permissions on /usr/bin/wine* files restored to root and others-may-execute. I'm guessing that this was done by an upgrade to a newer version of Ubuntu, or an update to the version of Wine installed. I don't know how to force these files to retain their ownership and permissions during such upgrades, so this may be a security weak spot.
Note: There are .dll.so and .exe.so files in /usr/lib32/wine but these are all read-only library files, and have no execute permissions on them. I don't believe these need to be limited to the wine account, but it doesn't hurt to change the ownership and permissions of this directory in the same way as described above, just to be sure.
The default umask determines the permission levels set on new files. In an umodified release of Ubuntu 9.04, the default umask is 022, which gives the owner full permissions (u+rwx), group members read and execute permissions (g+rx), and others (anyone not the owner or a member of the file or directory's group) read and execute permissions (o+rx).
The problem with such a umask setting is that newly-created files will by default allow anyone to read and execute them. Which would allow accounts other than wine to access and run new .exe files added to the system (assuming the /usr/bin/wine* files have become accessible to non-wine accounts, as described in the previous section).
A much stronger umask setting is 027, which creates new files (and directories) so that the file owner has full access, group members have read and execute permissions, and other users have no permissions on that file. (This is probably a sensible default for security-minded users to switch to, whether or not you want to run Wine under its own user account.) You can find out what umask setting your system currently has by typing umask in the terminal.
To change the default umask setting in Ubuntu, you can edit the /etc/profile file and add the following line right at the end:
umask 027Note: An even more secure setting is to use umask 077 which creates new files and directories so that the owner has full access, but group members and others have no access at all. However, the way I use my system, I prefer to have group members able to read and execute files, so I've used umask 027.
In theory, running Windows applications with Wine under the wine account is as simple as typing sudo -u wine wine software.exe but in practice there are a couple of things we need to run with this command to make it work.
First of all, the user wine doesn't have any access to the X server which handles graphics. So trying to run an application like Spotify will just generate a stream of error messages. To give the user wine permission to access the X server, we can type:
xhost +SI:localuser:wine
This will give wine permission to use the X server for this session only, which is a pain. I couldn't find a configuration file that lets you specify this as the default, so this xhost command will be added to the top of a script we'll call runaswine, which bundles everything together for convenience.
The command "sudo -u wine wine software.exe" should now work, but there's a potential problem in that the environment variables will still refer to your own user account. For instance, if you type env into the terminal, you'll see the value of all of the environment variables. A lot of them refer to your user account, or your home directory path, to which the wine account should no longer have access. To avoid this causing trouble for Wine, I've set the environment variables to reflect the wine account, using the env command like this:
sudo -u wine env HOME=/home/wine USER=wine USERNAME=wine LOGNAME=wine wine "$@"
(You may also want to add WINEDEBUG="fixme-all" to the list of environment variables you pass to the env command. See the March 2010 note in updates.)
I've left the XAUTHORITY variable pointing to my home directory, because I have to admit that I've not been able to make sense of what exactly the .Xauthority file does, and I can run Spotify as user wine without changing this. However, this may be a security weak spot, so I hope to work out whether this can be and needs to be changed to use a separate .Xauthority file in the wine home directory.
As all of this is a lot of typing, it's handy to put it into a script we'll call runaswine. In the script, instead of the example software.exe target, we'll use the arguments handed to the script. The complete runaswine script looks like this:
#!/bin/bash
# Run Wine as user wine.
# Should only be used for running Windows software with Wine emulator.
echo "Adding wine to X server permissions list."
xhost +SI:localuser:wine
echo "Running as wine:" "$@"
# Use sudo -u wine to run command (and all arguments) as user wine.
# and use env command to set environment variables for wine user.
sudo -u wine env HOME=/home/wine USER=wine USERNAME=wine LOGNAME=wine wine "$@"This is a Bash script, and the Bash interpreter replaces "$@" with all of the arguments supplied to this script (each argument quoted separately to preserve spaces within arguments). Create this script in your home directory and call it runaswine, and then make this script executable by typing:
chmod u+x runaswine
Now you can type something like:
~/runaswine software.exe "argument 1" "argument 2"
and it should call the runaswine script to neatly do all of the above to add wine to the X server permissions list, and invoke Wine with the temporary environment variable values, running software.exe with the provided arguments, all under the user account wine we specially created for the role.
Test it all works by typing:
~/runaswine winecfg
and you should see the graphical Wine configuration tool. Leave this open and then type into the terminal:
ps -Fe | grep wine
to see which processes are being executed by which user, filtered to show only lines which include the string "wine". You should see something like the following:
wine 13503 1 0 1232 2212 2 16:30 ? 00:00:10 /usr/bin/../lib32/../bin/wineserver wine 13506 1 0 923871 2892 2 16:30 ? 00:00:00 C:\windows\system32\services.exe wine 13508 13506 0 925690 7240 3 16:30 ? 00:00:00 C:\windows\system32\winedevice.exe MountMgr wine 13540 1 0 925224 9092 2 16:30 ? 00:00:00 C:\windows\system32\explorer.exe /desktop bob 16648 9572 0 2711 1656 3 17:46 pts/1 00:00:00 /bin/bash /home/bob/runaswine winecfg wine 16650 16648 0 926654 10440 2 17:46 pts/1 00:00:00 winecfg bob 16670 9572 0 1882 912 0 17:47 pts/1 00:00:00 grep wine
This shows that the Wine server and the Windows executables are being run under the user account (shown in the leftmost column) wine. (Note that both the grep command and the runaswine command are run under the user account bob, however.)
Note: I have no idea why wineserver is being called with such a convoluted path instead of just /usr/bin/wineserver.
Assuming everything so far has gone as described, you should be ready to install some Windows software using Wine, running under the wine account. Let's use Spotify as an example, as it requires graphics and audio to function correctly, so you'll quickly notice if something isn't working.
Download the Spotify installer (named "Spotify Installer.exe" at the time of writing) from the Spotify site. Then move or copy this file into /home/wine/.wine/drive_c (and you will need to use sudo to do this, because your own user account should not have any permissions on the wine account's home directory or its subdirectories). If this directory doesn't exist yet, try to run the winecfg application as described in the previous section. This should create the .wine directory and its subdirectories within /home/wine.
Next you must set wine as the owner and group of the file using chown like so:
sudo chown wine:wine /home/wine/.wine/drive_c/Spotify\ Installer.exe
Now that the installer file is in the "drive_c" directory, Wine should be able to refer to that file using the Windows-style "C:\" path. So you should now be able to use runaswine to start the Spotify installer like so:
~/runaswine "C:\Spotify Installer.exe"
If all goes as planned, the Spotify installer should run and you should be able to install Spotify as you normally would under Windows. If the installation completes successfully, and assuming you installed Spotify to the default path of "C:\Program Files\Spotify" then you should now be able to run Spotify using the command:
~/runaswine "C:\Program Files\Spotify\spotify.exe"
Hopefully everything has come together and you will now see Spotify appear and ask you to login to your Spotify account. You can confirm that all of the Wine processes are running under the user account wine by typing ps -Fe | grep wine as described in the previous section.
Once you've got Spotify running via the runaswine script, there should be nothing stopping you from installing and running other Windows applications. I found installing foobar2000 and dBpoweramp just as easy, though I've not tried any major applications such as 3D games.
For convenience, it's handy to create entries on the main menu to launch software under Wine (which you can do with the System -> Preferences -> "Main Menu" tool in Ubuntu 9.04). In Ubuntu and GNOME, the menu will not be able to use the ~ to represent your home directory, so replace ~/runaswine with something like /home/bob/runaswine to get it to work. If you like to give menu items the appropriate icon, the icons for Wine applications can often be found in /home/wine/.local/share/icons (but for some reason, not always).
All of the above takes a bit of doing at first, but once it's working you can, with ease, launch Windows software in Linux under a separate user account called wine. To the best of my knowledge, that ought to stop Wine and Windows software from having any access to any file or directory that you haven't granted to the user account wine.
However, the wine user account is still going to have access to a huge amount on your system: all of the generally-accessible configuration files, plus software in directories such as /usr/bin, and also access to the internet. But if the above advice allows you to keep your personal directory and files separate and inaccessible, then at least rogue software running under Wine should be limited in the damage it can do you.
I'm only a part-time shell hacker; I'm nowhere near to being a kernel developer. So I don't know how easy it would be for a rogue application running under user account wine to break out of its confines and gain access to other user accounts, restricted directories, or system devices. Plus, I've noted at least of couple of points in the above process that might be weak points.
If you spot anything incorrect, ineffective, or worse in this article, contact me and let me know.
2009-11-05: A couple of days ago I updated Ubuntu from 9.04 to 9.10, and this new version of Ubuntu has radically changed the way audio works. Sound output is normal using applications like Quod Libet under my own user account, but running Spotify under the wine account leads to sound output that is incredibly bass-heavy. Going to Sound Preferences and then selecting a different hardware device, or a similar change, causes the output to switch to a much more balanced sound, but this only lasts until Spotify starts playing another track, and then the bass-heavy effect returns. I've currently no idea what's causing this (could be the new version of Ubuntu, or new Wine libraries). If I work out what's causing it, I'll update this page. If you have any idea what might have changed in Ubuntu 9.10 to lead to this problem, let me know.
2010-03-14: After seeing the last few mebibytes of my home directory get used up steadily by some unknown plague, I traced the problem to the ~/.xsession-errors and ~/.xsession-errors.old files, which had grown to take up nearly seven gibibytes. These were full of lines such as:
fixme:ntdll:NtQueryInformationProcess (process=0xffffffff) Unimplemented information class: ProcessDebugFlags
Seeing "ntdll" told me that it was a Wine error being logged, and it turns out the "fixme" class of debugging message is enabled by default in Wine. You can use the environment variable WINEDEBUG to choose which classes of debugging message Wine should generate. (This took me a while to do, because I had the env command in the wrong place in my runaswine script. I've now fixed the commands on this page, so everything is good now.)
To disable the fixme class of debugging messages, you need to add WINEDEBUG="fixme-all" (that's fixme minus all) to the env command before you call the wine command. So the relevant line in the runaswine script becomes:
sudo -u wine env WINEDEBUG="fixme-all" HOME=/home/wine USER=wine USERNAME=wine LOGNAME=wine wine "$@"Remember to remove this environment variable again if Spotify develops a problem and you need to see all debugging output to help you work out what might be wrong.
Oh, and I still haven't worked out how to fix the sound problem that appeared in Spotify with Ubuntu 9.10.
2012-01-07: After an update to Spotify, I found that Spotify would load, login but then go entirely black. It turns out that this was caused by a change to terms and conditions which you are required to read and accept. For some reason, running Spotify under Wine, the popup which shows the new agreement would not appear so the application just sat there blankly.
The good news is that Spotify is a sensible bit of software, so if you login to your account while running Spotify in Windows and then read and agree to the terms and conditions, you won't need to agree to the same thing again if you then run Spotify on another machine. So Spotify does still run under Wine, but you might need to find a Windows machine briefly to fix this glitch.