File create high-level event

[AlonZivony]

We need a high-level event for the creation of new files. We need to think what is file creation before the implementation:

1. Inode creation, which is the unique representation of a file content.
2. The creation of a file (file struct?) which is an instance of a inode in the file system.
3. The association of an unoccupied path by a file (rename of a file is considered creation of a new file in this case).

Each has its pros and cons, as the content is according to the inode but the permissions and path is determined by the file. The path has its own importance, to track filesystem paths with the event. This is an open discussion, you are welcome to add your opinions :)

[AlonZivony]

@yanivagman @rafaeldtinoco @geyslan @josedonizetti if you have an opinion I will be glad to have it here

[yanivagman]

I think inode creation best describes file creation on the system. Struct file, like you said, is an instance of a file and its creation doesn't mean that a new file was created in the system in the sense the user thinks of a file. The third option of renaming a file should be handle with its own file_rename event, but in this case the file was already created, including its metadata that is not changed.

[AlonZivony]

I probably agree with you that between inode to file struct, indoe is much more reasonable. However, I think that path is useful too. Maybe not for file_create event. We can maybe create path_occupation or something similar, so users can track the file system structure. But this is for another issue.

[geyslan]

I would ask first what option should be exposed to the user? Asking for file creation in a directory, i.e. "/etc", or just for a specific filepath, i.e. "/etc/whatsoever"?

[AlonZivony]

I would ask first what option should be exposed to the user? Asking for file creation in a directory, i.e. "/etc", or just for a specific filepath, i.e. "/etc/whatsoever"?

You are referring to path occupation, not file creation, right? Because an inode could be created and be signed under "/tmp", and afterwards move to "/etc" without necessarily creating a new inode. Anyways, asking for the creation of a file under some directory sounds to me like arguments filtering on the pathname argument. So its less relevant to the implementation. However, I learn from your answer that you probably agree that a new file in a specific directory (not necessarily newly created file) is an interesting event. So the occupation of a path entry is important in you eyes, right?

[geyslan]

So the occupation of a path entry is important in you eyes, right?

I asked about how to filter because it's what's relevant to the user, a filepath, be it for a file, directory, hard link, symbolic links, etc. They all depend on inodes (in different ways), but for the user what would matter is the file name (occupation as you referred to it).

On that base, we have to consider that files can be:

• hard links/bind mounts (single inode and multiple paths/bind mounts).
• symlinks (multiple inodes pointing to a single path).

The association of an unoccupied path by a file (rename of a file is considered creation of a new file in this case).

Keeping track of inode -> multiple paths and path -> multiple inodes is what I consider relevant.

[AlonZivony]

Thanks @geyslan for your response :) I think this will go for event for new inode and event for new entry in file system, to track both like you said.

[rafaeldtinoco]

Keeping track of inode -> multiple paths and path -> multiple inodes is what I consider relevant.

Totally agree with @geyslan here. And with what yaniv said earlier.

Inode is what defines a "file" for the VFS (or in general), but... for the end user, a file is a "name". What was the last time you did a ls -i in your desktop =D ?

I would have a "file creation" higher event for "/tmp/XXXX" creation (with dir & base names, plus inode, c/m dates, etc) and I would also have a "file rename" higher level event for "/tmp/XXXX" -> "/etc/XXXX".

[geyslan]

I would have a "file creation" higher event for "/tmp/XXXX" creation (with dir & base names, plus inode, c/m dates, etc) and I would also have a "file rename" higher level event for "/tmp/XXXX" -> "/etc/XXXX".

Agree. The same inode but different events.

[jrmwooldridge]

For pure research d_instantiate is great and helpful for determining default security context for new files. Not sure about BPF though.

[AlonZivony]

For pure research d_instantiate is great and helpful for determining default security context for new files. Not sure about BPF though.

Nice! It seems like a great hook! We also have security_inode_rename for example, but it is only for existing inodes. I am not sure if creation of a new inode will trigger it. I think LSM hooks are usually preferable for long term use, but for now d_instantiate seems to cover more cases.