The inode operations only exist to support the proc_permission
function. Currently mem_read and mem_write have all the same
permission checks as ptrace. The fs check makes no sense
in this context, and we can trivially get around it by
calling ptrace.
So simply the code by killing the strange weird case.
I admit the code has had this check since 2.2 but even
there it doesn't seem to make sense.
Signed-off-by: Eric W. Biederman <[email protected]>
---
fs/proc/base.c | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
c5af674b972bf21e1bc69b8d9c343e3158d2b3c0
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 8b938ef..1d1feb7 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -881,10 +881,6 @@ static struct file_operations proc_oom_a
.write = oom_adjust_write,
};
-static struct inode_operations proc_mem_inode_operations = {
- .permission = proc_permission,
-};
-
#ifdef CONFIG_AUDITSYSCALL
#define TMPBUFLEN 21
static ssize_t proc_loginuid_read(struct file * file, char __user * buf,
@@ -1645,7 +1641,6 @@ static struct dentry *proc_pident_lookup
#endif
case PROC_TID_MEM:
case PROC_TGID_MEM:
- inode->i_op = &proc_mem_inode_operations;
inode->i_fop = &proc_mem_operations;
break;
#ifdef CONFIG_SECCOMP
--
1.2.2.g709a
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]