Bug#985481: debootstrap: Detection of docker container is broken with cgroup v2

2021-03-18 Thread Arnaud R

I just noticed that there is snippet in scripts/debian-common:

    if doing_variant fakechroot || [ "$CONTAINER" = "docker" ]; then
    setup_proc_symlink
    fi

The following bugs are related to docker and /proc, and are possibly 
related:


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921815

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968927

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953637


On Fri, 19 Mar 2021 10:02:44 +0700 Arnaud Rebillout  
wrote:


> Package: debootstrap
> Version: 1.0.123
> Severity: normal
> Tags: patch
> User: de...@kali.org
> Usertags: origin-kali
>
> Dear Maintainer,
>
> The code that is meant to detect if debootstrap is running from within a
> docker container is broken with cgroup v2. Talking about this particular
> function and line in the file `functions`:
>
> detect_container () {
> [...]
> elif grep -qs '[[:space:]]/docker/.*/sys/fs/cgroup' 
/proc/1/mountinfo; then

> CONTAINER="docker"
>
> This code only works for cgroup v1.
>
> After some research, and also after looking into the code of
> systemd-detect-virt, it seems that the right way to detect a docker
> container these days is to check for the file '/.dockerenv'.
>
> Hence I'm proposing this patch:
> https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/52
>
> Thanks!
>
>
> -- More debug logs:
>
> Here's what I get on current Debian sid:
>
> $ cat /proc/cmdline
> BOOT_IMAGE=/vmlinuz-5.10.0-4-amd64 root=<> tro quiet
>
> $ mount | grep cgroup
> cgroup2 on /sys/fs/cgroup type cgroup2 
(rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)

>
> $ sudo docker run --rm -it debian:testing grep 
'[[:space:]]/docker/.*/sys/fs/cgroup' /proc/1/mountinfo

>  no ouput, the detection code is broken!
>
> $ sudo docker run --rm -it debian:testing ls -l /.dockerenv
> -rwxr-xr-x 1 root root 0 Mar 19 02:37 /.dockerenv
>
> Just out of curiosity, I tried to get the current detection code to
> work, by booting my system with cgroup v1 only. This is done by setting
> the two boot parameters `systemd.unified_cgroup_hierarchy=0` and
> `systemd.legacy_systemd_cgroup_controller=1`.
>
> Here are the logs:
>
> $ cat /proc/cmdline
> BOOT_IMAGE=/vmlinuz-5.10.0-4-amd64 root=<> ro quiet 
systemd.unified_cgroup_hierarchy=0 
systemd.legacy_systemd_cgroup_controller=1

>
> $ mount | grep cgroup
> tmpfs on /sys/fs/cgroup type tmpfs 
(ro,nosuid,nodev,noexec,size=4096k,nr_inodes=1024,mode=755)
> cgroup on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
> cgroup on /sys/fs/cgroup/memory type cgroup 
(rw,nosuid,nodev,noexec,relatime,memory)




Bug#983494: arch-test breaks debootstrap into empty chroot

2021-03-17 Thread Arnaud R
Also struggling with something similar, I thought I hit this bug, but 
actually no. Let me bring more details.


> arch-test looks for its test files *inside* the chroot;

That's not how I read the code. It copies the helper in the chroot, and 
then it runs it with chroot:


https://github.com/kilobyte/arch-test/blob/28f25fef25cdb09805a20986414bf3435c67d47f/arch-test#L56

And here's a corresponding trace, while running it with '-x':

||

|++ basename /usr/lib/arch-test/arm64|
|||
+ HELPER_F=arm64
||
+ cp -p /usr/lib/arch-test/arm64 
/builds/kalilinux/build-scripts/kali-docker/arm64/kali-rolling/arm64

||
+ trap 'rm 
'\''/builds/kalilinux/build-scripts/kali-docker/arm64/kali-rolling/arm64'\''' 
0

||
++ chroot /builds/kalilinux/build-scripts/kali-docker/arm64/kali-rolling 
/arm64

||
+ MSG=
||
+ '[' 127 -eq 0 -a x = xok ']'
||
+ echo 'arm64: not supported on this machine/kernel'
||
arm64: not supported on this machine/kernel
||+ exit 1|

|Cheers,|

|  Arnaud
|