kernel/linux.git/fs/notify/fanotify, branch v6.6

fanotify: limit reporting of event with non-decodeable file handles

2023-10-19T14:19:20+00:00

Commit a95aef69a740 ("fanotify: support reporting non-decodeable file handles") merged in v6.5-rc1, added the ability to use an fanotify group with FAN_REPORT_FID mode to watch filesystems that do not support nfs export, but do know how to encode non-decodeable file handles, with the newly introduced AT_HANDLE_FID flag. At the time that this commit was merged, there were no filesystems in-tree with those traits. Commit 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles"), merged in v6.6-rc1, added this trait to overlayfs, thus allowing fanotify watching of overlayfs with FAN_REPORT_FID mode. In retrospect, allowing an fanotify filesystem/mount mark on such filesystem in FAN_REPORT_FID mode will result in getting events with file handles, without the ability to resolve the filesystem objects from those file handles (i.e. no open_by_handle_at() support). For v6.6, the safer option would be to allow this mode for inode marks only, where the caller has the opportunity to use name_to_handle_at() at the time of setting the mark. In the future we can revise this decision. Fixes: a95aef69a740 ("fanotify: support reporting non-decodeable file handles") Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara Message-Id: <20231018100000.2453965-2-amir73il@gmail.com>

fanotify: disallow mount/sb marks on kernel internal pseudo fs

2023-07-04T11:29:29+00:00

Hopefully, nobody is trying to abuse mount/sb marks for watching all anonymous pipes/inodes. I cannot think of a good reason to allow this - it looks like an oversight that dated back to the original fanotify API. Link: https://lore.kernel.org/linux-fsdevel/20230628101132.kvchg544mczxv2pm@quack3/ Fixes: 0ff21db9fcc3 ("fanotify: hooks the fanotify_mark syscall to the vfsmount code") Signed-off-by: Amir Goldstein Reviewed-by: Christian Brauner Signed-off-by: Jan Kara Message-Id: <20230629042044.25723-1-amir73il@gmail.com>

exportfs: check for error return value from exportfs_encode_*()

2023-05-25T11:17:04+00:00

The exportfs_encode_*() helpers call the filesystem ->encode_fh() method which returns a signed int. All the in-tree implementations of ->encode_fh() return a positive integer and FILEID_INVALID (255) for error. Fortify the callers for possible future ->encode_fh() implementation that will return a negative error value. name_to_handle_at() would propagate the returned error to the users if filesystem ->encode_fh() method returns an error. Reported-by: Dan Carpenter Link: https://lore.kernel.org/linux-fsdevel/ca02955f-1877-4fde-b453-3c1d22794740@kili.mountain/ Signed-off-by: Amir Goldstein Reviewed-by: Jeff Layton Signed-off-by: Jan Kara Message-Id: <20230524154825.881414-1-amir73il@gmail.com>

fanotify: support reporting non-decodeable file handles

2023-05-25T11:17:04+00:00

fanotify users do not always need to decode the file handles reported with FAN_REPORT_FID. Relax the restriction that filesystem needs to support NFS export and allow reporting file handles from filesystems that only support ecoding unique file handles. Even filesystems that do not have export_operations at all can fallback to use the default FILEID_INO32_GEN encoding, but we use the existence of export_operations as an indication that the encoded file handles will be sufficiently unique and that user will be able to compare them to filesystem objects using AT_HANDLE_FID flag to name_to_handle_at(2). For filesystems that do not support NFS export, users will have to use the AT_HANDLE_FID of name_to_handle_at(2) if they want to compare the object in path to the object fid reported in an event. Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara Message-Id: <20230502124817.3070545-5-amir73il@gmail.com>

exportfs: add explicit flag to request non-decodeable file handles

2023-05-22T16:08:37+00:00

So far, all callers of exportfs_encode_inode_fh(), except for fsnotify's show_mark_fhandle(), check that filesystem can decode file handles, but we would like to add more callers that do not require a file handle that can be decoded. Introduce a flag to explicitly request a file handle that may not to be decoded later and a wrapper exportfs_encode_fid() that sets this flag and convert show_mark_fhandle() to use the new wrapper. This will be used to allow adding fanotify support to filesystems that do not support NFS export. Acked-by: Jeff Layton Acked-by: Chuck Lever Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara Message-Id: <20230502124817.3070545-3-amir73il@gmail.com>

fanotify: use pidfd_prepare()

2023-04-03T09:16:57+00:00

We generally try to avoid installing a file descriptor into the caller's file descriptor table just to close it again via close_fd() in case an error occurs. Instead we reserve a file descriptor but don't install it into the caller's file descriptor table yet. If we fail for other, unrelated reasons we can just close the reserved file descriptor and if we make it past all meaningful error paths we just install it. Fanotify gets this right already for one fd type but not for pidfds. Use the new pidfd_prepare() helper to reserve a pidfd and a pidfd file and switch to the more common fd allocation and installation pattern. Acked-by: Jan Kara Message-Id: <20230327-pidfd-file-api-v1-3-5c0e9a3158e4@kernel.org> Signed-off-by: Christian Brauner

fanotify,audit: Allow audit to use the full permission event response

2023-02-07T11:53:53+00:00

This patch passes the full response so that the audit function can use all of it. The audit function was updated to log the additional information in the AUDIT_FANOTIFY record. Currently the only type of fanotify info that is defined is an audit rule number, but convert it to hex encoding to future-proof the field. Hex encoding suggested by Paul Moore . The {subj,obj}_trust values are {0,1,2}, corresponding to no, yes, unknown. Sample records: type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=3137 subj_trust=3 obj_trust=5 type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=0 subj_trust=2 obj_trust=2 Suggested-by: Steve Grubb Link: https://lore.kernel.org/r/3075502.aeNJFYEL58@x2 Tested-by: Steve Grubb Acked-by: Steve Grubb Signed-off-by: Richard Guy Briggs Signed-off-by: Jan Kara Message-Id:

fanotify: define struct members to hold response decision context

2023-02-07T11:53:53+00:00

This patch adds a flag, FAN_INFO and an extensible buffer to provide additional information about response decisions. The buffer contains one or more headers defining the information type and the length of the following information. The patch defines one additional information type, FAN_RESPONSE_INFO_AUDIT_RULE, to audit a rule number. This will allow for the creation of other information types in the future if other users of the API identify different needs. The kernel can be tested if it supports a given info type by supplying the complete info extension but setting fd to FAN_NOFD. It will return the expected size but not issue an audit record. Suggested-by: Steve Grubb Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2 Suggested-by: Jan Kara Link: https://lore.kernel.org/r/20201001101219.GE17860@quack2.suse.cz Tested-by: Steve Grubb Acked-by: Steve Grubb Signed-off-by: Richard Guy Briggs Signed-off-by: Jan Kara Message-Id: <10177cfcae5480926b7176321a28d9da6835b667.1675373475.git.rgb@redhat.com>

fanotify: Ensure consistent variable type for response

2023-02-07T11:53:32+00:00

The user space API for the response variable is __u32. This patch makes sure that the whole path through the kernel uses u32 so that there is no sign extension or truncation of the user space response. Suggested-by: Steve Grubb Link: https://lore.kernel.org/r/12617626.uLZWGnKmhe@x2 Signed-off-by: Richard Guy Briggs Acked-by: Paul Moore Tested-by: Steve Grubb Acked-by: Steve Grubb Signed-off-by: Jan Kara Message-Id: <3778cb0b3501bc4e686ba7770b20eb9ab0506cf4.1675373475.git.rgb@redhat.com>

Merge tag 'fsnotify-for_v6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs

2022-10-07T15:28:50+00:00

Pull fsnotify updates from Jan Kara: "Two cleanups for fsnotify code" * tag 'fsnotify-for_v6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: fanotify: Remove obsoleted fanotify_event_has_path() fsnotify: remove unused declaration