0

in CentOS, ext4 filesystem, I have a file that has the "extents" attribute, but I can't remove that file

-------------e-- index.php

rm -f does nothing (nor I get an error message)

tried to remove the attribute with chattr but, as the documentation states, it's not removable with chattr.

Can't find this on the internet. Only what it is but not how to remove the file.

ADDED strace rm -rf trace

execve("/usr/bin/rm", ["rm", "-rf", "index.php"], 0x7ffeaa85f270 /* 23 vars */) = 0
brk(NULL)                               = 0x900000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbe0ed2e000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=44848, ...}) = 0
mmap(NULL, 44848, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fbe0ed23000
close(3)                                = 0
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`&\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=2156592, ...}) = 0
mmap(NULL, 3985920, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbe0e740000
mprotect(0x7fbe0e904000, 2093056, PROT_NONE) = 0
mmap(0x7fbe0eb03000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c3000) = 0x7fbe0eb03000
mmap(0x7fbe0eb09000, 16896, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fbe0eb09000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbe0ed22000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbe0ed20000
arch_prctl(ARCH_SET_FS, 0x7fbe0ed20740) = 0
access("/etc/sysconfig/strcasecmp-nonascii", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/sysconfig/strcasecmp-nonascii", F_OK) = -1 ENOENT (No such file or directory)
mprotect(0x7fbe0eb03000, 16384, PROT_READ) = 0
mprotect(0x60d000, 4096, PROT_READ)     = 0
mprotect(0x7fbe0ed2f000, 4096, PROT_READ) = 0
munmap(0x7fbe0ed23000, 44848)           = 0
brk(NULL)                               = 0x900000
brk(0x921000)                           = 0x921000
brk(NULL)                               = 0x921000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=106172832, ...}) = 0
mmap(NULL, 106172832, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fbe081fe000
close(3)                                = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
lstat("/", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
newfstatat(AT_FDCWD, "index.php", {st_mode=S_IFREG|0444, st_size=4532, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(AT_FDCWD, "index.php", 0)      = 0
lseek(0, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
close(0)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

STRACE unlink

execve("/usr/bin/unlink", ["unlink", "index.php"], 0x7ffe5da1b8f8 /* 23 vars */) = 0
brk(NULL)                               = 0x25fe000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3f6d901000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=44848, ...}) = 0
mmap(NULL, 44848, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3f6d8f6000
close(3)                                = 0
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`&\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=2156592, ...}) = 0
mmap(NULL, 3985920, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3f6d313000
mprotect(0x7f3f6d4d7000, 2093056, PROT_NONE) = 0
mmap(0x7f3f6d6d6000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c3000) = 0x7f3f6d6d6000
mmap(0x7f3f6d6dc000, 16896, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f3f6d6dc000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3f6d8f5000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3f6d8f3000
arch_prctl(ARCH_SET_FS, 0x7f3f6d8f3740) = 0
access("/etc/sysconfig/strcasecmp-nonascii", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/sysconfig/strcasecmp-nonascii", F_OK) = -1 ENOENT (No such file or directory)
mprotect(0x7f3f6d6d6000, 16384, PROT_READ) = 0
mprotect(0x605000, 4096, PROT_READ)     = 0
mprotect(0x7f3f6d902000, 4096, PROT_READ) = 0
munmap(0x7f3f6d8f6000, 44848)           = 0
brk(NULL)                               = 0x25fe000
brk(0x261f000)                          = 0x261f000
brk(NULL)                               = 0x261f000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=106172832, ...}) = 0
mmap(NULL, 106172832, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3f66dd1000
close(3)                                = 0
unlink("index.php")                     = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++
  • 2
    The extents attribute is likely a red herring and is probably not your problem; it just describes how data is stored on the disk (see https://unix.stackexchange.com/a/360398/168757 for a description). It shouldn't impact your ability to delete files. – Stephen Harris Mar 13 '24 at 12:16
  • 1
    ("extent" with a t, not "extend". There are also "extended attributes", just that they're a different thing.) – ilkkachu Mar 13 '24 at 13:03
  • and yes, the e flag in itself doesn't affect how a file can or can not be deleted. There's something else going on. Run e.g. strace rm -rf and see what it says about the unlink() call? – ilkkachu Mar 13 '24 at 13:04
  • @ilkkachu, just added the traces for both rm and unlink (none worked) – dsantos80 Mar 13 '24 at 13:17
  • also changed to extents. Thanks, it's important to use the right terminology to help others. – dsantos80 Mar 13 '24 at 13:23
  • @StephenHarris, thanks. In fact, it's not that. I have another file on the same folder that has the same attribute. It's the only attribute the file shows and I can manipulate it so, it shouldn't be the extents attribute.

    Thank you so much. I'll inform when I figure this out. I had the same case some months ago and I was able to fix that.. should have kept some notes :(

    – dsantos80 Mar 13 '24 at 13:26
  • 2
    ok, found the issue.

    ls -i index.php , rm and then again ls -i showed that the inode change so, the file was deleted and then re-created

    I had a running process in php (client wp was hacked) that recreated the file as soon as I deleted it.

    Thank you for everybody's contribution!

    – dsantos80 Mar 13 '24 at 13:38
  • @dsantos80 could you either post that as an answer to your own question, or delete the question? + – Marcus Müller Mar 13 '24 at 15:38

1 Answers1

1

The extent attribute is likely a red herring. Perhaps you are really deleting the file, but it gets created again (by a malicious process) so quickly that you don't notice the delete worked?