Bug#985481: debootstrap: Detection of docker container is broken with cgroup v2
Hey Arnaud, thanks for the CC (and sorry for the delay).
On Mon, 12 Apr 2021 at 20:48, Arnaud Rebillout <arnaudr@kali.org> wrote:
> > Originally, ".dockerenv" was for transmitting the environment
> > variables of the container across the container boundary -- I would
> > not recommend relying on its existence either (IIRC, that code
> > you've linked to is the only reason it still exists). There's
> > likely something incriminatory inside /sys/fs/cgroup, but I haven't
> > checked recently.
> > https://github.com/moby/moby/issues/18355#issuecomment-220484748
> >
> > This makes it sounds like ".dockerenv" may be deprecated and later
> > removed.
>
> That's a good point, but it's also a 5 years old comment, and the
> .dockerenv file is still present these days.
>
> I would think that if Docker plans to remove it, they will issue a more
> formal deprecation warning that will give us enough time to fix things
> on our side. Also the fact that systemd checks for this file gives me
> more confidence that it's not just me doing something fancy here: it
> seems that this is the "de facto" solution to detect docker containers.
>
> FWIW, it's also the most common solution on Q&A sites like
> stackoverflow. Other people do that, because there is no better solution
> provided apparently. Unless I missed it.
>
> > Cgroup v2 is also mounted at /sys/fs/cgroup, so I wonder if the original
> > check should be rewritten to check for something under this path instead
> > of mountinfo? Also, using this /sys/fs/cgroup method, I'm not sure if
> > it's better debootstrap style to express the OR logical operator in the
> > regex or a shell "||" (ie: seems to be needed because the tree under
> > /sys/fs/cgroup is different between v1 and v2).
>
> I just had a quick look in /sys/fs/cgroup from within a container.
> Nothing obvious stands out, there's no file named docker, and nothing in
> the content of those files mentions docker. I'll attach the output below.
>
> I will CC Tianon, as he was the author of the comment mentioned above,
> and he might know better, 5 years after :)
>
> In short, Tianon, if you're reading those lines, our question is: what
> would be the right way to detect that we're running from within a docker
> container, apart from checking for the existence of the file
> `/.dockerenv` ???
Heh, I looked into the Docker code, and the only two places it's
currently used by Docker itself are in the line that creates it (as a
simple empty file in the container's init r/w layer) and some code in
libnetwork that uses it to detect that it's running inside a
container, of all things, which is both hilarious and depressing. A
container can also happily remove it during runtime without any ill
effects (as far as I can see), but the systemd code does include a
caveat that it's not a fully surefire detection method given that it
will often end up in non-Docker rootfses or filesystem images due to
them being created in/by/from Docker environments. :D
I'd definitely love to remove it completely in Docker itself, although
I believe other maintainers would rather use it for something more
useful (like some small amount of container metadata).
So the TLDR is that it's probably fine for now (definitely for
bullseye), but the final status is still very much TBD.
All that being said, I'm honestly a bit confused by debootstrap having
any kind of "detect Docker" code -- I run debootstrap inside Docker
containers a lot, and frankly expect it to run there exactly like it
does on my host (and I supply it with SYS_ADMIN appropriately as a
result, so it can properly mount things like /proc, /sys, and /dev).
♥,
- Tianon
4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
Reply to: