The forum

Hello,

I would really ask if it is possible to add an option to run PlayOnLinux (and all WineServers) as separate, special user. We can call him "wineuser".

This will close the big breach in Wine -> Virus can access and modify user data.
Although win viruses cannot execute/change executables on system, they DO have access to local user data (~) and by default user runs it so.

I had a real-life accident where "something" went through my data drive and added garbage to it(to every zip file it found).


Currently I do this manually. Steps:
1) create wineuser
2) (optional, depends on distribution)add it to groups(audio, video) to accelerate output.
3) "sudo xhost +local:" this allows every local user share same screen under X, for one section. It would be nice if we could add exception only for "wineuser".
4) su wineuser && playonlinux && exit


Please share your thoughts!

Good idea, in fact i have already think about it.

The problems are :
- Using sudo into playonlinux environement is clearly a lack of security
- You can't use :
sudo user && command. Firstly, the shell will require a password, and secondly, command will not be executed into the new user shell.

If you have an idea maybe, it could be interesting

Hey Tinou!

The trouble is very simple: wineserver and hosted applications have full access to user data. And viruses too. Sudden data corruption is not nice thing to discover.

Currently, I have created a "wineuser" user only for purpose of running wineserver separated.
To run, I do following:

1)me $: su root
2)root #: xhost +local: *see note
3)root #:exit
4)me $su wineuser
5)wineuser $playonlinux
6)wineuser $exit

This way I have POL and Wine server running in my account(me) in a window directly, as usual. But POL, wineserver and all chain of processes use/keep settings and access data from isolated, different account. Which only shares input controls and screen output with my account.

* this is the only command required as root, and allows local users to share same Xorg screen.
Without this it does not work. It is a per-session command, so I need to type it again, once I reboot.
Im pretty sure there EXISTS a better workaround(Im not pro in linux, yet).

Perhaps enabling wineuser permanent acess to local users screen, which are included in group "wine", ie allowed to use wineserver. This way, the setup is needed only at time of POL installation.

However it arises another problem, should multiuser environiment be present. Both physical users UserA and UserB will share all data from "wineuser". Perhaps creating "wineuser" for EACH user may solve this, ie assume we have user account "usera", then isolated accnt will be created and called "usera-pol".

Maybe it is possible to include an option, for each POL user right on start to select if he wishes to create and use isolated account or not.

Sadly I had experienced data corruption comming from nocd, for a game I legally own, which does not work in WINE due to CP. Binary crap injected in every folder and archive on data disk. Not thing I experience everyday(1st time in life), but worthy security addition IMHO.

In this case, the easier solution could be to add a function that Secure a wineprefix

ie. Removing Z:, and all symbolic links targeting user directory

Yes, but I tried to remove Z: -> / from winecfg many times. And every time, wine applications stop function... Wine somehow needs that link. :/

This is not possible, I think. Wine developers don't agree Wine can be multiuser. Many companies awaiting for that, but nobody will do that.

Some months ago, I did started fuse wine-multiuser helper. It would be great. But, for security manners of my system I stop working on the project.

If I found some free time I will relive this project.

The conception was:
WINE <-> WINESERVER
WINE <-> USERFS
WINESERVER <-> USERFS
USERFS OF ANDREE <-> ADMINFS(Real Wine Prefix; running of user having rights to this directory)
USERFS OF PATRIC <-> ADMINFS(Real Wine Prefix; running of user having rights to this directory)

The idea is like that: WINE application or WINE Server communicate with cache FUSE fs working as the same user. This file system also communicate with fs working as owner of current wine prefix(some think like admin).

All operations on directories outside user window directory have been done by ADMINFS. All operations on user home directory have been done by USERFS. If operation can't be done by ADMINFS, it have been done by USERFS(user fs is some think like cache). USERFS have access to files owned by user and admin fs have access to files owned by prefix creator.

So operation on file from : C:\\Users\\Lachu\\Desktop should been done by userfs.
Operation on file from C:\\Windows\\System32\\DX.dll should been done by adminfs or by userfs(If admin fs disagree).

Of course if another WINE Server opens some file in write mode, we disagree to open it by another(application must wait).

Maybe this would help.