New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Cant delete file as a root, is not immutable
Hello,
i found .php file that had 1970-01-01 modiffy date
lsattr shows: -------------e-
I was able to empty that file and stat shows:
Device: a4h/164d Inode: 40391585 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 566/usernamehere) Gid: ( 574/usernamehere)
rm -f returns: Permission denied
whoami: root
// UPDATE, FIXED: not only file, but also parent directory have to be immutable. Do:
chattr -i /path/to/
chattr -i /path/to/filetoremove
Comments
rm -rf / --- I don't see another solution ¯_(ツ)_/¯
... And now seriously... rm -f [file] should work as it will force to delete.
try moving that file to /dev/null :-)
My first thought is that a fsck may be required. Someone else may have a less annoying idea.
not a good idea. http://askubuntu.com/a/435891
That's only if you're dumb and replace
/dev/nullwith the PHP file. If you want to be extra safe about it, try moving it to/dev/null/file.php.(no guarantees, the fsck utility is the safest option, unless you find a way to fix the permissions)
My initial thought is SELinux. Check your logs
Thanx....i always thought of it as a null...back hole :-)...
Just take the file and divide by 0. Problem solved
Please kindly be more descriptive if you can. Im quite a newbie in Linux.
mv: cannot move
But i assume it have to be run after the partition on which the file is located is unmounted right
An SE Linux error would show up either in:
(1) run the dmesg command after you attempt to mv
(2) /var/log/messages or similar
@raindog308 thx, i tried to move it and right after checking dmesg + /var/log/messages and nothing related in it, it is CentOS 6
Can you give us the output of
sestatusandls -Z /path/to/file? Also, check /var/log/audit/audit.logTry running "lsof /file/name", might give some clues...
Maybe the file is somehow "opened" or used by the system preventing you from deleting it ?
If it was possible I would stop web service and try to delete it again.
Edit: didn't read properly.
sestatus: SELinux status: disabled
ls -Z is: -rw-r--r-- myusernamehere myusernamehere ? /path/to/file
that lsof command do not output anything. i replaced /file/name by path to that file
even lsof do not return any output?
btw, that file was an malicious php that allows upload of the scripts into the wordpress directory. I emptied it successfully.
I ran some tests, i opened two screen, in the first one i created a file and opened it with VI in the second screen i ran lsof /file/name where /file/name is the path of the file and i didn't get anything.
Not sure lsof /file/name should return something anyway.
i'd like someone to confirm but it seems you can't use the command lsof this way you have to use it on a directory like this:
lsof +D /file/name
And this way i see the file opened by my user.
Usually the simplest answer is the correct one. In short, you can't really create a file that root cannot delete. If the file is not immutable, root can delete it.
Are you sure there's no file system corruption? Are you sure the file is located on a volume that is currently not mounted as read only (I recognize you said you emptied the file, but nevertheless)?
Maybe just boot into a recovery mode, and delete the file that way. Then you can be sure there's no file locks, etc. getting in the way.
Also, there's another issue here. You said the file was a script that allowed people to upload scripts to WordPress's directory. That means your system is compromised. Have you identified the point of entry?
in addition you could have also used the command fuser:
fuser -km /file/name
The aim is to kill all process using the file specified
edit : be carefull with this command i used it and lost ssh connection, but i was able to reopen a connection and it worked it killed VI.
In some compromised systems root may not be root, but some other special user while the attacker is the real root with whatever username. It gives the false impression everything is OK to newbie admins when in fact the system not only that is compromised, but the rootkit is intercepting their calls and forges the answers.
It is not often to see that, though, and, if the system is compromised, then it would be a serious coincidence to have fs corruption too, you must assume it is because of the hack.
>>>> SOLVED <<<<<
=================
=================
im sorry for my stupidity, im really a newbie, i forgot that it is not enough file to be immutable, but also parent directory be immutable. After chown -i ../parentdir i removed bad file without issue :-(
=================
=================
Of course not. VI does not keep an open handle with the file. It opens it, reads it, closes it.
"lsof /path/.filename.swp" would show you an open file handle from vim
Try "lsof | grep filename" instead and you'll see.
Woah. You like living on the edge.
Of course you lost your ssh connection. You can be happy that you were able to reconnect. What your command does is getting the mount (-m) of the specified location and then kills (-k) every process currently affiliated with that mount. If the file happens to reside on the root file system it will kill nearly all, if not all, processes.
DO NOT DO THIS AT HOME
Please use the "i" option (-kim) or first list the processes (-am).
@postcd Glad that you could fix it. Was about to ask about the directory, but after all the info you already gave I thought you would have already checked that, too.
Glad you got it solved! Don't listen to my solution, the lack of caffeine has caused me to think that /dev/null = a directory.
I said i opened the file with VI in a screen so yes there was an open handle and i saw it when i used the command lsof +D
Nope use lsof /path/filname does not display anything
lsof filename does not work either
i think i lost connection just because i was in a screen executing a command asking to kill every process involving a file i called in my command so that simply showed command worked.
No that was an empty file created with a touch command so there was no risk at all but i prefered to add a warning.
erratum :
i ran other tests my aplogies @TWo
lsof | grep /path/filename works, it seems to be more effective than use lsof +D /path/directory_name
lsof /path/.filename.swp works too
You were right saying open a file with vi does not open handle.
Ask these guys for help: http://mentalfloss.com/uk/technology/41420/man-deletes-entire-company-with-one-line-of-code
Apologies accepted.
But I've never said that VI doesn't open a file handle. It does. While reading the file. But after reading it closes that handle. It does not keep the handle on the original file while you are editing it.
Thanks for the details.