cannot remove files from /tmp [SOLVED]
Rolf Gerrits
rm.gerrits at quicknet.nl
Wed Jan 10 21:48:34 UTC 2007
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
>
>
>
More information about the fedora-list
mailing list