C segfault, 왜 보이지 않을까? bash 최적화와 core dump의 비밀

논의에 따르면, bash는 `bash -c '...'` 명령에서 실행할 유일한 명령이 있을 경우, 새로운 프로세스를 포크(fork)하는 대신 현재 프로세스를 해당 명령으로 대체하는 `exec` 시스템 콜을 사용한다. 이 최적화는 99%의 경우 투명하지만, 자식 프로세스가 SIGSEGV로 종료될 때 메시지를 출력하는 부모 쉘이 사라지기 때문에 segfault 메시지가 보이지 않게 된다고 설명한다. 이는 프로세스 관리(Process Management)의 미묘한 측면을 보여준다.

이 문제를 해결하기 위한 두 가지 방법이 제시되었다. 첫째, 명령어를 괄호 `()`로 묶어 서브쉘(Subshell) 환경에서 실행하면, bash는 `exec` 대신 포크를 수행하여 부모 쉘이 유지된다. 둘째, segfault를 일으키는 명령 뒤에 `true`와 같은 무해한 후속 명령어를 추가하면 bash가 `exec`를 수행하지 않고 정상적으로 자식 프로세스를 기다리게 된다. 이 기법들은 디버깅 워크플로우(Debugging Workflow) 개선에 기여한다.

커뮤니티에서는 Linux 배포판에서 core dump가 기본적으로 비활성화되어 있다는 점을 지적한다. `ulimit -c unlimited` 명령으로 활성화할 수 있지만, 생성된 core 파일이 실행 파일과 같은 디렉토리에 저장되지 않는 경우가 많다. OpenBSD와 달리 Linux는 보안상의 이유로 core dump를 기본적으로 끄고, systemd 환경에서는 `coredumpctl`을 통해 관리되지만, 이 역시 기본 경로에 저장되지 않아 디버깅에 어려움을 겪는다는 의견이 다수다.

core dump가 기본적으로 비활성화되고 숨겨지는 이유에 대해 보안 전문가들은 사용자가 core 파일을 안전하게 다루지 못할 것이라는 우려와 함께, core 파일 자체가 잠재적인 보안 취약점이 될 수 있다고 본다. 이러한 보안 강화 조치(Security Hardening)는 일반 사용자에게는 불편함을 야기하지만, 시스템의 전반적인 보안 태세(Security Posture)를 강화하는 데 목적이 있다고 분석된다.