]>
Commit | Line | Data |
---|---|---|
a1703d59 GKH |
1 | From 0b37e097a648aa71d4db1ad108001e95b69a2da4 Mon Sep 17 00:00:00 2001 |
2 | From: Yann Droneaud <ydroneaud@opteya.com> | |
3 | Date: Thu, 9 Oct 2014 15:24:40 -0700 | |
4 | Subject: fanotify: enable close-on-exec on events' fd when requested in fanotify_init() | |
5 | MIME-Version: 1.0 | |
6 | Content-Type: text/plain; charset=UTF-8 | |
7 | Content-Transfer-Encoding: 8bit | |
8 | ||
9 | From: Yann Droneaud <ydroneaud@opteya.com> | |
10 | ||
11 | commit 0b37e097a648aa71d4db1ad108001e95b69a2da4 upstream. | |
12 | ||
13 | According to commit 80af258867648 ("fanotify: groups can specify their | |
14 | f_flags for new fd"), file descriptors created as part of file access | |
15 | notification events inherit flags from the event_f_flags argument passed | |
16 | to syscall fanotify_init(2)[1]. | |
17 | ||
18 | Unfortunately O_CLOEXEC is currently silently ignored. | |
19 | ||
20 | Indeed, event_f_flags are only given to dentry_open(), which only seems to | |
21 | care about O_ACCMODE and O_PATH in do_dentry_open(), O_DIRECT in | |
22 | open_check_o_direct() and O_LARGEFILE in generic_file_open(). | |
23 | ||
24 | It's a pity, since, according to some lookup on various search engines and | |
25 | http://codesearch.debian.net/, there's already some userspace code which | |
26 | use O_CLOEXEC: | |
27 | ||
28 | - in systemd's readahead[2]: | |
29 | ||
30 | fanotify_fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK, O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME); | |
31 | ||
32 | - in clsync[3]: | |
33 | ||
34 | #define FANOTIFY_EVFLAGS (O_LARGEFILE|O_RDONLY|O_CLOEXEC) | |
35 | ||
36 | int fanotify_d = fanotify_init(FANOTIFY_FLAGS, FANOTIFY_EVFLAGS); | |
37 | ||
38 | - in examples [4] from "Filesystem monitoring in the Linux | |
39 | kernel" article[5] by Aleksander Morgado: | |
40 | ||
41 | if ((fanotify_fd = fanotify_init (FAN_CLOEXEC, | |
42 | O_RDONLY | O_CLOEXEC | O_LARGEFILE)) < 0) | |
43 | ||
44 | Additionally, since commit 48149e9d3a7e ("fanotify: check file flags | |
45 | passed in fanotify_init"). having O_CLOEXEC as part of fanotify_init() | |
46 | second argument is expressly allowed. | |
47 | ||
48 | So it seems expected to set close-on-exec flag on the file descriptors if | |
49 | userspace is allowed to request it with O_CLOEXEC. | |
50 | ||
51 | But Andrew Morton raised[6] the concern that enabling now close-on-exec | |
52 | might break existing applications which ask for O_CLOEXEC but expect the | |
53 | file descriptor to be inherited across exec(). | |
54 | ||
55 | In the other hand, as reported by Mihai Dontu[7] close-on-exec on the file | |
56 | descriptor returned as part of file access notify can break applications | |
57 | due to deadlock. So close-on-exec is needed for most applications. | |
58 | ||
59 | More, applications asking for close-on-exec are likely expecting it to be | |
60 | enabled, relying on O_CLOEXEC being effective. If not, it might weaken | |
61 | their security, as noted by Jan Kara[8]. | |
62 | ||
63 | So this patch replaces call to macro get_unused_fd() by a call to function | |
64 | get_unused_fd_flags() with event_f_flags value as argument. This way | |
65 | O_CLOEXEC flag in the second argument of fanotify_init(2) syscall is | |
66 | interpreted and close-on-exec get enabled when requested. | |
67 | ||
68 | [1] http://man7.org/linux/man-pages/man2/fanotify_init.2.html | |
69 | [2] http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead-collect.c?id=v208#n294 | |
70 | [3] https://github.com/xaionaro/clsync/blob/v0.2.1/sync.c#L1631 | |
71 | https://github.com/xaionaro/clsync/blob/v0.2.1/configuration.h#L38 | |
72 | [4] http://www.lanedo.com/~aleksander/fanotify/fanotify-example.c | |
73 | [5] http://www.lanedo.com/2013/filesystem-monitoring-linux-kernel/ | |
74 | [6] http://lkml.kernel.org/r/20141001153621.65e9258e65a6167bf2e4cb50@linux-foundation.org | |
75 | [7] http://lkml.kernel.org/r/20141002095046.3715eb69@mdontu-l | |
76 | [8] http://lkml.kernel.org/r/20141002104410.GB19748@quack.suse.cz | |
77 | ||
78 | Link: http://lkml.kernel.org/r/cover.1411562410.git.ydroneaud@opteya.com | |
79 | Signed-off-by: Yann Droneaud <ydroneaud@opteya.com> | |
80 | Reviewed-by: Jan Kara <jack@suse.cz> | |
81 | Reviewed by: Heinrich Schuchardt <xypron.glpk@gmx.de> | |
82 | Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> | |
83 | Cc: Mihai Don\u021bu <mihai.dontu@gmail.com> | |
84 | Cc: Pádraig Brady <P@draigBrady.com> | |
85 | Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> | |
86 | Cc: Jan Kara <jack@suse.cz> | |
87 | Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu> | |
88 | Cc: Michael Kerrisk-manpages <mtk.manpages@gmail.com> | |
89 | Cc: Lino Sanfilippo <LinoSanfilippo@gmx.de> | |
90 | Cc: Richard Guy Briggs <rgb@redhat.com> | |
91 | Cc: Eric Paris <eparis@redhat.com> | |
92 | Cc: Al Viro <viro@zeniv.linux.org.uk> | |
93 | Cc: Michael Kerrisk <mtk.manpages@gmail.com> | |
94 | Signed-off-by: Andrew Morton <akpm@linux-foundation.org> | |
95 | Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | |
96 | Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | |
97 | ||
98 | --- | |
99 | fs/notify/fanotify/fanotify_user.c | 2 +- | |
100 | 1 file changed, 1 insertion(+), 1 deletion(-) | |
101 | ||
102 | --- a/fs/notify/fanotify/fanotify_user.c | |
103 | +++ b/fs/notify/fanotify/fanotify_user.c | |
104 | @@ -78,7 +78,7 @@ static int create_fd(struct fsnotify_gro | |
105 | ||
106 | pr_debug("%s: group=%p event=%p\n", __func__, group, event); | |
107 | ||
108 | - client_fd = get_unused_fd(); | |
109 | + client_fd = get_unused_fd_flags(group->fanotify_data.f_flags); | |
110 | if (client_fd < 0) | |
111 | return client_fd; | |
112 |