[Bug]: Error getting full file path in `fs-monitor` with archlinux and file in `/tmp`

[JuxhinDB]

Contact Details

No response

What happened?

@MatteoNardi:

Turns out the issue is not related to the kernel version, but to Archlinux. I reproduced the issue with another Archlinux machine running 5.15, which is the same version of my development Ubuntu 22.04 machine.

Creating a file with the path /tmp/1/2/3/4/myfile emits an event with path /1/2/3/4/myfile, so I suppose it has something to do with some special behavior of the /tmp folder. For some reason, the kernel struct dentry's chain of d_parent we traverse for building the path, ends prematurely.

Relevant log output

#### Kernel/OS


[vagrant@archlinux ~]$ uname -a
Linux archlinux 5.17.1-arch1-1 #1 SMP PREEMPT Mon, 28 Mar 2022 20:55:33 +0000 x86_64 GNU/Linux

Output

test tests::unlink_file ... FAILED                           

failures:                     

---- tests::file_name stdout ----                            
[INFO  bpf_common::trace_pipe] Logging events from /sys/kernel/debug/tracing/trace_pipe                                    
69581201284 1120 deleted /file_name_1                                                                                      
69581219467 1120 created /file_name_1                                                                                      
69581228087 1120 open /tmp/file_name_1 (33345)                                                                             

69581219467 1120 created /file_name_1 (3/4)                                                                                
- pid: 1120 (OK)              
- timestamp: 69581190947 - 69581233481 (OK)                                                                                
- event type: FsEvent :: FileCreated (OK)                                                                                  
- filename: (FAIL)                                           
  |    found: StringArray { data: "/file_name_1" }                                                                         
  | expected: StringArray { data: "/tmp/file_name_1" }                                                                     

thread 'tests::file_name' panicked at 'No event found matching results', /home/matteo/projects/pulsar-experiments/bpf_common/src/test_runner.rs:155:13   
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace                                              

---- tests::unlink_file stdout ----                          
[INFO  bpf_common::trace_pipe] Logging events from /sys/kernel/debug/tracing/trace_pipe                                    
70211704597 1120 deleted /unlink_file                                                                                      

70211704597 1120 deleted /unlink_file (3/4)                                                                                
- pid: 1120 (OK)              
- timestamp: 70211693859 - 70211718252 (OK)                                                                                
- event type: FsEvent :: FileDeleted (OK)                                                                                  
- filename: (FAIL)                                           
  |    found: StringArray { data: "/unlink_file" }                                                                         
  | expected: StringArray { data: "/tmp/unlink_file" }                                                                     

thread 'tests::unlink_file' panicked at 'No event found matching results', /home/matteo/projects/pulsar-experiments/bpf_common/src/test_runner.rs:155:13 


failures:                     
    tests::file_name                                         
    tests::unlink_file                                       

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[MatteoNardi]

This happens also to files in /dev/shm

[hnidoaht-101]

More information on this issue, it caused failed tests randomly in 3 tests under file-system-monitor. I'm on Manjaro Linux - kernel version 5.15.57-2-MANJARO

[MatteoNardi]

Ubuntu has no /tmp mount, by adding it I could reproduce the issue. It seems the path extracting code has a bug when encountering mount points. That code was mostly copied from Tracee ~~which strangely doesn't have this bug. I'll take a deeper look at this.~~

Update: The bug is present in the inode_create and inode_unlink LSM hooks because they get only a struct dentry argument. On the other hand, the file_open hook works fine since it gets a struct file.

If I got this right:

• struct dentry represents the filepath on the current file system.
• struct file represents an open file. It contains struct path, which is a struct dentry alongside the struct vfsmount
• struct vfsmount can be used to get the dentry of the directory where the current file-system is mounted on. This allows to build the full path.

This would mean struct dentry is not enough to get the full path. We should make sure this is correct and search for other means (eBPF attach points) to get the struct vfsmount

[krsh]

Same issue on Yocto

[MatteoNardi]

Commands to reproduce under Ubuntu and other distributions not using tmpfs:

mkdir /tmp/tmp/
sudo mount -t tmpfs some_arbitrary_name /tmp/tmp/
cargo build && sudo TMPDIR=/tmp/tmp ./target/debug/test-suite file