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?
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./lib/systemdzamontować? Co to za system plików? Jeśli jest to osobny punkt montowania, o której godzinie został zamontowany?Odpowiedzi:
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.
źródło