Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 30 Oct 2018 17:42:16 -0700
From:   Joel Fernandes <joel@joelfernandes.org>
To:     Aleksa Sarai <cyphar@cyphar.com>
Cc:     Daniel Colascione <dancol@google.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Tim Murray <timmurray@google.com>,
        Suren Baghdasaryan <surenb@google.com>
Subject: Re: [RFC PATCH] Implement /proc/pid/kill
Message-ID: <20181031004216.GC224709@google.com>
References: <20181029221037.87724-1-dancol@google.com>
 <20181030050012.u43lcvydy6nom3ul@yavin>
 <CAKOZuesKVic-5epRj8XcFNR_63SgvaPcbjDQuSLxNrEfS=O=Jg@mail.gmail.com>
 <20181030204501.jnbe7dyqui47hd2x@yavin>
 <20181030214243.GB32621@google.com>
 <20181030222339.ud4wfp75tidowuo4@yavin>
 <20181030223343.GB105735@joelaf.mtv.corp.google.com>
 <20181030224908.5rsldg4jsos7o5sa@yavin>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181030224908.5rsldg4jsos7o5sa@yavin>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Oct 31, 2018 at 09:49:08AM +1100, Aleksa Sarai wrote:
> On 2018-10-30, Joel Fernandes <joel@joelfernandes.org> wrote:
> > > > [...] 
> > > > > > > (Unfortunately
> > > > > > > there are lots of things that make it a bit difficult to use /proc/$pid
> > > > > > > exclusively for introspection of a process -- especially in the context
> > > > > > > of containers.)
> > > > > > 
> > > > > > Tons of things already break without a working /proc. What do you have in mind?
> > > > > 
> > > > > Heh, if only that was the only blocker. :P
> > > > > 
> > > > > The basic problem is that currently container runtimes either depend on
> > > > > some non-transient on-disk state (which becomes invalid on machine
> > > > > reboots or dead processes and so on), or on long-running processes that
> > > > > keep file descriptors required for administration of a container alive
> > > > > (think O_PATH to /dev/pts/ptmx to avoid malicious container filesystem
> > > > > attacks). Usually both.
> > > > > 
> > > > > What would be really useful would be having some way of "hiding away" a
> > > > > mount namespace (of the pid1 of the container) that has all of the
> > > > > information and bind-mounts-to-file-descriptors that are necessary for
> > > > > administration. If the container's pid1 dies all of the transient state
> > > > > has disappeared automatically -- because the stashed mount namespace has
> > > > > died. In addition, if this was done the way I'm thinking with (and this
> > > > > is the contentious bit) hierarchical mount namespaces you could make it
> > > > > so that the pid1 could not manipulate its current mount namespace to
> > > > > confuse the administrative process. You would also then create an
> > > > > intermediate user namespace to help with several race conditions (that
> > > > > have caused security bugs like CVE-2016-9962) we've seen when joining
> > > > > containers.
> > > > > 
> > > > > Unfortunately this all depends on hierarchical mount namespaces (and
> > > > > note that this would just be that NS_GET_PARENT gives you the mount
> > > > > namespace that it was created in -- I'm not suggesting we redesign peers
> > > > > or anything like that). This makes it basically a non-starter.
> > > > > 
> > > > > But if, on top of this ground-work, we then referenced containers
> > > > > entirely via an fd to /proc/$pid then you could also avoid PID reuse
> > > > > races (as well as being able to find out implicitly whether a container
> > > > > has died thanks to the error semantics of /proc/$pid). And that's the
> > > > > way I would suggest doing it (if we had these other things in place).
> > > > 
> > > > I didn't fully follow exactly what you mean. If you can explain for the
> > > > layman who doesn't know much experience with containers..
> > > > 
> > > > Are you saying that keeping open a /proc/$pid directory handle is not
> > > > sufficient to prevent PID reuse while the proc entries under /proc/$pid are
> > > > being looked into? If its not sufficient, then isn't that a bug? If it is
> > > > sufficient, then can we not just keep the handle open while we do whatever we
> > > > want under /proc/$pid ?
> > > 
> > > Sorry, I went on a bit of a tangent about various internals of container
> > > runtimes. My main point is that I would love to use /proc/$pid because
> > > it makes reuse handling very trivial and is always correct, but that
> > > there are things which stop us from being able to use it for everything
> > > (which is what my incoherent rambling was on about).
> > 
> > Ok thanks. So I am guessing if the following sequence works, then Dan's patch is not
> > needed.
> > 
> > 1. open /proc/<pid> directory
> > 2. inspect /proc/<pid> or do whatever with <pid>
> > 3. Issue the kill on <pid>
> > 4. Close the /proc/<pid> directory opened in step 1.
> > 
> > So unless I missed something, the above sequence will not cause any PID reuse
> > races.
> 
> (Sorry, I misunderstood your original question.)
> 
> The problem is that holding /proc/$pid doesn't stop the PID from dying
> and being reused. The benefit of holding open /proc/$pid is that you
> will get an error if you try to use it *after* the PID has died -- which
> means that you don't need to worry about explicitly checking for PID
> reuse if you are only operating with the file descriptor and not the
> PID.
> 
> So that sequence won't always work. There is a race where the pid might
> die and be recycled by the time you call kill(2) -- after you've done
> step 2. By tying step 2 and 3 together -- in this patch -- you remove
> the race (since in order to resolve the "kill" procfs file VFS must
> resolve the PID first -- atomically).

Makes sense, thanks.

> Though this race window is likely very tiny, and I wonder how much PID
> churn you really need to hit it.

Yeah that's what I asked initially how much of a problem it really is.

Also, I am wondering why the implementation does not want to keep a reference
to the task_struct for the duration of any open proc files/directories. Is
there a good reason?

 - Joel