Odd file ownership

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-

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-

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- is 209852, should be zero.
Clear<y>? yes

i_frag for inode 201255 (/src/linux- is 189, should be zero.
Clear<y>? yes

i_fsize for inode 201255 (/src/linux- 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

Much Better:

-rw-rw-r-- 1 nobody nogroup 8192 Jul 30 17:34 /usr/local/src/linux-

Now it’s 8KB, not 820TB

  1. #1 by Joshua on January 12, 2010 - 8:24 AM

    I probably could’ve fixed it myself with debugfs but fsck is much better at that kind of thing. 🙂

  2. #2 by Joshua on January 12, 2010 - 8:26 AM

    Lol – Linux will only “fsck” the filesystem when it’s “dirty.” Sometimes I think the UNIX dudes at Berkeley in 1969 were just messing with our heads.

    • #3 by Joshua on January 12, 2010 - 8:29 AM

      Lol – now I have a messed up version of Pink Floyd’s “Young Lust” in my head:

      Ooh, I need a dirty inode! Ooh, I need a dirty file!

      Yeah, I had coffee for the first time in a few days. I’m kinda in an odd mood. 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: