Re: [PATCH] audit: add MOVE_MOUNT auxiliary record to log mount relocation

Paul Moore <[email protected]> Tue, 28 Jul 2026 17:22:09 -0400
Newsgroups org.kernel.vger.audit,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel
Message-ID <CAHC9VhTR-qaU-WFiuWZLfxhNisTtKXahLMHrH7-Ts5o09VMYcw@mail.gmail.com>
On Mon, Jul 13, 2026 at 1:00=E2=80=AFPM Ricardo Robaina <[email protected]=
m> wrote:
>
> Modern mount tools (util-linux >=3D 2.39.1) use the new mount API
> (fsopen, fsconfig, fsmount, move_mount) instead of the legacy mount(2)
> syscall. The generic SYSCALL audit record logs the move_mount syscall
> but does not capture the flags argument, creating an audit gap for
> mount relocation operations.
>
> Add a MOVE_MOUNT auxiliary record that logs the flags argument passed
> to move_mount(2). Pathnames and file descriptors are captured through
> existing PATH records and SYSCALL record arguments.
>
>  ----
>  type=3DPATH : item=3D0 name=3D/mnt/test_src inode=3D1 dev=3D00:41 ...
>  type=3DSYSCALL : arch=3Dx86_64 syscall=3Dmove_mount ...
>  type=3DMOVE_MOUNT : fs_flags=3D0x4
>  ----
>  type=3DPATH : item=3D0 name=3D/mnt/test_dst inode=3D27460862 dev=3Dfc:00=
 ...
>  type=3DSYSCALL : arch=3Dx86_64 syscall=3Dmove_mount ...
>  type=3DMOVE_MOUNT : fs_flags=3D0x4
>
> Link: https://github.com/linux-audit/audit-kernel/issues/152
> Link: https://github.com/linux-audit/audit-kernel/issues/153
> Signed-off-by: Ricardo Robaina <[email protected]>
> ---
>  fs/namespace.c             |  3 +++
>  include/linux/audit.h      | 10 ++++++++++
>  include/uapi/linux/audit.h |  1 +
>  kernel/auditsc.c           | 13 +++++++++++++
>  4 files changed, 27 insertions(+)

This is because we only log the first four syscall parameters,
correct?  To put this another way, if we logged all six syscall
parameters this wouldn't be an issue, yes?

I'm aware of the argument for only logging the first four parameters,
but I've always thought it was a rather foolish decision.  Perhaps now
is the time to spend to investigate adding those two missing
parameters to the SYSCALL record so we don't have to worry about hacky
workarounds like this (to be clear, I know this hacky workaround isn't
your fault, you are just trying to make the best of a kludgy thing
<g>).

--=20
paul-moore.com