Carlo C's questions

Criei uma imagem docker com gcco binutils e gdbo debugger instalados dentro.

Eu anexaria gdbdesse contêiner docker a um processo dentro de um lxccontêiner em execução no mesmo host Linux. O lxccontêiner usa seu próprio PIDnamespace, portanto, gdba execução no contêiner docker reclama que o processo de destino e o depurador não estão no mesmo PIDnamespace.

[SR-PCE-251:~]$ docker run -it --pid host --rm --cap-add=SYS_PTRACE --security-opt seccomp=unconfined carlo/ubuntu
root@e7b2db23af34:/#
root@e7b2db23af34:/# id
uid=0(root) gid=0(root) groups=0(root)
root@e7b2db23af34:/# 
root@e7b2db23af34:/# gdb -q attach 11365
attach: No such file or directory.
Attaching to process 11365
[New LWP 24283]
[New LWP 20025]
[New LWP 20024]
[New LWP 19992]
[New LWP 19991]
[New LWP 13974]
[New LWP 13970]
[New LWP 13969]
[New LWP 13968]
[New LWP 13967]
[New LWP 13962]
[New LWP 13958]
[New LWP 13957]
[New LWP 13954]
[New LWP 13952]
[New LWP 13944]
[New LWP 12078]
[New LWP 11822]
[New LWP 11543]
[New LWP 11515]
[New LWP 11489]
[New LWP 11483]
[New LWP 11482]
[New LWP 11477]
[New LWP 11476]

warning: "target:/proc/11365/exe": could not open as an executable file: Operation not permitted.

warning: `target:/proc/11365/exe': can't open to read symbols: Operation not permitted.

warning: Could not load vsyscall page because no executable was specified

warning: Target and debugger are in different PID namespaces; thread lists and other data are likely unreliable.  Connect to gdbserver inside the container.
0x00007f0bf997ac73 in ?? ()
(gdb)

Como posso me livrar disso?

Usando unshare -Umreu criei um novo usuário, mount namespaces onde o processo de chamada é movido. Então via mount -t tmpfs tmpfs /eu montei uma nova instância tmpfs na raiz /da árvore de diretórios dentro do novo mount namespace.

Como o tmpfsestá vazio, eu esperaria ver uma lista vazia do comando ls -la /, no entanto, aqui está a saída:

ubuntu@ubuntu:~$ unshare -Umr /bin/bash
root@ubuntu:~# mount -t tmpfs tmpfs /
root@ubuntu:~# ls -la /
total 5309704
drwxr-xr-x  24 nobody nogroup       4096 Nov 22  2023 .
drwxrwxrwt   2 root   root            40 Nov 11 15:47 ..
drwxr-xr-x   2 nobody nogroup       4096 Jan 25  2023 bin
drwxr-xr-x   3 nobody nogroup       4096 Jan 25  2023 boot
drwxr-xr-x   2 nobody nogroup       4096 Nov 11  2019 cdrom
drwxr-xr-x  17 nobody nogroup       3820 Aug 22 14:22 dev
drwxr-xr-x 105 nobody nogroup       4096 Mar 14  2024 etc
-rw-r--r--   1 root   root    1688371200 Jan 19  2021 GISO
drwxr-xr-x   3 nobody nogroup       4096 Nov 11  2019 home
lrwxrwxrwx   1 nobody nogroup         34 Jan 25  2023 initrd.img -> boot/initrd.img-4.15.0-202-generic
lrwxrwxrwx   1 nobody nogroup         34 Jan 25  2023 initrd.img.old -> boot/initrd.img-4.15.0-132-generic
drwxr-xr-x  21 nobody nogroup       4096 Jan 25  2023 lib
drwxr-xr-x   2 nobody nogroup       4096 Jan 25  2023 lib64
drwx------   2 nobody nogroup      16384 Nov 11  2019 lost+found
drwxr-xr-x   2 nobody nogroup       4096 Feb 10  2021 media
drwxr-xr-x   2 nobody nogroup       4096 Aug  5  2019 mnt
drwxr-xr-x   3 nobody nogroup       4096 Nov 26  2020 opt
dr-xr-xr-x 123 nobody nogroup          0 Aug 22 12:22 proc
drwx------   4 nobody nogroup       4096 Dec  6  2023 root
drwxr-xr-x  24 nobody nogroup        820 Nov 11 15:20 run
drwxr-xr-x   2 nobody nogroup      12288 Jan 25  2023 sbin
drwxr-xr-x   4 nobody nogroup       4096 Nov 11  2019 snap
drwxr-xr-x   3 nobody nogroup       4096 Jan 24  2020 srv
-rw-------   1 nobody nogroup 3748659200 Nov 11  2019 swap.img
dr-xr-xr-x  13 nobody nogroup          0 Nov 11 15:40 sys
drwxrwxrwt  10 nobody nogroup       4096 Nov 11 15:42 tmp
drwxr-xr-x  10 nobody nogroup       4096 Aug  5  2019 usr
drwxr-xr-x  13 nobody nogroup       4096 Aug  5  2019 var
lrwxrwxrwx   1 nobody nogroup         31 Jan 25  2023 vmlinuz -> boot/vmlinuz-4.15.0-202-generic
lrwxrwxrwx   1 nobody nogroup         31 Jan 25  2023 vmlinuz.old -> boot/vmlinuz-4.15.0-132-generic
root@ubuntu:~#

como no sistema de arquivos montado como /antes do tmpfs ser montado. Por que estou obtendo esse resultado?

Conforme mostrado abaixo, no meu sistema Ubuntu, carloo diretório tem a permissão sticky bit definida. Ele contém o arquivo file1de propriedade do usuário lab.

lab@ubuntu:~$ ll | grep carlo
drwxrwxr-t  2 ubuntu ubuntu  4096 Oct 31 08:09 carlo/

lab@ubuntu:~$ ll /home/ubuntu/carlo/file1 
-rw-rw-r-- 1 lab ubuntu 0 Oct 31 08:09 /home/ubuntu/carlo/file1
lab@ubuntu:~$

Como você pode ver, o usuário labé o proprietário file1, mas não pode renomear ou excluir o arquivo.

lab@ubuntu:~$ mv /home/ubuntu/carlo/file1 /home/ubuntu/carlo/file2
mv: cannot move '/home/ubuntu/carlo/file1' to '/home/ubuntu/carlo/file2': Permission denied

lab@ubuntu:~$ rm /home/ubuntu/carlo/file1
rm: cannot remove '/home/ubuntu/carlo/file1': Permission denied
lab@ubuntu:~$

Esse é um comportamento esperado?

A saída de lsnsparece diferente com base no privilégio do usuário que o executa. ubuntuusuário e rootusuário obtêm resultados diferentes:

ubuntu@ubuntu:~$ lsns 
        NS TYPE   NPROCS    PID USER   COMMAND
4026531834 time        6 134628 ubuntu /lib/systemd/systemd --user
4026531835 cgroup      6 134628 ubuntu /lib/systemd/systemd --user
4026531836 pid         6 134628 ubuntu /lib/systemd/systemd --user
4026531837 user        5 134628 ubuntu /lib/systemd/systemd --user
4026531838 uts         6 134628 ubuntu /lib/systemd/systemd --user
4026531839 ipc         6 134628 ubuntu /lib/systemd/systemd --user
4026531840 net         6 134628 ubuntu /lib/systemd/systemd --user
4026531841 mnt         5 134628 ubuntu /lib/systemd/systemd --user
4026532290 user        1 134689 ubuntu /usr/bin/podman
4026532291 mnt         1 134689 ubuntu /usr/bin/podman
ubuntu@ubuntu:~$ 
ubuntu@ubuntu:~$ 
ubuntu@ubuntu:~$ sudo lsns
        NS TYPE   NPROCS    PID USER             COMMAND
4026531834 time      115      1 root             /sbin/init
4026531835 cgroup    115      1 root             /sbin/init
4026531836 pid       112      1 root             /sbin/init
4026531837 user      113      1 root             /sbin/init
4026531838 uts       112      1 root             /sbin/init
4026531839 ipc       115      1 root             /sbin/init
4026531840 net       115      1 root             /sbin/init
4026531841 mnt       101      1 root             /sbin/init
4026531862 mnt         1     25 root             kdevtmpfs
4026532284 mnt         1    414 root             /lib/systemd/systemd-udevd
4026532285 uts         1    414 root             /lib/systemd/systemd-udevd
4026532286 mnt         1    469 systemd-timesync /lib/systemd/systemd-timesyncd
4026532287 uts         1    469 systemd-timesync /lib/systemd/systemd-timesyncd
4026532288 mnt         1    572 systemd-network  /lib/systemd/systemd-networkd
4026532289 mnt         1    608 systemd-resolve  /lib/systemd/systemd-resolved
4026532290 user        1 134689 ubuntu           /usr/bin/podman
4026532291 mnt         1 134689 ubuntu           /usr/bin/podman
4026532292 mnt         1   5369 root             /usr/libexec/upowerd
4026532293 user        1   5369 root             /usr/libexec/upowerd
4026532295 mnt         2 134974 root             unshare --fork --pid --mount-proc /bin/bash
4026532296 pid         2 134975 root             /bin/bash
4026532297 mnt         2 134981 root             unshare --fork --pid --mount-proc /bin/zsh
4026532298 pid         1 134982 root             /bin/zsh
4026532345 uts         1    655 root             /lib/systemd/systemd-logind
4026532346 mnt         1    631 root             /usr/sbin/irqbalance --foreground
4026532347 mnt         1    655 root             /lib/systemd/systemd-logind
4026532348 mnt         1    678 root             /usr/sbin/ModemManager
ubuntu@ubuntu:~$

Além disso, o nome do processo init do sistema Ubuntu é diferente: systemdvs /sbin/init. Qual é o motivo disso? Obrigado.

Estou ciente de que unshare -mcria um novo namespace de montagem movendo o processo que o executa para o novo namespace de montagem que está sendo criado.

Este último obtém uma cópia do namespace de montagem do pai. Na verdade, observe o seguinte

root@ubuntu:~# cat /proc/self/mountinfo 
25 31 0:23 / /sys rw,nosuid,nodev,noexec,relatime shared:7 - sysfs sysfs rw
26 31 0:24 / /proc rw,nosuid,nodev,noexec,relatime shared:12 - proc proc rw
27 31 0:5 / /dev rw,nosuid,relatime shared:2 - devtmpfs udev rw,size=4008708k,nr_inodes=1002177,mode=755,inode64
28 27 0:25 / /dev/pts rw,nosuid,noexec,relatime shared:3 - devpts devpts rw,gid=5,mode=620,ptmxmode=000
29 31 0:26 / /run rw,nosuid,nodev,noexec,relatime shared:5 - tmpfs tmpfs rw,size=812844k,mode=755,inode64
31 1 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw
32 25 0:6 / /sys/kernel/security rw,nosuid,nodev,noexec,relatime shared:8 - securityfs securityfs rw
33 27 0:28 / /dev/shm rw,nosuid,nodev shared:4 - tmpfs tmpfs rw,inode64
34 29 0:29 / /run/lock rw,nosuid,nodev,noexec,relatime shared:6 - tmpfs tmpfs rw,size=5120k,inode64
35 25 0:30 / /sys/fs/cgroup rw,nosuid,nodev,noexec,relatime shared:9 - cgroup2 cgroup2 rw,nsdelegate,memory_recursiveprot
36 25 0:31 / /sys/fs/pstore rw,nosuid,nodev,noexec,relatime shared:10 - pstore pstore rw
37 25 0:32 / /sys/fs/bpf rw,nosuid,nodev,noexec,relatime shared:11 - bpf bpf rw,mode=700
38 26 0:33 / /proc/sys/fs/binfmt_misc rw,relatime shared:13 - autofs systemd-1 rw,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=17383
39 27 0:20 / /dev/mqueue rw,nosuid,nodev,noexec,relatime shared:14 - mqueue mqueue rw
40 27 0:34 / /dev/hugepages rw,relatime shared:15 - hugetlbfs hugetlbfs rw,pagesize=2M
41 25 0:7 / /sys/kernel/debug rw,nosuid,nodev,noexec,relatime shared:16 - debugfs debugfs rw
42 25 0:12 / /sys/kernel/tracing rw,nosuid,nodev,noexec,relatime shared:17 - tracefs tracefs rw
---------------------------- output omitted ------------------------------------------
root@ubuntu:~#

root@ubuntu:~# unshare -m /bin/bash
root@ubuntu:~# 
root@ubuntu:~# cat /proc/self/mountinfo 
714 713 8:2 / / rw,relatime - ext4 /dev/sda2 rw
715 714 0:5 / /dev rw,nosuid,relatime - devtmpfs udev rw,size=4008708k,nr_inodes=1002177,mode=755,inode64
716 715 0:25 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=000
719 715 0:28 / /dev/shm rw,nosuid,nodev - tmpfs tmpfs rw,inode64
720 715 0:20 / /dev/mqueue rw,nosuid,nodev,noexec,relatime - mqueue mqueue rw
725 715 0:34 / /dev/hugepages rw,relatime - hugetlbfs hugetlbfs rw,pagesize=2M
726 714 0:26 / /run rw,nosuid,nodev,noexec,relatime - tmpfs tmpfs rw,size=812844k,mode=755,inode64
739 726 0:29 / /run/lock rw,nosuid,nodev,noexec,relatime - tmpfs tmpfs rw,size=5120k,inode64
740 726 0:36 / /run/credentials/systemd-sysusers.service ro,nosuid,nodev,noexec,relatime - ramfs none rw,mode=700
741 726 0:26 /snapd/ns /run/snapd/ns rw,nosuid,nodev,noexec,relatime - tmpfs tmpfs rw,size=812844k,mode=755,inode64
742 726 0:26 /netns /run/netns rw,nosuid,nodev,noexec,relatime - tmpfs tmpfs rw,size=812844k,mode=755,inode64
743 726 0:46 / /run/user/1000 rw,nosuid,nodev,relatime - tmpfs tmpfs rw,size=812840k,nr_inodes=203210,mode=700,uid=1000,gid=1000,inode64
744 714 0:23 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
745 744 0:6 / /sys/kernel/security rw,nosuid,nodev,noexec,relatime - securityfs securityfs rw
746 744 0:30 / /sys/fs/cgroup rw,nosuid,nodev,noexec,relatime - cgroup2 cgroup2 rw,nsdelegate,memory_recursiveprot
747 744 0:31 / /sys/fs/pstore rw,nosuid,nodev,noexec,relatime - pstore pstore rw
748 744 0:32 / /sys/fs/bpf rw,nosuid,nodev,noexec,relatime - bpf bpf rw,mode=700
814 744 0:7 / /sys/kernel/debug rw,nosuid,nodev,noexec,relatime - debugfs debugfs rw
815 744 0:12 / /sys/kernel/tracing rw,nosuid,nodev,noexec,relatime - tracefs tracefs rw
---------------------------- output omitted ------------------------------------------
root@ubuntu:~#

As saídas são ligeiramente diferentes, embora as dependências pai-filho do ponto de montagem sejam as mesmas ( Idssão esperadas diferenças nas duas primeiras colunas, pois os namespaces de montagem não são os mesmos).

Agora a questão é: há uma razão por trás da ordem diferente em que os pontos de montagem são realmente mostrados?

No Linux Ubuntu quando no terminal eu executo sudo suou sudo su -o sistema cria uma nova sessão com um novo controle pts, ou seja

ubuntu@ubuntu:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.5 LTS
Release:        22.04
Codename:       jammy
ubuntu@ubuntu:~$ 
ubuntu@ubuntu:~$ uname -a
Linux ubuntu 5.15.0-124-generic #134-Ubuntu SMP Fri Sep 27 20:20:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@ubuntu:~$ 
ubuntu@ubuntu:~$ ps
    PID TTY          TIME CMD
 143254 pts/0    00:00:00 bash
 143302 pts/0    00:00:00 ps
ubuntu@ubuntu:~$ 
ubuntu@ubuntu:~$ sudo su -
root@ubuntu:~# 
root@ubuntu:~# ps
    PID TTY          TIME CMD
 143304 pts/1    00:00:00 sudo
 143305 pts/1    00:00:00 su
 143306 pts/1    00:00:00 bash
 143316 pts/1    00:00:00 ps
root@ubuntu:~#

É um comportamento esperado?

Conforme solicitado nos comentários:

$ ps     
PID TTY          TIME CMD  
146202 pts/0    00:00:00 bash  
146231 pts/0    00:00:00 ps 

$ sudo -s 
root@ubuntu:/home/ubuntu# ps
PID TTY          TIME CMD  
146233 pts/1    00:00:00 sudo  
146234 pts/1    00:00:00 bash  
146240 pts/1    00:00:00 ps