linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
@ 2018-09-27 13:05 Matthew Bobrowski
  2018-09-27 13:57 ` Amir Goldstein
                   ` (2 more replies)
  0 siblings, 3 replies; 20+ messages in thread
From: Matthew Bobrowski @ 2018-09-27 13:05 UTC (permalink / raw)
  To: Jan Kara; +Cc: amir73il, Steve Grubb, linux-fsdevel

This is a reduced version of a patch that I originally submitted a while ago.

In short, the fanotify API currently does not provide any means for user space
programs to receive events specifically when a file has been opened with the
intent to be executed. The FAN_EXEC flag will be set within the event mask when
a object has been opened with one of the open flags being __FMODE_EXEC.

Linux is used as an Operating System in some products, with an environment that
can be certified under the Common Criteria Operating System Protection Profile
(OSPP). This is a formal threat model for a class of technology. It requires
specific countermeasures to mitigate threats. It requires documentation to
explain how a product implements these countermeasures. It requires proof via a
test suite to demonstrate that the requirements are met, observed and checked by
an independent qualified third party. The latest set of requirements for OSPP
v4.2 can be found here:

https://www.niap-ccevs.org/Profile/Info.cfm?PPID=424&id=424

If you look on page 58, you will see the following requirement:

FPT_SRP_EXT.1 Software Restriction Policies   FPT_SRP_EXT.1.1

The OS shall restrict execution to only programs which match an administrator
specified [selection:
        file path,
        file digital signature,
        version,
        hash,
        [assignment: other characteristics]
]

This patch is to help aid in meeting this requirement.

Signed-off-by: Matthew Bobrowski <mbobrowski@mbobrowski.org>

---

diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index 94b52157bf8d..295549479be7 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -204,6 +204,7 @@ static int fanotify_handle_event(struct fsnotify_group *group,
 	BUILD_BUG_ON(FAN_OPEN_PERM != FS_OPEN_PERM);
 	BUILD_BUG_ON(FAN_ACCESS_PERM != FS_ACCESS_PERM);
 	BUILD_BUG_ON(FAN_ONDIR != FS_ISDIR);
+	BUILD_BUG_ON(FAN_EXEC != FS_EXEC);

 	if (!fanotify_should_send_event(iter_info, mask, data, data_type))
 		return 0;
diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c
index ababdbfab537..e22324f4642c 100644
--- a/fs/notify/fsnotify.c
+++ b/fs/notify/fsnotify.c
@@ -386,7 +386,7 @@ static __init int fsnotify_init(void)
 {
 	int ret;

-	BUG_ON(hweight32(ALL_FSNOTIFY_EVENTS) != 23);
+	BUG_ON(hweight32(ALL_FSNOTIFY_EVENTS) != 24);

 	ret = init_srcu_struct(&fsnotify_mark_srcu);
 	if (ret)
diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
index fd1ce10553bf..aad174c81322 100644
--- a/include/linux/fsnotify.h
+++ b/include/linux/fsnotify.h
@@ -216,6 +216,9 @@ static inline void fsnotify_open(struct file *file)
 	if (S_ISDIR(inode->i_mode))
 		mask |= FS_ISDIR;

+	if (file->f_flags & __FMODE_EXEC)
+		mask |= FS_EXEC;
+
 	fsnotify_parent(path, NULL, mask);
 	fsnotify(inode, mask, path, FSNOTIFY_EVENT_PATH, NULL, 0);
 }
diff --git a/include/linux/fsnotify_backend.h b/include/linux/fsnotify_backend.h
index b8f4182f42f1..edcdf2fd2328 100644
--- a/include/linux/fsnotify_backend.h
+++ b/include/linux/fsnotify_backend.h
@@ -38,6 +38,7 @@
 #define FS_DELETE		0x00000200	/* Subfile was deleted */
 #define FS_DELETE_SELF		0x00000400	/* Self was deleted */
 #define FS_MOVE_SELF		0x00000800	/* Self was moved */
+#define FS_EXEC 		0x00001000	/* File was executed */

 #define FS_UNMOUNT		0x00002000	/* inode on umount fs */
 #define FS_Q_OVERFLOW		0x00004000	/* Event queued overflowed */
@@ -62,7 +63,8 @@
 #define FS_EVENTS_POSS_ON_CHILD   (FS_ACCESS | FS_MODIFY | FS_ATTRIB |\
 				   FS_CLOSE_WRITE | FS_CLOSE_NOWRITE | FS_OPEN |\
 				   FS_MOVED_FROM | FS_MOVED_TO | FS_CREATE |\
-				   FS_DELETE | FS_OPEN_PERM | FS_ACCESS_PERM)
+				   FS_DELETE | FS_OPEN_PERM | FS_ACCESS_PERM |\
+				   FS_EXEC)

 #define FS_MOVE			(FS_MOVED_FROM | FS_MOVED_TO)

@@ -75,7 +77,8 @@
 			     FS_UNMOUNT | FS_Q_OVERFLOW | FS_IN_IGNORED | \
 			     FS_OPEN_PERM | FS_ACCESS_PERM | FS_EXCL_UNLINK | \
 			     FS_ISDIR | FS_IN_ONESHOT | FS_DN_RENAME | \
-			     FS_DN_MULTISHOT | FS_EVENT_ON_CHILD)
+			     FS_DN_MULTISHOT | FS_EVENT_ON_CHILD |\
+			     FS_EXEC)

 struct fsnotify_group;
 struct fsnotify_event;
diff --git a/include/uapi/linux/fanotify.h b/include/uapi/linux/fanotify.h
index 74247917de04..a850670333fd 100644
--- a/include/uapi/linux/fanotify.h
+++ b/include/uapi/linux/fanotify.h
@@ -10,7 +10,7 @@
 #define FAN_CLOSE_WRITE		0x00000008	/* Writtable file closed */
 #define FAN_CLOSE_NOWRITE	0x00000010	/* Unwrittable file closed */
 #define FAN_OPEN		0x00000020	/* File was opened */
-
+#define FAN_EXEC 		0x00001000	/* File was executed */
 #define FAN_Q_OVERFLOW		0x00004000	/* Event queued overflowed */

 #define FAN_OPEN_PERM		0x00010000	/* File open in perm check */
@@ -69,7 +69,8 @@
 #define FAN_ALL_EVENTS (FAN_ACCESS |\
 			FAN_MODIFY |\
 			FAN_CLOSE |\
-			FAN_OPEN)
+			FAN_OPEN |\
+			FAN_EXEC)

 /*
  * All events which require a permission response from userspace

^ permalink raw reply related	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-09-27 13:05 [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC Matthew Bobrowski
@ 2018-09-27 13:57 ` Amir Goldstein
  2018-09-28  1:27   ` Matthew Bobrowski
  2018-10-01 10:58 ` Jan Kara
  2018-10-01 11:06 ` Jan Kara
  2 siblings, 1 reply; 20+ messages in thread
From: Amir Goldstein @ 2018-09-27 13:57 UTC (permalink / raw)
  To: Matthew Bobrowski; +Cc: Jan Kara, Steve Grubb, linux-fsdevel, linux-api

[cc: linux-api]

On Thu, Sep 27, 2018 at 4:05 PM Matthew Bobrowski
<mbobrowski@mbobrowski.org> wrote:
>
> This is a reduced version of a patch that I originally submitted a while ago.
>
> In short, the fanotify API currently does not provide any means for user space
> programs to receive events specifically when a file has been opened with the
> intent to be executed. The FAN_EXEC flag will be set within the event mask when
> a object has been opened with one of the open flags being __FMODE_EXEC.
>
> Linux is used as an Operating System in some products, with an environment that
> can be certified under the Common Criteria Operating System Protection Profile
> (OSPP). This is a formal threat model for a class of technology. It requires
> specific countermeasures to mitigate threats. It requires documentation to
> explain how a product implements these countermeasures. It requires proof via a
> test suite to demonstrate that the requirements are met, observed and checked by
> an independent qualified third party. The latest set of requirements for OSPP
> v4.2 can be found here:
>
> https://www.niap-ccevs.org/Profile/Info.cfm?PPID=424&id=424
>
> If you look on page 58, you will see the following requirement:
>
> FPT_SRP_EXT.1 Software Restriction Policies   FPT_SRP_EXT.1.1
>
> The OS shall restrict execution to only programs which match an administrator
> specified [selection:
>         file path,
>         file digital signature,
>         version,
>         hash,
>         [assignment: other characteristics]
> ]
>
> This patch is to help aid in meeting this requirement.
>
> Signed-off-by: Matthew Bobrowski <mbobrowski@mbobrowski.org>
>
> ---
>
> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index 94b52157bf8d..295549479be7 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
> @@ -204,6 +204,7 @@ static int fanotify_handle_event(struct fsnotify_group *group,
>         BUILD_BUG_ON(FAN_OPEN_PERM != FS_OPEN_PERM);
>         BUILD_BUG_ON(FAN_ACCESS_PERM != FS_ACCESS_PERM);
>         BUILD_BUG_ON(FAN_ONDIR != FS_ISDIR);
> +       BUILD_BUG_ON(FAN_EXEC != FS_EXEC);
>
>         if (!fanotify_should_send_event(iter_info, mask, data, data_type))
>                 return 0;
> diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c
> index ababdbfab537..e22324f4642c 100644
> --- a/fs/notify/fsnotify.c
> +++ b/fs/notify/fsnotify.c
> @@ -386,7 +386,7 @@ static __init int fsnotify_init(void)
>  {
>         int ret;
>
> -       BUG_ON(hweight32(ALL_FSNOTIFY_EVENTS) != 23);
> +       BUG_ON(hweight32(ALL_FSNOTIFY_EVENTS) != 24);
>
>         ret = init_srcu_struct(&fsnotify_mark_srcu);
>         if (ret)
> diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
> index fd1ce10553bf..aad174c81322 100644
> --- a/include/linux/fsnotify.h
> +++ b/include/linux/fsnotify.h
> @@ -216,6 +216,9 @@ static inline void fsnotify_open(struct file *file)
>         if (S_ISDIR(inode->i_mode))
>                 mask |= FS_ISDIR;
>
> +       if (file->f_flags & __FMODE_EXEC)
> +               mask |= FS_EXEC;
> +

I think that may be breaking existing programs that do not expect to see
this bit in the event mask (i.e. if they only requested to see FAN_OPEN).
A possible mitigation would be to set a group flag FAN_ENABLE_EXEC
on the first time that user requests the FAN_EXEC event and then
compute the FAN_ALL_OUTGOING_EVENTS at runtime based on that
group flag (see example with FAN_ONDIR in my dev branch [1]).
Unlike my example, I don't think you have to expose the init flag
FAN_ENABLE_EXEC to users, because it can be set implicitly on the
first FAN_EXEC mark request.

>         fsnotify_parent(path, NULL, mask);
>         fsnotify(inode, mask, path, FSNOTIFY_EVENT_PATH, NULL, 0);
>  }
> diff --git a/include/linux/fsnotify_backend.h b/include/linux/fsnotify_backend.h
> index b8f4182f42f1..edcdf2fd2328 100644
> --- a/include/linux/fsnotify_backend.h
> +++ b/include/linux/fsnotify_backend.h
> @@ -38,6 +38,7 @@
>  #define FS_DELETE              0x00000200      /* Subfile was deleted */
>  #define FS_DELETE_SELF         0x00000400      /* Self was deleted */
>  #define FS_MOVE_SELF           0x00000800      /* Self was moved */
> +#define FS_EXEC                0x00001000      /* File was executed */
>
>  #define FS_UNMOUNT             0x00002000      /* inode on umount fs */
>  #define FS_Q_OVERFLOW          0x00004000      /* Event queued overflowed */
> @@ -62,7 +63,8 @@
>  #define FS_EVENTS_POSS_ON_CHILD   (FS_ACCESS | FS_MODIFY | FS_ATTRIB |\
>                                    FS_CLOSE_WRITE | FS_CLOSE_NOWRITE | FS_OPEN |\
>                                    FS_MOVED_FROM | FS_MOVED_TO | FS_CREATE |\
> -                                  FS_DELETE | FS_OPEN_PERM | FS_ACCESS_PERM)
> +                                  FS_DELETE | FS_OPEN_PERM | FS_ACCESS_PERM |\
> +                                  FS_EXEC)
>
>  #define FS_MOVE                        (FS_MOVED_FROM | FS_MOVED_TO)
>
> @@ -75,7 +77,8 @@
>                              FS_UNMOUNT | FS_Q_OVERFLOW | FS_IN_IGNORED | \
>                              FS_OPEN_PERM | FS_ACCESS_PERM | FS_EXCL_UNLINK | \
>                              FS_ISDIR | FS_IN_ONESHOT | FS_DN_RENAME | \
> -                            FS_DN_MULTISHOT | FS_EVENT_ON_CHILD)
> +                            FS_DN_MULTISHOT | FS_EVENT_ON_CHILD |\
> +                            FS_EXEC)
>
>  struct fsnotify_group;
>  struct fsnotify_event;
> diff --git a/include/uapi/linux/fanotify.h b/include/uapi/linux/fanotify.h
> index 74247917de04..a850670333fd 100644
> --- a/include/uapi/linux/fanotify.h
> +++ b/include/uapi/linux/fanotify.h
> @@ -10,7 +10,7 @@
>  #define FAN_CLOSE_WRITE                0x00000008      /* Writtable file closed */
>  #define FAN_CLOSE_NOWRITE      0x00000010      /* Unwrittable file closed */
>  #define FAN_OPEN               0x00000020      /* File was opened */
> -
> +#define FAN_EXEC               0x00001000      /* File was executed */
>  #define FAN_Q_OVERFLOW         0x00004000      /* Event queued overflowed */
>
>  #define FAN_OPEN_PERM          0x00010000      /* File open in perm check */
> @@ -69,7 +69,8 @@
>  #define FAN_ALL_EVENTS (FAN_ACCESS |\
>                         FAN_MODIFY |\
>                         FAN_CLOSE |\
> -                       FAN_OPEN)
> +                       FAN_OPEN |\
> +                       FAN_EXEC)
>

It *might* be better not to change the uapi exposed value of
FAN_ALL_EVENTS. I think in retrospect that exposing it was a mistake,
because no user program should be using this value, although for
brevity, some programs might be using this value and if said program
is recompiled with new headers, said program won't run on old kernels.
An alternative approach is to use new constants for internal kernel use,
and leave the old legacy uapi constants frozen in the past. see suggested
implementation on my dev branch [2].

Thanks,
Amir.

[1] https://github.com/amir73il/linux/commit/6fca47dfb793d1c00935e2f91d47ba209f61c4e8
[2] https://github.com/amir73il/linux/commit/24e970b4756ef9435cdbc8f35c29ff5ab65cfa81

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-09-27 13:57 ` Amir Goldstein
@ 2018-09-28  1:27   ` Matthew Bobrowski
  2018-09-28  5:39     ` Amir Goldstein
  0 siblings, 1 reply; 20+ messages in thread
From: Matthew Bobrowski @ 2018-09-28  1:27 UTC (permalink / raw)
  To: Amir Goldstein; +Cc: Jan Kara, Steve Grubb, linux-fsdevel, linux-api

Hi Amir,

On 27/9/18 11:57 pm, Amir Goldstein wrote:
> [cc: linux-api]
> 
> On Thu, Sep 27, 2018 at 4:05 PM Matthew Bobrowski
> <mbobrowski@mbobrowski.org> wrote:
>>
>> This is a reduced version of a patch that I originally submitted a while ago.
>>
>> In short, the fanotify API currently does not provide any means for user space
>> programs to receive events specifically when a file has been opened with the
>> intent to be executed. The FAN_EXEC flag will be set within the event mask when
>> a object has been opened with one of the open flags being __FMODE_EXEC.
>>
>> Linux is used as an Operating System in some products, with an environment that
>> can be certified under the Common Criteria Operating System Protection Profile
>> (OSPP). This is a formal threat model for a class of technology. It requires
>> specific countermeasures to mitigate threats. It requires documentation to
>> explain how a product implements these countermeasures. It requires proof via a
>> test suite to demonstrate that the requirements are met, observed and checked by
>> an independent qualified third party. The latest set of requirements for OSPP
>> v4.2 can be found here:
>>
>> https://www.niap-ccevs.org/Profile/Info.cfm?PPID=424&id=424
>>
>> If you look on page 58, you will see the following requirement:
>>
>> FPT_SRP_EXT.1 Software Restriction Policies   FPT_SRP_EXT.1.1
>>
>> The OS shall restrict execution to only programs which match an administrator
>> specified [selection:
>>         file path,
>>         file digital signature,
>>         version,
>>         hash,
>>         [assignment: other characteristics]
>> ]
>>
>> This patch is to help aid in meeting this requirement.
>>
>> Signed-off-by: Matthew Bobrowski <mbobrowski@mbobrowski.org>
>>
>> ---
>>
>> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
>> index 94b52157bf8d..295549479be7 100644
>> --- a/fs/notify/fanotify/fanotify.c
>> +++ b/fs/notify/fanotify/fanotify.c
>> @@ -204,6 +204,7 @@ static int fanotify_handle_event(struct fsnotify_group *group,
>>         BUILD_BUG_ON(FAN_OPEN_PERM != FS_OPEN_PERM);
>>         BUILD_BUG_ON(FAN_ACCESS_PERM != FS_ACCESS_PERM);
>>         BUILD_BUG_ON(FAN_ONDIR != FS_ISDIR);
>> +       BUILD_BUG_ON(FAN_EXEC != FS_EXEC);
>>
>>         if (!fanotify_should_send_event(iter_info, mask, data, data_type))
>>                 return 0;
>> diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c
>> index ababdbfab537..e22324f4642c 100644
>> --- a/fs/notify/fsnotify.c
>> +++ b/fs/notify/fsnotify.c
>> @@ -386,7 +386,7 @@ static __init int fsnotify_init(void)
>>  {
>>         int ret;
>>
>> -       BUG_ON(hweight32(ALL_FSNOTIFY_EVENTS) != 23);
>> +       BUG_ON(hweight32(ALL_FSNOTIFY_EVENTS) != 24);
>>
>>         ret = init_srcu_struct(&fsnotify_mark_srcu);
>>         if (ret)
>> diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
>> index fd1ce10553bf..aad174c81322 100644
>> --- a/include/linux/fsnotify.h
>> +++ b/include/linux/fsnotify.h
>> @@ -216,6 +216,9 @@ static inline void fsnotify_open(struct file *file)
>>         if (S_ISDIR(inode->i_mode))
>>                 mask |= FS_ISDIR;
>>
>> +       if (file->f_flags & __FMODE_EXEC)
>> +               mask |= FS_EXEC;
>> +
> 
> I think that may be breaking existing programs that do not expect to see
> this bit in the event mask (i.e. if they only requested to see FAN_OPEN).

A very good point and is definitely something that did cross my mind while
writing this patch.

> A possible mitigation would be to set a group flag FAN_ENABLE_EXEC
> on the first time that user requests the FAN_EXEC event and then
> compute the FAN_ALL_OUTGOING_EVENTS at runtime based on that
> group flag (see example with FAN_ONDIR in my dev branch [1]).
> Unlike my example, I don't think you have to expose the init flag
> FAN_ENABLE_EXEC to users, because it can be set implicitly on the
> first FAN_EXEC mark request.

Ah yes, I think this is quite elegant and could actually work well. Let me
review your suggestions and write an alternative patch using this
particular approach.

> 
>>         fsnotify_parent(path, NULL, mask);
>>         fsnotify(inode, mask, path, FSNOTIFY_EVENT_PATH, NULL, 0);
>>  }
>> diff --git a/include/linux/fsnotify_backend.h b/include/linux/fsnotify_backend.h
>> index b8f4182f42f1..edcdf2fd2328 100644
>> --- a/include/linux/fsnotify_backend.h
>> +++ b/include/linux/fsnotify_backend.h
>> @@ -38,6 +38,7 @@
>>  #define FS_DELETE              0x00000200      /* Subfile was deleted */
>>  #define FS_DELETE_SELF         0x00000400      /* Self was deleted */
>>  #define FS_MOVE_SELF           0x00000800      /* Self was moved */
>> +#define FS_EXEC                0x00001000      /* File was executed */
>>
>>  #define FS_UNMOUNT             0x00002000      /* inode on umount fs */
>>  #define FS_Q_OVERFLOW          0x00004000      /* Event queued overflowed */
>> @@ -62,7 +63,8 @@
>>  #define FS_EVENTS_POSS_ON_CHILD   (FS_ACCESS | FS_MODIFY | FS_ATTRIB |\
>>                                    FS_CLOSE_WRITE | FS_CLOSE_NOWRITE | FS_OPEN |\
>>                                    FS_MOVED_FROM | FS_MOVED_TO | FS_CREATE |\
>> -                                  FS_DELETE | FS_OPEN_PERM | FS_ACCESS_PERM)
>> +                                  FS_DELETE | FS_OPEN_PERM | FS_ACCESS_PERM |\
>> +                                  FS_EXEC)
>>
>>  #define FS_MOVE                        (FS_MOVED_FROM | FS_MOVED_TO)
>>
>> @@ -75,7 +77,8 @@
>>                              FS_UNMOUNT | FS_Q_OVERFLOW | FS_IN_IGNORED | \
>>                              FS_OPEN_PERM | FS_ACCESS_PERM | FS_EXCL_UNLINK | \
>>                              FS_ISDIR | FS_IN_ONESHOT | FS_DN_RENAME | \
>> -                            FS_DN_MULTISHOT | FS_EVENT_ON_CHILD)
>> +                            FS_DN_MULTISHOT | FS_EVENT_ON_CHILD |\
>> +                            FS_EXEC)
>>
>>  struct fsnotify_group;
>>  struct fsnotify_event;
>> diff --git a/include/uapi/linux/fanotify.h b/include/uapi/linux/fanotify.h
>> index 74247917de04..a850670333fd 100644
>> --- a/include/uapi/linux/fanotify.h
>> +++ b/include/uapi/linux/fanotify.h
>> @@ -10,7 +10,7 @@
>>  #define FAN_CLOSE_WRITE                0x00000008      /* Writtable file closed */
>>  #define FAN_CLOSE_NOWRITE      0x00000010      /* Unwrittable file closed */
>>  #define FAN_OPEN               0x00000020      /* File was opened */
>> -
>> +#define FAN_EXEC               0x00001000      /* File was executed */
>>  #define FAN_Q_OVERFLOW         0x00004000      /* Event queued overflowed */
>>
>>  #define FAN_OPEN_PERM          0x00010000      /* File open in perm check */
>> @@ -69,7 +69,8 @@
>>  #define FAN_ALL_EVENTS (FAN_ACCESS |\
>>                         FAN_MODIFY |\
>>                         FAN_CLOSE |\
>> -                       FAN_OPEN)
>> +                       FAN_OPEN |\
>> +                       FAN_EXEC)
>>
> 
> It *might* be better not to change the uapi exposed value of
> FAN_ALL_EVENTS. I think in retrospect that exposing it was a mistake,
> because no user program should be using this value, although for
> brevity, some programs might be using this value and if said program
> is recompiled with new headers, said program won't run on old kernels.
> An alternative approach is to use new constants for internal kernel use,
> and leave the old legacy uapi constants frozen in the past. see suggested
> implementation on my dev branch [2].

Yes, agreed.

> 
> Thanks,
> Amir.
> 
> [1] https://github.com/amir73il/linux/commit/6fca47dfb793d1c00935e2f91d47ba209f61c4e8
> [2] https://github.com/amir73il/linux/commit/24e970b4756ef9435cdbc8f35c29ff5ab65cfa81
> 

-- 

Thanks,
Matthew Bobrowski

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-09-28  1:27   ` Matthew Bobrowski
@ 2018-09-28  5:39     ` Amir Goldstein
  2018-10-01  8:21       ` Matthew Bobrowski
  0 siblings, 1 reply; 20+ messages in thread
From: Amir Goldstein @ 2018-09-28  5:39 UTC (permalink / raw)
  To: Matthew Bobrowski; +Cc: Jan Kara, Steve Grubb, linux-fsdevel, linux-api

On Fri, Sep 28, 2018 at 4:28 AM Matthew Bobrowski
<mbobrowski@mbobrowski.org> wrote:
>
> Hi Amir,
>
> On 27/9/18 11:57 pm, Amir Goldstein wrote:
> > [cc: linux-api]
> >
> > On Thu, Sep 27, 2018 at 4:05 PM Matthew Bobrowski
> > <mbobrowski@mbobrowski.org> wrote:
> >>
> >> This is a reduced version of a patch that I originally submitted a while ago.
> >>
> >> In short, the fanotify API currently does not provide any means for user space
> >> programs to receive events specifically when a file has been opened with the
> >> intent to be executed. The FAN_EXEC flag will be set within the event mask when
> >> a object has been opened with one of the open flags being __FMODE_EXEC.
> >>
...
> >> diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
> >> index fd1ce10553bf..aad174c81322 100644
> >> --- a/include/linux/fsnotify.h
> >> +++ b/include/linux/fsnotify.h
> >> @@ -216,6 +216,9 @@ static inline void fsnotify_open(struct file *file)
> >>         if (S_ISDIR(inode->i_mode))
> >>                 mask |= FS_ISDIR;
> >>
> >> +       if (file->f_flags & __FMODE_EXEC)
> >> +               mask |= FS_EXEC;
> >> +
> >
> > I think that may be breaking existing programs that do not expect to see
> > this bit in the event mask (i.e. if they only requested to see FAN_OPEN).
>
> A very good point and is definitely something that did cross my mind while
> writing this patch.
>

My only issue with my own suggestion is that this implicit behavior is harder
to document than the explicit behavior (i.e. "user will get FAN_EXEC only if
user sets fanotify_init flag FAN_ENABLE_EXEC"), so I haven't decided which
I prefer yet - waiting for Jan to weight in on this point.

The concept of "bonus flags" (flags that you got but did not ask for) is not
new to inotify (I think you can get IN_ATTRIB if you asked for IN_MODIFY),
but AFAIKT, it would be new to fanotify.

OTOH, getting an event that you asked for in the past and since then
removed the event bit from the mark is not a new behavior. Although this
is not the same as the implicit global enable flag I proposed.

The more I write about it, the more I am leaning towards explicit enable...

> > A possible mitigation would be to set a group flag FAN_ENABLE_EXEC
> > on the first time that user requests the FAN_EXEC event and then
> > compute the FAN_ALL_OUTGOING_EVENTS at runtime based on that
> > group flag (see example with FAN_ONDIR in my dev branch [1]).
> > Unlike my example, I don't think you have to expose the init flag
> > FAN_ENABLE_EXEC to users, because it can be set implicitly on the
> > first FAN_EXEC mark request.
>
> Ah yes, I think this is quite elegant and could actually work well. Let me
> review your suggestions and write an alternative patch using this
> particular approach.
>

If Jan accepts my proposal, you can base your patch on:
https://github.com/amir73il/linux/commits/fanotify_api-v3

Now I've modified my dev branch to use the implicit enable:
- Requesting any dentry event sets internal group flag FAN_ENABLE_DENTRY
- "bonus" event bit FAN_ONDIR is exposed if group has FAN_ENABLE_DENTRY
https://github.com/amir73il/linux/commits/fanotify_dentry

Thanks,
Amir.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-09-28  5:39     ` Amir Goldstein
@ 2018-10-01  8:21       ` Matthew Bobrowski
  2018-10-01  9:13         ` Amir Goldstein
  0 siblings, 1 reply; 20+ messages in thread
From: Matthew Bobrowski @ 2018-10-01  8:21 UTC (permalink / raw)
  To: Amir Goldstein; +Cc: Jan Kara, Steve Grubb, linux-fsdevel, linux-api

Hi Amir,

On 28/09/18 15:39, Amir Goldstein wrote:
> On Fri, Sep 28, 2018 at 4:28 AM Matthew Bobrowski
> <mbobrowski@mbobrowski.org> wrote:
>>
>> Hi Amir,
>>
>> On 27/9/18 11:57 pm, Amir Goldstein wrote:
>>> [cc: linux-api]
>>>
>>> On Thu, Sep 27, 2018 at 4:05 PM Matthew Bobrowski
>>> <mbobrowski@mbobrowski.org> wrote:
>>>>
>>>> This is a reduced version of a patch that I originally submitted a while ago.
>>>>
>>>> In short, the fanotify API currently does not provide any means for user space
>>>> programs to receive events specifically when a file has been opened with the
>>>> intent to be executed. The FAN_EXEC flag will be set within the event mask when
>>>> a object has been opened with one of the open flags being __FMODE_EXEC.
>>>>
> ...
>>>> diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
>>>> index fd1ce10553bf..aad174c81322 100644
>>>> --- a/include/linux/fsnotify.h
>>>> +++ b/include/linux/fsnotify.h
>>>> @@ -216,6 +216,9 @@ static inline void fsnotify_open(struct file *file)
>>>>         if (S_ISDIR(inode->i_mode))
>>>>                 mask |= FS_ISDIR;
>>>>
>>>> +       if (file->f_flags & __FMODE_EXEC)
>>>> +               mask |= FS_EXEC;
>>>> +
>>>
>>> I think that may be breaking existing programs that do not expect to see
>>> this bit in the event mask (i.e. if they only requested to see FAN_OPEN).
>>
>> A very good point and is definitely something that did cross my mind while
>> writing this patch.
>>
> 
> My only issue with my own suggestion is that this implicit behavior is harder
> to document than the explicit behavior (i.e. "user will get FAN_EXEC only if
> user sets fanotify_init flag FAN_ENABLE_EXEC"), so I haven't decided which
> I prefer yet - waiting for Jan to weight in on this point.
> 
> The concept of "bonus flags" (flags that you got but did not ask for) is not
> new to inotify (I think you can get IN_ATTRIB if you asked for IN_MODIFY),
> but AFAIKT, it would be new to fanotify.
> 
> OTOH, getting an event that you asked for in the past and since then
> removed the event bit from the mark is not a new behavior. Although this
> is not the same as the implicit global enable flag I proposed.
> 
> The more I write about it, the more I am leaning towards explicit enable...

Hm, I can't think of a good justification as to why something that provides
this type of behavior can't be an explicit enable, and why we'd go for an
implicit enable instead? I really like the idea of having an initialization
flag (i.e. FAN_ENABLE_EXECUTE) that controls whether your program is to
receive events that may potentially contain additional "bonus" flags (i.e.
FAN_EXECUTE), or not. The intent of having a flag of this nature is clear,
it makes sense, and would be a good way to potentially enable/disable any
API features moving forward.

>>> A possible mitigation would be to set a group flag FAN_ENABLE_EXEC
>>> on the first time that user requests the FAN_EXEC event and then
>>> compute the FAN_ALL_OUTGOING_EVENTS at runtime based on that
>>> group flag (see example with FAN_ONDIR in my dev branch [1]).
>>> Unlike my example, I don't think you have to expose the init flag
>>> FAN_ENABLE_EXEC to users, because it can be set implicitly on the
>>> first FAN_EXEC mark request.
>>
>> Ah yes, I think this is quite elegant and could actually work well. Let me
>> review your suggestions and write an alternative patch using this
>> particular approach.
>>
> 
> If Jan accepts my proposal, you can base your patch on:
> https://github.com/amir73il/linux/commits/fanotify_api-v3

Ok, great. I've gone ahead and written an updated patch that adds the
ability for programs to explicitly enable the receiving of events that
contain the "FAN_EXECUTE" bonus flag. Programs will have to provide
"FAN_ENABLE_EXECUTE" as one of their initialization flags when calling
fanotify_init() in order to receive any events where the "FAN_EXECUTE" flag
has been set. I think doing it this way would be a far better solution to
mitigate possibly breaking any existing programs.

You can find the patch here:
https://github.com/matthewbobrowski/linux/commit/3325b3bbd8613b0de1dd6bac24b52c481b760f1d

These changes are based off your branch 'fanotify_api-v3'. Let me know what
you think.

-- 

Kind regards,
Matthew Bobrowski

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-10-01  8:21       ` Matthew Bobrowski
@ 2018-10-01  9:13         ` Amir Goldstein
  0 siblings, 0 replies; 20+ messages in thread
From: Amir Goldstein @ 2018-10-01  9:13 UTC (permalink / raw)
  To: Matthew Bobrowski; +Cc: Jan Kara, Steve Grubb, linux-fsdevel, linux-api

On Mon, Oct 1, 2018 at 11:21 AM Matthew Bobrowski
<mbobrowski@mbobrowski.org> wrote:
>
> Hi Amir,
>
> On 28/09/18 15:39, Amir Goldstein wrote:
> > On Fri, Sep 28, 2018 at 4:28 AM Matthew Bobrowski
> > <mbobrowski@mbobrowski.org> wrote:
> >>
> >> Hi Amir,
> >>
> >> On 27/9/18 11:57 pm, Amir Goldstein wrote:
> >>> [cc: linux-api]
> >>>
> >>> On Thu, Sep 27, 2018 at 4:05 PM Matthew Bobrowski
> >>> <mbobrowski@mbobrowski.org> wrote:
> >>>>
> >>>> This is a reduced version of a patch that I originally submitted a while ago.
> >>>>
> >>>> In short, the fanotify API currently does not provide any means for user space
> >>>> programs to receive events specifically when a file has been opened with the
> >>>> intent to be executed. The FAN_EXEC flag will be set within the event mask when
> >>>> a object has been opened with one of the open flags being __FMODE_EXEC.
> >>>>
> > ...
[...]
> > If Jan accepts my proposal, you can base your patch on:
> > https://github.com/amir73il/linux/commits/fanotify_api-v3
>
> Ok, great. I've gone ahead and written an updated patch that adds the
> ability for programs to explicitly enable the receiving of events that
> contain the "FAN_EXECUTE" bonus flag. Programs will have to provide
> "FAN_ENABLE_EXECUTE" as one of their initialization flags when calling
> fanotify_init() in order to receive any events where the "FAN_EXECUTE" flag
> has been set. I think doing it this way would be a far better solution to
> mitigate possibly breaking any existing programs.
>
> You can find the patch here:
> https://github.com/matthewbobrowski/linux/commit/3325b3bbd8613b0de1dd6bac24b52c481b760f1d
>
> These changes are based off your branch 'fanotify_api-v3'. Let me know what
> you think.
>

Besides some nits I left in github:

I personally liked FAN_EXEC, better than FAN_EXECUTE.
If you have a string argument in favor of latter please share it.

Your changes enables receiving the FAN_EXEC "bonus" flag, but not to
request (or ignore) FAN_EXEC events (you did not add it to FAN_USER_EVENTS).
But you should also add a check in do_fanotify_mark() to return -EINVAL when
FAN_EXEC event mask was specified, but group has no FAN_ENABLE_EXEC.

So to clarify, if group has FAN_ENABLE_EXEC, the "bonus" flag can be
reported even if not requested (e.g. requested only FAN_OPEN), but if
user wishes
to get only FAN_EXEC events or only FAN_OPEN events that are not FAN_EXEC
user needs to first enable exec events in fanotify_init.

Thanks,
Amir.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-09-27 13:05 [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC Matthew Bobrowski
  2018-09-27 13:57 ` Amir Goldstein
@ 2018-10-01 10:58 ` Jan Kara
  2018-10-01 14:01   ` Amir Goldstein
  2018-10-01 11:06 ` Jan Kara
  2 siblings, 1 reply; 20+ messages in thread
From: Jan Kara @ 2018-10-01 10:58 UTC (permalink / raw)
  To: Matthew Bobrowski; +Cc: Jan Kara, amir73il, Steve Grubb, linux-fsdevel

On Thu 27-09-18 23:05:14, Matthew Bobrowski wrote:
> This is a reduced version of a patch that I originally submitted a while ago.
> 
> In short, the fanotify API currently does not provide any means for user space
> programs to receive events specifically when a file has been opened with the
> intent to be executed. The FAN_EXEC flag will be set within the event mask when
> a object has been opened with one of the open flags being __FMODE_EXEC.
> 
> Linux is used as an Operating System in some products, with an environment that
> can be certified under the Common Criteria Operating System Protection Profile
> (OSPP). This is a formal threat model for a class of technology. It requires
> specific countermeasures to mitigate threats. It requires documentation to
> explain how a product implements these countermeasures. It requires proof via a
> test suite to demonstrate that the requirements are met, observed and checked by
> an independent qualified third party. The latest set of requirements for OSPP
> v4.2 can be found here:
> 
> https://www.niap-ccevs.org/Profile/Info.cfm?PPID=424&id=424
> 
> If you look on page 58, you will see the following requirement:
> 
> FPT_SRP_EXT.1 Software Restriction Policies   FPT_SRP_EXT.1.1
> 
> The OS shall restrict execution to only programs which match an administrator
> specified [selection:
>         file path,
>         file digital signature,
>         version,
>         hash,
>         [assignment: other characteristics]
> ]
> 
> This patch is to help aid in meeting this requirement.
> 
> Signed-off-by: Matthew Bobrowski <mbobrowski@mbobrowski.org>

I agree with Amir's points wrt API so I won't repeat those. But I have one
more API question:

You implement FS_EXEC as a flag that can get set for certain FAN_OPEN
events. That is a new API concept for fanotify. So far you can only request
event of a certain type and then you get the same flag back when the event
happens.  There is also a case of FAN_ONDIR where you can restrict set of
events only to events on a particular inode type but that's again
different. Hence my question: Is there a good reason why we don't create
FAN_OPEN_EXEC event that would trigger only on executable opens?

If someone is interested only in executable opens, he'd have less events to
care about. OTOH additional FS_EXEC flag is probably more flexible (e.g.
you can easily implement equivalent of FAN_OPEN_NOEXEC in userspace if you
wished). Just the inconsistency of the FS_EXEC and e.g. how we handle
FAN_CLOSE_NOWRITE & FAN_CLOSE_WRITE is bothering me...

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-09-27 13:05 [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC Matthew Bobrowski
  2018-09-27 13:57 ` Amir Goldstein
  2018-10-01 10:58 ` Jan Kara
@ 2018-10-01 11:06 ` Jan Kara
  2 siblings, 0 replies; 20+ messages in thread
From: Jan Kara @ 2018-10-01 11:06 UTC (permalink / raw)
  To: Al Viro; +Cc: Jan Kara, amir73il, Steve Grubb, linux-fsdevel, Matthew Bobrowski

On Thu 27-09-18 23:05:14, Matthew Bobrowski wrote:
> This is a reduced version of a patch that I originally submitted a while ago.
> 
> In short, the fanotify API currently does not provide any means for user space
> programs to receive events specifically when a file has been opened with the
> intent to be executed. The FAN_EXEC flag will be set within the event mask when
> a object has been opened with one of the open flags being __FMODE_EXEC.
> 
> Linux is used as an Operating System in some products, with an environment that
> can be certified under the Common Criteria Operating System Protection Profile
> (OSPP). This is a formal threat model for a class of technology. It requires
> specific countermeasures to mitigate threats. It requires documentation to
> explain how a product implements these countermeasures. It requires proof via a
> test suite to demonstrate that the requirements are met, observed and checked by
> an independent qualified third party. The latest set of requirements for OSPP
> v4.2 can be found here:
> 
> https://www.niap-ccevs.org/Profile/Info.cfm?PPID=424&id=424
> 
> If you look on page 58, you will see the following requirement:
> 
> FPT_SRP_EXT.1 Software Restriction Policies   FPT_SRP_EXT.1.1
> 
> The OS shall restrict execution to only programs which match an administrator
> specified [selection:
>         file path,
>         file digital signature,
>         version,
>         hash,
>         [assignment: other characteristics]
> ]
> 
> This patch is to help aid in meeting this requirement.
> 
> Signed-off-by: Matthew Bobrowski <mbobrowski@mbobrowski.org>

Al, I'd like your opinion on one thing below:

> diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
> index fd1ce10553bf..aad174c81322 100644
> --- a/include/linux/fsnotify.h
> +++ b/include/linux/fsnotify.h
> @@ -216,6 +216,9 @@ static inline void fsnotify_open(struct file *file)
>  	if (S_ISDIR(inode->i_mode))
>  		mask |= FS_ISDIR;
> 
> +	if (file->f_flags & __FMODE_EXEC)
> +		mask |= FS_EXEC;
> +
>  	fsnotify_parent(path, NULL, mask);
>  	fsnotify(inode, mask, path, FSNOTIFY_EVENT_PATH, NULL, 0);
>  }

Audit guys want to detect when open happens as a result of a file being
executed (some rationale in the changelog above). From filesystem
notification POV it makes sense to me to report opens that require execute
permission so in principle I'm OK with the functionality. But is it OK to
use __FMODE_EXEC for this and thus effectively expose it to userspace? So
far it is pretty much internal VFS flag and although it apparently has the
right meaning (currently), I'm somewhat concerned that it may change in the
future. Thanks.

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-10-01 10:58 ` Jan Kara
@ 2018-10-01 14:01   ` Amir Goldstein
  2018-10-02  9:24     ` Jan Kara
  0 siblings, 1 reply; 20+ messages in thread
From: Amir Goldstein @ 2018-10-01 14:01 UTC (permalink / raw)
  To: Jan Kara; +Cc: Matthew Bobrowski, Steve Grubb, linux-fsdevel

On Mon, Oct 1, 2018 at 1:58 PM Jan Kara <jack@suse.cz> wrote:
>
> On Thu 27-09-18 23:05:14, Matthew Bobrowski wrote:
> > This is a reduced version of a patch that I originally submitted a while ago.
> >
> > In short, the fanotify API currently does not provide any means for user space
> > programs to receive events specifically when a file has been opened with the
> > intent to be executed. The FAN_EXEC flag will be set within the event mask when
> > a object has been opened with one of the open flags being __FMODE_EXEC.
> >
> > Linux is used as an Operating System in some products, with an environment that
> > can be certified under the Common Criteria Operating System Protection Profile
> > (OSPP). This is a formal threat model for a class of technology. It requires
> > specific countermeasures to mitigate threats. It requires documentation to
> > explain how a product implements these countermeasures. It requires proof via a
> > test suite to demonstrate that the requirements are met, observed and checked by
> > an independent qualified third party. The latest set of requirements for OSPP
> > v4.2 can be found here:
> >
> > https://www.niap-ccevs.org/Profile/Info.cfm?PPID=424&id=424
> >
> > If you look on page 58, you will see the following requirement:
> >
> > FPT_SRP_EXT.1 Software Restriction Policies   FPT_SRP_EXT.1.1
> >
> > The OS shall restrict execution to only programs which match an administrator
> > specified [selection:
> >         file path,
> >         file digital signature,
> >         version,
> >         hash,
> >         [assignment: other characteristics]
> > ]
> >
> > This patch is to help aid in meeting this requirement.
> >
> > Signed-off-by: Matthew Bobrowski <mbobrowski@mbobrowski.org>
>
> I agree with Amir's points wrt API so I won't repeat those. But I have one
> more API question:
>
> You implement FS_EXEC as a flag that can get set for certain FAN_OPEN
> events. That is a new API concept for fanotify. So far you can only request
> event of a certain type and then you get the same flag back when the event
> happens.  There is also a case of FAN_ONDIR where you can restrict set of
> events only to events on a particular inode type but that's again
> different. Hence my question: Is there a good reason why we don't create
> FAN_OPEN_EXEC event that would trigger only on executable opens?
>
> If someone is interested only in executable opens, he'd have less events to
> care about. OTOH additional FS_EXEC flag is probably more flexible (e.g.
> you can easily implement equivalent of FAN_OPEN_NOEXEC in userspace if you
> wished). Just the inconsistency of the FS_EXEC and e.g. how we handle
> FAN_CLOSE_NOWRITE & FAN_CLOSE_WRITE is bothering me...
>

I understand why the inconsitency is bothering you, but IMO it is too late
to change that. By trying to be more consistent in the *implementation* of
the flags, we will end up confusing users instead of making their life easy
by sticking to FAN_OPEN sematics they are used to.

IMO we need to report FAN_OPEN for every open like we do now.
and additionally report FAN_OPEN_EXEC for open for exec.
Then user can implement FAN_OPEN_NOEXEC by setting ignore mask
with FAN_OPEN_EXEC.

You can make the analogy to the compound event FAN_CLOSE.
If user sets a mask to the compound event FAN_CLOSE and sets ignore
mask with FAN_CLOSE_WRITE, then user effectively implemented
FAN_CLOSE_NOWRITE with similar semantics to implementation of
FAN_OPEN_NOEXEC.

Similarly, if user requests FAN_OPEN|FAN_CLOSE and then checks
(event->mask & FAN_OPEN) or (event->mask & FAN_CLOSE) it  has
similar meaning. Testing (event->mask & FAN_OPEN_EXEC) and
(event->mask & FAN_CLOSE_WRITE) in this case is similarly informative.

Honestly, I can't think of an application interested only in
FAN_CLOSE_NOWRITE nor only in FAN_OPEN_NOEXEC, but the
functionality is available for both. The fact that user *can* implement the
former without ignore mask and cannot implement to latter without
ignore mask is IMO the neccesary evil we need to carry for historic API
decisions.

Thanks,
Amir.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-10-01 14:01   ` Amir Goldstein
@ 2018-10-02  9:24     ` Jan Kara
  2018-10-02 10:37       ` Amir Goldstein
  2018-10-02 11:50       ` Matthew Bobrowski
  0 siblings, 2 replies; 20+ messages in thread
From: Jan Kara @ 2018-10-02  9:24 UTC (permalink / raw)
  To: Amir Goldstein; +Cc: Jan Kara, Matthew Bobrowski, Steve Grubb, linux-fsdevel

On Mon 01-10-18 17:01:23, Amir Goldstein wrote:
> On Mon, Oct 1, 2018 at 1:58 PM Jan Kara <jack@suse.cz> wrote:
> >
> > On Thu 27-09-18 23:05:14, Matthew Bobrowski wrote:
> > > This is a reduced version of a patch that I originally submitted a while ago.
> > >
> > > In short, the fanotify API currently does not provide any means for user space
> > > programs to receive events specifically when a file has been opened with the
> > > intent to be executed. The FAN_EXEC flag will be set within the event mask when
> > > a object has been opened with one of the open flags being __FMODE_EXEC.
> > >
> > > Linux is used as an Operating System in some products, with an environment that
> > > can be certified under the Common Criteria Operating System Protection Profile
> > > (OSPP). This is a formal threat model for a class of technology. It requires
> > > specific countermeasures to mitigate threats. It requires documentation to
> > > explain how a product implements these countermeasures. It requires proof via a
> > > test suite to demonstrate that the requirements are met, observed and checked by
> > > an independent qualified third party. The latest set of requirements for OSPP
> > > v4.2 can be found here:
> > >
> > > https://www.niap-ccevs.org/Profile/Info.cfm?PPID=424&id=424
> > >
> > > If you look on page 58, you will see the following requirement:
> > >
> > > FPT_SRP_EXT.1 Software Restriction Policies   FPT_SRP_EXT.1.1
> > >
> > > The OS shall restrict execution to only programs which match an administrator
> > > specified [selection:
> > >         file path,
> > >         file digital signature,
> > >         version,
> > >         hash,
> > >         [assignment: other characteristics]
> > > ]
> > >
> > > This patch is to help aid in meeting this requirement.
> > >
> > > Signed-off-by: Matthew Bobrowski <mbobrowski@mbobrowski.org>
> >
> > I agree with Amir's points wrt API so I won't repeat those. But I have one
> > more API question:
> >
> > You implement FS_EXEC as a flag that can get set for certain FAN_OPEN
> > events. That is a new API concept for fanotify. So far you can only request
> > event of a certain type and then you get the same flag back when the event
> > happens.  There is also a case of FAN_ONDIR where you can restrict set of
> > events only to events on a particular inode type but that's again
> > different. Hence my question: Is there a good reason why we don't create
> > FAN_OPEN_EXEC event that would trigger only on executable opens?
> >
> > If someone is interested only in executable opens, he'd have less events to
> > care about. OTOH additional FS_EXEC flag is probably more flexible (e.g.
> > you can easily implement equivalent of FAN_OPEN_NOEXEC in userspace if you
> > wished). Just the inconsistency of the FS_EXEC and e.g. how we handle
> > FAN_CLOSE_NOWRITE & FAN_CLOSE_WRITE is bothering me...
> >
> 
> I understand why the inconsitency is bothering you, but IMO it is too late
> to change that. By trying to be more consistent in the *implementation* of
> the flags, we will end up confusing users instead of making their life easy
> by sticking to FAN_OPEN sematics they are used to.
> 
> IMO we need to report FAN_OPEN for every open like we do now.
> and additionally report FAN_OPEN_EXEC for open for exec.

Fully agreed.

> Then user can implement FAN_OPEN_NOEXEC by setting ignore mask
> with FAN_OPEN_EXEC.

Good point.

> You can make the analogy to the compound event FAN_CLOSE.
> If user sets a mask to the compound event FAN_CLOSE and sets ignore
> mask with FAN_CLOSE_WRITE, then user effectively implemented
> FAN_CLOSE_NOWRITE with similar semantics to implementation of
> FAN_OPEN_NOEXEC.
> 
> Similarly, if user requests FAN_OPEN|FAN_CLOSE and then checks
> (event->mask & FAN_OPEN) or (event->mask & FAN_CLOSE) it  has
> similar meaning. Testing (event->mask & FAN_OPEN_EXEC) and
> (event->mask & FAN_CLOSE_WRITE) in this case is similarly informative.
> 
> Honestly, I can't think of an application interested only in
> FAN_CLOSE_NOWRITE nor only in FAN_OPEN_NOEXEC, but the
> functionality is available for both. The fact that user *can* implement the
> former without ignore mask and cannot implement to latter without
> ignore mask is IMO the neccesary evil we need to carry for historic API
> decisions.

So it seems we are in full agreement that we don't want "optional event
flags" as Matthew implemented it currently and rather want new event type
FAN_OPEN_EXEC?

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-10-02  9:24     ` Jan Kara
@ 2018-10-02 10:37       ` Amir Goldstein
  2018-10-03 15:40         ` Jan Kara
  2018-10-02 11:50       ` Matthew Bobrowski
  1 sibling, 1 reply; 20+ messages in thread
From: Amir Goldstein @ 2018-10-02 10:37 UTC (permalink / raw)
  To: Jan Kara; +Cc: Matthew Bobrowski, Steve Grubb, linux-fsdevel

On Tue, Oct 2, 2018 at 12:24 PM Jan Kara <jack@suse.cz> wrote:
>
> On Mon 01-10-18 17:01:23, Amir Goldstein wrote:
[...]
> > IMO we need to report FAN_OPEN for every open like we do now.
> > and additionally report FAN_OPEN_EXEC for open for exec.
>
> Fully agreed.
>
> > Then user can implement FAN_OPEN_NOEXEC by setting ignore mask
> > with FAN_OPEN_EXEC.
>
> Good point.
>
> > You can make the analogy to the compound event FAN_CLOSE.
> > If user sets a mask to the compound event FAN_CLOSE and sets ignore
> > mask with FAN_CLOSE_WRITE, then user effectively implemented
> > FAN_CLOSE_NOWRITE with similar semantics to implementation of
> > FAN_OPEN_NOEXEC.
> >
> > Similarly, if user requests FAN_OPEN|FAN_CLOSE and then checks
> > (event->mask & FAN_OPEN) or (event->mask & FAN_CLOSE) it  has
> > similar meaning. Testing (event->mask & FAN_OPEN_EXEC) and
> > (event->mask & FAN_CLOSE_WRITE) in this case is similarly informative.
> >
> > Honestly, I can't think of an application interested only in
> > FAN_CLOSE_NOWRITE nor only in FAN_OPEN_NOEXEC, but the
> > functionality is available for both. The fact that user *can* implement the
> > former without ignore mask and cannot implement to latter without
> > ignore mask is IMO the neccesary evil we need to carry for historic API
> > decisions.
>
> So it seems we are in full agreement that we don't want "optional event
> flags" as Matthew implemented it currently and rather want new event type
> FAN_OPEN_EXEC?
>

First, let me try to better define the semantic difference between
"optional event flag" vs. "new event type" (which may be clear to you).
The former may be reported to user even if user did not set the flag
in any mark mask.
The latter may be reported to user only if user set the event type in
a mark mask.

I am in fact in leaning to the former (as Mathew implemented it), because
I am looking at inotify and my effort to add the "dentry" events to fanotify.
First, my proposal suggests to report the optional event flag FAN_ONDIR,
just like inotify does.
Second, fsnotify_change() reports a combination of event types on a single
event mask (i.e. FS_MODIFY|FS_ATTRIB), which then may cause users
to see an event type they didn't ask for reported.
We could change fsnotify_change() to report 3 separate events for
FS_MODIFY,FS_ATTRIB,FS_ACCESS, but really, I don't see the point.

How badly can a program be written that it opts into EXEC/ONDIR events
in fanotify_init() and doesn't request them in fanotify_mark() and it flips
when those "optional" flags are reported?
Assuming we also properly document that behavior.
BTW, as far as I understand the current man page, I did not find any explicit
statement that says that you CANNOT get an event if you did not ask for it.
FWIW, inotify and fanotify man pages are quite similar, so it may infer that
fanotify inherits the same expectations as one had from inotify.

Having said all that, I'd like to clarify that I do not object to "new
event type",
I understand why you find it "cleaner".
I just find it less "efficient", because it adds extra calls to
fsnotify() for what
IMO is not a good enough reason.

Thoughts?
Amir.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-10-02  9:24     ` Jan Kara
  2018-10-02 10:37       ` Amir Goldstein
@ 2018-10-02 11:50       ` Matthew Bobrowski
  2018-10-03 15:45         ` Jan Kara
  1 sibling, 1 reply; 20+ messages in thread
From: Matthew Bobrowski @ 2018-10-02 11:50 UTC (permalink / raw)
  To: Jan Kara, Amir Goldstein; +Cc: Steve Grubb, linux-fsdevel

On 02/10/18 19:24, Jan Kara wrote:
> On Mon 01-10-18 17:01:23, Amir Goldstein wrote:
>> On Mon, Oct 1, 2018 at 1:58 PM Jan Kara <jack@suse.cz> wrote:
>>>
>>> On Thu 27-09-18 23:05:14, Matthew Bobrowski wrote:
>>>> This is a reduced version of a patch that I originally submitted a while ago.
>>>>
>>>> In short, the fanotify API currently does not provide any means for user space
>>>> programs to receive events specifically when a file has been opened with the
>>>> intent to be executed. The FAN_EXEC flag will be set within the event mask when
>>>> a object has been opened with one of the open flags being __FMODE_EXEC.
>>>>
>>>> Linux is used as an Operating System in some products, with an environment that
>>>> can be certified under the Common Criteria Operating System Protection Profile
>>>> (OSPP). This is a formal threat model for a class of technology. It requires
>>>> specific countermeasures to mitigate threats. It requires documentation to
>>>> explain how a product implements these countermeasures. It requires proof via a
>>>> test suite to demonstrate that the requirements are met, observed and checked by
>>>> an independent qualified third party. The latest set of requirements for OSPP
>>>> v4.2 can be found here:
>>>>
>>>> https://www.niap-ccevs.org/Profile/Info.cfm?PPID=424&id=424
>>>>
>>>> If you look on page 58, you will see the following requirement:
>>>>
>>>> FPT_SRP_EXT.1 Software Restriction Policies   FPT_SRP_EXT.1.1
>>>>
>>>> The OS shall restrict execution to only programs which match an administrator
>>>> specified [selection:
>>>>         file path,
>>>>         file digital signature,
>>>>         version,
>>>>         hash,
>>>>         [assignment: other characteristics]
>>>> ]
>>>>
>>>> This patch is to help aid in meeting this requirement.
>>>>
>>>> Signed-off-by: Matthew Bobrowski <mbobrowski@mbobrowski.org>
>>>
>>> I agree with Amir's points wrt API so I won't repeat those. But I have one
>>> more API question:
>>>
>>> You implement FS_EXEC as a flag that can get set for certain FAN_OPEN
>>> events. That is a new API concept for fanotify. So far you can only request
>>> event of a certain type and then you get the same flag back when the event
>>> happens.  There is also a case of FAN_ONDIR where you can restrict set of
>>> events only to events on a particular inode type but that's again
>>> different. Hence my question: Is there a good reason why we don't create
>>> FAN_OPEN_EXEC event that would trigger only on executable opens?
>>>
>>> If someone is interested only in executable opens, he'd have less events to
>>> care about. OTOH additional FS_EXEC flag is probably more flexible (e.g.
>>> you can easily implement equivalent of FAN_OPEN_NOEXEC in userspace if you
>>> wished). Just the inconsistency of the FS_EXEC and e.g. how we handle
>>> FAN_CLOSE_NOWRITE & FAN_CLOSE_WRITE is bothering me...
>>>
>>
>> I understand why the inconsitency is bothering you, but IMO it is too late
>> to change that. By trying to be more consistent in the *implementation* of
>> the flags, we will end up confusing users instead of making their life easy
>> by sticking to FAN_OPEN sematics they are used to.
>>
>> IMO we need to report FAN_OPEN for every open like we do now.
>> and additionally report FAN_OPEN_EXEC for open for exec.
> 
> Fully agreed.
> 
>> Then user can implement FAN_OPEN_NOEXEC by setting ignore mask
>> with FAN_OPEN_EXEC.
> 
> Good point.
> 
>> You can make the analogy to the compound event FAN_CLOSE.
>> If user sets a mask to the compound event FAN_CLOSE and sets ignore
>> mask with FAN_CLOSE_WRITE, then user effectively implemented
>> FAN_CLOSE_NOWRITE with similar semantics to implementation of
>> FAN_OPEN_NOEXEC.
>>
>> Similarly, if user requests FAN_OPEN|FAN_CLOSE and then checks
>> (event->mask & FAN_OPEN) or (event->mask & FAN_CLOSE) it  has
>> similar meaning. Testing (event->mask & FAN_OPEN_EXEC) and
>> (event->mask & FAN_CLOSE_WRITE) in this case is similarly informative.
>>
>> Honestly, I can't think of an application interested only in
>> FAN_CLOSE_NOWRITE nor only in FAN_OPEN_NOEXEC, but the
>> functionality is available for both. The fact that user *can* implement the
>> former without ignore mask and cannot implement to latter without
>> ignore mask is IMO the neccesary evil we need to carry for historic API
>> decisions.
> 
> So it seems we are in full agreement that we don't want "optional event
> flags" as Matthew implemented it currently and rather want new event type
> FAN_OPEN_EXEC?

So, what we're proposing here is to actually *not* go with amending the
additional _bonus_ flag to existing event(s) and to explicitly define a new
event type i.e. FAN_OPEN_EXEC?

I can't really see why we wouldn't go with the solution that I've originally
proposed. It basically provides the same capabilities as what FAN_OPEN_EXEC
would, but at the same time also offers the user the additional flexibility,
which is nice? I agree that using FAN_OPEN_EXEC may possibly be cleaner from a
user perspective, but just not entirely sure at this point whether it would be
adding some additional unnecessary complexity throughout the API.

Either way though, looking for guidance and feedback from yourself and Amir.

-- 

Kind regards,
Matthew Bobrowski

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-10-02 10:37       ` Amir Goldstein
@ 2018-10-03 15:40         ` Jan Kara
  2018-10-03 16:18           ` Amir Goldstein
  0 siblings, 1 reply; 20+ messages in thread
From: Jan Kara @ 2018-10-03 15:40 UTC (permalink / raw)
  To: Amir Goldstein; +Cc: Jan Kara, Matthew Bobrowski, Steve Grubb, linux-fsdevel

On Tue 02-10-18 13:37:13, Amir Goldstein wrote:
> On Tue, Oct 2, 2018 at 12:24 PM Jan Kara <jack@suse.cz> wrote:
> >
> > On Mon 01-10-18 17:01:23, Amir Goldstein wrote:
> [...]
> > > IMO we need to report FAN_OPEN for every open like we do now.
> > > and additionally report FAN_OPEN_EXEC for open for exec.
> >
> > Fully agreed.
> >
> > > Then user can implement FAN_OPEN_NOEXEC by setting ignore mask
> > > with FAN_OPEN_EXEC.
> >
> > Good point.
> >
> > > You can make the analogy to the compound event FAN_CLOSE.
> > > If user sets a mask to the compound event FAN_CLOSE and sets ignore
> > > mask with FAN_CLOSE_WRITE, then user effectively implemented
> > > FAN_CLOSE_NOWRITE with similar semantics to implementation of
> > > FAN_OPEN_NOEXEC.
> > >
> > > Similarly, if user requests FAN_OPEN|FAN_CLOSE and then checks
> > > (event->mask & FAN_OPEN) or (event->mask & FAN_CLOSE) it  has
> > > similar meaning. Testing (event->mask & FAN_OPEN_EXEC) and
> > > (event->mask & FAN_CLOSE_WRITE) in this case is similarly informative.
> > >
> > > Honestly, I can't think of an application interested only in
> > > FAN_CLOSE_NOWRITE nor only in FAN_OPEN_NOEXEC, but the
> > > functionality is available for both. The fact that user *can* implement the
> > > former without ignore mask and cannot implement to latter without
> > > ignore mask is IMO the neccesary evil we need to carry for historic API
> > > decisions.
> >
> > So it seems we are in full agreement that we don't want "optional event
> > flags" as Matthew implemented it currently and rather want new event type
> > FAN_OPEN_EXEC?
> >
> 
> First, let me try to better define the semantic difference between
> "optional event flag" vs. "new event type" (which may be clear to you).
> The former may be reported to user even if user did not set the flag
> in any mark mask.
> The latter may be reported to user only if user set the event type in
> a mark mask.
> 
> I am in fact in leaning to the former (as Mathew implemented it), because
> I am looking at inotify and my effort to add the "dentry" events to fanotify.
> First, my proposal suggests to report the optional event flag FAN_ONDIR,
> just like inotify does.

Well, we already do deliver FAN_ONDIR event flag if the event was on
directory AFAIK. Just with fanotify you also have to explicitely ask for
events on directories to be delivered by setting FAN_ONDIR in the mark's
mask.

> Second, fsnotify_change() reports a combination of event types on a single
> event mask (i.e. FS_MODIFY|FS_ATTRIB), which then may cause users
> to see an event type they didn't ask for reported.
> We could change fsnotify_change() to report 3 separate events for
> FS_MODIFY,FS_ATTRIB,FS_ACCESS, but really, I don't see the point.

OK.

> How badly can a program be written that it opts into EXEC/ONDIR events
> in fanotify_init() and doesn't request them in fanotify_mark() and it flips
> when those "optional" flags are reported?
> Assuming we also properly document that behavior.

Yeah, so I'm not so concerned about an applicating getting surprised by
additional event being set when it in fact explicitely asked for it. I'm
more concerned about the "ease to understand the interface and use it
correctly". I.e., the logic of interface design. And in this area, just
defining new FAN_OPEN_EXEC event like any other seems to win? No need for
special fanotify_init() flags and explanations in the manpage.

> BTW, as far as I understand the current man page, I did not find any explicit
> statement that says that you CANNOT get an event if you did not ask for it.
> FWIW, inotify and fanotify man pages are quite similar, so it may infer that
> fanotify inherits the same expectations as one had from inotify.
> 
> Having said all that, I'd like to clarify that I do not object to "new
> event type",
> I understand why you find it "cleaner".
> I just find it less "efficient", because it adds extra calls to
> fsnotify() for what
> IMO is not a good enough reason.

I'm not sure I understand your concern here. Are you concerned that
fsnotify_open() would need to do one call for FS_OPEN event and one call
for FS_OPEN_EXEC so that we won't "leak" FS_OPEN_EXEC event if user didn't
ask for it? If that's your concern, what if we just masked out all
"unwanted" events in fanotify_handle_event()? fanotify_should_send_event()
does all the masking anyway so it's not like we'd loose any performance
with that and with current set of fanotify events it would be completely
transparent.

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-10-02 11:50       ` Matthew Bobrowski
@ 2018-10-03 15:45         ` Jan Kara
  0 siblings, 0 replies; 20+ messages in thread
From: Jan Kara @ 2018-10-03 15:45 UTC (permalink / raw)
  To: Matthew Bobrowski; +Cc: Jan Kara, Amir Goldstein, Steve Grubb, linux-fsdevel

On Tue 02-10-18 21:50:24, Matthew Bobrowski wrote:
> On 02/10/18 19:24, Jan Kara wrote:
> > On Mon 01-10-18 17:01:23, Amir Goldstein wrote:
> >> On Mon, Oct 1, 2018 at 1:58 PM Jan Kara <jack@suse.cz> wrote:
> >>>
> >>> On Thu 27-09-18 23:05:14, Matthew Bobrowski wrote:
> >>>> This is a reduced version of a patch that I originally submitted a while ago.
> >>>>
> >>>> In short, the fanotify API currently does not provide any means for user space
> >>>> programs to receive events specifically when a file has been opened with the
> >>>> intent to be executed. The FAN_EXEC flag will be set within the event mask when
> >>>> a object has been opened with one of the open flags being __FMODE_EXEC.
> >>>>
> >>>> Linux is used as an Operating System in some products, with an environment that
> >>>> can be certified under the Common Criteria Operating System Protection Profile
> >>>> (OSPP). This is a formal threat model for a class of technology. It requires
> >>>> specific countermeasures to mitigate threats. It requires documentation to
> >>>> explain how a product implements these countermeasures. It requires proof via a
> >>>> test suite to demonstrate that the requirements are met, observed and checked by
> >>>> an independent qualified third party. The latest set of requirements for OSPP
> >>>> v4.2 can be found here:
> >>>>
> >>>> https://www.niap-ccevs.org/Profile/Info.cfm?PPID=424&id=424
> >>>>
> >>>> If you look on page 58, you will see the following requirement:
> >>>>
> >>>> FPT_SRP_EXT.1 Software Restriction Policies   FPT_SRP_EXT.1.1
> >>>>
> >>>> The OS shall restrict execution to only programs which match an administrator
> >>>> specified [selection:
> >>>>         file path,
> >>>>         file digital signature,
> >>>>         version,
> >>>>         hash,
> >>>>         [assignment: other characteristics]
> >>>> ]
> >>>>
> >>>> This patch is to help aid in meeting this requirement.
> >>>>
> >>>> Signed-off-by: Matthew Bobrowski <mbobrowski@mbobrowski.org>
> >>>
> >>> I agree with Amir's points wrt API so I won't repeat those. But I have one
> >>> more API question:
> >>>
> >>> You implement FS_EXEC as a flag that can get set for certain FAN_OPEN
> >>> events. That is a new API concept for fanotify. So far you can only request
> >>> event of a certain type and then you get the same flag back when the event
> >>> happens.  There is also a case of FAN_ONDIR where you can restrict set of
> >>> events only to events on a particular inode type but that's again
> >>> different. Hence my question: Is there a good reason why we don't create
> >>> FAN_OPEN_EXEC event that would trigger only on executable opens?
> >>>
> >>> If someone is interested only in executable opens, he'd have less events to
> >>> care about. OTOH additional FS_EXEC flag is probably more flexible (e.g.
> >>> you can easily implement equivalent of FAN_OPEN_NOEXEC in userspace if you
> >>> wished). Just the inconsistency of the FS_EXEC and e.g. how we handle
> >>> FAN_CLOSE_NOWRITE & FAN_CLOSE_WRITE is bothering me...
> >>>
> >>
> >> I understand why the inconsitency is bothering you, but IMO it is too late
> >> to change that. By trying to be more consistent in the *implementation* of
> >> the flags, we will end up confusing users instead of making their life easy
> >> by sticking to FAN_OPEN sematics they are used to.
> >>
> >> IMO we need to report FAN_OPEN for every open like we do now.
> >> and additionally report FAN_OPEN_EXEC for open for exec.
> > 
> > Fully agreed.
> > 
> >> Then user can implement FAN_OPEN_NOEXEC by setting ignore mask
> >> with FAN_OPEN_EXEC.
> > 
> > Good point.
> > 
> >> You can make the analogy to the compound event FAN_CLOSE.
> >> If user sets a mask to the compound event FAN_CLOSE and sets ignore
> >> mask with FAN_CLOSE_WRITE, then user effectively implemented
> >> FAN_CLOSE_NOWRITE with similar semantics to implementation of
> >> FAN_OPEN_NOEXEC.
> >>
> >> Similarly, if user requests FAN_OPEN|FAN_CLOSE and then checks
> >> (event->mask & FAN_OPEN) or (event->mask & FAN_CLOSE) it  has
> >> similar meaning. Testing (event->mask & FAN_OPEN_EXEC) and
> >> (event->mask & FAN_CLOSE_WRITE) in this case is similarly informative.
> >>
> >> Honestly, I can't think of an application interested only in
> >> FAN_CLOSE_NOWRITE nor only in FAN_OPEN_NOEXEC, but the
> >> functionality is available for both. The fact that user *can* implement the
> >> former without ignore mask and cannot implement to latter without
> >> ignore mask is IMO the neccesary evil we need to carry for historic API
> >> decisions.
> > 
> > So it seems we are in full agreement that we don't want "optional event
> > flags" as Matthew implemented it currently and rather want new event type
> > FAN_OPEN_EXEC?
> 
> So, what we're proposing here is to actually *not* go with amending the
> additional _bonus_ flag to existing event(s) and to explicitly define a new
> event type i.e. FAN_OPEN_EXEC?

Yes.

> I can't really see why we wouldn't go with the solution that I've originally
> proposed. It basically provides the same capabilities as what FAN_OPEN_EXEC
> would, but at the same time also offers the user the additional flexibility,
> which is nice?

Well, as Amir explained in his reply both your variant and new
FAN_OPEN_EXEC have the same level of flexibility.

> I agree that using FAN_OPEN_EXEC may possibly be cleaner from a user
> perspective, but just not entirely sure at this point whether it would be
> adding some additional unnecessary complexity throughout the API.

I think new FAN_OPEN_EXEC event would be actually simpler for the API.
There's no need for new fanotify_init() flag with that, explanations to the
user in the manpage how it behaves etc. It is just another event. The fact
that it is a subtype of FAN_OPEN may result in a need to do some masking in
fanotify_handle_event() but that's easy to do.

> Either way though, looking for guidance and feedback from yourself and Amir.

Sure, let us sort it out with Amir first and then we'll give you some
guidance where to go further :)

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-10-03 15:40         ` Jan Kara
@ 2018-10-03 16:18           ` Amir Goldstein
  2018-10-03 16:33             ` Jan Kara
  0 siblings, 1 reply; 20+ messages in thread
From: Amir Goldstein @ 2018-10-03 16:18 UTC (permalink / raw)
  To: Jan Kara; +Cc: Matthew Bobrowski, Steve Grubb, linux-fsdevel

On Wed, Oct 3, 2018 at 6:40 PM Jan Kara <jack@suse.cz> wrote:
>
> On Tue 02-10-18 13:37:13, Amir Goldstein wrote:
[...]
> > I am in fact in leaning to the former (as Mathew implemented it), because
> > I am looking at inotify and my effort to add the "dentry" events to fanotify.
> > First, my proposal suggests to report the optional event flag FAN_ONDIR,
> > just like inotify does.
>
> Well, we already do deliver FAN_ONDIR event flag if the event was on
> directory AFAIK. Just with fanotify you also have to explicitely ask for
> events on directories to be delivered by setting FAN_ONDIR in the mark's
> mask.
>

We actually mask it in out fanotify, so in inotify, it is out-only and
in fanotify, it is
in-only. BTW, I could not help cleaning up that horrible FAN_MARK_ONDIR
and it won us a very nice optimization of directory access events.
patches to follow soon.


>
> > How badly can a program be written that it opts into EXEC/ONDIR events
> > in fanotify_init() and doesn't request them in fanotify_mark() and it flips
> > when those "optional" flags are reported?
> > Assuming we also properly document that behavior.
>
> Yeah, so I'm not so concerned about an applicating getting surprised by
> additional event being set when it in fact explicitely asked for it. I'm
> more concerned about the "ease to understand the interface and use it
> correctly". I.e., the logic of interface design. And in this area, just
> defining new FAN_OPEN_EXEC event like any other seems to win? No need for
> special fanotify_init() flags and explanations in the manpage.
>

Ah! yes, that would be better.

> > BTW, as far as I understand the current man page, I did not find any explicit
> > statement that says that you CANNOT get an event if you did not ask for it.
> > FWIW, inotify and fanotify man pages are quite similar, so it may infer that
> > fanotify inherits the same expectations as one had from inotify.
> >
> > Having said all that, I'd like to clarify that I do not object to "new
> > event type",
> > I understand why you find it "cleaner".
> > I just find it less "efficient", because it adds extra calls to
> > fsnotify() for what
> > IMO is not a good enough reason.
>
> I'm not sure I understand your concern here. Are you concerned that
> fsnotify_open() would need to do one call for FS_OPEN event and one call
> for FS_OPEN_EXEC so that we won't "leak" FS_OPEN_EXEC event if user didn't
> ask for it?

Yes.

> If that's your concern, what if we just masked out all
> "unwanted" events in fanotify_handle_event()? fanotify_should_send_event()
> does all the masking anyway so it's not like we'd loose any performance
> with that and with current set of fanotify events it would be completely
> transparent.
>

I though about this first, but got myself confused thinking it would be messy.
Now I am looking again and don't understand why.

I will try to sum up the solution for us and for Mathew:
- No FAN_ENABLE_EXEC (sorry for that detour)
- Implementation in fsnotify_open() is exactly as Mathew did it, but
changing the
  name of the flag to FS_OPEN_EXEC
- Add FAN_OPEN_EXEC to valid user events mask and valid outgoing events
- fanotify_should_send_event() returns the mask  to be reported in the event
-- s/return false/return 0/
-- return event_mask & FAN_ALL_OUTGOING_EVENTS & marks_mask &
                                 ~marks_ignored_mask;

So we won't report events that user did not set a mask for and we won't report
events that user has set an ignore mask for.

Thanks,
Amir.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-10-03 16:18           ` Amir Goldstein
@ 2018-10-03 16:33             ` Jan Kara
  2018-10-03 20:45               ` Matthew Bobrowski
  2018-10-07 11:13               ` Matthew Bobrowski
  0 siblings, 2 replies; 20+ messages in thread
From: Jan Kara @ 2018-10-03 16:33 UTC (permalink / raw)
  To: Amir Goldstein; +Cc: Jan Kara, Matthew Bobrowski, Steve Grubb, linux-fsdevel

On Wed 03-10-18 19:18:27, Amir Goldstein wrote:
> On Wed, Oct 3, 2018 at 6:40 PM Jan Kara <jack@suse.cz> wrote:
> >
> > On Tue 02-10-18 13:37:13, Amir Goldstein wrote:
> [...]
> > > I am in fact in leaning to the former (as Mathew implemented it), because
> > > I am looking at inotify and my effort to add the "dentry" events to fanotify.
> > > First, my proposal suggests to report the optional event flag FAN_ONDIR,
> > > just like inotify does.
> >
> > Well, we already do deliver FAN_ONDIR event flag if the event was on
> > directory AFAIK. Just with fanotify you also have to explicitely ask for
> > events on directories to be delivered by setting FAN_ONDIR in the mark's
> > mask.
> >
> 
> We actually mask it in out fanotify, so in inotify, it is out-only and
> in fanotify, it is in-only.

OK, didn't notice that. Thanks for educating me.

> BTW, I could not help cleaning up that horrible FAN_MARK_ONDIR
> and it won us a very nice optimization of directory access events.
> patches to follow soon.

Cool! Less work for me as I also had tingling in my fingers to clean up
that mess, just didn't get to it yet :).

> > If that's your concern, what if we just masked out all
> > "unwanted" events in fanotify_handle_event()? fanotify_should_send_event()
> > does all the masking anyway so it's not like we'd loose any performance
> > with that and with current set of fanotify events it would be completely
> > transparent.
> >
> 
> I though about this first, but got myself confused thinking it would be messy.
> Now I am looking again and don't understand why.
> 
> I will try to sum up the solution for us and for Mathew:
> - No FAN_ENABLE_EXEC (sorry for that detour)
> - Implementation in fsnotify_open() is exactly as Mathew did it, but
> changing the
>   name of the flag to FS_OPEN_EXEC
> - Add FAN_OPEN_EXEC to valid user events mask and valid outgoing events
> - fanotify_should_send_event() returns the mask  to be reported in the event
> -- s/return false/return 0/
> -- return event_mask & FAN_ALL_OUTGOING_EVENTS & marks_mask &
>                                  ~marks_ignored_mask;
> 
> So we won't report events that user did not set a mask for and we won't report
> events that user has set an ignore mask for.

Exactly. Just I'd do the change to fanotify_should_send_event() as a
separate patch and rename that function to something like
fanotify_group_event_mask() or something like that to better express what
it will do.

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-10-03 16:33             ` Jan Kara
@ 2018-10-03 20:45               ` Matthew Bobrowski
  2018-10-07 11:13               ` Matthew Bobrowski
  1 sibling, 0 replies; 20+ messages in thread
From: Matthew Bobrowski @ 2018-10-03 20:45 UTC (permalink / raw)
  To: Jan Kara, Amir Goldstein; +Cc: Steve Grubb, linux-fsdevel

On 4/10/18 2:33 am, Jan Kara wrote:
> On Wed 03-10-18 19:18:27, Amir Goldstein wrote:
>> On Wed, Oct 3, 2018 at 6:40 PM Jan Kara <jack@suse.cz> wrote:
>>>
>>> On Tue 02-10-18 13:37:13, Amir Goldstein wrote:
>> [...]
>>>> I am in fact in leaning to the former (as Mathew implemented it), because
>>>> I am looking at inotify and my effort to add the "dentry" events to fanotify.
>>>> First, my proposal suggests to report the optional event flag FAN_ONDIR,
>>>> just like inotify does.
>>>
>>> Well, we already do deliver FAN_ONDIR event flag if the event was on
>>> directory AFAIK. Just with fanotify you also have to explicitely ask for
>>> events on directories to be delivered by setting FAN_ONDIR in the mark's
>>> mask.
>>>
>>
>> We actually mask it in out fanotify, so in inotify, it is out-only and
>> in fanotify, it is in-only.
> 
> OK, didn't notice that. Thanks for educating me.
> 
>> BTW, I could not help cleaning up that horrible FAN_MARK_ONDIR
>> and it won us a very nice optimization of directory access events.
>> patches to follow soon.
> 
> Cool! Less work for me as I also had tingling in my fingers to clean up
> that mess, just didn't get to it yet :).
> 
>>> If that's your concern, what if we just masked out all
>>> "unwanted" events in fanotify_handle_event()? fanotify_should_send_event()
>>> does all the masking anyway so it's not like we'd loose any performance
>>> with that and with current set of fanotify events it would be completely
>>> transparent.
>>>
>>
>> I though about this first, but got myself confused thinking it would be messy.
>> Now I am looking again and don't understand why.
>>
>> I will try to sum up the solution for us and for Mathew:
>> - No FAN_ENABLE_EXEC (sorry for that detour)
>> - Implementation in fsnotify_open() is exactly as Mathew did it, but
>> changing the
>>   name of the flag to FS_OPEN_EXEC
>> - Add FAN_OPEN_EXEC to valid user events mask and valid outgoing events
>> - fanotify_should_send_event() returns the mask  to be reported in the event
>> -- s/return false/return 0/
>> -- return event_mask & FAN_ALL_OUTGOING_EVENTS & marks_mask &
>>                                  ~marks_ignored_mask;
>>
>> So we won't report events that user did not set a mask for and we won't report
>> events that user has set an ignore mask for.
> 
> Exactly. Just I'd do the change to fanotify_should_send_event() as a
> separate patch and rename that function to something like
> fanotify_group_event_mask() or something like that to better express what
> it will do.
> 

Ok, great. This is well understood and also sounds good to me. I'll write
the patches based on this agreed approach and send them through.

-- 

Kind regards,
Matthew Bobrowski

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-10-03 16:33             ` Jan Kara
  2018-10-03 20:45               ` Matthew Bobrowski
@ 2018-10-07 11:13               ` Matthew Bobrowski
  2018-10-07 13:40                 ` Amir Goldstein
  2018-10-08  9:35                 ` Jan Kara
  1 sibling, 2 replies; 20+ messages in thread
From: Matthew Bobrowski @ 2018-10-07 11:13 UTC (permalink / raw)
  To: Jan Kara, Amir Goldstein; +Cc: Steve Grubb, linux-fsdevel

Hi Jan/Amir,

On 4/10/18 2:33 am, Jan Kara wrote:
> On Wed 03-10-18 19:18:27, Amir Goldstein wrote:
>> On Wed, Oct 3, 2018 at 6:40 PM Jan Kara <jack@suse.cz> wrote:
>>>
>>> On Tue 02-10-18 13:37:13, Amir Goldstein wrote:
>> [...]
>>>> I am in fact in leaning to the former (as Mathew implemented it), because
>>>> I am looking at inotify and my effort to add the "dentry" events to fanotify.
>>>> First, my proposal suggests to report the optional event flag FAN_ONDIR,
>>>> just like inotify does.
>>>
>>> Well, we already do deliver FAN_ONDIR event flag if the event was on
>>> directory AFAIK. Just with fanotify you also have to explicitely ask for
>>> events on directories to be delivered by setting FAN_ONDIR in the mark's
>>> mask.
>>>
>>
>> We actually mask it in out fanotify, so in inotify, it is out-only and
>> in fanotify, it is in-only.
> 
> OK, didn't notice that. Thanks for educating me.
> 
>> BTW, I could not help cleaning up that horrible FAN_MARK_ONDIR
>> and it won us a very nice optimization of directory access events.
>> patches to follow soon.
> 
> Cool! Less work for me as I also had tingling in my fingers to clean up
> that mess, just didn't get to it yet :).
> 
>>> If that's your concern, what if we just masked out all
>>> "unwanted" events in fanotify_handle_event()? fanotify_should_send_event()
>>> does all the masking anyway so it's not like we'd loose any performance
>>> with that and with current set of fanotify events it would be completely
>>> transparent.
>>>
>>
>> I though about this first, but got myself confused thinking it would be messy.
>> Now I am looking again and don't understand why.
>>
>> I will try to sum up the solution for us and for Mathew:
>> - No FAN_ENABLE_EXEC (sorry for that detour)
>> - Implementation in fsnotify_open() is exactly as Mathew did it, but
>> changing the
>>   name of the flag to FS_OPEN_EXEC
>> - Add FAN_OPEN_EXEC to valid user events mask and valid outgoing events
>> - fanotify_should_send_event() returns the mask  to be reported in the event
>> -- s/return false/return 0/
>> -- return event_mask & FAN_ALL_OUTGOING_EVENTS & marks_mask &
>>                                  ~marks_ignored_mask;
>>
>> So we won't report events that user did not set a mask for and we won't report
>> events that user has set an ignore mask for.
> 
> Exactly. Just I'd do the change to fanotify_should_send_event() as a
> separate patch and rename that function to something like
> fanotify_group_event_mask() or something like that to better express what
> it will do.

I've gone ahead and implemented the changes based on what we agreed above.
This first commit introduces the new event type FAN_OPEN_EXEC, as well as
adds the necessary check within the fsnotify_open() hook. You can find this
change here:

https://github.com/matthewbobrowski/linux/commit/2709f54a84047dc08fdc0bf3e8407a5275440c25

The second commit contains the necessary changes to
fanotify_should_send_event(). This function basically now returns the event
mask for the event containing flags ONLY set to those requested by the
user. You can find this change here:

https://github.com/matthewbobrowski/linux/commit/596c531365229d439e374149f5ba62011008bb0c

Please provide feedback on the above.

Also, we haven't really discussed how we can incorporate this within
fsnotify_perm(). However, I was thinking that we can simply do something
along the lines of what I've done here (defining another flag
FAN_OPEN_EXEC_PERM):

https://github.com/matthewbobrowski/linux/commit/664ba02fdb871d5e8cbf7cf59c592dd89a597a67

Thoughts?

-- 

Kind regards,
Matthew Bobrowski

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-10-07 11:13               ` Matthew Bobrowski
@ 2018-10-07 13:40                 ` Amir Goldstein
  2018-10-08  9:35                 ` Jan Kara
  1 sibling, 0 replies; 20+ messages in thread
From: Amir Goldstein @ 2018-10-07 13:40 UTC (permalink / raw)
  To: Matthew Bobrowski; +Cc: Jan Kara, Steve Grubb, linux-fsdevel

On Sun, Oct 7, 2018 at 2:13 PM Matthew Bobrowski
<mbobrowski@mbobrowski.org> wrote:
>
> Hi Jan/Amir,
>
> On 4/10/18 2:33 am, Jan Kara wrote:
> > On Wed 03-10-18 19:18:27, Amir Goldstein wrote:
> >> On Wed, Oct 3, 2018 at 6:40 PM Jan Kara <jack@suse.cz> wrote:
> >>>
> >>> On Tue 02-10-18 13:37:13, Amir Goldstein wrote:
> >> [...]
> >>>> I am in fact in leaning to the former (as Mathew implemented it), because
> >>>> I am looking at inotify and my effort to add the "dentry" events to fanotify.
> >>>> First, my proposal suggests to report the optional event flag FAN_ONDIR,
> >>>> just like inotify does.
> >>>
> >>> Well, we already do deliver FAN_ONDIR event flag if the event was on
> >>> directory AFAIK. Just with fanotify you also have to explicitely ask for
> >>> events on directories to be delivered by setting FAN_ONDIR in the mark's
> >>> mask.
> >>>
> >>
> >> We actually mask it in out fanotify, so in inotify, it is out-only and
> >> in fanotify, it is in-only.
> >
> > OK, didn't notice that. Thanks for educating me.
> >
> >> BTW, I could not help cleaning up that horrible FAN_MARK_ONDIR
> >> and it won us a very nice optimization of directory access events.
> >> patches to follow soon.
> >
> > Cool! Less work for me as I also had tingling in my fingers to clean up
> > that mess, just didn't get to it yet :).
> >
> >>> If that's your concern, what if we just masked out all
> >>> "unwanted" events in fanotify_handle_event()? fanotify_should_send_event()
> >>> does all the masking anyway so it's not like we'd loose any performance
> >>> with that and with current set of fanotify events it would be completely
> >>> transparent.
> >>>
> >>
> >> I though about this first, but got myself confused thinking it would be messy.
> >> Now I am looking again and don't understand why.
> >>
> >> I will try to sum up the solution for us and for Mathew:
> >> - No FAN_ENABLE_EXEC (sorry for that detour)
> >> - Implementation in fsnotify_open() is exactly as Mathew did it, but
> >> changing the
> >>   name of the flag to FS_OPEN_EXEC
> >> - Add FAN_OPEN_EXEC to valid user events mask and valid outgoing events
> >> - fanotify_should_send_event() returns the mask  to be reported in the event
> >> -- s/return false/return 0/
> >> -- return event_mask & FAN_ALL_OUTGOING_EVENTS & marks_mask &
> >>                                  ~marks_ignored_mask;
> >>
> >> So we won't report events that user did not set a mask for and we won't report
> >> events that user has set an ignore mask for.
> >
> > Exactly. Just I'd do the change to fanotify_should_send_event() as a
> > separate patch and rename that function to something like
> > fanotify_group_event_mask() or something like that to better express what
> > it will do.
>
> I've gone ahead and implemented the changes based on what we agreed above.
> This first commit introduces the new event type FAN_OPEN_EXEC, as well as
> adds the necessary check within the fsnotify_open() hook. You can find this
> change here:
>
> https://github.com/matthewbobrowski/linux/commit/2709f54a84047dc08fdc0bf3e8407a5275440c25
>
> The second commit contains the necessary changes to
> fanotify_should_send_event(). This function basically now returns the event
> mask for the event containing flags ONLY set to those requested by the
> user. You can find this change here:
>
> https://github.com/matthewbobrowski/linux/commit/596c531365229d439e374149f5ba62011008bb0c
>
> Please provide feedback on the above.

Generally looks good, please post as proper path series.
Comments on github version:
commit message for fanotify_should_send_event() is vague because it does
not name the use case of 2 events that are bundled together and does not
specify that this is a new use case introduced by the new event FAN_OPEN_EXEC
that is bundled together (in reporting) with FAN_OPEN.
I think if you try to explain the specific use case and not the abstract case,
result will be more understandable.

I probably said it before, but since we are way beyond initial RFC I
will repeat.
When posting an API change:
- Please CC linux-api
- Please prepare a man-pages patch and reference it (github?) from
your cover letter
- The sooner you write and LTP test to cover the new API the better
- A reference to a test in cover letter to say "this is how I tested"
is very nice to
  have, but you can also follow up on that later (assuming that you
did test somehow...)


>
> Also, we haven't really discussed how we can incorporate this within
> fsnotify_perm(). However, I was thinking that we can simply do something
> along the lines of what I've done here (defining another flag
> FAN_OPEN_EXEC_PERM):
>
> https://github.com/matthewbobrowski/linux/commit/664ba02fdb871d5e8cbf7cf59c592dd89a597a67
>
> Thoughts?
>

Seems reasonable to me. I think you should include this patch in the
series you post,
Jan can always choose to take only part of the series.

As I wrote in github comment, some lines are just too ugly to live,
even if you didn't
write them, so if you touch them and it is not a great effort, you
better fix them.
The BUG() statement in fsnotify_perm() simply cannot live.
Even the compiler should know this line cannot be reached, so it
should be removed.

Thanks,
Amir.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
  2018-10-07 11:13               ` Matthew Bobrowski
  2018-10-07 13:40                 ` Amir Goldstein
@ 2018-10-08  9:35                 ` Jan Kara
  1 sibling, 0 replies; 20+ messages in thread
From: Jan Kara @ 2018-10-08  9:35 UTC (permalink / raw)
  To: Matthew Bobrowski; +Cc: Jan Kara, Amir Goldstein, Steve Grubb, linux-fsdevel

Hi Matthew,

On Sun 07-10-18 22:13:22, Matthew Bobrowski wrote:
> On 4/10/18 2:33 am, Jan Kara wrote:
> > On Wed 03-10-18 19:18:27, Amir Goldstein wrote:
> >> On Wed, Oct 3, 2018 at 6:40 PM Jan Kara <jack@suse.cz> wrote:
> >>>
> >>> On Tue 02-10-18 13:37:13, Amir Goldstein wrote:
> >> [...]
> >>>> I am in fact in leaning to the former (as Mathew implemented it), because
> >>>> I am looking at inotify and my effort to add the "dentry" events to fanotify.
> >>>> First, my proposal suggests to report the optional event flag FAN_ONDIR,
> >>>> just like inotify does.
> >>>
> >>> Well, we already do deliver FAN_ONDIR event flag if the event was on
> >>> directory AFAIK. Just with fanotify you also have to explicitely ask for
> >>> events on directories to be delivered by setting FAN_ONDIR in the mark's
> >>> mask.
> >>>
> >>
> >> We actually mask it in out fanotify, so in inotify, it is out-only and
> >> in fanotify, it is in-only.
> > 
> > OK, didn't notice that. Thanks for educating me.
> > 
> >> BTW, I could not help cleaning up that horrible FAN_MARK_ONDIR
> >> and it won us a very nice optimization of directory access events.
> >> patches to follow soon.
> > 
> > Cool! Less work for me as I also had tingling in my fingers to clean up
> > that mess, just didn't get to it yet :).
> > 
> >>> If that's your concern, what if we just masked out all
> >>> "unwanted" events in fanotify_handle_event()? fanotify_should_send_event()
> >>> does all the masking anyway so it's not like we'd loose any performance
> >>> with that and with current set of fanotify events it would be completely
> >>> transparent.
> >>>
> >>
> >> I though about this first, but got myself confused thinking it would be messy.
> >> Now I am looking again and don't understand why.
> >>
> >> I will try to sum up the solution for us and for Mathew:
> >> - No FAN_ENABLE_EXEC (sorry for that detour)
> >> - Implementation in fsnotify_open() is exactly as Mathew did it, but
> >> changing the
> >>   name of the flag to FS_OPEN_EXEC
> >> - Add FAN_OPEN_EXEC to valid user events mask and valid outgoing events
> >> - fanotify_should_send_event() returns the mask  to be reported in the event
> >> -- s/return false/return 0/
> >> -- return event_mask & FAN_ALL_OUTGOING_EVENTS & marks_mask &
> >>                                  ~marks_ignored_mask;
> >>
> >> So we won't report events that user did not set a mask for and we won't report
> >> events that user has set an ignore mask for.
> > 
> > Exactly. Just I'd do the change to fanotify_should_send_event() as a
> > separate patch and rename that function to something like
> > fanotify_group_event_mask() or something like that to better express what
> > it will do.
> 
> I've gone ahead and implemented the changes based on what we agreed above.
> This first commit introduces the new event type FAN_OPEN_EXEC, as well as
> adds the necessary check within the fsnotify_open() hook. You can find this
> change here:
> 
> https://github.com/matthewbobrowski/linux/commit/2709f54a84047dc08fdc0bf3e8407a5275440c25
> 
> The second commit contains the necessary changes to
> fanotify_should_send_event(). This function basically now returns the event
> mask for the event containing flags ONLY set to those requested by the
> user. You can find this change here:
> 
> https://github.com/matthewbobrowski/linux/commit/596c531365229d439e374149f5ba62011008bb0c
> 
> Please provide feedback on the above.
> 
> Also, we haven't really discussed how we can incorporate this within
> fsnotify_perm(). However, I was thinking that we can simply do something
> along the lines of what I've done here (defining another flag
> FAN_OPEN_EXEC_PERM):
> 
> https://github.com/matthewbobrowski/linux/commit/664ba02fdb871d5e8cbf7cf59c592dd89a597a67
> 
> Thoughts?

>From a quick glance patches look OK to me but please post them normally via
email. That way it's easier for me to review and comment on various small
things in individual patches. Thanks!

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2018-10-08 16:45 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-27 13:05 [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC Matthew Bobrowski
2018-09-27 13:57 ` Amir Goldstein
2018-09-28  1:27   ` Matthew Bobrowski
2018-09-28  5:39     ` Amir Goldstein
2018-10-01  8:21       ` Matthew Bobrowski
2018-10-01  9:13         ` Amir Goldstein
2018-10-01 10:58 ` Jan Kara
2018-10-01 14:01   ` Amir Goldstein
2018-10-02  9:24     ` Jan Kara
2018-10-02 10:37       ` Amir Goldstein
2018-10-03 15:40         ` Jan Kara
2018-10-03 16:18           ` Amir Goldstein
2018-10-03 16:33             ` Jan Kara
2018-10-03 20:45               ` Matthew Bobrowski
2018-10-07 11:13               ` Matthew Bobrowski
2018-10-07 13:40                 ` Amir Goldstein
2018-10-08  9:35                 ` Jan Kara
2018-10-02 11:50       ` Matthew Bobrowski
2018-10-03 15:45         ` Jan Kara
2018-10-01 11:06 ` Jan Kara

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).