VOP_SETLABEL(9)

💅 VOP_SETLABEL 💅

okay so bestie, this is a page from the Kernel Developer's Manual — yes, we're doing kernel dev today, we're built different 💪 — and it's all about VOP_SETLABEL, the vnode call that persistently store an updated MAC label on a vnode. no cap, that's the whole vibe. 🎀

---

✨ SYNOPSIS ✨

#include <sys/param.h>
#include <sys/vnode.h>
#include <security/mac.h>

int
VOP_SETLABEL(struct vnode *vp, label *label);

---

🌸 DESCRIPTION 🌸

So here's the tea ☕: this vnode call gets made once the mac(9) file relabeling operation has been authorized, and now the filesystem has to actually be updated. like, permission was granted, bestie — now go write it down. 🫶

🦋 Single-Label vs. Multi-Label Filesystems

Single-label filesystems are the ones that don't implement per-file labels — and honestly? they can simply leave the vnode(9) operation undefined. iconic minimalism. ✨ but bestie, these filesystems must not set the MNT_MULTLABEL flag in their struct mount. not even a little.

Multi-label filesystems are the ones that do implement per-vnode label storage — they set the MNT_MULTILABEL flag in their struct mount. 💅

The UFS filesystem uses a superblock flag to persistently configure whether a specific filesystem implements a label for each vnode(9), and then keys various behaviors on whether that flag is set. so it's giving "flag-driven behavior" and we love that.

🎀 Extended Attributes

If the filesystem implements extended attributes, then the MAC Framework's vop_stdsetlabel_ea() function can be used, and it maps operations into a series of VOP_OPENEXTATTR(9), VOP_WRITEEXTATTR(9), and VOP_CLOSEEXTATTR(9). a lil trilogy, we stan. 📚

Filesystems will also need to call mac_vnode_create_extattr() when a new filesystem object is created, so that suitable extended attributes can be written out — and mac_vnode_associate_extattr() when a vnode(9) is associated with a filesystem object for the first time. these utility functions use VOP_OPENEXTATTR(9), VOP_READEXTATTR(9), VOP_WRITEEXTATTR(9), and VOP_CLOSEEXTATTR(9) as required. iykyk. 🔥

🧚 Locking and Crash Safety

In all cases, it is super important that exclusive vnode(9) locks be held to prevent concurrent access when a MAC label may not yet be initialized. 🔒 don't skip this, bestie, fr fr.

It's also important that operations are ordered so that a system crash does not leave a file improperly labeled. for example — and this is the main character example right here 👑 — the extended attribute for a newly created file must be written to disk before the file is linked by its parent directory, so that there's no opportunity for a crash to lead to an unlabeled file. order matters, periodt. 💀

---

🔒 LOCKS 🔒

The vnode will be locked on entry and should remain locked on return. that's it, that's the rule. 🫡

---

⭐ RETURN VALUES ⭐

If the MAC label is successfully set, then zero is returned. slay. ✨

Otherwise, an appropriate error code is returned. 😭

---

💜 ERRORS 💜

• [EOPNOTSUPP] — the file system does not support VOP_SETLABEL().
• [ENOSPC] — the file system is out of space. 💀
• [EROFS] — the file system is read-only.

Depending on the underlying implementation of VOP_SETLABEL(), other errors may also be possible. 👀

---

🌈 SEE ALSO 🌈

mac(9), mount(9), vnode(9), VOP_CLOSEEXTATTR(9), VOP_OPENEXTATTR(9), VOP_READEXTATTR(9), VOP_WRITEXTATTR(9)

---

👑 AUTHORS 👑

This manual page was written by Robert Watson. ty for your service, king. 🫶

---

and that's the whole page, bestie! this one came to you from the Debian edition, dated February 27, 2021 — go forth and label your vnodes responsibly 💅🦋🌸