Linux文件事件监控之Fanotify [一]【转】
转自:https://zhuanlan.zhihu.com/p/186027813
从监听到监控
Linux的文件事件监听的原理并不复杂,简单说就是当一个应用层的进程操作一个目录或文件时,会触发system call,此时内核的notification子系统可以守在那里,把该进程对文件的操作上报给应用层的监听进程(称为listerner)。
![](https://pic4.zhimg.com/80/v2-4bd6409eb9d445e0b9d257c8ceb159b7_720w.jpg)
在这个领域,自2001年的2.4版本就引入的dnotify可以说是先驱,然而,它的缺陷实在太多了。正如其名字传达的,只能监控directory,并且它采用的是signal机制来向listener发送通知,因而可以携带的信息很有限。
所以,dnotify基本已经成了「先烈」,一个更优秀的名为"inotify"的监听机制于2005年在2.6.13内核中亮相,它除了可以监控目录,还可以监听普通文件产生的事件。此外,inotify摈弃了signal机制,改为通过event queue的形式向listener上传事件的相关信息。
看起来,inotify已经算是比较完备了,但是它在应用上还是存在诸多限制。其中一个最明显的问题是它只能"notify",作为listener,只是知道有这个文件事件发生了,最多记录一下,但并不能改变什么(比如被杀毒软件判定为病毒文件,就需要阻止这个操作)。
![](https://pic3.zhimg.com/80/v2-6f1f262d7d0d5cc4ca3aea762c3e5ae2_720w.jpg)
到了2.6.36内核,fanotify的出现解决了这个痛点,允许listener介入并改变文件事件的行为,才算实现了从“监听”到“监控”的跨越,同时也扩展了其应用的范围。
两个API
fanotify的调用接口是比较简洁的,主要有2个API,但其可携带的参数还是为它的使用增加了很多的灵活性。作为listerner,首先需要通过fanotify_init()函数来设定监控的模式:
#include <fcntl.h>
#include <sys/fanotify.h>
int fanotify_init(unsigned int flags, unsigned int event_f_flags);
如果"flags"为"FAN_CLASS_CONTENT",意思是当一个文件的content准备好后,listerner就要介入了,然后给出阻止/放行的决定。为"FAN_CLASS_NOTIF"就是listerner只需要被notify就可以了,类似于「已阅」,但不给出任何的修改意见。
虽然fanotify在内核中并不是作为一个module存在的,也没有对应的设备文件,但从抽象的角度,你完全可以把它视作一个特殊的文件,而"fanotify_init"就是去"open"这个文件,因此这里的"event_f_flags" 其实和VFS中open()系统调用的"flags" 参数差不多(比如" O_RDONLY"),这也是为什么需要包含"fcntl.h"头文件的原因。
同open()一样,该函数返回的也是代表fanotify这个特殊文件的file descriptor,获得了fd后,就可以利用fanotify_mark()来展开具体的配置了:
int fanotify_mark(int fanotify_fd, unsigned int flags,
uint64_t mask, int dirfd, const char *pathname);
文件事件的监控大致包括两个维度:对哪些文件产生的事件感兴趣,以及对这些文件的哪些事件感兴趣。"flags" 就是用来增加/删除感兴趣的文件列表(通过"FAN_MARK_ADD"/"FAN_MARK_REMOVE"等),而"mask" 就是用来设置感兴趣的事件列表,比如"FAN_OPEN"就是当文件被打开时,产生一个事件给listener。
至于"dirfd" 和"pathname",则是用来给出文件路径的,比如"AT_FDCWD"就表示从当前路径(Current Working Directory)开始解析。
一个mark针对一个文件,那它是怎么和内核中表示文件的数据结构关联起来的呢?文件的唯一标识是inode,mark通过一个"fsnotify_mark_connector"类型的指针,指向了inode结构体中对应的元素(至于这里为什么是叫"fsnotify"而不是"fanotify",将在本文后半部分给出答案):
![](https://pic2.zhimg.com/80/v2-0abd530d94a8fcaa403e985c2e73fd1d_720w.jpg)
熟悉epoll的同学可能已经发现,fanotify_init()其实和epoll_create()挺像的,都是用来监听文件,而本身的instance也作为一个文件,有对应的file descriptor供应用程序操作。fanotify_mark()则可类比于epoll_ctl(),都是用来增删和修改事件列表的。
int epoll_create(int size);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
不过,fanotify并没有epoll_wait()这样的轮询机制,不能直接让listerner收到事件,所以在具体的使用上,fanotify和poll/epoll是层级的关系:
![](https://pic1.zhimg.com/80/v2-909528050bb4f1c3b89ec8b6f6269214_720w.jpg)
那为什么不直接只用epoll呢?这还得从fanotify的原理说起。先来看下对于一个被监控文件进行open操作时,fanotify是怎么发挥作用的:
![](https://pic4.zhimg.com/80/v2-9a0a73d8a68d9fa694bfa1f44df81f6b_720w.jpg)
在do_dentry_open()之前,都是VFS的标准调用路径,而到了security_file_open()这里,已经准备好hook,在此潜伏已久的各路人马就开始出手了:
int security_file_open(struct file *file)
{
int ret = call_int_hook(file_open, 0, file);
if (ret)
return ret;
return fsnotify_perm(file, MAY_OPEN);
}
这些人马主要来自LSM(Linux Security Module),比如著名的SELinux(参考这篇文章):
call_int_hook -->
hlist_for_each_entry(P, &security_hook_heads.FUNC, list) {
RC = P->hook.FUNC(__VA_ARGS__);
if (RC != 0)
break;
}
统一入口
走到fsnotify_perm()这里,终于轮到前面已经露过一回脸的fsnotify了。从dnotify到inoitfy,再到fanotify,缺陷和限制逐渐减少,但这不是一个迭代的关系,它们仨的代码目前都存在于"/fs/notify"目录。
同时,由于机制的相似性,它们存在很多共通之处,将这些共通之处提取出来,就成了fsnotify。fsnotify作为后端,负责接收文件事件,它被作为前端、和listener直接交互的dnotify, inotify和fanotify所共享。
每一个前端instance被抽象为一个"group"(在代码中由"fsnotify_group"结构体表示),每个group都有自己的notification queue(以下简称"nq"),用于向listener传递事件。
从效率的角度,fsnotify不会把收到的事件依次放到每个group的"nq"上,而是只维护一个event queue,根据各个group配置的mask,在其对应的"nq"里存放指针,指向event queue中感兴趣的事件。
![](https://pic1.zhimg.com/80/v2-23048f6ebd328b9f631285c06c0ff5fc_720w.jpg)
那fsnotify具体是如何将事件送到fanotify这个group,fanotify又是怎样和应用层的listener打交道的呢,请看下文分解。
参考:
原创文章,转载请注明出处。