When running an oci container that specifies a USER option in the build of the image the error Error: Failed to retrieve PID of executing child process is returned when trying to access incus exec. I was able to reproduce this behavior with the official haproxy and memcached images from docker hub. Locating a config.json file that defines the uid/gid of the container under /var/lib/incus directory, and changing it to root (0) the problem goes away.
Two questions:
Is it possible for incus to support running as a different user and be able to exec into the container?
Is there any added security benefit to this over changing the container to run as root? One that stands out on the surface is that a compromised container can install additional packages as root, but not as the less privileged user. That may not do much outside of the container but could have consequences in the container or aid any escaping.
The two that I tried were haproxy and memcached. I was only really using haproxy but went looking for another image on docker hub that switches users before the entrypoint. Those were the two, and both behaved the same. Other images like generic debian or Ubuntu just work as they execute the entrypoint as root. It was interesting tracking down the config.json file and essentially overriding the user the executes the entrypoint to root and no other changes, and it just works. For now I am working around it by building my own image from the original from docker hub and running as root, but then wonder how to avoid any container risk for exploitation. My biggest concern is the ability to easily install software that could help escape the container, but am not too familiar with the likelihood of that happening. Better to limit is my thoughts. Thank you for your support.