is_access_to_paths_allowed(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

okay bestie, welcome to is_access_to_paths_allowed(9) from the Kernel API Manual β€” the function that checks accesses for requests with a common path. she's giving serious kernel-helper main character energy, and we're obsessed. πŸ’…βœ¨

🌸 NAME 🌸

  • is_access_to_paths_allowed β€” check accesses for requests with a common path. that's the whole gig. πŸŽ€

✨ SYNOPSIS ✨

here's the signature, exactly as she ships:

bool is_access_to_paths_allowed (const struct landlock_domain *const
       domain , const struct path *const path , const access_mask_t
       access_request_parent1 , struct layer_masks *layer_masks_parent1 ,
       struct landlock_request *const log_request_parent1 , struct dentry
       *const dentry_child1 , const access_mask_t access_request_parent2 ,
       struct layer_masks *layer_masks_parent2 , struct landlock_request *const
       log_request_parent2 , struct dentry *const dentry_child2 );

🫢 ARGUMENTS 🫢

okay, argument-by-argument, because every single one matters:

  • domain β€” the domain to check against. πŸ‘‘
  • path β€” the file hierarchy to walk through. for refer checks, this would be the common mountpoint. πŸ¦‹
  • access_request_parent1 β€” the accesses to check, once layer_masks_parent1 is equal to layer_masks_parent2 (if any). this is tied to the unique requested path for most actions, or the source in case of a refer action (i.e. rename or link), or the source and destination in case of RENAME_EXCHANGE. love that for us. πŸ’–
  • layer_masks_parent1 β€” pointer to a matrix of layer masks per access masks, identifying the layers that forbid a specific access. bits from this matrix can be unset according to the path walk. an empty matrix means that domain allows all possible Landlock accesses (i.e. not only those identified by access_request_parent1). this matrix can initially refer to domain layer masks and, when the accesses for the destination and source are the same, to requested layer masks. ✨
  • log_request_parent1 β€” audit request to fill if the related access is denied. πŸ“
  • dentry_child1 β€” dentry to the initial child of the parent1 path. this pointer must be NULL for non-refer actions (i.e. not link nor rename). 🚨 so please don't play with that one.
  • access_request_parent2 β€” similar to access_request_parent1 but for a request involving a source and a destination. this refers to the destination, except in case of RENAME_EXCHANGE where it also refers to the source. must be set to 0 when using a simple path request. πŸ”₯
  • layer_masks_parent2 β€” similar to layer_masks_parent1 but for a refer action. this must be NULL otherwise. 🫢
  • log_request_parent2 β€” audit request to fill if the related access is denied. πŸ“
  • dentry_child2 β€” dentry to the initial child of the parent2 path. this pointer is only set for RENAME_EXCHANGE actions and must be NULL otherwise. 🚨

πŸ¦‹ DESCRIPTION πŸ¦‹

so the tea β˜•: this helper first checks that the destination has a superset of restrictions compared to the source (if any) for a common path. because of RENAME_EXCHANGE actions, source and destinations may be swapped. then it checks that the collected accesses and the remaining ones are enough to allow the request. that's the whole arc. periodt. πŸ’…

🌈 RETURN 🌈

True if the access request is granted, false otherwise. simple, iconic, no notes. βœ…

πŸŽ€ SEE ALSO πŸŽ€


mwah πŸ’‹ β€” this lil page comes from ./security/landlock, dated October 2026, and it's all about is_access_to_paths_allowed(9). take care of her! 🫢

πŸ“¦ where this page comes from