Thread (1 message) 1 message, 1 author, 2014-10-02

Re: [PATCH] fanotify: add a flag to allow setting O_CLOEXEC on event fd

From: Yann Droneaud <hidden>
Date: 2014-10-02 14:44:17
Also in: linux-fsdevel, lkml, stable

Hi,

Le jeudi 02 octobre 2014 à 10:13 +0100, Pádraig Brady a écrit :
On 10/02/2014 08:52 AM, Yann Droneaud wrote:
quoted
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);
Ugh really?
IMHO there should be widespread or at least known breakage with
O_CLOEXEC before adding messiness like this.
You should have read the other part of my message:
quoted
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.
quoted
So with a new flag to fanotify_init(), we could allow
newer applications to really enable O_CLOEXEC.
quoted
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 ?
 ...

I'm not really fond of this option.
It seems surprising to me that apps that would depend on
O_CLOEXEC being ineffective.
We have seen userspace developers making mistakes, and those mistakes
were mistakenly ignored by the kernel until someone try to fix the
mistake on kernel side, which broke the existing userspace application.
please reconsider this one.
I'm not going to promote this patch as it's a quick and dirty hack to
demonstrate what would be the other option.

Regards.

-- 
Yann Droneaud
OPTEYA
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help