On Mon, Oct 14, 2024 at 9:30 AM Mickaël Salaün <mic@xxxxxxxxxxx> wrote: > On Fri, Oct 11, 2024 at 05:34:21PM -0400, Paul Moore wrote: > > On Thu, Oct 10, 2024 at 11:26 AM Mickaël Salaün <mic@xxxxxxxxxxx> wrote: > > > > > > Use the new inode_get_ino() helper to log the user space's view of > > > inode's numbers instead of the private kernel values. > > > > > > Cc: Paul Moore <paul@xxxxxxxxxxxxxx> > > > Cc: Eric Paris <eparis@xxxxxxxxxx> > > > Signed-off-by: Mickaël Salaün <mic@xxxxxxxxxxx> > > > --- > > > security/lsm_audit.c | 10 +++++----- > > > 1 file changed, 5 insertions(+), 5 deletions(-) > > > > While answering some off-list questions regarding audit, I realized > > we've got similar issues with audit_name->ino and audit_watch->ino. > > It would be nice if you could also fix that in this patchset. > > I can do that with the next version, but I'm wondering how it would fit > with the UAPI's struct audit_rule_data which has only 32-bit > fields/values. Don't worry about audit_rule_data for the moment, that's obviously going to require a userspace update as well to supply 64-bit inode numbers. My guess is we'll probably want to introduce a new field type, e.g. AUDIT_INODE64 or similar, that either carries the high 32-bits and is used in conjunction with AUDIT_INODE, or we create the new AUDIT_INODE64 field as a "special" filter field which takes up two of the u32 value spots. Regardless, let's not worry about that for this patchset and focus on ensuring the underlying kernel filtering and reporting mechanisms work as expected so that when we do sort out the UAPI issues everything *should* work. > Does 64-bit inode filtering currently work? Likely not :/ -- paul-moore.com
