[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <159559628247.2141315.2107013106060144287.stgit@warthog.procyon.org.uk>
Date: Fri, 24 Jul 2020 14:11:22 +0100
From: David Howells <dhowells@...hat.com>
To: viro@...iv.linux.org.uk
Cc: linux-security-module@...r.kernel.org,
Casey Schaufler <casey@...aufler-ca.com>,
James Morris <jamorris@...ux.microsoft.com>,
Stephen Smalley <sds@...ho.nsa.gov>,
Miklos Szeredi <mszeredi@...hat.com>, dhowells@...hat.com,
torvalds@...ux-foundation.org, casey@...aufler-ca.com,
sds@...ho.nsa.gov, nicolas.dichtel@...nd.com, raven@...maw.net,
christian@...uner.io, jlayton@...hat.com, kzak@...hat.com,
mszeredi@...hat.com, linux-api@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 0/4] Mount notifications
Here's a set of patches to add notifications for mount topology events,
such as mounting, unmounting, mount expiry, mount reconfiguration.
An LSM hook is included to an LSM to rule on whether or not a mount watch
may be set on a particular path.
Why do we want mount notifications? Whilst /proc/mounts can be polled, it
only tells you that something changed in your namespace. To find out, you
have to trawl /proc/mounts or similar to work out what changed in the mount
object attributes and mount topology. I'm told that the proc file holding
the namespace_sem is a point of contention, especially as the process of
generating the text descriptions of the mounts/superblocks can be quite
involved.
The notification generated here directly indicates the mounts involved in
any particular event and gives an idea of what the change was.
This is combined with a new fsinfo() system call that allows, amongst other
things, the ability to retrieve in one go an { id, change_counter } tuple
from all the children of a specified mount, allowing buffer overruns to be
dealt with quickly.
This is of use to systemd to improve efficiency:
https://lore.kernel.org/linux-fsdevel/20200227151421.3u74ijhqt6ekbiss@ws.net.home/
And it's not just Red Hat that's potentially interested in this:
https://lore.kernel.org/linux-fsdevel/293c9bd3-f530-d75e-c353-ddeabac27cf6@6wind.com/
The kernel patches can also be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=notifications-pipe-core
David
---
David Howells (4):
watch_queue: Make watch_sizeof() check record size
watch_queue: Add security hooks to rule on setting mount watches
watch_queue: Implement mount topology and attribute change notifications
watch_queue: sample: Display mount tree change notifications
Documentation/watch_queue.rst | 12 +-
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm/unistd32.h | 2 +
arch/ia64/kernel/syscalls/syscall.tbl | 1 +
arch/m68k/kernel/syscalls/syscall.tbl | 1 +
arch/microblaze/kernel/syscalls/syscall.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n32.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n64.tbl | 1 +
arch/mips/kernel/syscalls/syscall_o32.tbl | 1 +
arch/parisc/kernel/syscalls/syscall.tbl | 1 +
arch/powerpc/kernel/syscalls/syscall.tbl | 1 +
arch/s390/kernel/syscalls/syscall.tbl | 1 +
arch/sh/kernel/syscalls/syscall.tbl | 1 +
arch/sparc/kernel/syscalls/syscall.tbl | 1 +
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
arch/xtensa/kernel/syscalls/syscall.tbl | 1 +
fs/Kconfig | 9 +
fs/Makefile | 1 +
fs/mount.h | 21 ++
fs/mount_notify.c | 228 ++++++++++++++++++++
fs/namespace.c | 22 ++
include/linux/dcache.h | 1 +
include/linux/lsm_hook_defs.h | 3 +
include/linux/lsm_hooks.h | 6 +
include/linux/security.h | 8 +
include/linux/syscalls.h | 2 +
include/uapi/asm-generic/unistd.h | 4 +-
include/uapi/linux/watch_queue.h | 36 +++-
kernel/sys_ni.c | 3 +
samples/watch_queue/watch_test.c | 44 +++-
security/security.c | 7 +
33 files changed, 421 insertions(+), 4 deletions(-)
create mode 100644 fs/mount_notify.c
Powered by blists - more mailing lists