Re: [PATCH v3 0/3] proc,security,selinux: let SELinux block FOLL_FORCE for /proc/self/mem

On Mon, Sep 14, 2026 at 01:05:39PM -0400, Paul Moore wrote:

On Thu, Sep 10, 2026 at 3:48 AM Christian Brauner [off-list ref] wrote:

quoted

On Mon, 07 Sep 2026 23:00:15 +0200, Jann Horn wrote:

quoted

proc,security,selinux: let SELinux block FOLL_FORCE for /proc/self/mem

The goal of this series is to let SELinux prevent the use of FOLL_FORCE
when a process writes into /proc/self/mem and the system is configured
with PROC_MEM_FORCE_ALWAYS (which used to be the default behavior, and
is still used by current Android devices).

[...]

Let's move this on a shared branch that both the vfs tree and the lsm
tree pull. That's the standard way of handling dependencies between two
subsystems that want to route code that touches both of them. Branch is
stable.

For some reason (/me looks at gmail) your email never hit my inbox, I
only noticed it now while reviewing Jann's patchset.

Oh weird?

Christian, can you explain why you merged LSM code that I haven't
ACK'd?  We've talked about this in the past and I think I've been
fairly clear about it; I wouldn't merge VFS code without an
ACK/Reviewed-by/etc. from you or Al, I've been expecting the same
consideration from you.

While I don't have a problem with a topic branch for this, can you
also explain why this topic branch should live in the VFS tree?  There
are more changes under security/ than fs/, and unless I've misread
Jann's cover letter, this entire patchset is focused around enabling
LSM/SELinux controls and not necessarily anything really new from a
VFS perspective.

See the reply on the bpf thread. I think this just a misunderstanding. I
was under the impression that with minor tweaks v2 was already acked by
lsm people.

In general, if a subsystems hooks into the vfs layer and filesystems
that are directly maintained by the vfs layer then the vfs tree provides
the shared branch. This is not at all specific to security. It's just
more pronounced for notify or security because hooks are accepted
layering violations that place constraints on how vfs code itself is
organized.

I think this is just a misunderstanding that would've been easy to
clarify without the kerfuffle.