From martin a. salazar on Fri, 05 Mar 1999
How can I delete files with attributes like these.
b---r----- 1 10080 24640 96, 68 Feb 10 1977 csh.cshrc b---rwxr-- 1 24672 8231 32, 39 Dec 16 2010 exports
These look CORRUPT. See below.
Your ability to remove files has nothing to do with the permissions of the files themselves, and often nothing to do with the ownership of the files.
Under UNIX (and Linux, of course) you need write access to the directory in which a link occurs to remove that link. So in a mode 777 directory you can remove any filename (link) REGARDLESS OF WHO OWNS THAT FILE AND REGARDLESS OF THE PERMISSIONS ON IT.
(As a special case under Linux and most modern versions of Unix if the mode of the directory is "sticky" --- mode 1xxx --- then you must have write access to the directory and you must own the file, or be root, to unlink/remove it).
Note that I've made a distinction here between the file and its names (links). In a Unix/Linux filesystem a file is an association between an inode (a management and meta-data structure) and a set of data blocks (the data or file contents). The file's name is a link from a directory to the inode. There can be many such links or "hard links.
Thus the process of removing a file involves "unlinking" it. When the link count is zero (there are no remaining links to a file) and there are not processes with a file open, then the filesystem driver removes the actual file (that is it marks the inode as deleted and adds all of its data blocks back to the "free" list.
So the 'rm' command doesn't actually "remove files" --- technically it "unlinks files from directories" (which often has the side effect of reducing the link count to zero and consequently deleting the file).
Understanding this hopefully explains why write access to a directory is generally sufficient to remove files in it.
Now regarding your example:
The filenames you show here would normall be related to regular files in the /etc/ directory. However the "permissions" you show suggest that these are block device nodes (links to things like your /dev/hda1, etc).
Moreover the ownership/group fields are rather unlikely to be valid UIDs or GIDs on your system. This suggests that you have a rather thoroughly corrupted filesystem. So, my first suggestion would be to boot from a clean rescue floppy and try 'e2fsck -c' Then consider re-installing Linux (after backing up any data, of course).