More on the 'cat /dev/console' question.

flatfish+++ · External Since: Dec 12, 2004 Posts: 2793

My PCLinuxOS .93a system has been acting a little weird ever since I ran
cat /dev/console as a user....

It seems a little slower and applications are acting wierd, in particular
pan was trying to post or download the same message (s) 100's of times all
by itself!
I hope it failed Smile

So I ran rootkithunter and it came up with something interesting....

A hidden directory under /dev called .udevdb
iow /dev/.udevdb.

Which RKhunter said to look into.........

I have no idea what this directory does (some of the contents are below),
however, and here is the interesting part.

The date and timestamp on the files are the exact same date and time that
I ran the cat /dev/console command, as a user.

Here is when I ran the command:

http://groups.google.com/group/comp.os.linux.advocacy/msg/1d8096e5d3d9161f

Here it is again:

[flatfish@localhost ~]$ date
Mon Sep 18 12:00:07 EDT 2006
[flatfish@localhost ~]$ cd /dev
[flatfish@localhost dev]$ ls -al console
crw------- 1 flatfish root 5, 1 Sep 17 22:33 console

Here is a partial list from that directory:

[root@localhost dev]# cd .udevdb
[root@localhost .udevdb]# ls -al
total 528
drwxr-xr-x 2 root root 2680 Sep 19 12:19 ./
drwxr-xr-x 21 root root 4180 Sep 19 12:19 ../
-rw-r--r-- 1 root root 104 Sep 17 22:33 block@hda
-rw-r--r-- 1 root root 107 Sep 17 22:33 block@hda@hda1
-rw-r--r-- 1 root root 131 Sep 17 22:33 block@hdc
-rw-r--r-- 1 root root 106 Sep 17 22:33 block@hdd
-rw-r--r-- 1 root root 109 Sep 17 22:33 block@hdd@hdd1
-rw-r--r-- 1 root root 109 Sep 17 22:33 block@hdd@hdd2
-rw-r--r-- 1 root root 109 Sep 17 22:33 block@hdd@hdd5
-rw-r--r-- 1 root root 105 Sep 17 22:33 block@hde
-rw-r--r-- 1 root root 108 Sep 17 22:33 block@hde@hde1
-rw-r--r-- 1 root root 106 Sep 17 22:33 block@hdf
-rw-r--r-- 1 root root 109 Sep 17 22:33 block@hdf@hdf1
-rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop0
-rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop1
-rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop2
-rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop3
-rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop4
-rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop5
-rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop6
-rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop7
-rw-r--r-- 1 root root 32 Sep 17 22:33 block@md0
-rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram0
-rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram1
-rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram10
-rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram11
-rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram12
-rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram13
-rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram14
-rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram15
-rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram2
-rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram3
-rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram4
-rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram5
-rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram6
-rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram7
-rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram8
-rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram9
-rw-r--r-- 1 root root 52 Sep 17 22:33 class@input@mice
-rw-r--r-- 1 root root 56 Sep 17 22:33 class@misc@agpgart
-rw-r--r-- 1 root root 58 Sep 17 22:33 class@misc@psaux
-rw-r--r-- 1 root root 53 Sep 17 22:34 class@printer@lp0
-rw-r--r-- 1 root root 50 Sep 17 22:34 class@sound@audio

.................. and so forth....

The machine has been shutdown several times since then.

Any ideas?

ed · External Since: Nov 20, 2006 Posts: 877

On Tue, 19 Sep 2006 13:00:40 -0400
flatfish+++ wrote:

> My PCLinuxOS .93a system has been acting a little weird ever since I
> ran cat /dev/console as a user....
>
> It seems a little slower and applications are acting wierd, in
> particular pan was trying to post or download the same message (s)
> 100's of times all by itself!
> I hope it failed Smile

>
> So I ran rootkithunter and it came up with something interesting....
>
> A hidden directory under /dev called .udevdb
> iow /dev/.udevdb.
>
> Which RKhunter said to look into.........
>
> I have no idea what this directory does (some of the contents are
> below), however, and here is the interesting part.
>
> The date and timestamp on the files are the exact same date and time
> that I ran the cat /dev/console command, as a user.
>
> Here is when I ran the command:
>
> http://groups.google.com/group/comp.os.linux.advocacy/msg/1d8096e5d3d9161f
>
> Here it is again:
>
> [flatfish@localhost ~]$ date
> Mon Sep 18 12:00:07 EDT 2006
> [flatfish@localhost ~]$ cd /dev
> [flatfish@localhost dev]$ ls -al console
> crw------- 1 flatfish root 5, 1 Sep 17 22:33 console
>
>
>
>
>
> Here is a partial list from that directory:
>
> [root@localhost dev]# cd .udevdb
> [root@localhost .udevdb]# ls -al
> total 528
> drwxr-xr-x 2 root root 2680 Sep 19 12:19 ./
> drwxr-xr-x 21 root root 4180 Sep 19 12:19 ../
> -rw-r--r-- 1 root root 104 Sep 17 22:33 block@hda
> -rw-r--r-- 1 root root 107 Sep 17 22:33 block@hda@hda1
> -rw-r--r-- 1 root root 131 Sep 17 22:33 block@hdc
> -rw-r--r-- 1 root root 106 Sep 17 22:33 block@hdd
> -rw-r--r-- 1 root root 109 Sep 17 22:33 block@hdd@hdd1
> -rw-r--r-- 1 root root 109 Sep 17 22:33 block@hdd@hdd2
> -rw-r--r-- 1 root root 109 Sep 17 22:33 block@hdd@hdd5
> -rw-r--r-- 1 root root 105 Sep 17 22:33 block@hde
> -rw-r--r-- 1 root root 108 Sep 17 22:33 block@hde@hde1
> -rw-r--r-- 1 root root 106 Sep 17 22:33 block@hdf
> -rw-r--r-- 1 root root 109 Sep 17 22:33 block@hdf@hdf1
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop0
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop1
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop2
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop3
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop4
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop5
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop6
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop7
> -rw-r--r-- 1 root root 32 Sep 17 22:33 block@md0
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram0
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram1
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram10
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram11
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram12
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram13
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram14
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram15
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram2
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram3
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram4
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram5
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram6
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram7
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram8
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram9
> -rw-r--r-- 1 root root 52 Sep 17 22:33 class@input@mice
> -rw-r--r-- 1 root root 56 Sep 17 22:33 class@misc@agpgart
> -rw-r--r-- 1 root root 58 Sep 17 22:33 class@misc@psaux
> -rw-r--r-- 1 root root 53 Sep 17 22:34 class@printer@lp0
> -rw-r--r-- 1 root root 50 Sep 17 22:34 class@sound@audio
>
> ................. and so forth....
>
> The machine has been shutdown several times since then.
>
> Any ideas?
>

Get a live cd and remove /dev/*, apart from MAKEDEV. Then boot from
regular kernel and append S to the boot parameters (for single user).
Then run sh /dev/MAKEDEV to restore all the files.

If you have a debian system run debsums to ensure the binaries match
their checksums.

Anyone have other suggestions?

Personally if you suspect a hack you should copy your /home directory
and any variable data that you want keeping to a safe location.

Then install some debian/openbsd based.

--
Regards, Ed :: http://www.gnunix.net
proud bash person
Vin Diesel's vision is based on both movement and smell.

Peter Kai Jensen · External Since: Oct 23, 2006 Posts: 202

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

flatfish+++ wrote:

> My PCLinuxOS .93a system has been acting a little weird ever since I
> ran cat /dev/console as a user....

I'm not surprised. Not that it's acting weird, because it's not, but
that you would continue your FUD.

> It seems a little slower and applications are acting wierd, in
> particular pan was trying to post or download the same message (s)
> 100's of times all by itself! I hope it failed Smile

Meh, application errors happen. I don't use 'pan', so I don't know if
this is a known bug. I can't for the life of me imagine how it might be
connected with reading from /dev/console, though.

> So I ran rootkithunter and it came up with something interesting....
>
> A hidden directory under /dev called .udevdb iow /dev/.udevdb.

You have *got* to be kidding. *EVERY* modern (2.6+) Linux system
running udev (which is the standard) will have that, or something very
similar.

> Which RKhunter said to look into.........

Apparently that application is out of date, as it should not flag a
standard part of the file system. Get the latest version from
http://www.rootkit.nl/ and check again. If it still shows up, file a
bug report, as it's incorrect behavior. Chkrootkit appears to behave
better (http://www.chkrootkit.org/).

> I have no idea what this directory does (some of the contents are
> below), however, and here is the interesting part.

The contents is a database for the udev dynamic device inode manager. A
simple google search will show that. In fact, given the hits I get on
'udevdb', I suspect that you found the directory while poking around,
googled it, and ran RKhunter (or pretended to have done so) because
someone else had reported that it found the udevdb directory when doing
so. Would fit your pattern.

> The date and timestamp on the files are the exact same date and time
> that I ran the cat /dev/console command, as a user.

That directory should have been populated during start of udev, which
usually happens at boot time. There are some things that can affect its
contents, though. I don't have time to give you an exhaustive list.
Reading from /dev/console is not one of them, though. Seriously, if
this was caused by reading from that file, then why were you even able
to do so? Obviously the permissions had already been changed in
advance, either by yourself or by some misguided automatic action (like
a faulty PAM config at login time).

> Here is when I ran the command:
>
> http://groups.google.com/group/comp.os.linux.advocacy/msg/1d8096e5d3d9161f
>
> Here it is again:
>
> [flatfish@localhost ~]$ date
> Mon Sep 18 12:00:07 EDT 2006
> [flatfish@localhost ~]$ cd /dev
> [flatfish@localhost dev]$ ls -al console
> crw------- 1 flatfish root 5, 1 Sep 17 22:33 console

Seems like that would have happened at login, if anything. Of course,
you could have run the command in the same minute, so it would be
difficult to tell them apart. Tell me, do you have a binary called
something along the lines of pam_console_apply?

> Here is a partial list from that directory:
>
> [root@localhost dev]# cd .udevdb
> [root@localhost .udevdb]# ls -al
> total 528
> drwxr-xr-x 2 root root 2680 Sep 19 12:19 ./
> drwxr-xr-x 21 root root 4180 Sep 19 12:19 ../
> -rw-r--r-- 1 root root 104 Sep 17 22:33 block@hda
> -rw-r--r-- 1 root root 107 Sep 17 22:33 block@hda@hda1
> -rw-r--r-- 1 root root 131 Sep 17 22:33 block@hdc
> -rw-r--r-- 1 root root 106 Sep 17 22:33 block@hdd
> -rw-r--r-- 1 root root 109 Sep 17 22:33 block@hdd@hdd1
> -rw-r--r-- 1 root root 109 Sep 17 22:33 block@hdd@hdd2
> -rw-r--r-- 1 root root 109 Sep 17 22:33 block@hdd@hdd5
> -rw-r--r-- 1 root root 105 Sep 17 22:33 block@hde
> -rw-r--r-- 1 root root 108 Sep 17 22:33 block@hde@hde1
> -rw-r--r-- 1 root root 106 Sep 17 22:33 block@hdf
> -rw-r--r-- 1 root root 109 Sep 17 22:33 block@hdf@hdf1
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop0
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop1
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop2
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop3
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop4
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop5
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop6
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop7
> -rw-r--r-- 1 root root 32 Sep 17 22:33 block@md0
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram0
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram1
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram10
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram11
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram12
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram13
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram14
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram15
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram2
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram3
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram4
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram5
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram6
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram7
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram8
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram9
> -rw-r--r-- 1 root root 52 Sep 17 22:33 class@input@mice
> -rw-r--r-- 1 root root 56 Sep 17 22:33 class@misc@agpgart
> -rw-r--r-- 1 root root 58 Sep 17 22:33 class@misc@psaux
> -rw-r--r-- 1 root root 53 Sep 17 22:34 class@printer@lp0
> -rw-r--r-- 1 root root 50 Sep 17 22:34 class@sound@audio
>
> ................. and so forth....

I don't see anything out of the ordinary.

> The machine has been shutdown several times since then.

So it perhaps saves the udev configuration at reboot time. Not unusual
(since it preserves any devices you create by hand), though I personally
discourage it.

> Any ideas?

About what, exactly? I don't really see what your problem is, or rather
how you connect it with reading from /dev/console (which I still can't
understand why you even did in the first place).

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

iD8DBQFFEEM3d1ZThqotgfgRAhk9AJ46iiBtDoNwYvvPJZWVeQ6SrpUBsACcDqQZ
vDfRP8h8eZ6I0X6zs7s7CLE=
=OXU5
-----END PGP SIGNATURE-----
--
PeKaJe

Linux has a history of standing on the shoulders of giants, while Microsoft has
a history of trying to break giants' legs. The latter is quite less efficient.

flatfish+++ · External Since: Dec 12, 2004 Posts: 2793

On Tue, 19 Sep 2006 18:03:49 +0000, ed wrote:

> Get a live cd and remove /dev/*, apart from MAKEDEV. Then boot from
> regular kernel and append S to the boot parameters (for single user).
> Then run sh /dev/MAKEDEV to restore all the files.
>
> If you have a debian system run debsums to ensure the binaries match
> their checksums.
>
> Anyone have other suggestions?
>
> Personally if you suspect a hack you should copy your /home directory
> and any variable data that you want keeping to a safe location.
>
> Then install some debian/openbsd based.

Hi Ed!
Thank you for the reply.
I really have no reason to suspect a comprimise, I was just curious and
maybe all those years of Windows habits die hard.
haha!

See my reply to Peter Kai Jensen for more details.
And thanks again for taking the time to reply.

flatfish+++ · External Since: Dec 12, 2004 Posts: 2793

On Tue, 19 Sep 2006 19:21:29 +0000, Peter Kai Jensen wrote:

> I'm not surprised. Not that it's acting weird, because it's not, but
> that you would continue your FUD.

No FUD intended.
I just have some questions.

> Meh, application errors happen. I don't use 'pan', so I don't know if
> this is a known bug. I can't for the life of me imagine how it might be
> connected with reading from /dev/console, though.

Me either but it never happened before and the last thing out of the
ordainary I did was run that cat command.
The reason I thought it might have been related was because it kind of
acted the same way as kde/X acted right after running the cat /dev/console
command as a user.

Windows in the application opened and closed themselves, the mouse acted
weird and pan was trying to post the same article 100's of times with the
error box (ool doesn't allow more than 2 simultaneous connections) popping
up and incrementing up in to the 100's.

> You have *got* to be kidding. *EVERY* modern (2.6+) Linux system
> running udev (which is the standard) will have that, or something very
> similar.

I'm not kidding.
I'm a user, not a programmer and certainly not a Linux file system expert.
The only reason I brought it up was the dates and the fact that the root
kit hunter flagged it as suspicious.

>> Which RKhunter said to look into.........
>
> Apparently that application is out of date, as it should not flag a
> standard part of the file system. Get the latest version from
> http://www.rootkit.nl/ and check again. If it still shows up, file a
> bug report, as it's incorrect behavior.

That's the version I used.
I'm wondering if it doesn't like the permissions on the files?
I honestly never changed a thing when I ran the cat/dev/console command.
Everything was left the way it installed.

Chkrootkit appears to behave
> better (http://www.chkrootkit.org/).

It fails on a make:

root@localhost chkrootkit-0.46a]# make sense
gcc -DHAVE_LASTLOG_H -o chklastlog chklastlog.c
gcc -DHAVE_LASTLOG_H -o chkwtmp chkwtmp.c
gcc -DHAVE_LASTLOG_H -D_FILE_OFFSET_BITS=64 -o ifpromisc ifpromisc.c
gcc -o chkproc chkproc.c
gcc -o chkdirs chkdirs.c
gcc -o check_wtmpx check_wtmpx.c
gcc -static -o strings-static strings.c
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
make: *** [strings-static] Error 1
[root@localhost chkrootkit-0.46a]#

> The contents is a database for the udev dynamic device inode manager. A
> simple google search will show that. In fact, given the hits I get on
> 'udevdb', I suspect that you found the directory while poking around,
> googled it, and ran RKhunter (or pretended to have done so) because
> someone else had reported that it found the udevdb directory when doing
> so. Would fit your pattern.

You're paranoid, but no I did not do this.
My concern was more along the lines of why do the dates/times exactly
match the date time I ran the cat /dev/console command?

Besides, how would I possibly be able to fake the exact date and time that
shows up in my google post from a couple of days ago?
If you ever saw my artwork you would know I am dangerous with
Photoshop/gimp.
IOW cluless at faking screens and there is no reason anyhow, I'm just
asking a question not slamming Linux.

>> The date and timestamp on the files are the exact same date and time
>> that I ran the cat /dev/console command, as a user.
>
> That directory should have been populated during start of udev, which
> usually happens at boot time. There are some things that can affect its
> contents, though. I don't have time to give you an exhaustive list.
> Reading from /dev/console is not one of them, though. Seriously, if
> this was caused by reading from that file, then why were you even able
> to do so? Obviously the permissions had already been changed in
> advance, either by yourself or by some misguided automatic action (like
> a faulty PAM config at login time).

I suspect the *root* of the problem is that PCLinuxOS may be set up
incorrectly as far as PAM or permissions are concerned and that would
account for why I (and others, Suse users as well) are able to run the
command as a user and other people get a permission denied.

My concern is, what did cat /dev/console do to these files that made the
date change?
I've rebooted several times since, I've only run the command once (that
was enough) and the dates do not change after a reboot.

What does cat /dev/console *do* to those files?

I'm going to send a note to texstar to describe the problem and see if
indeed there is a bug in PAM or permissions in general or if it is WAD.

> Seems like that would have happened at login, if anything. Of course,
> you could have run the command in the same minute, so it would be
> difficult to tell them apart. Tell me, do you have a binary called
> something along the lines of pam_console_apply?

Yes I do.

[root@localhost chkrootkit-0.46a]# locate pam_console_apply
/usr/share/man/man8/pam_console_apply.8.bz2
/lib/security/pam_console_apply_devfsd.so
/sbin/pam_console_apply
[root@localhost chkrootkit-0.46a]#

>
> About what, exactly? I don't really see what your problem is, or rather
> how you connect it with reading from /dev/console (which I still can't
> understand why you even did in the first place).

The reason I connect it with the cat /dev/console is that the dates and
times in that directory are the same as the date and time when I ran the
command.

Had the root kit hunter not flagged that directory, either by false or
real error, I never would have even known it existed.
It's hidden as well.

Thank you for the response Peter!

Jim Richardson · External Since: Jan 15, 2005 Posts: 1227

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 19 Sep 2006 13:00:40 -0400,
flatfish+++ wrote:
> My PCLinuxOS .93a system has been acting a little weird ever since I ran
> cat /dev/console as a user....
>
> It seems a little slower and applications are acting wierd, in particular
> pan was trying to post or download the same message (s) 100's of times all
> by itself!
> I hope it failed Smile

>
> So I ran rootkithunter and it came up with something interesting....
>
> A hidden directory under /dev called .udevdb
> iow /dev/.udevdb.
>

it's part of udev, the replacement for devfs.

> Which RKhunter said to look into.........
>
> I have no idea what this directory does (some of the contents are below),
> however, and here is the interesting part.
>
> The date and timestamp on the files are the exact same date and time that
> I ran the cat /dev/console command, as a user.
>
> Here is when I ran the command:
>
> http://groups.google.com/group/comp.os.linux.advocacy/msg/1d8096e5d3d9161f
>
> Here it is again:
>
> [flatfish@localhost ~]$ date
> Mon Sep 18 12:00:07 EDT 2006
> [flatfish@localhost ~]$ cd /dev
> [flatfish@localhost dev]$ ls -al console
> crw------- 1 flatfish root 5, 1 Sep 17 22:33 console
>
>
>

I owe you an apology for that. I checked on a bunch of machines,
including some CentOS 4.3 boxes, and they had the perms of the
/dev/console set to the user with the active X session. Frankly, I think
that's a bug, for the reasons listed above, but I don't think you
chowned the file.

>
>
> Here is a partial list from that directory:
>
> [root@localhost dev]# cd .udevdb
> [root@localhost .udevdb]# ls -al
> total 528
> drwxr-xr-x 2 root root 2680 Sep 19 12:19 ./
> drwxr-xr-x 21 root root 4180 Sep 19 12:19 ../
> -rw-r--r-- 1 root root 104 Sep 17 22:33 block@hda
> -rw-r--r-- 1 root root 107 Sep 17 22:33 block@hda@hda1
> -rw-r--r-- 1 root root 131 Sep 17 22:33 block@hdc
> -rw-r--r-- 1 root root 106 Sep 17 22:33 block@hdd
> -rw-r--r-- 1 root root 109 Sep 17 22:33 block@hdd@hdd1
> -rw-r--r-- 1 root root 109 Sep 17 22:33 block@hdd@hdd2
> -rw-r--r-- 1 root root 109 Sep 17 22:33 block@hdd@hdd5
> -rw-r--r-- 1 root root 105 Sep 17 22:33 block@hde
> -rw-r--r-- 1 root root 108 Sep 17 22:33 block@hde@hde1
> -rw-r--r-- 1 root root 106 Sep 17 22:33 block@hdf
> -rw-r--r-- 1 root root 109 Sep 17 22:33 block@hdf@hdf1
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop0
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop1
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop2
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop3
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop4
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop5
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop6
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@loop7
> -rw-r--r-- 1 root root 32 Sep 17 22:33 block@md0
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram0
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram1
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram10
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram11
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram12
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram13
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram14
> -rw-r--r-- 1 root root 38 Sep 17 22:33 block@ram15
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram2
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram3
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram4
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram5
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram6
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram7
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram8
> -rw-r--r-- 1 root root 34 Sep 17 22:33 block@ram9
> -rw-r--r-- 1 root root 52 Sep 17 22:33 class@input@mice
> -rw-r--r-- 1 root root 56 Sep 17 22:33 class@misc@agpgart
> -rw-r--r-- 1 root root 58 Sep 17 22:33 class@misc@psaux
> -rw-r--r-- 1 root root 53 Sep 17 22:34 class@printer@lp0
> -rw-r--r-- 1 root root 50 Sep 17 22:34 class@sound@audio
>
> ................. and so forth....
>
> The machine has been shutdown several times since then.
>
> Any ideas?
>

it's part of udev, it's normal. Among other things, udev will create the
/dev/ filesystem upon boot, and will add/subtract devices from the dev
tree as needed. Far better than a static /dev/ tree.

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

iD4DBQFFEOzNd90bcYOAWPYRAvOSAJ9ck2MfZbFHsgN0YYI91qFBezsGfgCY7dlV
FT0NqjeUJYis5NhRlHo3EQ==
=trRZ
-----END PGP SIGNATURE-----

--
Jim Richardson http://www.eskimo.com/~warlock
Never be in the company of anyone with whom you would not want to die.
-- Fremen Saying