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.