On Fri, Jan 9, 2026 at 3:47 PM Rick Macklem <[email protected]> wrote:
>
> On Fri, Jan 9, 2026 at 3:42 PM Benjamin Kaduk <[email protected]> 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 <[email protected]> wrote:
> > > >
> > > > On Thu, Jan 8, 2026 at 4:33 PM Rick Macklem <[email protected]> 
> > > > wrote:
> > > >>
> > > >> The branch main has been updated by rmacklem:
> > > >>
> > > >> URL: 
> > > >> https://cgit.FreeBSD.org/src/commit/?id=a6d57f312f18bbeeda8a34e99d0a662b0db9a190
> > > >>
> > > >> commit a6d57f312f18bbeeda8a34e99d0a662b0db9a190
> > > >> Author:     Rick Macklem <[email protected]>
> > > >> AuthorDate: 2026-01-08 16:27:32 +0000
> > > >> Commit:     Rick Macklem <[email protected]>
> > > >> 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.
Oh, and I forgot to mention "assuming the server doesn't reboot while
the RPC is in progress". (The reboot while the RPC is in progress might
be handled by ZFS if it was properly patched, but I'm not conversant
with the ZFS code and do not understand the details of how the ZIL
is used.)

rick

>
> rick
>
> >
> > Thanks!
> >
> > -Ben

Reply via email to