Container with USER specified should use that, not a new one created by x11docker

[wwoods]

Hi, thanks for putting together x11docker! Great script. One bug I've found is that if I have a docker script which specifies e.g. USER dock, the x11docker script does a number of things wrong:

1. It creates a new non-root user rather than using the existing one.
2. It creates a new home directory /fakehome/${USER} rather than using the home directory for the specified non-root user.

These are erroneous behavior, I believe. If I understand the reasoning correctly, x11docker creates a non-root user to avoid security issues. However, the manner in which it does this breaks images that already use a non-root user. I had to specify --runasroot "rm -rf /fakehome/${USER}; ln -s /home/dock /fakehome/${USER}" as a workaround, and the logged-in username is still wrong.

I'll point out that the sudoers behavior of x11docker would be good to retain.

[mviereck]

One bug I've found is that if I have a docker script which specifies e.g. USER dock, the x11docker script does a number of things wrong:
It creates a new non-root user rather than using the existing one.

It's not a bug, it's a feature. :-p
Most USER settings in the wild are rather poorly implemented and only serve the purpose to avoid root in container. Their uid and gid are random numbers that may or may not match the host user. Mostly they don't have a password. They may even miss a HOME directory.

x11docker does a clean user setup. Also, shared files with --home or --sharedir should be owned by the host user.

For that reasons x11docker will not enable USER of image as default.

But as you point out, in some cases the user setup in image is preferred.
In the latest commit x11docker provides --user=RETAIN to retain the user specified in image.

Some options like --home, --systemd and --sudouser will fail with --user=RETAIN and a note is shown.

I did some test runs with --user=RETAIN and it seems to work well so far. Maybe some options I did not thought of yet will fail. Please report if you find a bug introduced by --user=RETAIN.

I'll point out that the sudoers behavior of x11docker would be good to retain.

x11docker will not change /etc/sudoers with option --user=RETAIN. It may have been customized in image as well.

[wwoods]

Thanks for the quick response @mviereck ! Looks like --user=RETAIN mostly fixes things, but it still breaks sudo. I think you're right about respecting /etc/sudoers if user is retained. Nonetheless, if I use this script:

if [ "yes" == "yes" ]; then
    # OLD, non-x11docker version
    export XEPH_DISPLAY=":10"
    Xephyr $XEPH_DISPLAY -ac -br -fullscreen -glamor &
    BLAH=$!
    export DISPLAY="$XEPH_DISPLAY"
    docker run --rm --device /dev/snd -e DISPLAY --cap-add sys_admin -v /tmp/.X11-unix:/tmp/.X11-unix:rw -v /usr/lib/x86_64-linux-gnu/libXv.so.1:/usr/lib/x86_64-linux-gnu/libXv.so.1 $* ide-ui-xfce4
    kill $BLAH
else
    docker-compose rm -f && docker-compose build ide-ui-xfce4 && x11docker/x11docker --desktop -fy --no-init --user=RETAIN -- --rm -- ide-ui-xfce4 xfce4-session
fi

The top version (my old from before I found x11docker) lets me use sudo in the image, whereas the bottom version (x11docker) does not. So you must have left a flag flipped somewhere.

[mviereck]

it still breaks sudo

As a default security setting x11docker sets docker run options --cap-drop=ALL --security-opt=no-new-privileges. This prohibits su and sudo to root.
You can disable this with x11docker option --cap-default.

Side note: You don't need to set --rm in x11docker command. x11docker always sets --rm on itself.
You might be interested to run x11docker with option -D or --debug. The output shows the created docker run command.

[mviereck]

You can disable this with x11docker option --cap-default.

A minor change: Option--sudouser along with --user=RETAIN will set the needed capabilities for sudo and su. Now you can use --sudouser as well as --cap-default.

--sudouser sets less capabilities than --cap-default, but it is only a minor difference.

[mviereck]

--user=RETAIN now supports all options except --home. It works now with e.g. --systemd and --dbus-system.
Just to note: Instead of --user=RETAIN it is possible to set --user=uid:gid if its uid and gid are known. If a user with same uid and gid exists on host, it is possible to use option --home.

I had to specify --runasroot "rm -rf /fakehome/${USER}; ln -s /home/dock /fakehome/${USER}" as a workaround

A bit late, but however: It is easier to set --env HOME=/home/dock.