sys_execve and sys_uselib do not call into fsnotify
Subsystems (2)
PATCH 1/1 sys_execve and sys_uselib do not call into fsnotify
sys_execve and sys_uselib do not call into fsnotify so inotify does not get open events for these types of syscalls. This patch simply makes the requisite fsnotify calls.
---
fs/exec.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
fs/exec.c +5 -0
@@ -51,6 +51,7 @@#include <linux/audit.h> #include <linux/tracehook.h> #include <linux/kmod.h> +#include <linux/fsnotify.h> #include <asm/uaccess.h> #include <asm/mmu_context.h>
@@ -135,6 +136,8 @@ asmlinkage long sys_uselib(const char __user * library)if (IS_ERR (file)) goto out; +fsnotify_open (file->f_path.dentry); + error = -ENOEXEC ;if (file->f_op) {struct linux_binfmt * fmt;
@@ -687,6 +690,8 @@ struct file *open_exec(const char *name)if (IS_ERR (file))return file; +fsnotify_open (file->f_path.dentry); + err =deny_write_access (file);if (err) {fput (file);
Hello Eric,
Quoted 3 lines · Eric Paris
sys_execveandsys_uselibdo not call into fsnotify so inotify does not get open events for these types of syscalls. This patch simply makes the requisite fsnotify calls.
Just curious, isn't the fact that the open still may fail a problem? For example, if the lib is not executable in sys_uselib or if the file was denied write access in open_exec.
Regards,
Frederik
Quoted 45 lines
Signed-off-by Eric Paris <[email protected]>---
fs/exec.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)fs/exec.c +5
-1@@ -51,6 +51,7 @@#include <linux/audit.h> #include <linux/tracehook.h> #include <linux/kmod.h> +#include <linux/fsnotify.h> #include <asm/uaccess.h> #include <asm/mmu_context.h> @@ -135,6 +136,8 @@ asmlinkage long sys_uselib(const char __user * library)if (IS_ERR (file)) goto out; +fsnotify_open (file->f_path.dentry); + error = -ENOEXEC ;if (file->f_op) {struct linux_binfmt * fmt;@@ -687,6 +690,8 @@ struct file *open_exec(const char *name)if (IS_ERR (file))return file; +fsnotify_open (file->f_path.dentry); + err =deny_write_access (file);if (err) {fput (file); --To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 10 lines · Frederik Deweerdt
Hello Eric,
Quoted 3 lines · Eric Paris
sys_execveandsys_uselibdo not call into fsnotify so inotify does not get open events for these types of syscalls. This patch simply makes the requisite fsnotify calls.Just curious, isn't the fact that the open still may fail a problem? For example, if the lib is not executable in
sys_uselibor if the file was denied write access inopen_exec.
I could be convinced to change it but like what I have. At this point the file is open. If it fails after this we are going to call fput() which calls __fput() which calls fsnotify_close(). Seemed odd to leave a close without an open (although that's what we have today.)
This doesn't mean the syscall was successful, but the file was opened, and it will be closed....
-Eric
Quoted 5 lines · Eric Paris
Quoted 3 lines · Frederik Deweerdt
Just curious, isn't the fact that the open still may fail a problem? For example, if the lib is not executable in
sys_uselibor if the file was denied write access inopen_exec.
Quoted 7 lines
I could be convinced to change it but like what I have. At this point the file is open. If it fails after this we are going to call
fput()which calls__fput()which callsfsnotify_close(). Seemed odd to leave a close without an open (although that's what we have today.)This doesn't mean the syscall was successful, but the file was opened, and it will be closed....
OK, thanks for clarifying,
Frederik
Quoted 3 lines · On Wed, 17 Dec 2008 13:53:20 -0500 Eric Paris <[email protected]> wrote:
sys_execveandsys_uselibdo not call into fsnotify so inotify does not get open events for these types of syscalls. This patch simply makes the requisite fsnotify calls.
These two functions are grovelling around in pretty low-level fs operations. One wonders whether they could be converted (ie: cleaned up) to use do_sys_open() or some other such higher-level thing.
That way, this fsnotify bug would be magically fixed, too.
Quoted 7 lines
Quoted 3 lines · On Wed, 17 Dec 2008 13:53:20 -0500 Eric Paris <[email protected]> wrote:
sys_execveandsys_uselibdo not call into fsnotify so inotify does not get open events for these types of syscalls. This patch simply makes the requisite fsnotify calls.
Quoted 5 lines
These two functions are grovelling around in pretty low-level fs operations. One wonders whether they could be converted (ie: cleaned up) to use
do_sys_open()or some other such higher-level thing.That way, this fsnotify bug would be magically fixed, too.
hmm..
In current implementaion, do_sys_open() call fd_install(). then, it cause /proc/{pid}/fd entry change. iow, compatibility break.
Yup, it is fixable. but I think Eric's implementation is simpler.
Quoted 5 lines
sys_execveandsys_uselibdo not call into fsnotify so inotify does not get open events for these types of syscalls. This patch simply makes the requisite fsnotify calls.Signed-off-by Eric Paris <[email protected]>
I hope append your latter explain into the patch description.
Quoted 7 lines
I could be convinced to change it but like what I have. At this point the file is open. If it fails after this we are going to call
fput()which calls__fput()which callsfsnotify_close(). Seemed odd to leave a close without an open (although that's what we have today.)This doesn't mean the syscall was successful, but the file was opened, and it will be closed....
I think open/close pairing is important thing to this patch.
Otherthings, looks good to me. very thanks.