https://lore.kernel.org/linux-fsdevel/20250307164216.GI2023217@ZenIV/
> Signed-off-by: Mateusz Guzik
Yeah, I like this much more than the original. Feel free to add:
Reviewed-by: Jan Kara
Honza
> This is an alternative
On Fri 07-03-25 14:19:38, Richard Guy Briggs wrote:
> On 2025-03-07 15:52, Jan Kara wrote:
> > On Thu 06-03-25 20:12:23, Richard Guy Briggs wrote:
> > > On 2025-03-06 16:06, Jan Kara wrote:
> > > > On Wed 05-03-25 16:33:19, Richard Guy Briggs wrote:
> > &g
On Thu 06-03-25 20:12:23, Richard Guy Briggs wrote:
> On 2025-03-06 16:06, Jan Kara wrote:
> > On Wed 05-03-25 16:33:19, Richard Guy Briggs wrote:
> > > When no audit rules are in place, fanotify event results are
> > > unconditionally dropped due to an explicit
, struct
> fanotify_response_info_audit_rule *friar)
> -{
> - if (!audit_dummy_context())
> - __audit_fanotify(response, friar);
> -}
> -
I think this is going to break compilation with !CONFIG_AUDITSYSCALL &&
CONFIG_FANOTIFY?
Honza
--
Jan Kara
SUSE Labs, CR
ures such as
subvolumes, snapshotting, etc.). Going to 128-bits for everybody seems
like a waste so at last LSF summit we've discussed about starting to push
file handles (output of name_to_handle_at(2)) as a replacement of st_ino
for file/dir identifier in a filesystem. For the kernel this would be
convenient because each filesystem can pack there what it needs. But
userspace guys were not thrilled by this (mainly due to the complexities of
dynamically sized identifier and passing it around). So this transition
isn't currently getting much traction and we'll see how things evolve.
Honza
--
Jan Kara
SUSE Labs, CR
evice* numbers, right? Exactly so that
st_ino + st_dev actually stay unique for each file. Whether it matters for
audit I don't dare to say :). Bcachefs does not care and returns non-unique
inode numbers.
Honza
--
Jan Kara
SUSE Labs, CR
re.
>
> So I'm appending the patches that I have on top of your patch in
> vfs.misc. Can you (other as well ofc) take a look and tell me whether
> that's not breaking anything completely other than later audit events?
The changes look good as far as I'm concerned but let me CC audit guys if
they have some thoughts regarding the change in generating audit event for
the parent. Paul, does it matter if open(O_CREAT) doesn't generate audit
event for the parent when we are failing open due to trailing slashes in
the pathname? Essentially we are speaking about moving:
audit_inode(nd->name, dir, AUDIT_INODE_PARENT);
from open_last_lookups() into lookup_open().
Honza
--
Jan Kara
SUSE Labs, CR
static int path_removexattr(const char __user
> *pathname,
> return error;
> }
>
> +SYSCALL_DEFINE4(removexattrat, int, dfd, const char __user *, pathname,
> + const char __user *, name, int, flags)
> +{
Same comment as above - "flags" -> "at_flags" and reorder args please.
Honza
--
Jan Kara
SUSE Labs, CR
