| Message ID | 20191128155940.17530-12-mszeredi@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | various vfs patches | expand |
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?
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
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 --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 }, };
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(-)