dd가 라이브 디스크 쓰기에 대해 보호되지 않는 이유는 무엇입니까?

나는 dd가 고급 사용자 도구라는 것을 알고 있지만 잘못된 키를 누르면 기본적으로 전체 컴퓨터가 망가질 수 있다는 것이 나에게는 이해가 되지 않습니다.

토목 건축에 사용되는 전동 공구의 종류와 작은 일 하나라도 잘못하면 어떤 일이 발생할 수 있는지 생각해 보세요. 이런 일들이 더 예방 가능해질 수 있을까요? 그럴 수도 있지만 균형은 사고를 예방하기 쉽게 만드는 것이 도구의 유용성을 떨어뜨리거나 당황스럽게 만드는 정도입니다.

자동차를 운전하는 것도 비슷한 비유이며 잠재적으로 더 심각한 결과를 가져올 수 있지만 인간은 항상 그렇게 해왔습니다(사실 너무 많이). 물론 천천히 하면 더 안전하겠지만, 우리는 어떤 위험을 감수할 가치가 있는지 함께 결정합니다. 마찬가지로 컴퓨터도 dd존재하지 않았다면 더 안전하겠지만 위험보다 유용성이 더 크다고 여겨지기 때문에 컴퓨터는 존재합니다.

dd가 명령을 받는 디스크에 쓰는 것을 방지하는 보안 조치가 없는 이유는 무엇입니까?

실제로 그렇습니다. 기본적으로 장치 파일(예: /dev/sda1)에 쓰기 위해서는 수퍼유저 권한이 필요하기 때문입니다. 따라서 as root또는 via를 사용하지 않는 한 sudo한 번의 클릭으로 .NET을 사용하여 전체 컴퓨터를 망칠 수는 없습니다 dd.

이는 우리를 다음으로 이끈다슈퍼유저 권한으로 명령을 실행하는 것에 대한 모든 경고가 표시되는 이유는 무엇입니까? 이러한 경고는 너무 흔해서 이를 보지 않고는 *nix 시스템을 작동시키기가 어렵다고 생각합니다. 마치 공사 구역에 눈치채지 못한 채 들어가는 것과 같습니다.안전모 구역징후.

공사 구역에 있을 이유가 없다면 떠나십시오. 이 경우 적절한 안전 예방 조치를 취하십시오. 세상은 위험한 곳일 수 있으며 어떤 곳은 다른 곳보다 더 위험합니다. 생각 없이 행동하지 마세요. 나쁜 일이 일어나지 않을 정도의 보안 수준(그래서 너무 어렵게 생각할 필요 없음)은 이에 대해 할 수 있는 일이 많지 않다는 것을 의미합니다. 때로는 이것이 바람직할 때도 있지만 그렇지 않을 때도 있습니다.

dd 명령이 대상에 마운트된 파일 시스템이 포함되어 있는지 먼저 확인한 다음 확인 메시지를 표시하거나 특수 플래그를 요구하지 않는 이유를 묻는 것이 합리적입니다. 간단한 대답은 dd를 이런 방식으로 사용할 수 있을 것으로 예상되는 모든 스크립트를 손상시키고 해당 스크립트는 대화형 입력을 처리하도록 설계되지 않았다는 것입니다. 예를 들어, 파티션을 마운트할 때 원시 장치의 파티션 테이블을 수정하는 것이 합리적일 수 있습니다. 첫 번째 섹터만 수정하면 됩니다.

시중에는 수많은 Linux 시스템이 있으며 사람들이 어떤 미친 설정을 생각해 냈는지 아는 것은 불가능합니다. 따라서 dd의 관리자가 알 수 없는 수의 환경에서 문제를 일으킬 수 있는 이전 버전과 호환되지 않는 변경을 수행할 가능성은 거의 없습니다.

"옵션이나 확인 메시지와 같은 작은 단계를 추가"하려면 질문 설명에서 artm이 제안한 대로 래퍼 스크립트를 사용하면 됩니다.

즉, 다소 어려운 dd 명령줄 인수를 직접 처리하는 대신 관심 있는 옵션 구문을 사용하여 관심 있는 dd 인수를 가져오는 bash(또는 Python 등)에서 스크립트를 생성하세요. 더 편안합니다. 스크립트는 인수가 합리적인지 확인하고 인수(및 최종 dd 명령줄)를 인쇄하므로 모든 것이 올바른지 확인할 수 있습니다. 그런 다음 스크립트는 "계속하시겠습니까? [y/N]"이라고 묻습니다. 따라서 y스크립트가 실제로 구축된 dd 명령줄을 실행하도록 하려면 이를 입력해야 합니다.

따라서 스크립트가 /dev/sda 또는 해당 파티션에 쓰는 것을 원하지 않으면 그렇게 할 수 없도록 설정할 수 있습니다. 필요한 입력 및 출력 장치가 실제로 선택되었는지 확인하는 데 도움이 되도록 스크립트는 blkid 명령을 사용하여 이러한 장치의 UUID 및 디스크 레이블을 얻을 수 있습니다. 등.