From: Paul Moore <paul@paul-moore.com>
To: "Christian Göttsche" <cgoettsche@seltendoof.de>, audit@vger.kernel.org
Cc: "Eric Paris" <eparis@redhat.com>,
"Christian Göttsche" <cgzones@googlemail.com>
Subject: Re: [PATCH RFC 4/4] audit: retain file paths for descriptor PATH records
Date: Mon, 28 Sep 2026 18:10:54 -0400 [thread overview]
Message-ID: <4efed6c106525339f6074e3c19c65139@paul-moore.com> (raw)
In-Reply-To: <20260917143948.106603-4-cgoettsche@seltendoof.de>
On Sep 17, 2026 =?UTF-8?q?Christian=20G=C3=B6ttsche?= <cgoettsche@seltendoof.de> wrote:
>
> fchown() and the other audit_file() callers collect inode metadata but
> emit name=(null), even though file->f_path is available.
>
> Retain the path with balanced dentry and mount references, and use the
> existing audit_log_d_path() formatter when no filename was collected.
> Release references on context cleanup and entry reuse. Filesystem
> exclusions continue to skip entry creation.
>
> The name reflects d_path() at event emission: concurrent renames and
> unlinks can affect it. Original lookup names retain precedence.
>
> This adds sizeof(struct path) to each audit_names. With the preceding
> capability and layout changes, audit_context grows from 880 to 960 bytes
> on the tested x86_64 SELinux configuration and remains in the 1 KiB
> kmalloc class. Other LSM configurations can have different object sizes.
>
> Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
> ---
> kernel/audit.h | 1 +
> kernel/auditsc.c | 19 +++++++++++++++++--
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/audit.h b/kernel/audit.h
> index bd798f8553a0..ef8d25af18c8 100644
> --- a/kernel/audit.h
> +++ b/kernel/audit.h
> @@ -76,6 +76,7 @@ struct audit_names {
> struct list_head list; /* audit_context->names_list */
>
> struct filename *name;
> + struct path fd_path; /* owned audit_file() fallback */
Since you were looking at ways to reduce the size of audit_names, I
suspect you could probably put name/name_len and fd_path in a union
as you should never have both in use at the same time, right? You would
need some way to indicate which was in use, but if you can steal some
bits back from the name_len field you could use that.
Just a thought, obviously what you have here is just fine.
> u64 ino;
> struct lsm_prop oprop;
> dev_t dev;
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index b14765cdd56f..3d2f130bc0f8 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -935,6 +935,7 @@ static inline void audit_free_names(struct audit_context *context)
> list_del(&n->list);
> if (n->name)
> putname(n->name);
> + path_put(&n->fd_path);
Do we need to reset n->fd_path.{dentry,mnt} to NULL just as we do the
audit_context's pwd field? You are already doing something similar in
audit_copy_inode().
> if (n->should_free)
> kfree(n);
> }
> @@ -1530,7 +1531,9 @@ static void audit_log_name(struct audit_context *context, struct audit_names *n,
> audit_log_n_untrustedstring(ab, n->name->name,
> n->name_len);
> }
> - } else
> + } else if (n->fd_path.dentry)
> + audit_log_d_path(ab, " name=", &n->fd_path);
> + else
> audit_log_format(ab, " name=(null)");
>
> if (n->ino != AUDIT_INO_UNSET)
> @@ -2222,6 +2225,10 @@ static void audit_copy_inode(struct audit_names *name,
> const struct dentry *dentry,
> struct inode *inode, unsigned int flags)
> {
> + /* An entry can be reused for a different lookup or object. */
> + path_put(&name->fd_path);
> + name->fd_path = (struct path) { };
> +
> name->ino = inode->i_ino;
> name->dev = inode->i_sb->s_dev;
> name->mode = inode->i_mode;
> @@ -2358,7 +2365,15 @@ void __audit_inode(struct filename *name, const struct dentry *dentry,
>
> void __audit_file(const struct file *file)
> {
> - __audit_inode(NULL, file->f_path.dentry, 0);
> + struct audit_names *n;
> +
> + n = audit_inode_entry(NULL, file->f_path.dentry, 0);
> + if (!n)
> + return;
> +
> + /* Resolve at event emission, so renames and unlinks can affect the name. */
> + n->fd_path = file->f_path;
> + path_get(&n->fd_path);
> }
>
> /**
> --
> 2.55.0
--
paul-moore.com
next prev parent reply other threads:[~2026-09-28 22:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 14:39 [RFC PATCH 1/4] audit: separate file and process capability storage Christian Göttsche
2026-09-17 14:39 ` [RFC PATCH 2/4] audit: compact name entries and context fields Christian Göttsche
2026-09-17 14:49 ` sashiko-bot
2026-09-28 22:10 ` [PATCH RFC " Paul Moore
2026-09-17 14:39 ` [RFC PATCH 3/4] audit: return the collected inode entry from a private helper Christian Göttsche
2026-09-17 14:45 ` sashiko-bot
2026-09-28 22:10 ` [PATCH RFC " Paul Moore
2026-09-17 14:39 ` [RFC PATCH 4/4] audit: retain file paths for descriptor PATH records Christian Göttsche
2026-09-17 14:58 ` sashiko-bot
2026-09-28 22:10 ` Paul Moore [this message]
2026-09-17 14:50 ` [RFC PATCH 1/4] audit: separate file and process capability storage sashiko-bot
2026-09-28 22:10 ` [PATCH RFC " Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4efed6c106525339f6074e3c19c65139@paul-moore.com \
--to=paul@paul-moore.com \
--cc=audit@vger.kernel.org \
--cc=cgoettsche@seltendoof.de \
--cc=cgzones@googlemail.com \
--cc=eparis@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox