РЕДАКТИРОВАТЬ: я полностью забыл об этой теме. Оказывается, у меня был плохой жесткий диск. Нам пришлось повторно развернуть этот сервер для других нужд, поэтому я, наконец, добрался до замены одного неисправного диска, и мы снова в деле.
В течение нескольких недель я не мог понять, почему я не могу удалить именно этот файл. Как root я могу, но мой сценарий оболочки работает от имени другого пользователя. Итак, я запускаю ls -la, а его там нет. Однако, если я вызову его как параметр, он появится! Конечно, владелец root, поэтому я не могу удалить.
Обратите внимание, 6535 отсутствует ...
[root@server]# ls -la 653*
-rw-rw-r-- 1 svn svn 24002 Mar 26 01:00 653
-rw-rw-r-- 1 svn svn 7114 Mar 26 01:01 6530
-rw-rw-r-- 1 svn svn 8653 Mar 26 01:01 6531
-rw-rw-r-- 1 svn svn 6836 Mar 26 01:01 6532
-rw-rw-r-- 1 svn svn 3308 Mar 26 01:01 6533
-rw-rw-r-- 1 svn svn 3918 Mar 26 01:01 6534
-rw-rw-r-- 1 svn svn 3237 Mar 26 01:01 6536
-rw-rw-r-- 1 svn svn 3195 Mar 26 01:01 6537
-rw-rw-r-- 1 svn svn 27725 Mar 26 01:01 6538
-rw-rw-r-- 1 svn svn 263473 Mar 26 01:01 6539
Теперь он появляется, если вы вызываете его напрямую.
[root@server]# ls -la 6535
-rw-rw-r-- 1 root root 3486 Mar 26 01:01 6535
Вот кое-что интересное. Итак, я поймал эту проблему, потому что в моем сценарии оболочки он не может быть удален, потому что 6535 принадлежит пользователю root. Файл фактически появляется после того, как я запустил "rm -rf". Я пробовал это раньше, и мне не удалось удалить каталог, так как он сказал мне, что каталог не пуст. Я вошел, посмотрел и, конечно же, наконец обнаружил файл «6535». Понятия не имею, зачем он это делает.
Strace говорит следующее
#strace ls -la 653* 2>&1 | grep ^open
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/lib64/tls/librt.so.1", O_RDONLY) = 3
open("/lib64/libacl.so.1", O_RDONLY) = 3
open("/lib64/libselinux.so.1", O_RDONLY) = 3
open("/lib64/tls/libc.so.6", O_RDONLY) = 3
open("/lib64/tls/libpthread.so.0", O_RDONLY) = 3
open("/lib64/libattr.so.1", O_RDONLY) = 3
open("/etc/selinux/config", O_RDONLY) = 3
open("/proc/mounts", O_RDONLY) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
open("/proc/filesystems", O_RDONLY) = 3
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
open("/usr/share/locale/en_US.UTF-8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/nsswitch.conf", O_RDONLY) = 3
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/lib64/libnss_files.so.2", O_RDONLY) = 3
open("/etc/passwd", O_RDONLY) = 3
open("/etc/group", O_RDONLY) = 3
open("/etc/mtab", O_RDONLY) = 3
open("/proc/meminfo", O_RDONLY) = 3
open("/etc/localtime", O_RDONLY) = 3
Это немного тревожно. Я бы подтвердил, что ваш ls файл не был изменен путем сравнения с заведомо исправным файлом. Вы можете использовать инструменты пакета вашего дистрибутива для проверки файла в изолированной системе.
Иногда имена файлов содержат странные символы, такие как последовательности перемещения курсора. Попробуйте это, чтобы убедиться:
ls -lq
Вместо управляющих символов на нем должны отображаться вопросительные знаки (возможно, это значение по умолчанию, но может и не быть).
Это частично демонстрирует тип проблемы, которая может присутствовать:
touch A C
touch B$(tput cuu1)$'\r'
ls -l
ls -lq
ls -l --show-control-chars # for systems that have that option and default to -q
Я бы также попробовал:
type -a ls
alias ls
declare -f ls
md5sum /bin/ls # compare to a known-good identical system
чтобы увидеть, определен ли псевдоним или функция, или чтобы увидеть, находится ли двоичный файл в нечетном месте или был изменен.
Вы можете проверить этот том.
Я обычно делаю что-то подобное, если считаю, что ls было изменено ...
python -c "import os; print os.listdir('.')"
Конечно, Python, библиотека C, ядро или файловая система могут также могут быть изменены, но обычно это просто утилиты оболочки.
Вы можете точно узнать, что делает ls, используя strace, и это может сказать вам, почему он избегает показа этого имени файла.
strace ls -la 653* 2>&1 | less
просмотрите это и посмотрите, что происходит.
strace ls -la 653* 2>&1 | grep ^open
Результат будет выглядеть так:
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/lib/librt.so.1", O_RDONLY) = 3
open("/lib/libacl.so.1", O_RDONLY) = 3
open("/lib/libselinux.so.1", O_RDONLY) = 3
open("/lib/libc.so.6", O_RDONLY) = 3
open("/lib/libpthread.so.0", O_RDONLY) = 3
open("/lib/libattr.so.1", O_RDONLY) = 3
open("/lib/libdl.so.2", O_RDONLY) = 3
open("/lib/libsepol.so.1", O_RDONLY) = 3
open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = 3
open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 3
open("/selinux/mls", O_RDONLY|O_LARGEFILE) = 3
и если вы видите что-то вроде
open("/var/tmp/.../H@ckl1st", O_RDONLY) = 3
будь осторожен, тебя затащили ...
Это не окончательный тест, но это хороший индикатор ...
(если вы используете solaris или другие ОС, вам может потребоваться использовать truss или другую аналогичную утилиту вместо strace)
(если вы используете оболочку, производную от csh / tcsh, вам, вероятно, потребуются другие операторы перенаправления)
Быстрое обновление, пришлось заменить сервер по другим причинам. Это была файловая система. Теперь все хорошо !!! Спасибо всем.
Теория взлома интересна, но у меня есть альтернативная теория. Семантика удаления файлов Unix будет сохранять файл до тех пор, пока все процессы не закроют открытые дескрипторы файла, указывающие на него. Возможно, кто-то приостановил проверку / фиксацию SVN, или серверный поток завис. Если перезапуск процесса SVN (или Apache) решит вашу проблему, я бы возложил вину на это.
Возможно, вы сможете определить процесс, который все еще использует этот файл, с помощью lsof | grep 6535?