Re: [PATCH 1/1] fanotify: check permissions when creating file descriptor

From: Jan Kara
Date: Tue Apr 22 2014 - 09:40:51 EST


On Sat 19-04-14 22:53:53, Heinrich Schuchardt wrote:
> When monitoring a directory or a mount with the fanotify API
> the call to fanotify_init checks,
> * the process has cap_sys_admin capability
>
> The call to fanotify_mark checks,
> * the process has read authorization for directory or mount
>
> A directory or mount may contain files for which the process
> has no read or write authorization.
> Yet when reading from the fanotify file descriptor, structures
> fanotify_event_metadata are returned, which contain a file
> descriptor for these files, and will allow to read or write.
>
> The patch adds an authorization check for read and write
> permission. In case of missing permission, reading from the
> fanotify file descriptor returns EACCES.
OK, am I right you are concerned about a situation where fanotify group
descriptor is passed to an unpriviledged process which handles all the
incoming events? I'm asking because the permission checking can be
relatively expensive (think of acls) so we better do it for a reason.
I'd prefer to hear from Eric what the original intention regarding
permissions was...

Honza
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@xxxxxx>
> ---
> fs/notify/fanotify/fanotify_user.c | 20 +++++++++++++++-----
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> index 4e565c8..5d22a20 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -62,6 +62,8 @@ static int create_fd(struct fsnotify_group *group,
> {
> int client_fd;
> struct file *new_file;
> + int mask;
> + int ret;
>
> pr_debug("%s: group=%p event=%p\n", __func__, group, event);
>
> @@ -75,11 +77,19 @@ static int create_fd(struct fsnotify_group *group,
> */
> /* it's possible this event was an overflow event. in that case dentry and mnt
> * are NULL; That's fine, just don't call dentry open */
> - if (event->path.dentry && event->path.mnt)
> - new_file = dentry_open(&event->path,
> - group->fanotify_data.f_flags | FMODE_NONOTIFY,
> - current_cred());
> - else
> + if (event->path.dentry && event->path.mnt) {
> + /* check permissions before granting access to file */
> + mask = MAY_READ;
> + if (group->fanotify_data.f_flags & (O_RDWR | O_WRONLY))
> + mask |= MAY_WRITE;
> + ret = inode_permission(event->path.dentry->d_inode, mask);
> + if (ret)
> + new_file = ERR_PTR(ret);
> + else
> + new_file = dentry_open(&event->path,
> + group->fanotify_data.f_flags | FMODE_NONOTIFY,
> + current_cred());
> + } else
> new_file = ERR_PTR(-EOVERFLOW);
> if (IS_ERR(new_file)) {
> /*
> --
> 1.9.1
>
--
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/