All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yann Droneaud <ydroneaud@opteya.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Yann Droneaud <ydroneaud@opteya.com>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Eric Paris <eparis@redhat.com>,
	Richard Guy Briggs <rgb@redhat.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	stable@vger.kernel.org, linux-api@vger.kernel.org,
	Jan Kara <jack@suse.cz>, Lino Sanfilippo <LinoSanfilippo@gmx.de>,
	Valdis Kletnieks <Valdis.Kletnieks@vt.edu>,
	Michael Kerrisk-manpages <mtk.manpages@gmail.com>
Subject: [PATCH] fanotify: add a flag to allow setting O_CLOEXEC on event fd
Date: Thu,  2 Oct 2014 09:52:29 +0200	[thread overview]
Message-ID: <1412236349-30035-1-git-send-email-ydroneaud@opteya.com> (raw)
In-Reply-To: <1412230855.28184.5.camel@localhost.localdomain>

In order to not potentially break applications which were
requesting O_CLOEXEC on event file descriptors but which
actually need it to be not effective as the kernel currently
ignore the flag, so the file descriptor is inherited accross
exec regardless of O_CLOEXEC (please forgive me for the
wording), this patch introduces FAN_FD_CLOEXEC flag to
fanotify_init() so that application can request O_CLOEXEC
to be effective.
Newer application would use FAN_FD_CLOEXEC flag along
O_CLOEXEC to enable close on exec on newly created
file descriptor:

  fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK|FAN_FD_CLOEXEC,
                     O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME);

Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
---

Hi Andrew,

While I believe fanotify_init() must enable close-on-exec
when requested by userspace to prevent unwelcomed security
issue, I understand your concerns regarding the possible
breakage on userspace application requesting O_CLOEXEC
but relying on it not being enable on file descriptor
created for the events.

So with a new flag to fanotify_init(), we could allow
newer applications to really enable O_CLOEXEC.

But I feel bad to have to force application to specify
twice they want close on exec:
  - are you sure ?
  - are you really sure ?
  - is this your final answer ?
  ...

Regards.

Yann Droneaud
OPTEYA


 fs/notify/fanotify/fanotify_user.c | 6 +++++-
 include/uapi/linux/fanotify.h      | 5 ++++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index c991616acca9..3c1fb1412f37 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -78,7 +78,7 @@ static int create_fd(struct fsnotify_group *group,
 
 	pr_debug("%s: group=%p event=%p\n", __func__, group, event);
 
-	client_fd = get_unused_fd_flags(group->fanotify_data.f_flags);
+	client_fd = get_unused_fd_flags(group->fanotify_data.f_flags & O_CLOEXEC);
 	if (client_fd < 0)
 		return client_fd;
 
@@ -706,6 +706,10 @@ SYSCALL_DEFINE2(fanotify_init, unsigned int, flags, unsigned int, event_f_flags)
 		return -EINVAL;
 	}
 
+	if ((event_f_flags & O_CLOEXEC) &&
+	    !(flags & FAN_FD_CLOEXEC))
+		event_f_flags ^= O_CLOEXEC;
+
 	user = get_current_user();
 	if (atomic_read(&user->fanotify_listeners) > FANOTIFY_DEFAULT_MAX_LISTENERS) {
 		free_uid(user);
diff --git a/include/uapi/linux/fanotify.h b/include/uapi/linux/fanotify.h
index 030508d195d3..f2d517be3152 100644
--- a/include/uapi/linux/fanotify.h
+++ b/include/uapi/linux/fanotify.h
@@ -36,7 +36,10 @@
 #define FAN_UNLIMITED_QUEUE	0x00000010
 #define FAN_UNLIMITED_MARKS	0x00000020
 
-#define FAN_ALL_INIT_FLAGS	(FAN_CLOEXEC | FAN_NONBLOCK | \
+/* flags used for fanotify_init() too */
+#define FAN_FD_CLOEXEC		0x00000100
+
+#define FAN_ALL_INIT_FLAGS	(FAN_CLOEXEC | FAN_NONBLOCK | FAN_FD_CLOEXEC | \
 				 FAN_ALL_CLASS_BITS | FAN_UNLIMITED_QUEUE |\
 				 FAN_UNLIMITED_MARKS)
 
-- 
1.9.3


  parent reply	other threads:[~2014-10-02  8:41 UTC|newest]

Thread overview: 33+ 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 ` [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
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               ` Yann Droneaud [this message]
2014-10-02  9:13                 ` [PATCH] fanotify: add a flag to allow setting O_CLOEXEC on event fd 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 ` [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=1412236349-30035-1-git-send-email-ydroneaud@opteya.com \
    --to=ydroneaud@opteya.com \
    --cc=LinoSanfilippo@gmx.de \
    --cc=Valdis.Kletnieks@vt.edu \
    --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=mtk.manpages@gmail.com \
    --cc=rgb@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xypron.glpk@gmx.de \
    --subject='Re: [PATCH] fanotify: add a flag to allow setting O_CLOEXEC on event fd' \
    /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

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.