From: Steve Grubb <sgrubb@redhat.com>
To: John Dennis <jdennis@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: Configuration file monitoring - reporting content changes
Date: Tue, 21 Jul 2015 13:59:01 -0400 [thread overview]
Message-ID: <3307081.aEimE15yPr@x2> (raw)
In-Reply-To: <55AE5967.70609@redhat.com>
On Tuesday, July 21, 2015 10:38:31 AM John Dennis wrote:
> On 07/20/2015 07:08 PM, Steve Grubb wrote:
> > On Monday, July 20, 2015 09:53:47 PM Burn Alting wrote:
> >> I am interested in any Linux based capability that will monitor
> >> identified files and report on actual changes to the monitored file.
> >
> > I know of nothing that does this. But as long as the list of files is
> > limited, it doesn't sound like a hard program to write.
> >
> > Any one else with an opinion?
>
> Yes :-) I'm not so sure it's an easy program to write and be robust in a
> variety of scenarios. I know because I wrote such a program once. The
> basic problem is most people think in terms of monitoring a file by name
> (e.g. it's pathname). But inotify operates on inodes, not filenames. If
> that file is subject to any variety of log rotation strategies or
> modifications by a configuration manager whereby the file is renamed or
> moved to a different directory then any program using inotify to monitor
> the file needs to become reasonably sophisticated and be able to track
> those changes. It is entirely possible for two processes to have opened
> the same file by name but have them be 2 different files (e.g. after
> opening the file path is modified but the process still has the original
> inode open, now a 2nd process opens the same filename but gets a
> different inode). Conflating inodes with filenames can lead to
> unexpected results and if the purpose is some sort of security
> monitoring it will be important these issues are accounted for.
I recently was doing some experimenting with the fanotify API. In my mind, I
think its likely to be better. But it has limitations such as mmap'ed file may
not generate a modify event. So, if I were going to do it, I'd start there.
But you do raise a whole lot of good points. My guess is this would watch
config files which logrotate wouldn't apply. But yes, editors do open a temp
copy and then do a rename. In my experimenting, I didn't bother to see how
fanotify handle renames. (You would think its a modify event.)
-Steve
> Some of this is discussed in these documents which accompany the lwatch
> (Log Watch) program I wrote:
>
> https://jdennis.fedorapeople.org/lwatch/html/InotifyOverview.html
> https://jdennis.fedorapeople.org/lwatch/html/LogWatchOverview.html
next prev parent reply other threads:[~2015-07-21 17:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-20 11:53 Configuration file monitoring - reporting content changes Burn Alting
[not found] ` <201507202109.GAJ05274.tSFOJFFVQMLOHO@I-love.SAKURA.ne.jp>
2015-07-20 13:03 ` Burn Alting
2015-07-20 17:53 ` Smith, Gary R
2015-07-20 22:12 ` Burn Alting
2015-07-20 23:08 ` Steve Grubb
2015-07-21 13:47 ` EXT :Re: " Boyce, Kevin P (AS)
2015-07-21 21:48 ` Burn Alting
2015-07-21 14:38 ` John Dennis
2015-07-21 17:59 ` Steve Grubb [this message]
2015-07-21 21:54 ` Burn Alting
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3307081.aEimE15yPr@x2 \
--to=sgrubb@redhat.com \
--cc=jdennis@redhat.com \
--cc=linux-audit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox