On Wed 14-08-24 17:25:27, Josef Bacik wrote:
> From: Amir Goldstein <amir73il@xxxxxxxxx>
>
> With FAN_DENY response, user trying to perform the filesystem operation
> gets an error with errno set to EPERM.
>
> It is useful for hierarchical storage management (HSM) service to be able
> to deny access for reasons more diverse than EPERM, for example EAGAIN,
> if HSM could retry the operation later.
>
> Allow fanotify groups with priority FAN_CLASSS_PRE_CONTENT to responsd
> to permission events with the response value FAN_DENY_ERRNO(errno),
> instead of FAN_DENY to return a custom error.
>
> Limit custom error values to errors expected on read(2)/write(2) and
> open(2) of regular files. This list could be extended in the future.
> Userspace can test for legitimate values of FAN_DENY_ERRNO(errno) by
> writing a response to an fanotify group fd with a value of FAN_NOFD in
> the fd field of the response.
>
> The change in fanotify_response is backward compatible, because errno is
> written in the high 8 bits of the 32bit response field and old kernels
> reject respose value with high bits set.
>
> Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
...
> diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
> index 7f06355afa1f..d0722ef13138 100644
> --- a/fs/notify/fanotify/fanotify.h
> +++ b/fs/notify/fanotify/fanotify.h
> @@ -528,3 +528,13 @@ static inline unsigned int fanotify_mark_user_flags(struct fsnotify_mark *mark)
>
> return mflags;
> }
> +
> +static inline u32 fanotify_get_response_decision(u32 res)
> +{
> + return res & (FANOTIFY_RESPONSE_ACCESS | FANOTIFY_RESPONSE_FLAGS);
> +}
I'm not convinced this helper really helps readability. Probably I'll drop
it on commit...
> +
> +static inline int fanotify_get_response_errno(int res)
'res' should be u32 here. Otherwise C compiler would do arithmetic shifting
and returned errno would be wrong. I can fix this on commit.
> +{
> + return res >> FAN_ERRNO_SHIFT;
> +}
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
