I have a script on my server (RHEL 5.4) that checks hourly for bad file ownership (like being owned by a UID or GID that isn’t listed in /etc/passwd). I got a message this morning alerting me to the fact that a file that had been there for a long time had suddenly become owned by a totally bogus UID:
The following files are unowned: 201255 12 -rw-rw-r-- 1 868089856 196608 901303182039961 Jul 30 17:34 /usr/local/src/linux-188.8.131.52/drivers/media/video/em28xx/em28xx-reg.h They've been assigned to nobody:nogroup - please find out who they belong to and assign the proper ownership. -cron daemon on dustpuppy
Now, that file is part of the Linux kernel source tree I keep in /usr/local/src. It’s been there for a long time and the kernel sources are owned by root:users. Somehow yesterday, this file became owned by UID 868089856 and GID 196608. Even though 868089856 is a valid 32-bit integer, I don’t think it’s a valid UID. I’m hoping this was just a filesystem hiccup and not someone doing something dodgy on my box. None of the IDS, security sentries, log watchers, rootkit checks, etc. tripped or said anything and there was no chown() call in the system audit logs corresponding to that file. So I’m just going to keep a close eye and make sure nothing else goes wonky.
UPDATE: The system is also reporting that file is 820TB:
-rw-rw-r– 1 nobody nogroup 820T Jul 30 17:34 /usr/local/src/linux-184.108.40.206/drivers/media/video/em28xx/em28xx-reg.h
Considering the entire array is 1TB and the /usr/local filesystem is a bit under 1GB, I find it difficult to believe that I have an 820TB C header file.
UPDATE 2: I unmounted the filesystem and gave it a good fsck. But fsck said that it was clean. I remounted it but it’s still got the bogus file size. I’m waiting for wc to come back with an accurate byte count.
UPDATE 3: I used debugfs to mark the filesystem dirty so fsck would be forced to fix it. It worked:
fsck 1.39 (29-May-2006) e2fsck 1.39 (29-May-2006) /dev/VolGroup00/LogVol10 was not cleanly unmounted, check forced. Pass 1: Checking inodes, blocks, and sizes Inode 201255, i_size is 901303182039961, should be 8192. Fix<y>? yes Pass 2: Checking directory structure i_faddr for inode 201255 (/src/linux-220.127.116.11/drivers/media/video/em28xx/em28xx-reg.h) is 209852, should be zero. Clear<y>? yes i_frag for inode 201255 (/src/linux-18.104.22.168/drivers/media/video/em28xx/em28xx-reg.h) is 189, should be zero. Clear<y>? yes i_fsize for inode 201255 (/src/linux-22.214.171.124/drivers/media/video/em28xx/em28xx-reg.h) is 51, should be zero. Clear<y>? yes Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/VolGroup00/LogVol10: ***** FILE SYSTEM WAS MODIFIED ***** /dev/VolGroup00/LogVol10: 32005/262144 files (1.5% non-contiguous), 137231/262144 blocks
-rw-rw-r-- 1 nobody nogroup 8192 Jul 30 17:34 /usr/local/src/linux-126.96.36.199/drivers/media/video/em28xx/em28xx-reg.h
Now it’s 8KB, not 820TB