[PATCH] lsm: make SECURITY_PATH always enabled

[Song Liu]

Hi Paul, 

Thanks for your quick comments! 

> On Apr 22, 2025, at 12:53 PM, Paul Moore <paul at paul-moore.com> wrote:
> 
> On Apr 22, 2025 Song Liu <song at kernel.org> wrote:
>> 
>> Only TOMOYO needed CONFIG_SECURITY_PATH when it was introduced. But now,
>> AppArmor, EVM, IMA and LandLock also need it. And kernels are likely built
>> with at least one of these enabled if CONFIG_SECURITY is enabled. Let's
>> simplify the dependency.
>> 
>> Signed-off-by: Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp>
>> Signed-off-by: Song Liu <song at kernel.org>
>> ---
>> This was initially proposed in [1], but got Nacked by Paul.
> 
> I chose not to merge the patch with the following comment:
> 
> "If a Kconfig option is only needed by a subset of LSMs, which is the
>  case for CONFIG_SECURITY_PATH, it should remain a build-time option."
> 
> ... and that reasoning still sounds reasonable to me today.

I agree that a way to disable some LSM hooks at build time is valuable.

> 
>> ... but it is really up to the LSMs to decide how
>> they use struct path.
> 
> LSMs are currently free to select CONFIG_SECURITY_PATH as needed.  In
> fact, if you look any modern Linux tree you'll see that TOMOYO, AppArmor,
> Landlock, IMA, and EVM all select CONFIG_SECURITY_PATH based on their
> individual Kconfig settings.

However, I don't think existing CONFIG_SECURITY_* are doing the right 
things. Among all the configs, CONFIG_SECURITY_PATH is the most awkward
to me. Say , if we have CONFIG_SECURITY_PATH, shouldn't we also have 
CONFIG_SECURITY_INODE? IOW, something like:

#ifdef CONFIG_SECURITY_INODE
int security_inode_rmdir(struct inode *dir, struct dentry *dentry);
#endif

#ifdef CONFIG_SECURITY_PATH
int security_path_rmdir(struct inode *dir, struct dentry *dentry);
#endif 

OR, maybe we should just remove security_inode_rmdir(), and users of 
security_inode_rmdir() can just use security_path_rmdir() instead? 
As I writing this, I think merging security_inode_rmdir() and
security_path_rmdir() is a better solution. But the motivation stays
the same: the separation of CONFIG_SECURITY_PATH from CONFIG_SECURITY
is weird. 

Does this make sense?

Thanks,
Song

[...]