Howto: Install Wine applications for Multiple Users

[crazier22]

First of all, congrats for the good job! I've found another solution where you should symlink everything but the .reg files, but it was difficult to implement and dangerous to the data. Yours is a more elegant solution by far.

I'm using this solution to install msoffice on my eeepc (my spouse hates openoffice ). Once it has just 4GB, any disk space saving is welcome!

I want to help you improving it, so let me tell you what is happening here...

In order to open any .xls with Excel and using your solution, for example, I use "open with" pointing to a little shell script file.

#!/bin/bash
sudo -u windows -H wine "C:\Program Files\Microsoft Office\OFFICE11\EXCEL.EXE" "`winepath -w "$@"`"

You can adapt it to your own windows' programs.

Following snkiz's directions, I found the gnome menu information under ~windows/.local/share but wasn't able to make it appears on another user's menu yet, but found some some useful information here (I'll spend some time on it later): http://automatthias.wordpress.com/20...om-gnome-menu/

Regards

[snkiz]

I read the link seems the poster never found the /etc/xdg directory in ubuntu but I believe that is only used for new user setups. I tried to put a script there to run nvidia settings on startup but it did not transfer into existing user directories. Ubuntu puts all the .desktop files in /usr/share/applications or /usr/share/apps (kde) You can use /usr/local/share to add extra .desktop files, they will be added to the menu according to how the file is written. I don't yet know where ubuntu keeps the menu configs of if they can be mirrored in /usr/local/ On an eailer note everything I found about getting wine to do this for us is either wayy over my head. or not possible by design. (The whole multi access to files go boom thing)

[crazier22]

I suppose the menu configs are under ~windows/.config/menus/applications-merged/ . Is that what you were looking for?

Sorry if I can't help much, but I'm still learning about the gnome menu system. It's not totally clear for me.

Till I can see, we need to symlink something like:
~windows/.config/menus/applications-merged <- ~/.config/menus/applications-merged
~windows/.local/share/[applications,desktop-directories,icons] <- ~/.local/share/[applications,desktop-directories,icons]
; and edit .desktop files changing the "env wineprefix=.../" to "sudo -u windows -H" (I'm sure about this part, at least )

What do you think?

[snkiz]

that would get sticky because if you symlink into the user config folders in the home directory you will get permissions conflicts. The wine menu configs need to placed in a folder where they will be the system can use them

[rsay]

I have made progress on the menu problem.

Based on your suggestions, I created a link from the the wine menu folder of the windows user to a shared system folder that I named Wine_global. I chose this folder to try and make this work for gnome and kde.

sudo ln -s /home/windows/.local/share/applications/wine/ /etc/X11/applnk/Wine_global

Now, when wine installs programs to the menu, they propagate to all users.

I installed PokerStars.exe as an example, since it was a platinum app on Wine HQ.

Of course, the default wine menu install doesn't account for running the program as the windows user so I have to edit the PokerStars.desktop file in the /etc/X11/applnk/Wine_global/Programs/PokerStars directory as follows.

Original:

[Desktop Entry]
Name=PokerStars
Exec=env WINEPREFIX="/home/windows/.wine" wine "C:\\Program Files\\PokerStars\\PokerStarsUpdate.exe" 
Type=Application
StartupWMClass=Wine
Path=/home/windows/.wine/dosdevices/c:/Program Files/PokerStars
Icon=/home/windows/.local/share/icons/6604_pokerstarsupdate.0.xpm

Fixed:

[Desktop Entry]
Name=PokerStars
Exec=env WINEPREFIX="/home/windows/.wine" sudo -u windows -H wine "C:\\Program Files\\PokerStars\\PokerStarsUpdate.exe" 
Type=Application
StartupWMClass=Wine
Path=/home/windows/.wine/dosdevices/c:/Program Files/PokerStars
Icon=/home/windows/.local/share/icons/6604_pokerstarsupdate.0.xpm

Basically just adding "sudo -u windows -H" in front of "wine" in the Exec line.

Now, all the users have a Wine_global menu (or whatever you called it), that can run the programs as the windows user. This keeps the shared wine menu distinct from the users local wine if they have it installed.

I would like to have a gui like alacarte to edit the menu, but even when I tried sudo -u windows -H alacarte, the changes didn't propagate back to the /etc/X11/applnk.

[crazier22]

If I'm not wrong, if you set wineprefix, it's going to use and modify the registry of the user you set.

Looking at your orginal .desktop file I noted that your test was done with wineprefix = ~/windows/.wine and it should work once the registry is the same (sudo -u windows points you to the user windows itself).

I'm going to travel in 2 days and can't have my computer in trouble, so I can't test it right now. For now it's working. If someoneelse could test it with another user it would be great!

Regards

[rsay]

crazier22, remember that in this scheme, we aren't running another users wine, we are running wine AS the other user. The wineprefix wasn't something I put in btw, it was generated by wine when the example program (PokerStars) installed. My goal here was to alter things as little as possible because I don't want to learn the intricacies of wine.

[Craig73]

Could you expand your HowTo to clarify the implications of such a configuration so users understand what they are choosing. It might be appropriate to refer to other possible configurations.

This is a setup where users are all using a common Windows folder. Without digging into it, my initial gut reaction is that the following are potential exposures:

User Experience:
1) Since all users are running Windows programs at the same user, they may not be able to personalize their Windows applications (depending if the data is stored in the registry or in a relocatable file)

Stability:
1) Users are not restricted from updating or installing new windows updates. They could mess up the configuration and or change applications that others depend on.

2) If a user switches users while running a Windows app and tries to run a Windows app under the other user, are key files locked? or is there a risk of data corruption?

Security Risks:
1) I expect it could allow a non-privileged user to trick a privileged user into executing malicious code. (Say by replacing a windows exe that an admin would run with a malicious one, or by inadvertently installing malware into the common Windows folder)

2) Since the windows folder is shared, nothing there is confidential. Even if users store their data in their own folder, backup data, temp files, registry data, user preferences all could contain confidential information.

-------------------------

It's amusing that someone stated that this solution is more elegant. But they perhaps didn't realize what the drawbacks might be. It is perhaps easier than creating a bunch of symlinks, but it does not protect and separate application from the user configurable data. And it exposes the system to significant security and privacy risks.

[rsay]

Craig73,

I appreciate you looking at the howto. I will try to respond to your points. To give you more background information: I don't run very much windows software; 3 applications total. 2 of them are for my personal use only, but 1 is used by my whole family. I use this setup in my home to run Rosetta Stone language software. The program only allows 3 installations and I have 5 users. The program is way too expensive to buy a second license and the software that allows me to monitor the kids individual progress wouldn't work if I installed it for individual users.

User experience:
1. I agree that nobody should "personalize" a shared program. The changes will be seen by everybody. In my case, however, the software I am sharing has its own user management so learning progress, microphone settings etc. are individualized.

Stability:
1. A user with permissions to access windows programs as the windows user can install windows application updates that are accessible from within the application. Any desirable or undesirable changes would be shared by all the users.
2. I think the risk of data corruption would be the same as opening a second copy of the same application in any wine installation. Obviously, the risk would vary with each windows program. I have everybody just close the Rosetta Stone program when they are done with their lesson, because I worry about possible data corruption too. I haven't specifically tried to mess it up, but I haven't had any problems either. I suppose fast-user-switching could be disabled if the program you are working with is prone to data corruption. Somebody really good could probably even write a wrapper around the fast user switcher to check if the shared windows user was running a program before allowing a switch. You might be able to have your cake and eat it too.

Security:
1. You cannot trick a user into running a program with elevated privileges. You probably saw sudo and got concerned that we were running as root. Everybody, who is given access, will run the programs with the privileges of the windows user that you configure. If you check the first two links under the credits, you will see that I derived this method from users who wanted to run firefox as an unprivileged user, outside of their normal account, for more secure internet browsing. I recommend in the howto that the windows user be given only the privileges required to run the programs you share. My windows user can access the cd and play/record sound. My windows user can't read/write to any other users directories. I believe the risk to my system is actually less when running applications in the shared wine than under my personal wine, because the windows user has less system privileges than my normal user account does.

2. I agree with you entirely here. No data used in a shared environment can be confidential. Remember, that you are choosing the group of people who will have access to your information. You have multiple options here. As mentioned in the howto, if you want to work with something really confidential, you would install it to your personal wine. If you have something that should only be shared with a subset of users, you can go through the process a second time and define a more limited group. You can make it as granular as you want. One of the elegant things is that this shared wine environment is not a replacement for a more secure and more stable single user wine environment. It is used in addition to the single user wine environment, to solve specific problems.

If you haven't tried to create a multiuser wine environment in a while, you might not know that the "tried and true" symlink method stopped working. (That's what got me started on this project.) If the symlink method were feasible (or becomes feasible again), I hope you have a better understanding of how this method would provide you with a more secure environment by running applications as an unprivileged user.

Although I disagree with the harshness of your conclusion, I believe that you have made some valid points about data privacy and how each user could mess things up for the others. These points would be applicable to any shared user environment. I will edit the howto to reinforce these cautions. I hope I have provided you some insight into how you can mitigate or eliminate your concerns and still have the benefit of a shared wine environment, if you need it.

[synss]

Hi, that is nice, but I believe there is a simpler way: instead of creating a user windows, why not simply create a group? This avoids requiring sudo and feels more appropriate to me.

In short, create a group 'wine' (I call it wine, and not windows, but it does not matter)

sudo addgroup wine

add whoever needs to be part of this group

sudo gpasswd -a <USER> wine

where <USER> is a user who should have permission to use wine
move .wine/drive_c away (I suppose wine is already installed!) and set the correct permissions

sudo -s
mkdir -p /usr/local/wine
mv ~/.wine/drive_c /usr/local/wine
chown -R root:wine /usr/local/wine
chmod g+r /usr/local/wine
exit

the chown line says /usr/local/wine and all of its contents belong to group wine;
the chmod line says every member of the group wine can read the files within /usr/local/wine (it is probably the default, anyway, so I guess it is not necessary; one may want to check that the group has execute permission on the exe files and the directories)
finally, symlink the users ~/.wine/drive_c to /usr/local/wine
e.g.,

mv ~/.wine/drive_c{,.bak}; ln -s /usr/local/wine_c ~/.wine/drive_c

the mv thing backs up ~/.wine/drive_c. There should not be any ~/.wine/drive_c anymore since we moved it to /usr/local/wine, so if it gives an error, it is a good sign! However, if you do it for several users, and they have already run wine, you need to move their drive_c out of the way. The ln thing actually creates the symlink.

Done, no need to use sudo later, when you run windows apps.

NB: you had better use your own user with the chown command, e.g.,

chown -R synss:wine /usr/local/wine

so that you can install (you and only you, by the way) windows apps without root permissions.