Can anyone recommend a piece of software that will watch a file or a
directory and tell me what processes mess with the files in there? In
particular, I'd like it to react when a file is removed.

I tried dnotify but it only tells me that it happened, after it
happened, not who did it.

I need this because on this one Debian testing server I have a problem
that's driving me mad: something comes around and periodically removes
files from /var dirs, making certain services crash and burn: Samba
tdb files, Apache SSL mutex, MySQL and Postgres runtime files and so
on. And I can't figure out who the hell is doing that.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

lsof will show you currently open files, and of course you can pipe it
through grep. If they aren't already opened, though, it might not
.

I'd do a complete inventory of the files that get deleted, and then
check the permissions on all of them. That might give you some clues.

You might also check your cron jobs. rgrep through the /etc/cron*
directories and see if any of the missing filenames are there.

Another question is, how often does it happen? Is it regular or
random?

You might also install tiger and see if it finds anything. And, of
course, install logwatch and check its messages daily. And make sure
you're getting the mail for root so you can see any warnings. And grep
through your logs in /var/log.

Let us know if you find the culprit.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

WireSpot wrote:

> Can anyone recommend a piece of software that will watch a file or a
> directory and tell me what processes mess with the files in there? In
> particular, I'd like it to react when a file is removed.

Tripwire can tell you that it's changed, but not who has changed it.
There's a debian package by the same name for the free version (retired
product got GPL'd), though the change management features and auditing
support are way better if you're in a business environment with a budget to
go in on Tripwire Enterprise.

> I tried dnotify but it only tells me that it happened, after it
> happened, not who did it.

I know there's some kind of auditing option that you have to enable at the
kernel level to be able to pass that kind of auditing information to
programs like dnotify and tripwire, but they escape me right now.

> I need this because on this one Debian testing server I have a problem
> that's driving me mad: something comes around and periodically removes
> files from /var dirs, making certain services crash and burn: Samba
> tdb files, Apache SSL mutex, MySQL and Postgres runtime files and so
> on. And I can't figure out who the hell is doing that.

Is tmpreaper installed, but misconfigured?


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, Jan 22, 2007 at 04:52:53PM +0200, WireSpot wrote:
> Can anyone recommend a piece of software that will watch a file or a
> directory and tell me what processes mess with the files in there? In
> particular, I'd like it to react when a file is removed.
>
> I tried dnotify but it only tells me that it happened, after it
> happened, not who did it.
>
> I need this because on this one Debian testing server I have a problem
> that's driving me mad: something comes around and periodically removes
> files from /var dirs, making certain services crash and burn: Samba
> tdb files, Apache SSL mutex, MySQL and Postgres runtime files and so
> on. And I can't figure out who the hell is doing that.

If it were me and I didn't know any better, I'd suspect a security
breach until proved otherwise. I'm assuming that you haven't been
running something like samhain from day one. Look at when this problem
started in relation to when a package got installed.

As far as 'who' is doing this, I would guess that the only user with the
privledge to do this is root. The problem of processes is that they
come and go. You can look at all the running processes in /proc and
examine all the command lines and environments but it may not .

To clarify, how do you mean "periodically"? Do you mean periodically
like a cron job, or at random intervals (occasionally)?

Doug.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

I don't mean periodically, more like "random but often". Sometimes
several times a day, sometimes not at all.

The server is on an intranet, in a mainly Windows network, and cannot
be accessed from the Internet. It holds little interest to anybody
apart from myself. It simply doesn't hold any useful information, so
I'd say that, logically, the possibility that a human is doing this is
remote.

I've tried inotify too, but all these monitoring tools seem focused
exclusively on what and when happens, not on who did it. I'm wondering
if it's even possible to catch a process in the act. As you said, even
with all the ps and lsof and proc info it's still hard to figure out
what's going on, if I'm doing it even a second too late.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Jan 28, 2007 at 12:48:36PM +0200, WireSpot wrote:
> I don't mean periodically, more like "random but often". Sometimes
> several times a day, sometimes not at all.

I know you've said this before, but is it the same files? or the same
directory? if it is, in that you can narrow down the scope somewhat,
maybe a simple chown root:root, chmod 000 on the appropriate part of
the file system will get you some info: if they still disappear, then
someone's got root...
>
> The server is on an intranet, in a mainly Windows network, and cannot
> be accessed from the Internet. It holds little interest to anybody
> apart from myself. It simply doesn't hold any useful information, so
> I'd say that, logically, the possibility that a human is doing this is
> remote.

how many other users? just because YOU don't think its very
interesting doesn't mean others don't. sometimes its just interesting
to be able to do it...

I know I'm no here, just trying to point out that you may be
eliminating possibilities that maybe shouldn't be eliminated.

A

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFvQRVaIeIEqwil4YRArOJAKDHDZJpvp/hSMZCRKCxbhrSDf+J4gCeNJbz
3Y54bHLSwNgbve94tGV7EaA=
=Noe5
-----END PGP SIGNATURE-----

On 1/28/07, Andrew Sackville-West <andrew@farwestbilliards.com> wrote:
> I know you've said this before, but is it the same files? or the same
> directory? if it is, in that you can narrow down the scope somewhat,
> maybe a simple chown root:root, chmod 000 on the appropriate part of
> the file system will get you some info: if they still disappear, then
> someone's got root...

Pretty much files under /var/run. I've only noticed files whose
dissapearance actually hurts a service. There doesn't seem to be a
logic, or I haven't seen it yet.

The chown idea is perhaps worth investigating. Well, if the culprit is
a daemon that runs with root priviledges it's not going to be much
use, but still... Or perhaps chattr -i and see if a specific error
message appears anywhere.

> how many other users? just because YOU don't think its very
> interesting doesn't mean others don't. sometimes its just interesting
> to be able to do it...
>
> I know I'm no here, just trying to point out that you may be
> eliminating possibilities that maybe shouldn't be eliminated.

I'm fairly sure there's no human involved in this. There's absolutely
no gain in this, since it's a fresh install, except perhaps in driving
me crazy. And if a regular 9-to-5 office accountant learned to hack
Debian just to get to me then I have bigger problems that this.

But seriously, Occam's Razor says that in this circumstances it's more
likely to be a crazed piece of software rather than a crazed person.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org