diff mbox series

[11/12] vfs: don't parse "posixacl" option

Message ID 20191128155940.17530-12-mszeredi@redhat.com
State New
Headers show
Series various vfs patches | expand

Commit Message

Miklos Szeredi Nov. 28, 2019, 3:59 p.m. UTC
Unlike the others, this is _not_ a standard option accepted by mount(8).

In fact SB_POSIXACL is an internal flag, and accepting MS_POSIXACL on the
mount(2) interface is possibly a bug.

The only filesystem that apparently wants to handle the "posixacl" option
is 9p, but it has special handling of that option besides setting
SB_POSIXACL.

Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
---
 fs/fs_context.c | 1 -
 1 file changed, 1 deletion(-)

Comments

Al Viro Dec. 17, 2019, 3:42 a.m. UTC | #1
On Thu, Nov 28, 2019 at 04:59:39PM +0100, Miklos Szeredi wrote:
> Unlike the others, this is _not_ a standard option accepted by mount(8).
> 
> In fact SB_POSIXACL is an internal flag, and accepting MS_POSIXACL on the
> mount(2) interface is possibly a bug.
> 
> The only filesystem that apparently wants to handle the "posixacl" option
> is 9p, but it has special handling of that option besides setting
> SB_POSIXACL.

Huh?  For e.g. ceph having -o posixacl and -o acl are currently equivalent;
your patch would seem to break that, wouldn't it?
Miklos Szeredi Dec. 17, 2019, 4:18 a.m. UTC | #2
On Tue, Dec 17, 2019 at 4:42 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Thu, Nov 28, 2019 at 04:59:39PM +0100, Miklos Szeredi wrote:
> > Unlike the others, this is _not_ a standard option accepted by mount(8).
> >
> > In fact SB_POSIXACL is an internal flag, and accepting MS_POSIXACL on the
> > mount(2) interface is possibly a bug.
> >
> > The only filesystem that apparently wants to handle the "posixacl" option
> > is 9p, but it has special handling of that option besides setting
> > SB_POSIXACL.
>
> Huh?  For e.g. ceph having -o posixacl and -o acl are currently equivalent;
> your patch would seem to break that, wouldn't it?

Yet again, this has nothing to do with mount(2) behavior.  Also note
that mount(8) does *not* handle "posixacl" and does *not* ever set
MS_POSIXACL.

So this has exactly zero chance of breaking anything.

Thanks,
Miklos
Al Viro Dec. 17, 2019, 4:28 a.m. UTC | #3
On Tue, Dec 17, 2019 at 05:18:16AM +0100, Miklos Szeredi wrote:
> On Tue, Dec 17, 2019 at 4:42 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > On Thu, Nov 28, 2019 at 04:59:39PM +0100, Miklos Szeredi wrote:
> > > Unlike the others, this is _not_ a standard option accepted by mount(8).
> > >
> > > In fact SB_POSIXACL is an internal flag, and accepting MS_POSIXACL on the
> > > mount(2) interface is possibly a bug.
> > >
> > > The only filesystem that apparently wants to handle the "posixacl" option
> > > is 9p, but it has special handling of that option besides setting
> > > SB_POSIXACL.
> >
> > Huh?  For e.g. ceph having -o posixacl and -o acl are currently equivalent;
> > your patch would seem to break that, wouldn't it?
> 
> Yet again, this has nothing to do with mount(2) behavior.  Also note
> that mount(8) does *not* handle "posixacl" and does *not* ever set
> MS_POSIXACL.
> 
> So this has exactly zero chance of breaking anything.

Point.  OK, I'm crawling in direction of bed right now - it's that or grab more
coffee, and I'll have to get up before 7am tomorrow ;-/

Later...
diff mbox series

Patch

diff --git a/fs/fs_context.c b/fs/fs_context.c
index 394a05bc03d5..738f59b6c06a 100644
--- a/fs/fs_context.c
+++ b/fs/fs_context.c
@@ -42,7 +42,6 @@  static const struct constant_table common_set_sb_flag[] = {
 	{ "dirsync",	SB_DIRSYNC },
 	{ "lazytime",	SB_LAZYTIME },
 	{ "mand",	SB_MANDLOCK },
-	{ "posixacl",	SB_POSIXACL },
 	{ "ro",		SB_RDONLY },
 	{ "sync",	SB_SYNCHRONOUS },
 };