Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.dist > #1014139
| From | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| Newsgroups | linux.debian.bugs.dist, linux.debian.kernel |
| Subject | Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2) |
| Date | 2020-06-16 18:30 +0200 |
| Message-ID | <AimDf-6DY-1@gated-at.bofh.it> (permalink) |
| References | (7 earlier) <Ai2uS-2IP-9@gated-at.bofh.it> <Ai9PH-7gF-3@gated-at.bofh.it> <Ai9PH-7gF-1@gated-at.bofh.it> <AedoR-7Uq-1@gated-at.bofh.it> <Ai9PH-7gF-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Cross-posted to 2 groups.
Hi Bruce,
On Mon, Jun 15, 2020 at 10:42:12PM -0400, J. Bruce Fields wrote:
> On Mon, Jun 15, 2020 at 10:38:20PM -0400, J. Bruce Fields wrote:
> > Thanks for the detailed reproducer.
> >
> > It's weird, as the server is basically just setting the transmitted
> > umask and then calling into the vfs to handle the rest, so it's not much
> > different from any other user. But the same reproducer run just on the
> > ext4 filesystem does give the right permissions....
> >
> > Oh, but looking at the system call, fs_namei.c:do_mkdirat(), it does:
> >
> > if (!IS_POSIXACL(path.dentry->d_inode))
> > mode &= ~current_umask();
> > error = security_path_mkdir(&path, dentry, mode);
> > if (!error)
> > error = vfs_mkdir(path.dentry->d_inode, dentry, mode);
> >
> > whereas nfsd just calls into vfs_mkdir().
> >
> > And that IS_POSIXACL() check is exactly a check whether the filesystem
> > supports ACLs. So I guess it's the responsibility of the caller of
> > vfs_mkdir() to handle that case.
>
> But, that's unsatisfying: why isn't vfs_mkdir() taking care of this
> itself? And what about that security_path_mkdir() call? And are the
> other cases of that switch in fs/nfsd/vfs.c:nfsd_create_locked()
> correct? I think there may be some more cleanup here called for, I'll
> poke around tomorrow.
This might be unneeded to test but as additional datapoint which
confirms the suspect: I tried check the commit around 47057abde515
("nfsd: add support for the umask attribute") in 4.10-rc1
A kernel built with 47057abde515~1, and mounting from an enough recent
client which has at least dff25ddb4808 ("nfs: add support for the
umask attribute") does not show the observed behaviour, the server
built with 47057abde515 does.
Regards,
Salvatore
Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Bug#962254: NFS(v4) broken at 4.19.118-2 Elliott Mitchell <ehem+debian@m5p.com> - 2020-06-05 07:50 +0200
Bug#962254: NFS(v4) broken at 4.19.118-2 Salvatore Bonaccorso <carnil@debian.org> - 2020-06-05 08:50 +0200
Bug#962254: NFS(v4) broken at 4.19.118-2 Elliott Mitchell <ehem+debian@m5p.com> - 2020-06-05 20:20 +0200
Bug#962254: NFS(v4) broken at 4.19.118-2 Salvatore Bonaccorso <carnil@debian.org> - 2020-06-05 20:40 +0200
Bug#962254: NFS(v4) broken at 4.19.118-2 Elliott Mitchell <ehem+debian@m5p.com> - 2020-06-06 00:40 +0200
Bug#934160: Bug#962254: NFS(v4) broken at 4.19.118-2 Elliott Mitchell <ehem+debian@m5p.com> - 2020-06-09 04:00 +0200
Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported ZFS (with acltype=off) (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2) Salvatore Bonaccorso <carnil@debian.org> - 2020-06-13 15:00 +0200
Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported ZFS (with acltype=off) (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2) "J. Bruce Fields" <bfields@redhat.com> - 2020-06-15 17:10 +0200
Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2) Salvatore Bonaccorso <carnil@debian.org> - 2020-06-15 21:00 +0200
Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2) "J. Bruce Fields" <bfields@redhat.com> - 2020-06-16 04:50 +0200
Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2) Salvatore Bonaccorso <carnil@debian.org> - 2020-06-16 07:40 +0200
Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2) Salvatore Bonaccorso <carnil@debian.org> - 2020-06-16 18:30 +0200
Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2) "J. Bruce Fields" <bfields@redhat.com> - 2020-06-17 03:10 +0200
Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl Salvatore Bonaccorso <carnil@debian.org> - 2020-06-17 07:10 +0200
Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2) Salvatore Bonaccorso <carnil@debian.org> - 2020-06-16 07:40 +0200
Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2) "J. Bruce Fields" <bfields@redhat.com> - 2020-06-17 17:40 +0200
Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2) Andreas Gruenbacher <agruenba@redhat.com> - 2020-06-17 19:00 +0200
csiph-web