Kernel-internal VOP_ACCESS(3-arg) callers silently get access(2)-style REAL-ID authorization semantics from vop_helper_access

Summary

vop_helper_access selects cr_ruid/cr_rgid (real IDs) whenever a_flags lacks AT_EACCESS. That is correct for access(2)/faccessat(2) and exec is correct via VOP_EACCESS. But the bare 3-arg VOP_ACCESS macro also passes flags=0, so kernel-internal authorization callers of that macro get REAL-ID permission checks — inconsistent with the kernel's primary open(2)/path gate naccess_lva which uses EFFECTIVE uid/groups. On every currently-reachable internal path the deviation is deny-only (spurious EACCES for euid≠ruid processes): sys_fhopen is euid-0-gated; fp_vpopen serves only kernel consumers; tmpfs_lookup and ext2 lookup/rename VWRITE checks sit behind nlookup's effective-ID gate; the NFS server sees only client creds where ruid==uid (flagged 'XXX ruid/rgid vs uid/gid' by the authors). The hazard is latent: any new internal caller of VOP_ACCESS — or any reordering letting the helper's check run before an effective-ID gate — silently converts real-ID matching into an authorization GRANT for setuid/setgid contexts. Fix: internal authorization callers should use VOP_EACCESS (one-line changes at vfs_syscalls.c:4888, kern_fp.c:162, tmpfs_vnops.c:180, ext2 sites).

Timeline

• 2026-09-02 Discovered during pass-2 audit of vfs_helper.c (GLM 5.3).