From mboxrd@z Thu Jan  1 00:00:00 1970
From: giacomo@tesio.it (Giacomo Tesio)
Date: Tue, 24 Oct 2017 21:18:40 +0200
Subject: [9fans] Backgrounding a task
In-Reply-To: <98A462DFDA6CBC03654DC58C6B063013@musolino.id.au>
References: <98A462DFDA6CBC03654DC58C6B063013@musolino.id.au>
Message-ID: <CAHL7psGm=_6nkJcyHq3tB2_j9JEt0soQQGqBPs8KaqDGfEAD=A@mail.gmail.com>
Topicbox-Message-UUID: c409f4ce-ead9-11e9-9d60-3106f5b1d025

2017-10-24 16:21 GMT+02:00 Alex Musolino <alex at musolino.id.au>:
> Creating a child process is something that a process explicitly
> controls and the RFNOTEG flag of rfork(2) allows a process to control
> whether or not it shares its namespace with its children.  Allowing
> other, unrelated processes to fiddle with your namespace is quite
> different.
>
> Think about multiple processes owned by multiple users running on a
> cpu server.  Which processes should be allowed to join which
> namespaces?
>
> Perhaps allowing only the hostowner to join namespaces for debugging
> and administration purposes would be acceptable.

I like this idea a lot. I will give it a try in Jehanne.

However I'm going to use a slightly different design: writing "clone"
to /proc/$pid/ns will cause the current process to replace its own
name space with a *copy* of that of $pid.
If the owner of $pid is different from that of the current process or
if $pid is not running on the same machine as the current process, the
write will fail with an error.

However any change to the name space after the clone does not impact
the original process.

As for the plumber, I will add a message that make the plumber clone
the name space of a target process.

This should address both use-cases without issues for the processes
running in the original name space.


Giacomo