Linux find polecenie działa nieprawidłowo

Szukając usługi rozwiązanej przez system po ostatnim ujawnieniu podatności, zauważyłem bardzo dziwne zachowanie z polecenia find.

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

Polecenie zwraca 0 lub dwa wiersze jako dane wyjściowe dla pierwszego uruchomienia. Ale jeśli uruchomię polecenie po raz drugi, otrzymam:

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

Oznacza to, że po raz pierwszy „znajdź” nie znajdzie wszystkiego. Zdarza się to tylko raz. Ponowne uruchomienie polecenia pokazuje prawidłowe wyjście. Sprawdziłem to w niektórych innych systemach z zainstalowanym Debianem 8 (jessie). Na tych z jądrem 4.9+ ten problem występuje zawsze, ale na systemach z jądrem 3.16 tak się nie dzieje.
Po ponownym uruchomieniu systemu wszystko to dzieje się ponownie. Ale zachowanie jest takie samo dla każdego systemu. Oznacza to, że jeśli testowanie w określonym systemie zwróci (nieprawidłowo) dwa wiersze danych wyjściowych dla pierwszego uruchomienia i poprawne dane wyjściowe dla drugiego uruchomienia, to pierwsze uruchomienie polecenia po ponownym uruchomieniu systemu ponownie wydrukuje 2 wiersze. Dlatego systemy wykazują takie samo zachowanie po każdym ponownym uruchomieniu (zgodnie z moimi testami). Szczegóły plików są następujące:

-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

EDYCJA: Wszystkim tym, którzy sugerują problem, może być związany z tym konkretnym przypadkiem dla tych konkretnych plików: „ system-rozwiązany ” jest tylko przykładem. Dzieje się tak również podczas wyszukiwania innych słów kluczowych. To kolejny przykład, który podaje nieprawidłowe wyniki dla pierwszego uruchomienia:

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

Czy nikt tutaj nie jest w stanie sprawdzić tego problemu na Debianie 8 z najnowszym jądrem z repozytorium backport?

linux find

— użytkownik2808671
źródło

Czy możesz spróbować porównać ślady dwóch połączeń, na przykład używając strace? W jakim systemie operacyjnym zaobserwowałeś nieprawidłowe zachowanie? Co rozumiesz przez „zwraca 0 lub dwa wyniki jak wyżej”? Zero lub dwa wiersze wyniku lub kod wyjścia 0 + dwa wiersze? Czy to się powtórzy po uruchomieniu nowej powłoki lub ponownym uruchomieniu? Może być istotne, że pierwsze wywołanie zwraca tylko pliki, a drugie zwraca pliki i katalogi.

— l0b0

@ l0b0 Tak jak powiedziałem, dzieje się to na Debianie z jądrem 4.9 w wielu systemach. Nie sprawdziłem innych dystrybucji. 0 lub 2 oznacza zero lub dwa wiersze wyniku. Dzieje się tak po każdym ponownym uruchomieniu. Twoje ostatnie oświadczenie nie ma tutaj zastosowania. Stara się zwrócić wszystko. Zarówno katalogi, jak i pliki.

— user2808671

@ l0b0 Cóż, nie jestem pewien, czego szukasz, ale jak widać, wspomniałem o poleceniu, aby można było odtworzyć problem. To polecenie musi zwrócić wszystkie ścieżki zawierające „systemd-resolved”, ale nie zrobi tego. Istnieje łącznie pięć ścieżek spełniających ten warunek, ale program „znajdź” zwraca tylko dwie z nich lub jedną lub zero. Liczy się tutaj to, że narzędzie daje błędne dane wyjściowe i brakuje niektórych poprawnych ścieżek. I jak wspomniałem, sprawdziłem to w innych systemach z Debianem, te z jądrem 4.9 mają ten problem. To może być coś poważnego poza przestrzenią użytkownika.

— user2808671

@ MarkWagner Nie. Wypełniłem raport o błędzie zarówno na liście dyskusyjnej GNU findutils, jak i na liście backportów Debiana. Wydaje mi się to bardzo poważne, ponieważ źródło tego problemu może wpływać na wiele innych rzeczy, choć nie wiem, czy się ze mną zgadzacie. W każdym razie „find” jest bardzo popularnym narzędziem, a jego wyniki muszą być niezawodne.

— user2808671

Jak /lib/systemdzamontować? Co to za system plików? Jeśli jest to osobny punkt montowania, o której godzinie został zamontowany?

— Andrew Henle,

Domyślna wersja findutils, która jest zainstalowana w Debianie 8, to 4.4.2 i jest to najnowsza wersja w repozytoriach jessie. Pobieram najnowszą wersję (4.6.0) kodu źródłowego findutils i buduję pliki binarne ze źródła. Następnie wykonałem te same testy i polecenie „znajdź” pokazało poprawne wyjście dla pierwszego uruchomienia.

Następnie pobrałem kod źródłowy findutils w wersji 4.4.2 z archiwum GNU i skompilowałem go. Ten sam problem wystąpił w przypadku skompilowanego polecenia find. Więc ten problem nie występuje w findutils 4.6.0.

Ale nadal nie wiem, dlaczego niektórzy użytkownicy nie uzyskują takich samych wyników za pomocą findutils 4.4.2 (domyślna wersja narzędzia zainstalowanego na Debianie) i nie wiem, dlaczego Debian powinien być nadal wydawany z tą starą wersją findutils i ewentualnie inne narzędzia Linuksa i powodują tę problematyczną sytuację. A ostatnią rzeczą jest to, że dokładny techniczny powód tego, co dziwnie się wydarzyło, jest wciąż nieznany, co nie jest pożądane. Ponieważ nie jestem pewien, czy w moim środowisku systemu operacyjnego jest coś niepokojącego.

— użytkownik2808671
źródło