13

I've got 4 specific files that seem to keep disappearing from a user's home directory. As far as we know, there are no cronjobs or other automated tasks that would be removing them. I've setup auditd on them but the logs aren't really showing anything of interest. I can see our backup utility accessing them every night until the point they aren't there anymore, but nothing else. Is there anything that would be causing those files to be removed that would get around auditd?

The files in question are these:

/home/username/.bashrc
/home/username/.bash_profile

as well as a couple of files in that user's .ssh directory. Copies of these files placed into a subfolder called "keepers" get deleted at the same time as well. Changing the permissions on them to 000 and having them owned by root hasn't helped.

I've currently got inotifywait setup to log create,delete,move on that subfolder, so hopefully that will turn up something, although it doesn't log much aside from when it happened, not what caused it.

Chad P
  • 1,460
  • 2
  • 14
  • 16
  • 1
    Please add their names and paths to your post, it may help. – Shadok Aug 23 '11 at 13:18
  • 2
    Also posting auditd logs might be helpful. – Janne Pikkarainen Aug 23 '11 at 13:23
  • 3
    Also you might try creating the files owned as root and chmod 000 to see if they still get removed (or if that causes something else to complain/error out). – polynomial Aug 28 '11 at 06:44
  • 5
    In addition to chmod 0000, you could try chattr +i to try to prevent even root from removing it – mer Sep 12 '11 at 13:39
  • Is this problem happening only for a single user (you called `username`)? – Khaled Sep 12 '11 at 13:48
  • Yes, just a single user and those 4 files. Keep in mind too that this isn't a "user" that logs in frequently, we just occasionally have to log in to do work as that account. It has several cronjobs running that I thought might be the culprit but a search of those hasn't turned up anything either. – Chad P Sep 12 '11 at 14:14
  • 1
    be aware that chattr just helps on ext filesystems. but a chattr should help. :-) You can also use SELINUX instead of chattr to stop those files from being modified. but IMHO the deletion must come from a process or user. – JMW Sep 12 '11 at 16:15
  • 1
    This may not help much, but can you determine, down to the nearest minute, when these files are deleted? Is it the same time for every occurrence? Is it every night? If you see any sort of recognizable pattern, especially a "precise" one, chances are this is an automated process of some sort. If the deletion times are fairly random, this would hint at a human-caused problem. Determining which is occurring can eliminate a lot of the detective work. – Larold Sep 14 '11 at 20:17
  • 1
    Can you update your post and write what process was modifying the files? – colemik Jan 06 '12 at 11:03
  • Did you ever find out what was happening to these files @ChadP? I have the same issue. – Codemonkey Oct 15 '17 at 13:41
  • Specifically mine get deleted upon each reboot. – Codemonkey Oct 31 '17 at 09:41
  • I've figured mine out. I have a cron bash script that runs every minute. It cd's to a cache directory of my website, and deletes any files older then 5 minutes. Sometimes after a reboot that directory doesn't exist, in which case it deletes any files older than 5 minutes in my home directory. Adding a check that the directory exists is all that was needed! – Codemonkey Oct 31 '17 at 09:53

6 Answers6

20

Solution 1: systemtap
You can use systemtap to show all PIDs that are trying to use unlink() on the inode of .bashrc and .bash_profile files.

Install systemtap and the debug symbols for your kernel.

Create a file with name unlink.stap with the following content:

probe syscall.unlink
{
    printf ("%s(%d) unlink (%s) userID(%d)\n", execname(), pid(), argstr, uid())
}

Then run it with sudo stap unlink.stap

Solution 2: inotify
You can also use inotify to see when the file is deleted.

Solution 3: ftrace
Another solution is to use ftrace:

trace-cmd record -e \*unlink\*

Wait for the file to be deleted, press CTRL+C to stop trace-cmd record ..., then run:

trace-cmd report

Solution 4: bpftrace
Install bpftrace, then run:

bpftrace -e 'tracepoint:syscalls:sys_enter_unlink* { printf("%s %s\n", comm, str(args->pathname)); }'
Mircea Vutcovici
  • 16,706
  • 4
  • 52
  • 80
5

in addition to micea's answer, you can chattr +i the files as root and see if anything logs an error when trying to remove them.

Sirex
  • 5,447
  • 2
  • 32
  • 54
4

Are you absolutely sure the user himself is not (accidentally) deleting them ?

I had some clueless (Windows) users with the same problem. Turned out that they deleted those files themselves every time they visited their home-dir with a ftp client. They noticed the .xxxx files (the ftp client didn't hide them) and removed the "clutter".

It never occurred to me they did it to themselves until one of them complained about the spontaneously re-appearing files he had deleted several days before.

Tonny
  • 6,252
  • 1
  • 17
  • 31
3

We use bash logout scripts (~/.bash_logout) to clean out certain files upon logout - you might check to see if you have that setup, perhaps with a fat-fingered glob in it.

Ram
  • 612
  • 3
  • 10
2

More seems like an intruder, who is doing a find /home/user -name filename -exec rm -f {} \; after all his sneaking :). Just guessing, because you mentioned that the backup files are also getting deleted.

SparX
  • 1,924
  • 12
  • 10
1

To prevent losing the files and their content you can setup libtrash via LD_PRELOAD. Using libtrash you can do number of things but those that might be interesting to you are

INTERCEPT_UNLINK
INTERCEPT_RENAME
INTERCEPT_FOPEN
INTERCEPT_OPEN

Good article about libtrash can be found here

Other thing you mention, that you chowned files to root and they still got removed. It is because /home/username is owned by username; and if dir has say mod 755; then any file or dir in that dir owned by no matter who can be removed by user; even if it is roots file or dir. It's basically due to fact that removing file in dir means changing the dir contents and user has 7 (in 755) of that dir so he can do whatever he wants.

There are ways to block this as other people already suggested via chattr on ext file systems to set files as immutable (+i). Then one would need to unset the immutable flag before making any changes to file/dir which has the +i flag. Immutable flag / chattr can only be used by root.

Hrvoje Špoljar
  • 5,162
  • 25
  • 42