Re: git: a6d57f312f18 - main - nfsd: Fix handling of hidden/system during Open/Create

Reply: Rick Macklem : "Re: git: a6d57f312f18 - main - nfsd: Fix handling of hidden/system during Open/Create"
In reply to: Benjamin Kaduk: "Re: git: a6d57f312f18 - main - nfsd: Fix handling of hidden/system during Open/Create"
Go to: [ bottom of page ] [ top of archives ] [ this month ]

From: Rick Macklem <rick.macklem_at_gmail.com>
Date: Fri, 09 Jan 2026 23:47:09 UTC

On Fri, Jan 9, 2026 at 3:42 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> On Fri, Jan 09, 2026 at 03:04:33PM -0800, Rick Macklem wrote:
> > On Fri, Jan 9, 2026 at 11:56 AM Benjamin Kaduk <bjkfbsd@gmail.com> wrote:
> > >
> > > On Thu, Jan 8, 2026 at 4:33 PM Rick Macklem <rmacklem@freebsd.org> wrote:
> > >>
> > >> The branch main has been updated by rmacklem:
> > >>
> > >> URL: https://cgit.FreeBSD.org/src/commit/?id=a6d57f312f18bbeeda8a34e99d0a662b0db9a190
> > >>
> > >> commit a6d57f312f18bbeeda8a34e99d0a662b0db9a190
> > >> Author:     Rick Macklem <rmacklem@FreeBSD.org>
> > >> AuthorDate: 2026-01-08 16:27:32 +0000
> > >> Commit:     Rick Macklem <rmacklem@FreeBSD.org>
> > >> CommitDate: 2026-01-08 16:27:32 +0000
> > >>
> > >>     nfsd: Fix handling of hidden/system during Open/Create
> > >>
> > >>     When an NFSv4.n client specifies settings for the archive,
> > >>     hidden and/or system attributes during a Open/Create, the
> > >>     Open/Create fails for ZFS.  This is caused by ZFS doing
> > >>     a secpolicy_xvattr() call, which fails for non-root.
> > >>     If this check is bypassed, ZFS panics.
> > >>
> > >>     This patch resolves the problem by disabling va_flags
> > >>     for the VOP_CREATE() call in the NFSv4.n server and
> > >>     then setting the flags with a subsequent VOP_SETATTR().
> > >>
> > >
> > > The diff doesn't really include enough context to tell -- does this introduce a race window where a file that's supposed to be hidden and/or system is visible without that attribute from a different process?
> > I believe that the answer is no.
> >
> > VOP_CREATE() returns the new file's vnode exclusively locked
> > and the update via VOP_SETATTR() happens before the vnode
> > lock is released.
>
> I expected/hoped that that was the case, but just couldn't tell from the
> diff itself.
I suppose I should have said that "if there is a race, it is in the FreeBSD
OpenZFS port and I would consider that a bug".
I am not  ZFS guy.

rick

>
> Thanks!
>
> -Ben