On Wed 25 Oct 2017 at 09:38:54 (-0400), Gene Heskett wrote: > On Wednesday 25 October 2017 09:19:04 Roberto C. Sánchez wrote: > > > On Tue, Oct 24, 2017 at 11:49:21AM -0500, David Wright wrote: > > > Perhaps you could watch the file with inotifywait, and capture > > > a ps and maybe even a lsof listing at that moment. > > > > I have both inotify-hookable and incrond watching the file and the > > output of `lsof /etc/resolv.conf` and `ps -ef` triggered by both of > > those for any access if resolv.conf (whether read or write) does not > > show anything related to resolv.conf at all, except for the incron and > > inotify-hookable processes watching the file. > > > > Regards, > > > > -Roberto > > And I have a thought. The immutable bit may be hiding the attempted > access from inotifywait because it may be set to only report success at > changing the file. I am not familiar with inotify-hookable. But > inotifywait has several options so I'd study the man page to see if a > different one may be more suitable to catch this perp. I use it here to > tell kmail about incoming mail by triggering on the closing of > the /var/spool/mail/name file(s) after procmail has delivered it. It > has worked well for that for at least a decade now. > > But thats not germane to this, only that I am familiar with it to that > extent.
I think that is correct. I would assume that the immutable attribution bit is seen as soon as the directory entry is consulted, whereas the inode is the item actually being watched for change. But if the OP is going to unset the attribution, I hope they'll post the lsattr output first: we've had no evidence posted here that an immutable file has been modified. Cheers, David.
