I have a forum script running on server and somehow small number of attachments begin to get lost. I want to find out what is deleting them and at what time. How can I setup Linux auditd (auditctl) to watch directory tree (attachments are stored inside multi-level directory tree) to watch for file deletions there?
May be I should use some other tool for this?
This is an answer i wrote to a previous question:
Generally if you wish to know what a process/user/file is doing without having to run lsof against it 24/7 you use auditctl.
Assuming you have a recent-ish kernel audit control should be a simple operation. (This is in Debian-fu, if you're running Red Hat translate as appropriate)
# apt-get install auditdMake sure that its running (/etc/init.d/auditd status).
auditctl -a entry,always -F arch=b64 -S open -F pid=<process id>Replace b64 with b32 if you're running 32-bit arch, open can be replaced by any system call or the word 'all'
For more read the auditctl manpage.
You can use this method and ask it to watch for the 'unlink' system call.
The -w parameter is useful for watching files/directories, but the as the man page explains there are caveats.
-w path Insert a watch for the file system object at path. You cannot insert a watch to the top level directory. This is prohibited by the kernel. Wildcards are not supported either and will generate a warning. The way that watches work is by tracking the inode internally. This means that if you put a watch on a directory, you will see what appears to be file events, but it is really just the updating of meta data. You might miss a few events by doing this. If you need to watch all files in a directory, its recommended to place an individual watch on each file. Unlike syscall auditing rules, watches do not impact performance based on the number of rules sent to the kernel.
While fenix's auditd recommendation seems ideal, you may find a filesystem IDS such as AIDE helpful. Unfortunately, it's unlikely to be fine-grained enough for what you're attempting to isolate.
I'll often write scripts as a solution for problems like what you describe. If you cannot accomplish what you want with solutions recommended, write something yourself. It's often not very complicated.
A couple of ideas. You can use strace to see what your application is doing, but it may generate a log of logs and may slow down the system.
Another idea is to use inotifywait, then lsof/fuser on the file to see what is using it. You can try run this script at high priority (if you can) to have information as accurate as possible. It will probably not catch the unlink call, since the file will be gone before the event is delivered.
