On Fri, Jan 9, 2026 at 11:56 AM Benjamin Kaduk <[email protected]> wrote: > > CAUTION: This email originated from outside of the University of Guelph. Do > not click links or open attachments unless you recognize the sender and know > the content is safe. If in doubt, forward suspicious emails to > [email protected]. > > 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. rick > > Thanks, > > Ben
