All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
	Matthew Bobrowski <mbobrowski@mbobrowski.org>,
	linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH v4 07/15] fanotify: copy event fid info to user
Date: Thu, 3 Jan 2019 18:13:29 +0100	[thread overview]
Message-ID: <20190103171329.GC22409@quack2.suse.cz> (raw)
In-Reply-To: <20181202113826.32133-8-amir73il@gmail.com>

On Sun 02-12-18 13:38:18, Amir Goldstein wrote:
> If group requested FAN_REPORT_FID and event has file identifier,
> copy that information to user reading the event after event metadata.
> 
> fid information is formatted as struct fanotify_event_info_fid
> that includes a generic header struct fanotify_event_info_header,
> so that other info types could be defined in the future using the
> same header.
> 
> metadata->event_len includes the length of the fid information.
> 
> The fid information includes the filesystem's fsid (see statfs(2))
> followed by an NFS file handle of the file that could be passed as
> an argument to open_by_handle_at(2).
> 
> Cc: <linux-api@vger.kernel.org>
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>

The patch looks mostly good, some smaller comments below.

> ---
>  fs/notify/fanotify/fanotify.h      |  5 ++
>  fs/notify/fanotify/fanotify_user.c | 85 ++++++++++++++++++++++++++++--
>  include/uapi/linux/fanotify.h      | 20 +++++++
>  3 files changed, 105 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
> index cddebea5ff67..265fbaa2d5b7 100644
> --- a/fs/notify/fanotify/fanotify.h
> +++ b/fs/notify/fanotify/fanotify.h
> @@ -99,6 +99,11 @@ static inline bool fanotify_event_has_ext_fh(struct fanotify_event *event)
>  		!fanotify_inline_fh_len(event->fh_len);
>  }
>  
> +static inline void *fanotify_event_fh(struct fanotify_event *event)
> +{
> +	return fanotify_fid_fh(&event->fid, event->fh_len);
> +}
> +
>  /*
>   * Structure for permission fanotify events. It gets allocated and freed in
>   * fanotify_handle_event() since we wait there for user response. When the
> diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> index 9b9e6704f9e7..032a9a225a21 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -47,6 +47,22 @@ struct kmem_cache *fanotify_mark_cache __read_mostly;
>  struct kmem_cache *fanotify_event_cachep __read_mostly;
>  struct kmem_cache *fanotify_perm_event_cachep __read_mostly;
>  
> +static int fanotify_event_info_len(struct fanotify_event *event)
> +{
> +	if (!fanotify_event_has_fid(event))
> +		return 0;
> +
> +	return sizeof(struct fanotify_event_info_fid) +
> +		sizeof(struct file_handle) + event->fh_len;
> +}
> +
> +#define FANOTIFY_EVENT_ALIGN (sizeof(void *))

Please no. This will be different for 32-bit vs 64-bit and that is just
asking for trouble with applications that start depending on particular
alignment in weird ways. Just make this 4 and be done with it. The info
header is 4 bytes so any additional info will get 4-byte alignment at best
anyway.

> +
> +static int fanotify_round_event_info_len(struct fanotify_event *event)
> +{
> +	return roundup(fanotify_event_info_len(event), FANOTIFY_EVENT_ALIGN);
> +}
> +
>  /*
>   * Get an fsnotify notification event if one exists and is small
>   * enough to fit in "count". Return an error pointer if the count
> @@ -57,6 +73,9 @@ struct kmem_cache *fanotify_perm_event_cachep __read_mostly;
>  static struct fsnotify_event *get_one_event(struct fsnotify_group *group,
>  					    size_t count)
>  {
> +	size_t event_size = FAN_EVENT_METADATA_LEN;
> +	struct fanotify_event *event;
> +
>  	assert_spin_locked(&group->notification_lock);
>  
>  	pr_debug("%s: group=%p count=%zd\n", __func__, group, count);
> @@ -64,11 +83,18 @@ static struct fsnotify_event *get_one_event(struct fsnotify_group *group,
>  	if (fsnotify_notify_queue_is_empty(group))
>  		return NULL;
>  
> -	if (FAN_EVENT_METADATA_LEN > count)
> +	if (FAN_GROUP_FLAG(group, FAN_REPORT_FID)) {
> +		event = FANOTIFY_E(fsnotify_peek_first_event(group));
> +		event_size += fanotify_round_event_info_len(event);
> +	}
> +
> +	if (event_size > count)
>  		return ERR_PTR(-EINVAL);
>  
> -	/* held the notification_lock the whole time, so this is the
> -	 * same event we peeked above */
> +	/*
> +	 * Held the notification_lock the whole time, so this is the
> +	 * same event we peeked above
> +	 */
>  	return fsnotify_remove_first_event(group);
>  }
>  
> @@ -174,6 +200,47 @@ static int process_access_response(struct fsnotify_group *group,
>  	return 0;
>  }
>  
> +static int copy_fid_to_user(struct fanotify_event *event, char __user *buf)
> +{
> +	struct fanotify_event_info_fid info;
> +	struct file_handle handle;
> +	size_t fh_len = event->fh_len;
> +	size_t info_len = fanotify_event_info_len(event);
> +	size_t len = roundup(info_len, FANOTIFY_EVENT_ALIGN);
> +
> +	if (!info_len)
> +		return 0;
> +
> +	/* Copy event info fid header followed by vaiable sized file handle */
> +	info.hdr.info_type = FAN_EVENT_INFO_TYPE_FID;
> +	info.hdr.len = info_len;

I'm somewhat undecided whether the info_len should include the padding or
not. Including it would make code somewhat simpler (in particular userspace
would not have to be aware of FANOTIFY_EVENT_ALIGN - which you currently
don't propagate BTW), also fanotify_event_info_len() could just include the
padding and thus reduce the possibility we forget about it in some place.
OTOH not including it could save us from having to specify length of some
variable length array in some future event info type (e.g. here we would
not have to pass handle length if we didn't want to pass opaque
file_handle).

Currently I'm leaning more towards including it, what are your thoughts on
this?

> +	info.fsid = event->fid.fsid;
> +	info_len = sizeof(info) + sizeof(struct file_handle);

The value set here does not appear to be used anywhere?

> +	if (copy_to_user(buf, &info, sizeof(info)))
> +		return -EFAULT;

You can leak 1 byte of uninitialized stack contents to userspace here
(info.hdr.pad). I'd suggest you use empty initializers for info and handle
to make sure we cannot leak anything and the compiler will hopefully
eliminate the unnecessary zeroing.

> +
> +	buf += sizeof(info);
> +	len -= sizeof(info);
> +	handle.handle_type = event->fh_type;
> +	handle.handle_bytes = event->fh_len;

Use local variable fh_len here?

> +	if (copy_to_user(buf, &handle, sizeof(handle)))
> +		return -EFAULT;
> +
> +	buf += sizeof(handle);
> +	len -= sizeof(handle);
> +	if (copy_to_user(buf, fanotify_event_fh(event), fh_len))
> +		return -EFAULT;
> +
> +	/* Pad with 0's */
> +	buf += fh_len;
> +	len -= fh_len;
> +	WARN_ON_ONCE(len < 0 || len >= FANOTIFY_EVENT_ALIGN);
> +	if (len > 0 && clear_user(buf, len))
> +		return -EFAULT;
> +
> +	return 0;
> +}
> +

									Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2019-01-03 17:13 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-02 11:38 [PATCH v4 00/15] fanotify: add support for more event types Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 01/15] fsnotify: annotate directory entry modification events Amir Goldstein
2019-01-03 15:41   ` Jan Kara
2019-01-03 16:31     ` Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 02/15] fsnotify: send all event types to super block marks Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 03/15] fsnotify: move mask out of struct fsnotify_event Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 04/15] fanotify: rename struct fanotify_{,perm_}event_info Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 05/15] fanotify: open code fill_event_metadata() Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 06/15] fanotify: encode file identifier for FAN_REPORT_FID Amir Goldstein
2019-01-03 16:18   ` Jan Kara
2018-12-02 11:38 ` [PATCH v4 07/15] fanotify: copy event fid info to user Amir Goldstein
2019-01-03 17:13   ` Jan Kara [this message]
2019-01-04  3:58     ` Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 08/15] fanotify: enable FAN_REPORT_FID init flag Amir Goldstein
2018-12-08  9:26   ` Amir Goldstein
2018-12-10 16:20     ` Jan Kara
2018-12-11  6:12       ` Matthew Bobrowski
2018-12-11  6:58         ` Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 09/15] fanotify: cache fsid in fsnotify_mark_connector Amir Goldstein
2019-01-04  9:38   ` Jan Kara
2019-01-04  9:54     ` Jan Kara
2018-12-02 11:38 ` [PATCH v4 10/15] vfs: add vfs_get_fsid() helper Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 11/15] fanotify: use vfs_get_fsid() helper instead of vfs_statfs() Amir Goldstein
2019-01-04  9:55   ` Jan Kara
2018-12-02 11:38 ` [PATCH v4 12/15] fanotify: check FS_ISDIR flag instead of d_is_dir() Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 13/15] fanotify: support events with data type FSNOTIFY_EVENT_INODE Amir Goldstein
2019-01-04 10:17   ` Jan Kara
2019-01-04 11:12     ` Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 14/15] fanotify: add support for create/attrib/move/delete events Amir Goldstein
2019-01-04 10:26   ` Jan Kara
2018-12-02 11:38 ` [PATCH v4 15/15] fanotify: report FAN_ONDIR to listener with FAN_REPORT_FID Amir Goldstein
2019-01-04 10:57   ` Jan Kara
2019-01-04 11:42     ` Amir Goldstein
2019-01-04 12:18       ` Jan Kara
2019-01-04 12:39         ` Amir Goldstein
2019-01-05  0:34           ` Matthew Bobrowski
2019-01-05  8:18             ` Amir Goldstein
2019-01-07  7:40         ` Amir Goldstein
2019-01-04 12:19       ` Jan Kara
2019-01-04 23:46       ` Matthew Bobrowski
2019-01-05  7:59         ` Amir Goldstein
2019-01-05  9:49           ` Matthew Bobrowski
2019-01-07  7:37             ` Amir Goldstein
2019-01-04 11:00 ` [PATCH v4 00/15] fanotify: add support for more event types Jan Kara
2019-01-07  7:46   ` Amir Goldstein
2019-01-09 14:02     ` Jan Kara
2019-01-09 15:34       ` Amir Goldstein
2019-01-10  7:49         ` Amir Goldstein
2019-01-10  9:22           ` Jan Kara
2019-01-10  9:50             ` Amir Goldstein
2019-01-10 11:43               ` Jan Kara
2019-01-10 11:55                 ` Amir Goldstein
2019-01-10  8:53         ` Jan Kara
2019-01-10 10:10           ` Amir Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190103171329.GC22409@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=amir73il@gmail.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mbobrowski@mbobrowski.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.