问题标签 [fanotify]

我正在检查当前fatrace的源代码。

调用fanotify获取数据值的主循环如下：

当提取与事件关联的文件名时，代码如下所示：

/proc/self/fd/"data->fd"我很困惑为什么文件名是从而不是提取的/proc/"data->pid"/fd/"data->fd"？

是否有像 fanotify 这样的设施，但用于 exec() 操作？类似于MacOS 中的 kauth，但在用户空间中。

fanotify 似乎只通知（并允许/拒绝）文件打开/关闭/读取/写入。

我已经看到可以通过其他方式（也在此处）通知 fork 和 exec 的代码，但是没有办法允许或拒绝 exec。此外，这种方法似乎也有缺点，因为并非所有内核都使用 netlink/proc 连接器编译，并且它可能会被事件淹没。

这与手册页中的示例几乎相同。一切都更新到最新版本。gcc 是 4.9.2。gdb 是 7.8.1。linux内核是3.17.6-1（64位）。安装是最近的拱形引导程序。这是缩减的案例：

大多数时候，这很好用，但有时却不行。我认为这是 fanotify_mark 永远不会返回的时候。在尝试调试时，我发现我可以（不能）复制它进行调试。如果我使用 gdb 并尝试使用 'n' 单步执行，fanotify_mark() 将永远不会返回并且是不可中断的 (^C, ^Z)。

这可以在其他地方复制，还是我做错了什么？

/iaw

亲爱的 linux C 程序员：

在 linux fanotify 工具中，我知道如何监视文件打开（FAN_OPEN）。如果我一直监控到关闭，我还可以了解打开是“读取”还是“写入”，因为有 FAN_CLOSE_WRITE 和 FAN_CLOSE_NOWRITE。

我一直认为会在 open() 时间告诉 POSIX 文件是否打开以进行读/写，这样 fanotify 会让我在打开时区分它们，而不是在关闭时区分它们。我在这里一定是错的。

我是吗？为什么？

/iaw

我正在开发备份服务。它跟踪要备份的目录中文件的更改。它通过设置监视（在 Linux 中使用 inotify）并比较文件更改后的修改时间和大小来实现。如果是，则将整个文件复制到备份。我在想，这样可以做得更有效率吗？如果备份服务可以确定偏移量和写入的字节数，它可以只复制它，而不是复制整个文件。我一直在寻找 fanotify，它提供了一些有趣的功能，比如修改文件的 fd（由其他进程）。现在我想它停止了。据我所知，没有办法使用 fanotify 的过程如何从 fd 确定文件的更改方式。

我是否忽略了某些内容，或者无法获取此信息？

我发现非常不清楚 fanotify 标志代表什么。我用它来进行访问控制，并想识别为读取和写入而打开的文件。取自人：

FAN_OPEN_PERM 应用程序想要打开文件或目录。阅读器必须编写一个响应，以确定是否应授予打开文件系统对象的权限。

是否可以只允许读取文件而不允许写入？

编辑：我很清楚这些可以在接收FAN_CLOSE_WRITEand时实现FAN_CLOSE_NOWRITE，但我想根据文件是打开读取还是编辑来做出访问决定

我想使用，fanotify(7)我遇到的问题是，在某些内核CONFIG_FANOTIFY_ACCESS_PERMISSIONS上不起作用，尽管CONFIG_FANOTIFY已配置。

至少我想报告这种情况。

现在在 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 手册页的示例将任何信息写入文件，同时处理文件打开和关闭的事件。对“fopen”的系统调用导致系统挂起。当我将“FAN_OPEN_PERM”更改为“FAN_OPEN”时，一切正常，但“FAN_OPEN_PERM”标志不允许记录文件。

有什么我错过了使用 fanotify 技术的地方吗？或者处理 fanotify 存在任何限制？

或者在处理 fanotify 事件时记录文件的任何更好的想法？

我已经在 'Ubuntu 14.04.3 64bit' 和 '3.16.0-70-generic' 内核版本下编译和测试。

我添加了一些这样的代码：

然后，我将下一个代码添加到“handle_events”函数中

查看修改后的“handle_events”函数

我正在尝试编写一个备份实用程序，该实用程序应该可以处理大量文件夹中大约 2 TB 的数据。

我希望它在文件被创建/编辑/删除时对文件执行操作，最好还有文件移动或重命名。

我搞砸了 fanotify，只是意识到它只适用于文件编辑。如果可以的话，我反对使用 inotify，因为我必须编辑最大文件监视，我不想这样做。我想这会对性能产生很大的影响。

我最好只设置一个文件监视，它可以递归地处理它下面的所有文件。有没有这方面经验的人知道什么是好方法？我应该去 inotify 并只接受性能打击吗？或者我可以采取不同的方法吗？

我从 fanotify 接收文件系统事件。有时我想获得正在访问的文件的绝对路径。

通常，这不是问题 -fanotify_event_metadata包含一个文件描述符fd，所以我可以调用readlink并/proc/self/fd/<fd>获取我的路径。

但是，如果路径超出，PATH_MAX readlink则无法再使用 - 它会失败并显示ENAMETOOLONG. 我想知道在这种情况下是否有办法获取文件路径。

显然，我可以fstat从 fanotify 获得的描述符并遍历整个文件系统，寻找具有相同设备 ID 和 inode 编号的文件。但是这种方法在性能方面对我来说是不可行的（即使我优化它以忽略比 更短的路径PATH_MAX）。

我尝试通过重新打开并调用来获取fd父O_PATH目录openat(fd, "..", ...)。显然，这失败了，因为fd没有引用目录。我还尝试在readlink调用失败后检查缓冲区的内容（希望它包含部分路径）。那也没有用。

到目前为止，我已经设法在打开它们的进程的工作目录中获取文件的长路径（fanotify 事件包含pid一个目标进程，因此我可以/proc/<pid>/cwd从那里读取并获取到根目录的路径）。但这是部分解决方案。

有没有办法在不遍历整个文件系统的情况下从文件描述符中获取绝对路径？最好是与内核 2.6.32/glibc 2.11 一起工作的那个。

更新：对于好奇。我已经弄清楚为什么readlink("/proc/self/fd/<fd>", ...使用足够大的缓冲区来存储整个路径的调用不起作用。

查看do_proc_readlink的实现。请注意，它不buffer直接使用提供。相反，它分配一个页面并在调用d_path时将其用作临时缓冲区。换句话说，不管有多大buffer，d_path总是会被限制在一个页面的大小。在 amd64 上是 4096 字节。一样PATH_MAX！当它用完提到的页面时，它-ENAMETOOLONG本身由prepend返回。