拦截文件系统系统调用
我正在编写一个应用程序，我需要拦截一些文件系统系统调用，例如。取消链接。我想保存一些文件，比如 abc.txt。如果用户删除该文件，那么我需要将其复制到其他地方。所以我需要在删除 abc 之前取消链接来调用我的代码，以便我可以保存它。我已经完成了与拦截系统调用相关的线程，但是像 LD_PRELOAD 这样的方法在我的情况下不起作用，因为我希望它是安全的并在内核中实现，所以这个方法不会有用。 inotify 在事件发生后发出通知，因此我无法保存它。你能建议任何这样的方法吗？我想在内核模块中实现它，而不是修改内核代码本身。 Graham Lee建议的另一种方法，我曾想过这种方法，但它有一些问题，我需要所有文件的硬链接镜像，它不消耗空间，但仍然可能有问题，因为我必须重复镜像驱动器以保持镜像最新日期，它也不能跨分区工作，并且在不支持链接的分区上工作，所以我想要一个解决方案，通过它我可以将挂钩附加到文件/目录，然后监视更改而不是重复扫描。 我还想添加对写入修改文件的支持，我无法使用硬链接。 我想通过替换系统调用来拦截系统调用，但我在 linux > 中找不到任何执行此操作的方法3.0。请建议一些方法来做到这一点。
I am writing an application for which I need to intercept some filesystem system calls eg. unlink. I would like to save some file say abc. If user deletes the file then I need to copy it to some other place. So I need unlink to call my code before deleting abc so that I could save it. I have gone through threads related to intercepting system calls but methods like LD_PRELOAD it wont work in my case because I want this to be secure and implemented in kernel so this method wont be useful. inotify notifies after the event so I could not be able to save it. Could you suggest any such method. I would like to implement this in a kernel module instead of modifying kernel code itself.
Another method as suggested by Graham Lee, I had thought of this method but it has some problems ,I need hardlink mirror of all the files it consumes no space but still could be problematic as I have to repeatedly mirror drive to keep my mirror up to date, also it won't work cross partition and on partition not supporting link so I want a solution through which I could attach hooks to the files/directories and then watch for changes instead of repeated scanning.
I would also like to add support for write of modified file for which I cannot use hard links.
I would like to intercept system calls by replacing system calls but I have not been able to find any method of doing that in linux > 3.0. Please suggest some method of doing that.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
至于挂钩内核并拦截系统调用，这是我在编写的安全模块中所做的事情：
https://github.com/cormander/tpe-lkm
查看hijacks.c和symbols.c的代码；它们的使用方式在 security.c 内的
hijack_syscalls函数中。我还没有在linux上尝试过这个> 3.0 尚未发布，但相同的基本概念应该仍然有效。这有点棘手，您可能必须编写大量内核代码才能在取消链接之前进行文件复制，但这里是可能的。
As far as hooking into the kernel and intercepting system calls go, this is something I do in a security module I wrote:
https://github.com/cormander/tpe-lkm
Look at hijacks.c and symbols.c for the code; how they're used is in the
hijack_syscallsfunction inside security.c. I haven't tried this on linux > 3.0 yet, but the same basic concept should still work.It's a bit tricky, and you may have to write a good deal of kernel code to do the file copy before the unlink, but it's possible here.
一个建议可能是用户空间中的文件系统（FUSE）。也就是说，编写一个 FUSE 模块（当然，在用户空间中），它拦截与文件系统相关的系统调用，执行您想要的任何任务，并可能在之后调用“默认”系统调用。
然后，您可以使用 FUSE 文件系统挂载某些目录，并且在大多数情况下，似乎不需要覆盖默认的系统调用行为。
One suggestion could be Filesystems in Userspace (FUSE.) That is, write a FUSE module (which is, granted, in userspace) which intercepts filesystem-related syscalls, performs whatever tasks you want, and possibly calls the "default" syscall afterwards.
You could then mount certain directories with your FUSE filesystem and, for most of your cases, it seems like the default syscall behavior would not need to be overridden.
您可以使用 inotify 观看取消链接事件，尽管这对于您的目的来说可能发生得太晚了（我不知道，因为我不知道你的目的，你应该尝试找出答案）。基于 LSM 的内核替代方案（我指的是 SMACK、TOMOYO 和朋友）实际上适用于强制访问控制，因此可能不适合您的目的。
You can watch unlink events with inotify, though this might happen too late for your purposes (I don't know because I don't know your purposes, and you should experiment to find out). The in-kernel alternatives based on LSM (by which I mean SMACK, TOMOYO and friends) are really for Mandatory Access Control so may not be suitable for your purposes.
如果您只想处理删除，则可以保留正在监视的文件的硬链接（通过
link创建）的“影子”目录（通过inotify，如 Graham 的建议）李）。如果原始文件现在已取消链接，您仍然可以根据需要处理影子文件，而无需使用内核模块。
If you want to handle deletions only, you could keep a "shadow" directory of hardlinks (created via
link) to the files being watched (viainotify, as suggested by Graham Lee).If the original is now unlinked, you still have the shadow file to handle as you want to, without using a kernel module.