VACCESS_ACL_NFS4(9)

💖 VACCESS_ACL_NFS4 💖

okay bestie, so this one lives in section 9 of the Kernel Developer's Manual (the kernel-dev girlies know 👑), and it's literally the function that decides whether your NFSv4 ACL says yes or no to an access request. vaccess_acl_nfs4 — generate a NFSv4 ACL access control decision using vnode parameters. no cap, that's the whole gig.

---

✨ SYNOPSIS ✨

first you gotta pull in the headers, periodt:

#include <sys/param.h>
#include <sys/vnode.h>
#include <sys/acl.h>

int
vaccess_acl_nfs4(enum vtype type, uid_t file_uid, gid_t file_gid,
    struct acl *acl, accmode_t accmode, struct ucred *cred,
    int *privused);

---

🌸 DESCRIPTION 🌸

so this call implements the logic for the Unix discretionary file security model with NFSv4 ACL extensions. it's giving "classic Unix permissions but with the NFSv4 glow-up" 💅

here's what you're handing it:

• the vnode's type — type
• the owning UID — file_uid
• the owning GID — file_gid
• the access ACL for the file — acl
• the desired access mode — accmode
• the requesting credential — cred
• and an optional call-by-reference int pointer — privused — that reports back whether privilege was actually required for the call to succeed

now about that privused bestie, listen up: the caller can set it to NULL if she simply does not wish to be informed of privilege information 🫶 OR she can point it at an integer that will be set to 1 if privilege is used, and 0 otherwise. no in-between, we don't do ambiguity here.

this call is intended to support implementations of VOP_ACCESS(9) — those implementations use their own access methods to retrieve the vnode properties, and then invoke vaccess_acl_nfs4() to do the actual check. and they may choose to implement additional security mechanisms whose results get composed with the return value. teamwork, honestly ✨

the algorithm vaccess_acl_nfs4() runs is based on the NFSv4 ACL evaluation algorithm, as described in NFSv4 Minor Version 1, draft-ietf-nfsv4-minorversion1-21.txt. it selects a matching entry from the access ACL, which may then be composed with an available ACL mask entry — providing Unix security compatibility. the way it serves both worlds at once? iconic.

once the appropriate protections are selected for the current credential, the requested access mode, in combination with the vnode type, gets compared against the discretionary rights available for the credential. and if the rights granted by those discretionary protections are insufficient, then super-user privilege — if it's available for the credential — will also be considered. so there's a little backup plan in the mix 😌

---

⭐ RETURN VALUES ⭐

• vaccess_acl_nfs4() returns 0 on success 🎉
• or a non-zero error value on failure 💀

---

🎀 ERRORS 🎀

• [EACCES] — Permission denied. An attempt was made to access a file in a way forbidden by its file access permissions. rude, but valid.
• [EPERM] — Operation not permitted. An attempt was made to perform an operation limited to processes with appropriate privileges or to the owner of a file or other resource.

---

🦋 SEE ALSO 🦋

• vaccess(9)
• vnode(9)
• VOP_ACCESS(9)

---

👑 AUTHORS 👑

the current implementation of vaccess_acl_nfs4() was written by Edward Tomasz Napierala <trasz@FreeBSD.org>. thank you king 🙏

---

💀 BUGS 💀

ngl, this manual page should include a full description of the NFSv4 ACL evaluation algorithm, or cross reference another page that does. it does not. we're aware. it's a known situation. 😭

---

mwah, that's the whole page bestie 💜 this one came from Debian, dated September 18, 2009 — yes she's a vintage icon and she still slays 🌈✨