Re: [PATCH] file: Call security_file_alloc() after initializing the filp

[Al Viro <viro@zeniv.linux.org.uk>]

On Fri, Dec 12, 2025 at 06:01:53PM +0800, tianjia.zhang wrote:

> The scenario is as follows: I have hooked all LSM functions and
> abstracted struct file into an object using higher-level logic. In my
> handler functions, I need to print the file path of this object for
> debugging purposes. However, doing so will cause a crash unless I
> explicitly know that handler in the file_alloc_security context—which,
> in my case, I don't.
> 
> Of course, obtaining the path isn't strictly required; I understand that
> in certain situations—such as during initialization—there may be no
> valid path at all. Even so, it would be acceptable if I could reliably
> determine from filp->f_path that fetching the path is inappropriate. The
> problem is that, without knowing whether I'm in the file_alloc_security
> context, I have no reliable way to decide whether it's safe to attempt
> retrieving the path.

<sarcasm>

"I can't figure out which of the functions in my code is calling (directly)
this function in my code; there's a predicate that might allow me to do
that, but it doesn't really work without this change to function outside
of my code.  With this change I can make the things work; no, I won't
tell you which predicate it is, you'll just have to avoid any changes
in the area in the future, lest my code breaks".

</sarcasm>

In case it's not obvious from the above, your reasoning is unconvincing.