run wine as non-root user

[paleozogt]

per @rachetfoot's suggestion (#12), we should install/run wine as a non-root user (e.g., UID 1000 / GID 1000).

[paleozogt]

One tricky bit here is that we can't run the Docker container as the current user

docker run -u $(id -u):$(id -g)

See the Wine FAQ, Can I install applications to be shared by multiple users?

They'll have to know to run as the user inside the container:

docker run -u 1000:$(id -g)

Running it with the current group at least makes it so that the current user can still access any files created by the container.

[spraot]

Thanks for having a look at this. I guess my user has always been 1000 so the wine check was never triggered with my change. However, the process of running a VC build shouldn't change the registry, so the underlying issue that that wine user check is working around shouldn't apply here. So for the purposes of this docker container, we just need to work around the check somehow.

The suggestion in the wine bug report is: "The check can be disabled by creating a temporary wineprefix dir that contains symlinks to the real files."

This code is untested, but I think this would be the way roughly to implement the symlink suggestion:

In dockerfile:

ENV USRWINEPREFIX /opt/winetmp/
RUN mkdir -p $USRWINEPREFIX && chown -R wine:wine $USRWINEPREFIX && chmod 775 $USRWINEPREFIX

In command script before running wine:

WINEPREFIXMAIN=$WINEPREFIX
WINEPREFIX=$USRWINEPREFIX/$UID
if [ ! -d "$WINEPREFIX" ]; then
    ln -s $WINEPREFIXMAIN/* $WINEPREFIX/
fi

Then we would run the container with:

docker run -u $(id -u):1000

[paleozogt]

@rachetfoot Oh, interesting. At one point I tried doing a symlink to the WINPREFIX, but it didn't work. What I didn't understand was that the workaround is to have a user-owned folder full of symlinks into the other WINEPREFIX.

I'm trying this out and should have something into master soon. Thanks for the tip!

[paleozogt]

@rachetfoot this has been merged to master :)

[spraot]

Nice!