我想利用fanotify(7)
和我遇到的问题是,在某些内核CONFIG_FANOTIFY_ACCESS_PERMISSIONS
不起作用,虽然配置了CONFIG_FANOTIFY
。如何确定是否启用了CONFIG_FANOTIFY_ACCESS_PERMISSIONS?
至少我想报告这种情况。
现在在Debian和Ubuntu上,我可以使用相当于grep CONFIG_FANOTIFY_ACCESS_PERMISSIONS /boot/config-$(uname -r)
来验证该功能是否可用。在其他一些系统上,我可以使用相当于zgrep CONFIG_FANOTIFY_ACCESS_PERMISSIONS /proc/config.gz
,但可能有更多的系统未被这两种方法所覆盖。
有没有办法找出任何fanotify(7)
函数是否在当前正在运行的内核上提供fanotify权限处理?
我正在考虑类似于返回ENOSYS
的方法,当fanotify_mark()
没有实现(fanotify_mark(2)
),但在文档中找不到类似的东西。
好找。那将是例如'fanotify_mark(-1,FAN_MARK_FLUSH,FAN_ALL_PERM_EVENTS,-1,NULL)'如果没有fanotify支持,'C库调用产生-1'errno == ENOSYS',如果没有访问权限事件支持,'errno == EINVAL'和'errno == EBADF'如果Fanotify支持访问权限支持可用。但是,你能依靠这种无证的行为吗?未来可能会改变吗?我不知道;我自己可能不会相信这一点。不过,这可能值得在linux-fsdevel邮件列表中查询。 –
@NominalAnimal,是的,完全没有记录,但我没有看到为什么这个检查可能会在未来被删除的原因;检查用户请求是否受支持是合乎逻辑的。 – gavv
实际上,我更担心检查在某个时间点被重新排序。 [在该函数中]的各种检查有很多种方式(https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/notify/fanotify/fanotify_user.c)重新排序会禁用检测。例如,如果在掩码检查之前检查了文件描述符。 –