[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOQ4uxiu3hkx9KJdcb0EchARyM+mYS-Yz+xU9w4MBRUH6RoDzg@mail.gmail.com>
Date: Thu, 21 Nov 2024 12:39:07 +0100
From: Amir Goldstein <amir73il@...il.com>
To: Christian Brauner <brauner@...nel.org>
Cc: Jan Kara <jack@...e.cz>, Josef Bacik <josef@...icpanda.com>, kernel-team@...com,
linux-fsdevel@...r.kernel.org, torvalds@...ux-foundation.org,
viro@...iv.linux.org.uk, linux-xfs@...r.kernel.org,
linux-btrfs@...r.kernel.org, linux-mm@...ck.org, linux-ext4@...r.kernel.org
Subject: Re: [PATCH v8 02/19] fsnotify: opt-in for permission events at file
open time
> This is fine by me. But I want to preemptively caution to please not
> spread the disease of further defines based on such multi-bit defines
> like fanotify does. I'm specifically worried about stuff like:
>
> #define ALL_FSNOTIFY_PERM_EVENTS (FS_OPEN_PERM | FS_ACCESS_PERM | \
> FS_OPEN_EXEC_PERM)
>
> #define FS_EVENTS_POSS_ON_CHILD (ALL_FSNOTIFY_PERM_EVENTS | \
> FS_ACCESS | FS_MODIFY | FS_ATTRIB | \
> FS_CLOSE_WRITE | FS_CLOSE_NOWRITE | \
> FS_OPEN | FS_OPEN_EXEC)
What do you mean?
Those are masks for event groups, which we test in many cases.
What is wrong with those defined?
For FMODE_, we do not plan to add anymore defined (famous last words).
Thanks,
Amir.
Powered by blists - more mailing lists