Rolf Gerrits <rm.gerrits@xxxxxxxxxxx> initially asked:
>
> I have a problem removing files from the /tmp directory ...
> At startup the system cannot remove them either
>
> <snip>
> ------s-w- 1 rpm 20752 16384 Jan 15 1971 linc-160f-0-2c899751e4a49
> -----ws--x 1 rpm 49661 16384 Jan 1 1970 linc-d19-0-5e596cf89dd0e
> -----ws--x 1 rpm 49661 16384 Jan 1 1970 linc-d1b-0-5e596cf865a39
> -----ws--x 1 rpm 49661 8192 Jan 1 1970 linc-d38-0-5fcf32a247496
> -----ws--x 1 rpm 49661 16384 Jan 1 1970
> OSL_PIPE_500_SingleOfficeIPC_5c953c8cde59b25240dbf8a4df6a2ff6
> ------Sr-- 1 rpm 16832 28672 Jan 1 1970 virtual-rolf.usyUMr
> <snip>
>
> This probably happened with the recent crashes I have with my FC4/6
> system ( or maybe they are the cause of it ? )
> .... any suggestions ?
>
> Rolf
I had suggested he examine the output of "lsattr -a *", which showed:
> ----i----j--T linc-160f-0-2c899751e4a49
> s--D-a-A-j-t- linc-d19-0-5e596cf89dd0e
> ---D-a-A-j-t- linc-d1b-0-5e596cf865a39
> s--D-ad--j-t- linc-d38-0-5fcf32a247496
> suS--a-----t- OSL_PIPE_500_SingleOfficeIPC_5c953c8cde59b25240dbf8a4df6a2ff6
> --S-i--A-j--T virtual-rolf.usyUMr
Based on "info chattr" output, we can translate these mode bits as:
a - append only,
c - compressed,
d - no dump,
i - immutable,
j - data journalling,
s - secure deletion,
t - no tail-merging,
u - undeletable,
A - no atime updates ,
D - synchronous directory updates,
S - synchronous updates,
T - top of directory hierarchy.
So basically, Rolf's got some set-gid files he can't erase as root because
the files attribute bits (the lsattr/chattr stuff, not the file mode bits)
are preventing it.
Thus, from where I sit, it looks like the following ought to do the job
(and I tested this by creating some files matching the modes/attributes
Rolf reported):
$ cd /tmp
$ su
# chattr -sDiaAjtT linc*
# rm -f ./linc*
# chattr -SiAjT virtual-rolf.usyUMr
# rm -f virtual-rolf.usyUMr
# chattr -suSat OSL_PIPE_500_SingleOfficeIPC_5c953c8cde59b25240dbf8a4df6a2ff6
# rm -f OSL_PIPE_500_SingleOfficeIPC_5c953c8cde59b25240dbf8a4df6a2ff6
# exit
# ls -l /tmp
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.
Note however, that if you're running SELinux, your mileage may vary about
a lot of this stuff.
Hope this helps,
-S
