may_follow_link(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

okay so welcome to the Kernel API Manual page for may_follow_link(9), bestie β€” this one is a whole safety vibe check for symlinks ✨


🌸 NAME 🌸

may_follow_link β€” check symlink following for unsafe situations πŸ•΅οΈβ€β™€οΈ


✨ SYNOPSIS ✨

int may_follow_link (struct nameidata *nd , const struct inode *inode );

πŸŽ€ ARGUMENTS πŸŽ€

  • nd β€” nameidata pathwalk data. It's the pathwalk data, literally.
  • inode β€” Used for idmapping. That's its whole job here, no cap.

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so picture this: the sysctl_protected_symlinks sysctl is enabled πŸ‘€ In that case, CAP_DAC_OVERRIDE needs to be specifically ignored if the symlink is in a sticky world-writable directory. Why? Because this is to protect privileged processes from failing races against path names that may change out from under them by way of other users creating malicious symlinks 😭 It's giving safety rails for a very chaotic directory moment.

The way that this works: it will permit symlinks to be followed only when:

  • outside a sticky world-writable directory, or
  • when the uid of the symlink and follower match, or
  • when the directory owner matches the symlink's owner.

Returns 0 if following the symlink is allowed, -ve on error. That's the return vibe β€” 0 means slay, -ve means nope πŸ’€


πŸ‘€ SEE ALSO πŸ‘€

The kernel file ./fs/namei.c is part of the see-also crew too, and here's the whole group chat, no one left out: check_acl(9), acl_permission_check(9), generic_permission(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), 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) πŸ’–


mwah πŸ’‹ and that's the cute little sign-off: source/version is ./fs, date stamp is October 2026, and this may_follow_link(9) page is officially done, bestie 🫢✨

πŸ“¦ where this page comes from