text: Kentaro Takeda wrote:> ----- What is this patch for? -----> > There are security_inode_*() LSM hooks for attribute-based MAC, but they are not> suitable for pathname-based MAC because they don't receive "struct vfsmount"> information.> > ----- How this patch was developed? -----> > Two pathname-based MACs, AppArmor and TOMOYO Linux, are trying to merge> upstream. But because of "struct vfsmount" problem, they have been unable toe> merge upstream.> > Here are the list of approaches and the reasons of denial.I know I'm late to the game in this, but as I recently asked about this and didn't get an answer, I'll re-ask my approach.Why can't you do thisin lookup()- resolve rules (not for single process, but for all processes) for said path and tag dentry (seem to already have a hook)in permission()- check tag based on current security contextin rename(),....- drop dentry tag and force a lookup next time its used (invalidate dentry)you then don't have to jump through hoops to handle things like symbolic links as they are handled implicitly.the only place I can see this approach "failing" (as in different semantics than your approach) is- hard links within a single namespace and bind mounts shared between namespaces (in that different rules would be resolved for different path names for the same file).But from a security perspective, both would seem like a very bad idea in general that one would ant to prevent. or to rephrase, why would you want to allow that? What's the benefit in allowing that?