All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.debian@gmx.de>
To: Yann Droneaud <ydroneaud@opteya.com>
Cc: Eric Paris <eparis@redhat.com>,
	Richard Guy Briggs <rgb@redhat.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	stable@vger.kernel.org, linux-api@vger.kernel.org,
	Jan Kara <jack@suse.cz>
Subject: Re: [PATCHv8 1/6] fanotify: enable close-on-exec on events' fd when requested in fanotify_init()
Date: Thu, 25 Sep 2014 22:57:23 +0200	[thread overview]
Message-ID: <542481B3.8070300@gmx.de> (raw)
In-Reply-To: <9d050a2db4f9cf68cd6cb038f16cccb0f73c6e66.1411562410.git.ydroneaud@opteya.com>

On 24.09.2014 15:11, Yann Droneaud wrote:
> According to commit 80af258867648 ('fanotify: groups can specify
> their f_flags for new fd'), file descriptors created as part of
> file access notification events inherit flags from the
> event_f_flags argument passed to syscall fanotify_init(2).
>
> So while it is legal for userspace to call fanotify_init() with
> O_CLOEXEC as part of its second argument, O_CLOEXEC is currently
> silently ignored.
>
> Indeed event_f_flags are only given to dentry_open(), which only
> seems to care about O_ACCMODE and O_PATH in do_dentry_open(),
> O_DIRECT in open_check_o_direct() and O_LARGEFILE in
> generic_file_open().

I tested on kernel 3.17.0-rc5. I passed O_CLOEXEC in event_f_flags.
When I called fcnt(event_metadata->fd, F_GETFD) it did not return 
FD_CLOEXEC. So I can confirm your observation that O_CLOEXEC is not 
working as expected.

I found this definition
#define get_unused_fd() get_unused_fd_flags(0)

So essentially when get_unused_fd() is called for a fanotify event 
O_CLOEXEC is ignored.

This is what your patch fixes.

>
> More, there's no effective check on event_f_flags value that
> would catch unknown / unsupported values, unlike the one on
> f_flags argument of the syscall (see FAN_ALL_INIT_FLAGS in
> include/uapi/linux/fanotify.h).

The fanotify_init(2) man page describes which flags are allowable in 
event_f_flags.

Could you, please, explain why the following code in fanotify_user.c is 
not to be considered an effective check:

     if (event_f_flags & ~FANOTIFY_INIT_ALL_EVENT_F_BITS)
         return -EINVAL;

     switch (event_f_flags & O_ACCMODE) {
     case O_RDONLY:
     case O_RDWR:
     case O_WRONLY:
         break;
     default:
         return -EINVAL;
     }

I CC Jan Kara as he reviewed the code.

Best regards

Heinrich Schuchardt

WARNING: multiple messages have this Message-ID (diff)
From: Heinrich Schuchardt <xypron.debian-Mmb7MZpHnFY@public.gmane.org>
To: Yann Droneaud <ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
Cc: Eric Paris <eparis-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
Subject: Re: [PATCHv8 1/6] fanotify: enable close-on-exec on events' fd when requested in fanotify_init()
Date: Thu, 25 Sep 2014 22:57:23 +0200	[thread overview]
Message-ID: <542481B3.8070300@gmx.de> (raw)
In-Reply-To: <9d050a2db4f9cf68cd6cb038f16cccb0f73c6e66.1411562410.git.ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>

On 24.09.2014 15:11, Yann Droneaud wrote:
> According to commit 80af258867648 ('fanotify: groups can specify
> their f_flags for new fd'), file descriptors created as part of
> file access notification events inherit flags from the
> event_f_flags argument passed to syscall fanotify_init(2).
>
> So while it is legal for userspace to call fanotify_init() with
> O_CLOEXEC as part of its second argument, O_CLOEXEC is currently
> silently ignored.
>
> Indeed event_f_flags are only given to dentry_open(), which only
> seems to care about O_ACCMODE and O_PATH in do_dentry_open(),
> O_DIRECT in open_check_o_direct() and O_LARGEFILE in
> generic_file_open().

I tested on kernel 3.17.0-rc5. I passed O_CLOEXEC in event_f_flags.
When I called fcnt(event_metadata->fd, F_GETFD) it did not return 
FD_CLOEXEC. So I can confirm your observation that O_CLOEXEC is not 
working as expected.

I found this definition
#define get_unused_fd() get_unused_fd_flags(0)

So essentially when get_unused_fd() is called for a fanotify event 
O_CLOEXEC is ignored.

This is what your patch fixes.

>
> More, there's no effective check on event_f_flags value that
> would catch unknown / unsupported values, unlike the one on
> f_flags argument of the syscall (see FAN_ALL_INIT_FLAGS in
> include/uapi/linux/fanotify.h).

The fanotify_init(2) man page describes which flags are allowable in 
event_f_flags.

Could you, please, explain why the following code in fanotify_user.c is 
not to be considered an effective check:

     if (event_f_flags & ~FANOTIFY_INIT_ALL_EVENT_F_BITS)
         return -EINVAL;

     switch (event_f_flags & O_ACCMODE) {
     case O_RDONLY:
     case O_RDWR:
     case O_WRONLY:
         break;
     default:
         return -EINVAL;
     }

I CC Jan Kara as he reviewed the code.

Best regards

Heinrich Schuchardt

  reply	other threads:[~2014-09-25 21:00 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-24 13:11 [PATCHv8 0/6] Getting rid of get_unused_fd() / enable close-on-exec Yann Droneaud
2014-09-24 13:11 ` Yann Droneaud
2014-09-24 13:11 ` Yann Droneaud
2014-09-24 13:11 ` Yann Droneaud
2014-09-24 13:11 ` [PATCHv8 1/6] fanotify: enable close-on-exec on events' fd when requested in fanotify_init() Yann Droneaud
2014-09-25 20:57   ` Heinrich Schuchardt [this message]
2014-09-25 20:57     ` Heinrich Schuchardt
2014-09-26  8:58     ` Yann Droneaud
2014-09-27  7:26       ` Heinrich Schuchardt
2014-09-29  8:49         ` [PATCHv8.1] " Yann Droneaud
2014-09-29 11:50           ` Jan Kara
2014-10-01 22:36           ` Andrew Morton
2014-10-01 22:36             ` Andrew Morton
2014-10-02  6:20             ` Yann Droneaud
2014-10-02  6:50               ` Mihai Donțu
2014-10-02  7:52               ` [PATCH] fanotify: add a flag to allow setting O_CLOEXEC on event fd Yann Droneaud
2014-10-02  9:13                 ` Pádraig Brady
2014-10-02  9:13                   ` Pádraig Brady
2014-10-02  9:13                   ` Pádraig Brady
2014-10-02 11:55                   ` Michael Kerrisk (man-pages)
2014-10-02 14:44                   ` Yann Droneaud
2014-10-02 14:44                     ` Yann Droneaud
2014-10-02 10:44             ` [PATCHv8.1] fanotify: enable close-on-exec on events' fd when requested in fanotify_init() Jan Kara
2014-10-02 10:44               ` Jan Kara
2014-10-02 19:46               ` Andrew Morton
2014-10-02 19:46                 ` Andrew Morton
2014-10-03  8:39                 ` [PATCHv8.2] " Yann Droneaud
2014-10-03  8:39                   ` Yann Droneaud
2014-09-24 13:11 ` [PATCHv8 2/6] ia64: trivial: replace get_unused_fd() by get_unused_fd_flags(0) Yann Droneaud
2014-09-24 13:11   ` Yann Droneaud
2014-09-24 13:11 ` [PATCHv8 3/6] ppc/cell: " Yann Droneaud
2014-09-24 13:11   ` Yann Droneaud
2014-09-24 13:11 ` [PATCHv8 4/6] binfmt_misc: " Yann Droneaud
2014-09-24 13:11 ` [PATCHv8 5/6] file: " Yann Droneaud
2014-09-24 13:11 ` [PATCHv8 6/6] file: remove get_unused_fd() macro Yann Droneaud

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=542481B3.8070300@gmx.de \
    --to=xypron.debian@gmx.de \
    --cc=akpm@linux-foundation.org \
    --cc=eparis@redhat.com \
    --cc=jack@suse.cz \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rgb@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=ydroneaud@opteya.com \
    /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.