[Bug 2037682] [NEW] curtin in-target issues if process uses /proc and new pid namespace is used

[Joao Andre Simioni]

Public bug reported:

Hi Team,

we are facing an issue when running commands "in-target" that rely on /proc/ information, but have been
launched in a new pid namespace (curtin behavior). 

One example is installing a dkms package using late-commands:

autoinstall:
  late-commands:
   - TARGET_MOUNT_POINT=/target curtin in-target -- apt install -y r8168-dkms
   
The dkms script (/usr/sbin/dkms) has a loop dependent on the the /proc/$pid of a spawned process:

(eval "$1" >/dev/null 2>&1) & pid=$!
while [ -d /proc/$pid ]; do

But the /proc is a bind to the default namespace /proc, and lists all the processes, but the new PID
is in the new namespace, so /proc/$pid will refer to a different process or will be non-existent.

Inspecting curtin behavior, here is what is happening:

ChrootableTarget will mount, by default, "/dev", "/proc", "/run", "/sys" to the target system with 
the --bind flag, before running the command, and after that, the command is executed using:

['unshare', '--fork', '--pid', '--', 'chroot', '/target', 'command']

The process pid and /proc will not show the same information.

Trying some possible solutions here, I thought about adding --mount-proc=/target/proc to unshare, 
but that fails:

unshare --mount-proc=/target/proc --fork --pid -- chroot /target hostname
unshare: cannot change /target/proc filesystem propagation: Invalid argument

I see that subp accepts a unshare_pid=False that would avoid creating a new namespace 
(and solving the problem for these scenarios), but I found no way to pass it to the curtin 
in-target command.

Another option would be create the new namespace, mount proc, and run
the command afterward.

Any suggestions on how to solve this?

Thanks

** Affects: curtin
     Importance: Undecided
         Status: Incomplete

** Summary changed:

- curting in-target issues if process uses /proc and new pid namespace is used
+ curtin in-target issues if process uses /proc and new pid namespace is used

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to curtin.
https://bugs.launchpad.net/bugs/2037682

Title:
  curtin in-target issues if process uses /proc and new pid namespace is
  used

Status in curtin:
  Incomplete

Bug description:
  Hi Team,

  we are facing an issue when running commands "in-target" that rely on /proc/ information, but have been
  launched in a new pid namespace (curtin behavior). 

  One example is installing a dkms package using late-commands:

  autoinstall:
    late-commands:
     - TARGET_MOUNT_POINT=/target curtin in-target -- apt install -y r8168-dkms
     
  The dkms script (/usr/sbin/dkms) has a loop dependent on the the /proc/$pid of a spawned process:

  (eval "$1" >/dev/null 2>&1) & pid=$!
  while [ -d /proc/$pid ]; do

  But the /proc is a bind to the default namespace /proc, and lists all the processes, but the new PID
  is in the new namespace, so /proc/$pid will refer to a different process or will be non-existent.

  Inspecting curtin behavior, here is what is happening:

  ChrootableTarget will mount, by default, "/dev", "/proc", "/run", "/sys" to the target system with 
  the --bind flag, before running the command, and after that, the command is executed using:

  ['unshare', '--fork', '--pid', '--', 'chroot', '/target', 'command']

  The process pid and /proc will not show the same information.

  Trying some possible solutions here, I thought about adding --mount-proc=/target/proc to unshare, 
  but that fails:

  unshare --mount-proc=/target/proc --fork --pid -- chroot /target hostname
  unshare: cannot change /target/proc filesystem propagation: Invalid argument

  I see that subp accepts a unshare_pid=False that would avoid creating a new namespace 
  (and solving the problem for these scenarios), but I found no way to pass it to the curtin 
  in-target command.

  Another option would be create the new namespace, mount proc, and run
  the command afterward.

  Any suggestions on how to solve this?

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/2037682/+subscriptions