Monitoring File and Directory Access on Linux

monitoring file and directory access on linux

You probably want inotify-tools. Inotify is part of the linux kernal that triggers events on watched files, directories, or even the contents of entire directories. These tools are command line utilities that tap into the capabilities of inotify and allow you to use them, for example, in your shell scripts.

Specifically, you will probably want to look at inotifywatch

How to monitor a complete directory tree for changes in Linux?

To my knowledge, there's no other way than recursively setting an inotify watch on each directory.

That said, you won't run out of file descriptors because inotify does not have to reserve an fd to watch a file or a directory (its predecessor, dnotify, did suffer from this limitation). inotify uses "watch descriptors" instead.

According to the documentation for inotifywatch, the default limit is 8192 watch descriptors, and you can increase it by writing the new value to /proc/sys/fs/inotify/max_user_watches.

Linux - How to track all files accessed by a process?

lsof:

Try doing this as a starter :

lsof -p <PID>

this command will list all currently open files, fd, sockets for the process with the passed process ID.

For your special needs, see what I can offer as a solution to monitor a php script :

php foo.php & _pid=$!
lsof -r1 -p $_pid
kill %1 # if you want to kill php script

strace:

I recommend the use of strace. Unlike lsof, it stays running for as long as the process is running. It will print out which syscalls are being called when they are called. -e trace=file filters only for syscalls that access the filesystem:

sudo strace -f -t -e trace=file php foo.php

or for an already running process :

sudo strace -f -t -e trace=file -p <PID>

Is it possible to monitor all programs for accessing a file that does not exist?

Watching for non-existant file access is tricky. Kernel has inotify API to watch for file changes, but it wouldn't work for accessing non-existant files. One possible way to be to hook an open() syscall.

Easier solution would be to start httpd with strace directly in foreground, that way no call would be missed.
Example from my local debian box. Stop the service first, then:

source /etc/apache2/envvars 
strace -e trace=open,close,read,write,connect,accept -ff -s 1024 /usr/sbin/apache2 -DFOREGROUND -k start

Make a request in another terminal and the output will show the syscalls made:

curl localhost:80/test -v

Response:

[pid 25419] read(32, "GET /test HTTP/1.1\r\nHost: localhost\r\nUser-Agent: curl/7.47.0\r\nAccept: */*\r\n\r\n", 8000) = 77
[pid 25419] open("/.htaccess", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 25419] open("/var/.htaccess", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 25419] open("/var/www/.htaccess", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 25419] open("/var/www/html/.htaccess", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 25419] read(32, 0x7fa39685b048, 8000) = -1 EAGAIN (Resource temporarily unavailable)
[pid 25419] write(27, "::1 - - [23/Jul/2019:18:35:59 +0200] \"GET /test HTTP/1.1\" 404 438 \"-\" \"curl/7.47.0\"\n", 84) = 84
[pid 25419] read(32, "", 8000) = 0
[pid 25419] read(32, "", 512) = 0
[pid 25419] close(32) = 0
[pid 25419] read(5, 0x7fffc7a4a0df, 1) = -1 EAGAIN (Resource temporarily unavailable)

Monitoring file access in Linux

It is not possible to reliably audit directly attached file access in Linux from userspace alone.

You could poll with lsof but you would risk not detecting accesses between polling. The purpose of the original dnotify module (obsoleted by inotify...) was to avoid having to incur the overhead of polling and to avoid loosing events. The audit system gives user identification at the time of file open.

If you can move the file to an NFS server, then you can use the NFS logging to record access to the file.

The customer could be correct about not installing new packages if this is a production server or if it is a development server that is about to go live. You should consider asking for authorization to set up auditing on the next development or testing server.



Related Topics



Leave a reply



Submit