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

[tianjia.zhang]

On 12/9/25 4:22 PM, Mateusz Guzik wrote:
> On Tue, Dec 09, 2025 at 03:53:47PM +0800, Tianjia Zhang wrote:
> > When developing a dedicated LSM module, we need to operate on the
> > file object within the LSM function, such as retrieving the path.
> > However, in `security_file_alloc()`, the passed-in `filp` is
> > only a valid pointer; the content of `filp` is completely
> > uninitialized and entirely random, which confuses the LSM function.
>
> I take it you have some underlying routine called by other hooks as well
> which ends up looking at ->f_path.
>
> Given that f_path *is not valid* to begin with, memsetted or not, your
> file_alloc_security hoook should not be looking at it to begin with.
>
> So I don't think this patch has merit.

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.