linux-next: manual merge of the akpm-current tree with the vfs tree

linux-next: manual merge of the akpm-current tree with the vfs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
fs/anon_inodes.c between commit 24b0303e9532 ("take anon inode allocation
to libfs.c") from the vfs tree and commit 02f3ac4386d9 ("anon_inodefs:
forbid open via /proc") from the akpm-current tree.

I just dropped the akpm-current changes for today - they should probably
be applied to fs/libfs.c.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the akpm-current tree with the vfs tree

[Oleg Nesterov]

On 11/08, Stephen Rothwell wrote:
>
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got a conflict in
> fs/anon_inodes.c between commit 24b0303e9532 ("take anon inode allocation
> to libfs.c") from the vfs tree and commit 02f3ac4386d9 ("anon_inodefs:
> forbid open via /proc") from the akpm-current tree.
>
> I just dropped the akpm-current changes for today - they should probably
> be applied to fs/libfs.c.

Well, this probably means that

	anon_inodefs-forbid-open-via-proc.patch

should be dropped. I'll rediff this patch against vfs.git

Oleg.

Re: linux-next: manual merge of the akpm-current tree with the vfs tree

[Oleg Nesterov]

On 11/08, Oleg Nesterov wrote:
>
> On 11/08, Stephen Rothwell wrote:
> >
> > Hi Andrew,
> >
> > Today's linux-next merge of the akpm-current tree got a conflict in
> > fs/anon_inodes.c between commit 24b0303e9532 ("take anon inode allocation
> > to libfs.c") from the vfs tree and commit 02f3ac4386d9 ("anon_inodefs:
> > forbid open via /proc") from the akpm-current tree.
> >
> > I just dropped the akpm-current changes for today - they should probably
> > be applied to fs/libfs.c.
>
> Well, this probably means that
>
> 	anon_inodefs-forbid-open-via-proc.patch
>
> should be dropped. I'll rediff this patch against vfs.git

24b0303e9532 also removes anon_inode_fops. It seems that it was not really
needed anyway, inode_init_always() does inode->i_fop = empty_fops...

So probably we can simply change empty_fops but I need to recheck.

Oleg.

--- x/fs/inode.c
+++ x/fs/inode.c
@@ -114,6 +114,11 @@ int proc_nr_inodes(ctl_table *table, int
 }
 #endif
 
+static int empty_open(struct inode *inode, struct file *file)
+{
+	return -ENXIO;
+}
+
 /**
  * inode_init_always - perform inode structure intialisation
  * @sb: superblock inode belongs to
@@ -125,7 +130,9 @@ int proc_nr_inodes(ctl_table *table, int
 int inode_init_always(struct super_block *sb, struct inode *inode)
 {
 	static const struct inode_operations empty_iops;
-	static const struct file_operations empty_fops;
+	static const struct file_operations empty_fops = {
+		.open = empty_open,
+	};
 	struct address_space *const mapping = &inode->i_data;
 
 	inode->i_sb = sb;

[PATCH 0/1] fs: forbid to open anon-inode files via /proc

[Oleg Nesterov]

On 11/08, Oleg Nesterov wrote:
>
> On 11/08, Oleg Nesterov wrote:
> >
> > On 11/08, Stephen Rothwell wrote:
> > >
> > > Hi Andrew,
> > >
> > > Today's linux-next merge of the akpm-current tree got a conflict in
> > > fs/anon_inodes.c between commit 24b0303e9532 ("take anon inode allocation
> > > to libfs.c") from the vfs tree and commit 02f3ac4386d9 ("anon_inodefs:
> > > forbid open via /proc") from the akpm-current tree.
> > >
> > > I just dropped the akpm-current changes for today - they should probably
> > > be applied to fs/libfs.c.
> >
> > Well, this probably means that
> >
> > 	anon_inodefs-forbid-open-via-proc.patch
> >
> > should be dropped. I'll rediff this patch against vfs.git
>
> 24b0303e9532 also removes anon_inode_fops. It seems that it was not really
> needed anyway, inode_init_always() does inode->i_fop = empty_fops...
>
> So probably we can simply change empty_fops but I need to recheck.

Well. It looks "really obvious" that any user of inode_init_always()
either needs to change ->i_fop or this file should not be opened via
/proc...

So, Al, feel free to ignore, this is minor. Still I think this patch
makes sense. Based on vfs.git#for-next.

Oleg.

[PATCH 1/1] fs: forbid to open anon-inode files via /proc

[Oleg Nesterov]

open("/proc/pid/$anon-fd") should fail, we can't create the new
file with correctly. Currently this creates the bogus file with
->f_op == empty_fops copied from ->i_fop, this is harmless but
still wrong and misleading.

Now that anon_inode_fops has gone away we can add empty_no_open()
to disallow this. This affects anon_inode_getfile() and the new
aio_private_file().

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
 fs/inode.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/fs/inode.c b/fs/inode.c
index 4bcdad3..b7c159c 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -114,6 +114,11 @@ int proc_nr_inodes(ctl_table *table, int write,
 }
 #endif
 
+static int empty_no_open(struct inode *inode, struct file *file)
+{
+	return -ENXIO;
+}
+
 /**
  * inode_init_always - perform inode structure intialisation
  * @sb: superblock inode belongs to
@@ -124,8 +129,10 @@ int proc_nr_inodes(ctl_table *table, int write,
  */
 int inode_init_always(struct super_block *sb, struct inode *inode)
 {
+	static const struct file_operations empty_fops = {
+		.open = empty_no_open,
+	};
 	static const struct inode_operations empty_iops;
-	static const struct file_operations empty_fops;
 	struct address_space *const mapping = &inode->i_data;
 
 	inode->i_sb = sb;
-- 
1.5.5.1