VACCESS_ACL_POSIX1E(9)

πŸ’– vaccess_acl_posix1e πŸ’–

okay bestie, welcome to vaccess_acl_posix1e(9) from the Kernel Developer's Manual β€” yes she's a section 9 girlie, kernel-internals only, no cap πŸŽ€


✨ NAME ✨

vaccess_acl_posix1e β€” generate a POSIX.1e ACL access control decision using vnode parameters

like. the whole point of her. she looks at a vnode and a credential and goes "hmm, allowed or not?" πŸ’…


🌸 SYNOPSIS 🌸

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

int
vaccess_acl_posix1e(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 POSIX.1e ACL extensions ✨ it's the actual brain doing the math, fr fr.

here's what she takes in:

  • 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, which returns whether or not privilege was required for a successful evaluation of the call πŸ‘‘

about that privused pointer β€” the caller can set it to NULL if they simply don't want to be informed of privilege info, bestie, no hard feelings πŸ’… or they can point it at an integer, and it'll get set to 1 if privilege is used, and 0 otherwise. very demure, very mindful.

now the vibe: this call is intended to support implementations of VOP_ACCESS(9), which will use their own access methods to retrieve the vnode properties and then invoke vaccess_acl_posix1e() to do the actual check. and listen β€” implementations of VOP_ACCESS(9) may choose to implement additional security mechanisms whose results will be composed with the return value. so she's not the whole story, she's the main character of her part 🌈

the algorithm she runs is based on the POSIX.1e ACL evaluation algorithm. the way it works: the algorithm selects a matching entry from the access ACL, which may then be composed with an available ACL mask entry β€” providing Unix security compatibility 🫢

once appropriate protections are selected for the current credential, the requested access mode, combined with the vnode type, gets compared against the discretionary rights available for that credential. and if the rights granted by discretionary protections are insufficient? then super-user privilege, if available for the credential, will also be considered πŸ‘‘ periodt.


⭐ RETURN VALUES ⭐

  • vaccess_acl_posix1e() 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. she said no 🚫
  • [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. also no, but with ✨authority✨

🧚 SEE ALSO 🧚

go read them, iykyk πŸ“š


πŸ‘‘ AUTHORS πŸ‘‘

This manual page and the current implementation of vaccess_acl_posix1e() were written by Robert Watson. thank you for your service king πŸ«‘πŸ’œ


πŸ™ˆ BUGS πŸ™ˆ

This manual page should include a full description of the POSIX.1e ACL evaluation algorithm, or cross reference another page that does.

yeah. she's aware. the docs are lowkey incomplete, bestie β€” the algorithm deserves a full writeup or at least a link to one, and right now it's giving "we'll finish it later" 😭 iconic honestly.


and that's the whole page!! this one came from Debian, dated August 22, 2001 β€” vintage, but still slaying in kernel space πŸ’…πŸŒΈ mwah, go check your ACLs πŸŽ€

πŸ“¦ where this page comes from