generic_permission(9)

💅 generic_permission(9) — the Kernel API Manual, bestie edition

okay so this is a page from the Kernel API Manual, and the whole main character here is generic_permission(9). she checks whether you're allowed to touch a file on a Posix-like filesystem. let's get into it ✨

---

🌸 NAME 🌸

generic_permission — literally just checking for access rights on a Posix-like filesystem. that's it. that's the vibe check 🫶

---

🎀 SYNOPSIS 🎀

int generic_permission (struct mnt_idmap *idmap , struct inode *inode ,
       int mask );

---

🦋 ARGUMENTS 🦋

• idmap — the idmap of the mount that the inode was found from. yes it matters, keep reading 💅
• inode — the inode we're checking access rights for. the actual file-ish thing, no cap.
• mask — the right to check for, i.e. MAY_READ, MAY_WRITE, MAY_EXEC, MAY_NOT_BLOCK … the little "…" means there's more where that came from, k? 🙈

---

✨ DESCRIPTION ✨

So. This one is used to check for read/write/execute permissions on a file. and here's the iconic part: we use "fsuid" for this, which lets us set arbitrary permissions for filesystem access without changing the "normal" uids that are used for other things. that's the whole slay. separate concerns, periodt 💅

generic_permission is rcu-walk aware, bestie. it returns -ECHILD in case an rcu-walk request cannot be satisfied (eg. requires blocking or too much complexity). and then? it would just get called again in ref-walk mode. no drama, it's giving "try again later" energy 😭

okay now the idmap part, pay attention 🔥

If the inode has been found through an idmapped mount, the idmap of the vfsmount must be passed through idmap. This function will then take care to map the inode according to idmap before checking permissions.

On non-idmapped mounts — or if permission checking is to be performed on the raw inode — simply pass nop_mnt_idmap. easy. done. bye 🧚

ngl, if you skip the idmap argument when you actually need it, that's a you problem. pass nop_mnt_idmap only when it's non-idmapped or you really do want the raw inode. 🫶

---

👑 SEE ALSO 👑

Kernel file ./fs/namei.c and honestly the whole friend group:

• check_acl(9)
• acl_permission_check(9)
• do_inode_permission(9)
• sb_permission(9)
• inode_permission(9)
• path_get(9)
• path_put(9)
• path_connected(9)
• try_to_unlazy(9)
• try_to_unlazy_next(9)
• complete_walk(9)
• may_follow_link(9)
• safe_hardlink_source(9)
• may_linkat(9)
• may_create_in_sticky(9)
• lookup_fast(9)
• start_dirop(9)
• end_dirop(9)
• kern_path_parent(9)
• vfs_path_parent_lookup(9)
• vfs_path_lookup(9)
• try_lookup_noperm(9)
• lookup_noperm(9)
• lookup_one(9)
• lookup_one_unlocked(9)
• lookup_one_positive_killable(9)
• lookup_one_positive_unlocked(9)
• lookup_noperm_unlocked(9)
• start_creating(9)
• start_removing(9)
• start_creating_killable(9)
• start_removing_killable(9)
• start_creating_noperm(9)
• start_removing_noperm(9)
• start_creating_dentry(9)
• start_removing_dentry(9)
• __start_renaming(9)
• start_renaming(9)
• start_renaming_dentry(9)
• start_renaming_two_dentries(9)
• vfs_prepare_mode(9)
• vfs_create(9)
• atomic_open(9)
• vfs_lookup_open(9)
• vfs_tmpfile(9)
• kernel_tmpfile_open(9)
• end_creating_path(9)
• dentry_create(9)
• vfs_mknod(9)
• vfs_mkdir(9)
• vfs_rmdir(9)
• vfs_unlink(9)
• vfs_symlink(9)
• vfs_link(9)
• vfs_rename(9)
• vfs_readlink(9)
• vfs_get_link(9)
• page_get_link(9)
• page_put_link(9)

like, the entire fs/namei.c roster showed up to the party 🌈

---

💖 that's the whole page, bestie 💖

cute little sign-off: this one comes from ./fs, dated October 2026, and yeah — it's generic_permission(9) all the way down. go check some permissions, you icon. 🎀🌸🦋💜