Detect you are running in a docker container - buildx

[bsutton]

Description

I’m the maintainer of the dcli package which is intended to replace bash using dart as an alternate scripting language.

https://pub.dev/packages/dcli

DCli has a feature that allow users to run privileged code by running sudo.

When running in a docker container we don’t need to use sudo (it doesn’t exist anyway).

As such, dcli needs a generic way to detect if it is running in a docker container.

Previously we have used the presence of ‘/.dockerenv’ to determine if we are in a docker container.

It however looks like that when running under buildx the .dockerenv file no longer exists.

As such I’m looking of a reliable way of detecting if dcli is running in a docker container.

Is there any official/correct way to determine if you are running in a docker container?

You can see from this thread there are a few suggested ways but these are all rather hacky.
https://forums.docker.com/t/detect-you-are-running-in-a-docker-container-buildx/139673

We need a reliable, stable and documented method to determine if we are running in a container.

For the likes of dcli, relying of an environment variable being injected (or any other user action) isn't sustainable as the user is unlikely to know the requirement and dcli needs to behave correctly 'out of the box'.

[cpuguy83]

Every way of trying to detect you are running in a container is going to be hacky.
We generally don't have a way to do this on purpose, because software should work the same no matter if it is in a container or not (with some caveats around restricting default capabilities to prevent container breakouts).

The most fail-safe way to detect if you need sudo is to check if your process has the capabilities it needs to perform whatever actions it needs to perform.
You can read your capability set from /proc/self/status, or if its file perms or something that's the issue, you can check your uid/gid and see if they match (or try to perform the action and catch EPERM from the kernel).

This is really what you want anyway, it doesn't matter if you are in a container or not.
A process in a container can require sudo just as much as a process outside one.

Alternatively, a cheap trick would be check if sudo exists and use that if it does.

[bsutton]

because software should work the same no matter if it is in a container or not

I'm pushing back here and so my clumsy statements aren't taken the wrong way, this is meant to be a positive discussion :)

I have a problem with this statement being overly opinionated. It always raises a red flag for me when I see these sort of overarching - we know better statements.

There are too many edge cases that we sitting here can't think of that may require this knowledge.

It would seem to me that providing a simple mechanism (like the .dockerenv) file that people can count on removes the issue from the discussion.

The documentation for this method can simply state that we your code should work the same when in a container, but if it doesn't, then this is the documented way to pivot.

We can be opinionated and forgiving.

[neersighted]

This is similar to kernel version checks -- it sounds tempting, but you really should not do it. Other containerization systems/builders may not provide the same guarantees, and rather than trying to build different tests/code-paths for e.g. rootless LXC, Podman/Buildah, and Docker/BuildKit, you really are better off doing a functional test.

That is to say: try to do what you need to do, and if it fails, consider falling back to sudo. Keep it simple, and adapt to the many diverse environments (e.g. FreeBSD Linuxulator!) your users might try to run you in as flexibly as you can, rather than making assumptions based on environment markers.