cannot remove files from /tmp [SOLVED]

[Rolf Gerrits]

Steve,

I followed your suggestion and used "chattr" to get access to the files

# lsattr linc-d19-0-5e596cf89dd0e
s--D-a-A-j-t- linc-d19-0-5e596cf89dd0e
# chattr -sDaAjt linc-d19-0-5e596cf89dd0e
# chown root:root linc-d19-0-5e596cf89dd0e
# rm linc-d19-0-5e596cf89dd0e
... and gone !!!

I did not use the script you suggested, because there are other linc* 
files in my /tmp.
But the command sequence was clear enough for me to get this done.
The "chown" was necessary to get ownership op the file ( owner was "rpm" ).

Note, that I found two more "problem" files in root's /lost+found  
directory and removed these as well succesfully

Additional comments :
** My system IS out of the box !
I use aMule and  xawtv  from the ATRpms repository though ... I can 
consider this out of the box too.
My PC  runs W98 , FC4 (this one) and FC6  ( failing to install properly 
... crashed without warning ).
** I  fsck-ed  all partitions of FC4  running FC6 and visa-versa ( some 
errors were corrected .. did not say which)
** I run SELinux (permissive)
and
** I have OpenOffice on FC4  and use this to edit documents ( original 
created with MSWORD ).

I will definitely have a look at the rootkit stuf .
I am running Linux from RH7 onwards and never have had any problems 
whatsoever ever.
I never even had to reboot for anything exept for kernel updates and 
installing new releases.
For everything is a first though ....

I will do the fsck again on FC4 ... just to see if all is well still.

Thanks to everyone helping me out here ... learned a few things along 
the way too !

Rolf

Steve Siegfried wrote:

>James Wilkinson wrote:
>  
>
>>Steve Siegfried wrote:
>>    
>>
>>>As an aside: 99.99% of Linux programs don't mess with file attribute bits.
>>>             The only time I've seen these attributes modified in 
>>>             a non-orange-book-secure (i.e.: SELinux) environment
>>>             was done as part of a script-kiddie break-in/root-hack. 
>>>             Because of this, I'm gonna ask: are you sure you're not
>>>             being hacked even as you try and resolve this?  Suggest at a
>>>             minimum, you pick up a copy of chkrootkit available through
>>>             http://www.chkrootkit.org and run it.
>>>      
>>>
>>Firstly, chkrootkit is in extras, although it's more trustworthy if you
>>run it from "known good" media (e.g. a CD). (It is possible for a
>>rootkit to modify the kernel so that everything looks good to
>>user-space).
>>
>>Secondly, Rolf's problems could also come from a corrupted filesystem. I'd
>>recommend booting from a rescue CD, *not* mounting any filesystems, and
>>fscking the filesystem in question.
>>
>>Lastly, although 99.9% of Linux *programs* don't mess with file
>>attribute bits, it's a lot more common at the distribution level (and I
>>seem to remember stuff like Bastille does it too)[1]. But the set of
>>attributes that have been set doesn't look right for that.
>>
>>Hope this helps,
>>
>>James.
>>
>>[1] For example, setting immutable bits on key system binaries to make
>>rootkits' lives that much harder.
>>    
>>
>
>James is correct.  Rolf should fsck his file systems (especially the one
>holding /tmp).  However, Rolf originally wrote:
>   Rolf>
>   Rolf> This probably happened with the recent crashes I have with my FC4/6
>   Rolf> system ( or maybe they are the cause of it ? )
>   Rolf> .... any suggestions ?
>
>Which _should_ have forced an fsck after any crash.
>
>Note that when folks say "fsck the filesystem", left unsaid but implied
>is, "until the fsck runs cleanly."  Running fsck on a badly hosed
>filesystem sometimes means running it more than once and sometimes also
>in interactive mode (i.e.: "fsck -r ...").
>
>
>
>Since Rolf's running FC4 (and/or FC6), I ran the following on each of
>my FC5 filesystems (the -printf option on find is necessary to avoid
>choking on files whose name contains blanks):
>
>   $ su
>   # cd <whatever>
>   # find . -mount -type f -printf "'%p'\n" | xargs -l1 lsattr | grep -v '^-------------'
>
>... and didn't find any files with any file-attribute bits set.
>
>Based on this experiment, we can probably conclude that (out of the box
>+ updates) FC systems don't mess with file attribute bits.  It may well
>be that some of Rolf's applications DO, but based on the range of stuff
>I'm running, I'd say it's unlikely.
>
>Caveats: - run on FC5 "out of the box" (plus updates) with ext2 filesystems
>           (should also work on ext3 filesystems, too),
>         - system is NOT running SELinux stuff.
>
>
>
>As I recall, the file /tmp/OSL_PIPE_... gets created by OpenOffice and
>is one of the munged files.
>
>I should point out that there's an OpenOffice exploit via WMF or EMF
>files that got closed recently in FC5 and FC6 (Don't know about FC4).
>For this reason, I'd recommend that Rolf make sure he's got a recent
>openoffice.org-base rpm (and friends) installed.  In FC5, the specific
>version is openoffice.org-base-2.0.2-5.20.2.  More info on this can be
>had by Google'ing "OpenOffice exploit" and looking for articles from
>January 2007.
>
>Hope this doesn't just confuse things'idly,
>
>-S
>
>  
>