В Linux команда поиска работает неправильно

В поисках системно-разрешенного сервиса после недавнего обнаружения уязвимостей я обнаружил очень странное поведение команды find.

 root@localhost:/# find . -name "*systemd-resolved*"
./usr/share/man/man8/systemd-resolved.service.8.gz
./usr/share/man/man8/systemd-resolved.8.gz

Команда возвращает 0 или две строки в качестве вывода для первого запуска. Но если я запускаю команду во второй раз, я получаю:

root@localhost:/# find . -name "*systemd-resolved*"
./usr/share/man/man8/systemd-resolved.service.8.gz
./usr/share/man/man8/systemd-resolved.8.gz
./lib/systemd/systemd-resolved
./lib/systemd/system/systemd-resolved.service.d
./lib/systemd/system/systemd-resolved.service

Это означает, что в первый раз «найти» на самом деле не все найти. Также это происходит только один раз. Выполнение команды в следующий раз показывает правильный вывод. Я проверял это на некоторых других системах с установленным Debian 8 (jessie). В ядрах с ядром 4.9+ эта проблема возникает всегда, но в системах с ядром 3.16 этого не происходит.
После перезагрузки системы все это повторяется. Но поведение одинаково для каждой отдельной системы. Это означает, что если тестирование в конкретной системе возвращает (ошибочно) две строки вывода для первого запуска и правильные выходные данные для второго запуска, то при первом запуске команды после перезагрузки системы снова выводятся 2 строки. Таким образом, системы показывают одинаковое поведение после каждой перезагрузки (согласно моим тестам). Подробности файлов следующие:

-rw-r--r-- 1 root root  ./usr/share/man/man8/systemd-resolved.service.8.gz
lrwxrwxrwx 1 root root  ./usr/share/man/man8/systemd-resolved.8.gz -> systemd-resolved.service.8.gz
-rwxr-xr-x 1 root root  ./lib/systemd/systemd-resolved
drwxr-xr-x 2 root root  ./lib/systemd/system/systemd-resolved.service.d
-rw-r--r-- 1 root root  ./lib/systemd/system/systemd-resolved.service

РЕДАКТИРОВАТЬ: Для всех тех, кто предлагает проблему, может быть связано с этим конкретным случаем для этих конкретных файлов: « система решена » просто в качестве примера. Это происходит и при поиске других ключевых слов. Это еще один пример, который дает неправильные результаты для первого запуска:

root@localhost:/# find . -name "*apache*"

Не кто-нибудь здесь может проверить эту проблему на Debian 8 с последним ядром из репозитория backport?

linux find

— user2808671
источник

Можете ли вы попробовать сравнить следы двух вызовов, например, используя strace? На какой ОС вы наблюдали ошибочное поведение? Что вы подразумеваете под "возвращает 0 или два результата, как указано выше"? Ноль или две строки вывода, или код выхода 0 + две строки? Это происходит снова после запуска новой оболочки или перезагрузки? Может быть уместно, что первый вызов возвращает только файлы, а второй возвращает файлы и каталоги.

— 10

@ l0b0 Как я уже говорил, это происходит в Debian с ядром 4.9 в нескольких системах. Я не проверял другие дистрибутивы. 0 или 2 означает ноль или две строки вывода. Это происходит после каждой перезагрузки. Ваше последнее утверждение здесь не применимо. Он пытается вернуть все. Оба каталога и файлы.

— user2808671

@ l0b0 Ну, я не уверен, что ты ищешь, но, как ты видишь, я упомянул команду, чтобы можно было воспроизвести проблему. Эта команда должна вернуть все пути, содержащие «systemd-resolved», но это не так. Всего существует пять путей, удовлетворяющих этому условию, но программа «find» возвращает только два из них или один или ноль. Здесь важно то, что инструмент дает неправильный вывод и пропускает некоторые правильные пути. И как я упоминал, я проверял это на других системах с Debian, у тех с ядром 4.9 есть эта проблема. Это может быть что-то серьезное за пределами пользовательского пространства.

— user2808671

@MarkWagner Нет. Я заполнил отчет об ошибках как в gnu findutils, так и в списке рассылки Debian backports. Это кажется мне очень серьезным, поскольку источник этой проблемы может повлиять на многие другие вещи, хотя я не знаю, согласны ли вы, ребята, со мной. В любом случае «найти» является очень популярным инструментом, и его результаты должны быть надежными.

— user2808671

Как /lib/systemdмонтируется? Что это за файловая система? Если это отдельная точка монтирования, какое время это был установлен?

— Эндрю Хенле

Версия findutils по умолчанию, установленная в Debian 8, - 4.4.2, и это самая новая версия в репозиториях jessie. Я загружаю последнюю версию (4.6.0) исходного кода findutils и собираю двоичные файлы из исходного кода. Затем я выполнил те же тесты, и команда «find» показала правильный вывод при первом запуске.

Затем я скачал исходный код findutils версии 4.4.2 из архива gnu и скомпилировал его. Та же проблема произошла с скомпилированной командой поиска. Так что эта проблема не происходит с findutils 4.6.0.

Но я до сих пор не знаю, почему некоторые пользователи не получают такие же результаты, используя findutils 4.4.2 (версия утилиты по умолчанию, установленная в Debian), и не знаю, почему Debian все еще следует выпускать с этой старой версией findutils. и, возможно, другие утилиты Linux и вызвать эту проблемную ситуацию. И последнее, что точная техническая причина того, что произошло странно, до сих пор неизвестна, что нежелательно. Потому что я не уверен, есть ли что-то тревожное в моей среде ОС.

— user2808671
источник