disclaimer
Filesystems are the most complex part of any OS. I am not a specialist in linux filesystems and even don`t commit the code to linux kernel. So all information here cannot be considered reliable, code has tons of bugs and can damage your machine and ruin the rest of your life
Usermode notifications
linux has 3 mechanisms for passing filesystem notification to user-mode:
all they projected to used-mode as file, so you can use lsof (or even just something like "ls /proc/*/fdinfo/* | xargs grep notify") to find then and what processes do they belong to. Unfortunately (as usually) this information is not enough. Let see for example function fanotify_fdinfo. We can notice that there are 3 possible source of notifications:
- just simple inode - for them dumped inode->i_ino & superblock s_dev - I don`t know how you can in usermode find mountpoint for this superblock
- mount point (btw struct mount even not described in linux/include). At least knowing mnt_id you can find name in /proc/pid/mountinfo file
- superblock - s_dev again dumping
Can you have real-time notifications about setting new xxnotify? Yes, via security_path_notify
Kernel mode notifications
Can you have the same functionality provided by xxnotify in kernel mode? Definitely yes - kernel audit uses it. I could not find any sample code to do this in your own driver so I wrote one. This is not very complex (although function fsnotify_destroy_group is not exported so you need some sort of kallsyms lookup). You can add to tracked_inode everything you want - like full filename, stat etc
And now the main question
Can you find all sources of filesystem notification?
I am not aware of any tools to do this so I wrote one by myself. Let`s think how we can implement this:
- we need enum superblocks first. Function iterate_supers is not exported (who can it stop?)
- then you can enum all mount points (mount_lock is not exported too)
- and enum inodes in current superblock and then enum installed fsnotify_marks (btw as you can guess functions fsnotify_first_mark/fsnotify_next_mark not exported too. My inner paranoia says that there is too many deliberately hidden functions)
Sample of output:
sudo ./lkmem -F -c ~/krnl/curr ~/krnl/System.map-5.11.0-34-generic...superblock[24] at 0xffff8a044be2a000 dev 8388610 flags 70018000 inodes 15923 sda2 mnt_count 43 root 0xffff8a0448f0ecc0 s_type: 0xffffffffa580eaa0 - kernel!ext4_fs_type s_op: 0xffffffffa5050080 - kernel!ext4_sops dq_op: 0xffffffffa50501c0 - kernel!ext4_quota_operations s_qcop: 0xffffffffa5050160 - kernel!ext4_qctl_operations s_export_op: 0xffffffffa5050020 - kernel!ext4_export_ops mnt[0] 0xffff8a04420fec80 mark_cnt 0 mnt_id 28 / rw,relatime shared:1 - ext4 /dev/sda2 rw,errors=remount-ro inode[1873] 0xffff8a0365f1e1a0 i_no 398369 i_flags 1000 FILE i_fsnotify_mask: 1FFE i_fsnotify_marks 0xffff8a036edb5de0 count 1 fsnotify[0] 0xffff8a036ccb8720 mask 1FFE ignored_mask 0 flags 6 group: 0xffff8a036ec09500 ops: 0xffffffffc08f0160 - lkntfy
P.S.: I don`t know why some super-blocks have huge amount of mount points (43 in the above sample). It is quite possible that this is another memory leak