BaSzErr - blog:2022:01:30

2022-01-30_-_missing_user_in_docker_image

anonymous@undisclosed.example.com (Anonymous) — Sun, 30 Jan 2022 20:40:39 +0000

2022-01-30 - missing user in docker image

most of the time i don't run docker images as root… for obvious reasons. ;) however there are some tools, that will complain if current UID does not seem to have corresponding /etc/passwd entry. for example calling ssh-keygen -f mykey -N “” -t “ed25519” inside a container, started as –user 1234:1234 will end up with error No user 1234. :/

while i'm far from seeing logic in ssh-keygen needing to have /etc/passwd entry for a current user, that's how things seem to be working atm.

many ppl on the internet suggest to just add your user to the image, or simply assume that UID:GID is 1000:1000. these are no-go for me. adding user to image makes it impossible to change later on, thus everyone is stuck with your hardcoded user… that might not even match their setup! while it's true that 1000:1000 is the most common on workstations, since usually installation has just one user account, but this fails spectacularly on shared hosts (eg. build machines on CI agents), where typically multiple users have access to it. CI agent is also a typical setup where might share a volume between host and container, so that build artifacts “survive” after container is done with building them.

so a workaround for situation this is needed. my current best take is via a proxy shell script, like this:

#!/bin/bash
set -eu -o pipefail
 
# workaround for missing user account in /etc/passwd - some tools can't handle it...
read R_UID R_GID <<< "$(echo "$REAL_USER" | tr ':' ' ')"
groupadd -g "$R_GID" "user"
useradd -g "$R_GID" -u "$R_UID" -s "/bin/bash" "user"
 
if [ $# -eq 0 ]
then
  exec setpriv --reuid "user" --regid "user" --init-groups "bash"
fi
exec setpriv --reuid "user" --regid "user" --init-groups "$@"

it can then be added to Dockerfile:

FROM four_favorite_distro:version
COPY shell_proxy /usr/local/bin/
ENTRYPOINT ["shell_proxy"]
...

and run container like this:

docker run \
  -it \
  --rm \
  -e REAL_USER="$(id -u):$(id -g)" \
  container \
    command arg1 arg2 ...

so docker will now start container as root, with REAL_USER pointing to UID and GID of user that it should really be running. in the entrypoint script user named user is created with appropriate UID and GID and then setpriv is used to execute provided command or start interactive bash shell, if no command is given.

2022-01-30_-_real_story_behind_wayland_and_x

anonymous@undisclosed.example.com (Anonymous) — Sun, 30 Jan 2022 20:25:34 +0000

2022-01-30 - real story behind Wayland and X

some time ago a friend of mine shared with me the real story behind Wayland and X – cool insight into how Wayland came into being and why X11 must (eventually) go.

one thing that is still missing for me – X11 forwarding equivalent. this is my daily use case and not having it would make my life way more painful. :/

2022-01-30_-_world_ugliest_increment

anonymous@undisclosed.example.com (Anonymous) — Sun, 30 Jan 2022 20:11:37 +0000

2022-01-30 - world ugliest increment

some time ago i was working on a small project, that used elasticsearch as a data backend. i was facing an interesting issue, of having to do atomic increment, on a record. say under foo.bar.data.answer key. the problem however was that the target record could already exist… or not. if it did exist, it could already have some value assigned… or could have been created by a different request, that do not set that field at all.

the answer was painful, to say the least. i've ended up with this:

{
  "script": {
    "source": "if ( ctx._source.containsKey('foo') ) { ctx._source.foo.bar.data.answer += 1; } else { ctx._source.put('foo', params); }",
    "params": {
      "bar": {
        "data": {
          "answer": 1
        }
      }
    }
  },
  "upsert": {
    "date": "2020-07-20",
    "xxx": "ain't gonna do anything the first time - either upsert OR script will work..."
  }
}

so… ES will always execute either upsert or script. if there entry is not there, upsert will create some generic entry template. if the elemet exists, script will be called instead. script.source has a simple program – if given key (“branch”) exists, action is executed (here – incrementing a value). if not, content of params is put under the key foo, thus effectively crating some initial value, that later increments can work with.

in my case, the problem was even more extreme, as the path itself depended on some runtime values, thus this “incremenation” code was in fact a metaprogram, generating ES script, based on the path and values needed.

well, at the end of the day –it worked. but i guess this deserves a prize for a worst incrementation ever. it would be really nice to have ES feature, that would allow to address an existing key or create new, with a default value, in case it does not exist. such an operation would save a lot of effort.

2022-01-30_-_x11_forwarding_to_docker_container

anonymous@undisclosed.example.com (Anonymous) — Sun, 30 Jan 2022 20:21:18 +0000

2022-01-30 - X11 forwarding to docker container

sometime ago i had an issue with X11 forwarding for containers. for quite some time i just used setup SSHd in container and X11 forward via SSH. later on things improved. in fact my steam containerization efforts did use that approach, yet it was not exposed, so maybe it would be good to point it out explicitly.

the spell is:

docker run \
  -it \
  -rm \
  -u "$(id -u):$(id -g)" \
  -e DISPLAY \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  "your_image_with_x11_app"

so the key thing is to forward DISPLAY variable and path to X11 socket file. simple and straight forward… once you spent enough time on the net googling for quirks. ;)

btw: for QT-based applications you may also want to pass -e QT_X11_NO_MITSHM=1, to disabled shared memory usage.