Linux find 명령이 잘못 작동합니다


14

최근 취약성 공개 이후 시스템 해결 서비스를 검색하면서 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 또는 2 행을 리턴합니다. 그러나 두 번째 명령을 실행하면 다음과 같은 결과가 나타납니다.

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이 설치된 시스템에서는 발생하지 않습니다.
시스템 재부팅 후이 모든 것이 다시 발생합니다. 그러나 각 개별 시스템의 동작은 동일합니다. 즉, 특정 시스템에서 테스트 한 결과 첫 번째 실행시 두 줄의 출력이 반환되고 두 번째 실행시 올바른 출력이 반환되면 시스템을 다시 부팅 한 후 명령을 처음 실행하면 두 행이 다시 인쇄됩니다. 따라서 시스템은 재부팅 할 때마다 동일한 테스트를 수행합니다 (내 테스트에 따라). 파일 세부 사항은 다음과 같습니다.

-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

편집 : 문제를 제안하는 모든 사람들 에게이 특정 파일에 대한이 특정 사례와 관련이있을 수 있습니다 : " system-resolved "는 예와 같습니다. 다른 키워드도 검색 할 때 발생합니다. 이것은 첫 번째 실행에 잘못된 결과를 제공하는 또 다른 예입니다.

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

여기 아무도 백 포트 저장소의 최신 커널을 가진 데비안 8에서이 문제를 확인할 수 없습니까?


2
strace? 를 사용하여 두 호출의 추적을 비교할 수 있습니까 ? 어떤 OS에서 잘못된 동작을 관찰 했습니까? "위와 같이 0 또는 2 개의 결과를 반환합니다"는 무슨 뜻입니까? 0 또는 2 줄의 출력 또는 종료 코드 0 + 2 줄? 새 쉘을 시작하거나 재부팅 한 후에 다시 발생합니까? 첫 번째 호출은 파일 만 반환하고 두 번째 호출은 파일과 디렉터리를 반환하는 것이 적절할 수 있습니다.
l0b0

1
@ l0b0 내가 말했듯이 여러 시스템의 Kernel 4.9가 설치된 Debian에서 발생합니다. 다른 배포판을 확인하지 않았습니다. 0 또는 2는 0 개 또는 2 개의 출력 라인을 의미합니다. 재부팅 할 때마다 발생합니다. 마지막 진술은 여기에 적용되지 않습니다. 모든 것을 반환하려고 시도합니다. 디렉토리와 파일 모두.
user2808671

1
@ l0b0 글쎄, 당신이 찾고있는 것이 확실하지 않지만, 보시다시피 명령을 언급하여 문제를 재현 할 수 있습니다. 이 명령은 "systemd-resolved"를 포함하는 모든 경로를 반환해야하지만 그렇지 않습니다. 이 조건을 만족시키는 총 5 개의 경로가 있지만 "찾기"프로그램은 2 개 또는 1 개 또는 0 개만 반환합니다. 여기서 중요한 것은 도구가 잘못된 출력을 제공하고 올바른 경로를 놓친다는 것입니다. 내가 언급했듯이 데비안이있는 다른 시스템에서 이것을 확인했지만 커널 4.9가있는 시스템에는이 문제가 있습니다. 이것은 사용자 공간을 넘어선 심각한 문제 일 수 있습니다.
user2808671

2
@MarkWagner 아니요. gnu findutils와 Debian backports 메일 링리스트 모두에 버그 보고서를 작성했습니다. 이 문제의 원인이 다른 많은 것들에 영향을 미칠 수 있기 때문에 이것은 나에게 매우 심각한 것 같습니다. 어쨌든 "찾기"는 매우 인기있는 도구이며 그 출력은 신뢰할 수 있어야합니다.
user2808671

2
/lib/systemd마운트 방법 어떤 종류의 파일 시스템입니까? 이 지점을 별도의 마운트 있다면, 어떤 시간 이 마운트했다?
Andrew Henle

답변:


4

Debian 8에 설치된 findutils의 기본 버전은 4.4.2이며 이것은 jessie 저장소의 최신 버전입니다. findutils 소스 코드의 최신 버전 (4.6.0)을 다운로드하고 소스에서 바이너리를 빌드했습니다. 그런 다음 동일한 테스트를 수행하고 "find"명령 이 첫 번째 실행에 올바른 출력을 표시했습니다.

그런 다음 gnu 아카이브에서 findutils 버전 4.4.2 소스 코드를 다운로드 하여 컴파일했습니다. 컴파일 된 find 명령에 대해 동일한 문제점이 발생했습니다. 따라서 findutils 4.6.0에서는이 문제가 발생하지 않습니다.

그러나 나는 여전히 일부 사용자가 findutils 4.4.2 (데비안에 설치된 유틸리티의 기본 버전)를 사용하여 동일한 결과를 얻지 못하는 이유를 모르고 왜 이전 버전의 findutils로 데비안이 여전히 출시되어야하는지 모르겠습니다. 다른 Linux 유틸리티 일 수 있으며이 문제가 발생할 수 있습니다. 그리고 마지막으로 이상하게 일어난 일의 정확한 기술적 이유는 아직 알려지지 않았으므로 바람직하지 않습니다. OS 환경에 문제가 있는지 확실하지 않기 때문입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.