0

There's a process in my system (a standard desktop installation with upwards of 150 quiescent processes at any time) that is sporadically resetting a config file's permissions that I have explicitly set so that it could be read by multiple users.

Even though I have ways to prevent that from happening (eg, changing the file's owner), I really want to find the process that is doing the change, if only so that I can terminate it with extreme prejudice.

I know the kernel has at least 2 mechanisms for this, inotify and the more recent fanotify. However, the latter only intercepts changes to file contents, not to the inode, while the former does detect such changes but doesn't report the process responsible.

So is there another kernel mechanism which i don't know about? Or some other roundabout way of "trapping" the process as it's going to change the file's permissions, or after it has done so?

guntbert
  • 1,637
processterminator
  • 3
  • Thanks for your reply. The post you suggested does not directly resolve my issue, since in my case there are a lot of processes opening and closing that file, and in fact the one that is changing its permissions probably doesn't even open it first (ie, it uses chmod on the file by name). However, i've noticed a mention of SystemTap in the comments to that post, and glancing through the documentation it appears that a kernel modification is required to catch that sort of events (SystemTap places extensive hooks in the kernel). So, apparently, a standard mainline kernel can't do it. – processterminator May 30 '20 at 19:23
  • Per @StalinVigneshKumar's suggestion and StéphaneChazelas's answer (https://unix.stackexchange.com/a/99091/72707), check out: auditctl -w /path/to/that/file -p [r|w|x|a]. Then just watch the generated log file at /var/log/audit/audit.log. – Cbhihe May 30 '20 at 20:12

1 Answers1

0

First try list the open files if you can diagnose , which display the user too along with which program does that.

lsof /path/file-name

Check out these for more details :

Check which process modify file

Stalin Vignesh Kumar
  • 1,755
  • 6
  • 15
  • Please see my comment to guntbert above. Listing open files will not help because a process doesn't have to open a file to change its permissions, and in any case there are many processes working with that file at once. Apparently, a profiling/diagnostics tool like SystemTap will do the trick, but that requires installing kernel modules and whatnot and i find doing that a bit overkill just for this one application. So what i'd like to know is, can an unmodified mainline kernel do this sort of operation (telling which process changed a file's permissions, even if the file is never opened)? – processterminator May 30 '20 at 19:30
  • 1
    @processterminator auditctl from the link I provided wouldn't help ? – Stalin Vignesh Kumar May 30 '20 at 19:33
  • You're right, the kernel audit framework appears to be the way to do it... I guess it's one of those more complicated parts of the kernel that i've always neglected... Thanks! – processterminator May 30 '20 at 20:17
  • @processterminator cool .. Pleasure. Have a great day – Stalin Vignesh Kumar May 30 '20 at 20:20