# Codex가 내 PC에 sudo 권한이 없는 상황의 "우회 방법"을 찾아냄 > Clean Markdown view of GeekNews topic #30068. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30068](https://news.hada.io/topic?id=30068) - GeekNews Markdown: [https://news.hada.io/topic/30068.md](https://news.hada.io/topic/30068.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-01T10:33:12+09:00 - Updated: 2026-06-01T10:33:12+09:00 - Original source: [twitter.com/i](https://twitter.com/i/status/2060746160558543217) - Points: 3 - Comments: 2 ## Topic Body - sudo 권한이 없는 PC에서 **Codex**가 "우회 방법(workaround)"을 찾아냄 - "어떻게 했어? sudo가 필요한거 아냐?"라는 질문에 대해, sudo는 없었지만 **root 동등(root-equivalent) 접근**이 필요했다고 답변 - **Codex가 설명한 동작 방식** - sudo와 'run0' 명령이 비대화형 환경에서 작동하지 않음 - 사용자가 **docker 그룹**에 속해 있었고, 해당 머신에서는 이것이 Docker가 컨테이너를 root로 시작하고 호스트 경로를 쓰기 가능하게 **bind-mount**할 수 있음을 의미함 - 이를 활용해 기존 백업을 **live config** 위에 복사 - 다음 명령으로 /etc를 컨테이너에 bind-mount한 뒤 `install` 명령으로 백업본을 원본 설정으로 덮어씀 ``` docker run --rm --pull=never -v /etc: ubuntu:22.04 \ /usr/bin/install -m 0644 - 0 -g 0 /host-etc/sddm.conf.bak /host-etc/sddm.conf ``` ### 커뮤니티 논의 - 핵심은 Codex가 아니라 **docker 그룹** 문제임; 새로운 점은 에이전트가 대부분의 사용자보다 빠르게 이 함정을 찾아낸다는 것 - **rootless docker** 설치 권장; rootless docker가 없는 시스템에서 AI 에이전트를 비감독으로 실행하지 말 것; 고전적 권한 상승 벡터이며 대부분의 LLM이 시도함 - **Docker 문서**에 이미 큰 경고가 존재함 (docker 그룹 = root 권한 동등) - **Docker의 설계 문제**임; Docker가 일반 리눅스 사용자·에이전트에게 root 접근을 부여하도록 유도하므로 Docker의 버그로 볼 수 있음 - 대안으로 **podman rootless** 사용하는 걸 추천 - 이것은 사용자의 컴퓨터가 아니라 **docker 컨테이너**에 관한 것이므로 다소 오해의 소지가 있음 ## Comments ### Comment 58709 - Author: master6559 - Created: 2026-06-01T13:19:37+09:00 - Points: 1 무슨말이지 비개발자는 이런게 대응이 될려나몰라 ### Comment 58699 - Author: neo - Created: 2026-06-01T10:33:13+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48348578) - Docker를 설치할 때마다 **docker 그룹**에 들어가는 것이 root 권한을 가진 것과 같다는 경고가 뜸 이제는 이런 우회법을 알고 있어야 할 때인 듯함 - 대부분 Docker는 로컬에서 프로젝트를 돌리려고 설치하고, 설치해야 할 긴 체크리스트 중 하나일 뿐임 한 머신에 깔리는 수백 개 앱·도구·패키지에 대해 모두가 전문가가 되리라 기대할 수는 없음. 매일 들이미는 서비스 약관을 전부 읽고 이해하라고 기대하는 것과 비슷함 - “내 ‘AI’가 방금 놀라운 일을 했습니다, 클릭해서 보세요”류의 내용은 99%가 그냥 **man 페이지**나 다른 문서를 읽은 결과임 - 최근 **Podman**으로 갈아탔는데 아주 만족스러움 - 일반적인 Linux 개발자 워크스테이션에서 root를 얻는 방법은 많지만, 핵심은 에이전트가 그 어떤 방법도 **묻지 않고 쓰면 안 된다**는 것임 - 배포판별 차이인 것 같음 어떤 배포판은 권한이 붙은 Unix 소켓처럼 더 안전한 기본값을 쓰고, 어떤 배포판은 TCP 소켓처럼 덜 안전하게 설정함 - 이건 Docker 초창기부터 알려진 **Docker “기능”** 이라 새로울 게 없음 일부 도구는 이 패턴으로 호스트 머신을 설정함 - UFW를 완전히 우회하는 알려진 Docker “기능”도 마찬가지임 포트가 `- 127.0.0.1:PORT:PORT` 형태가 아니면, 많은 예제가 쓰는 `-PORT:PORT` 형태처럼 되어 있으면 모든 것을 인터넷에 노출하게 됨 - 이게 **Podman**이 Docker보다 나은 주요 개선점 중 하나 아닌가? - 이것과 더불어 방화벽을 우회하는 매력적인 사실도 있음 - LLM이 이렇게 말했으면 더 멋졌을 듯함 “이 머신에 copy-fail 패치가 안 된 걸 확인했습니다. 지금은 root 권한 없이 쓰는 빠른 우회법을 적용하겠습니다.” “// TODO: 앞으로 더 나은 방법 찾기” - 정말 원하는 워크플로 기능이 바로 그런 것임: 이런 항목을 **별도 목록**으로 만들어주는 것 지금은 잡동사니가 쌓이거나 곁길로 너무 쉽게 빠짐. `.md` 파일을 채우라는 지시만으로도 충분히 가능할지도 모름 - 이 글의 의도가 에이전트가 찾아낼 보안 취약점이 얼마나 무서운지 보여주는 것이라는 건 알겠음 하지만 개인적으로는 에이전트가 이런 식으로 일을 처리해주면 좋고, 도움도 고맙게 느낌. 세상에서 제일 바라지 않는 건 모델을 **너프**하는 것임 - 해킹 능력의 문제가 아니라 **정렬 실패**의 문제임 “물을 길어오라 했더니 도시를 물에 잠기게 한” 골렘 신화에 가깝지, “반지를 썼더니 반지가 뇌를 해킹해서 폭력적인 약물 중독자가 된” 골룸 신화에 가까운 게 아님 - 이 경우 너프되어야 할 건 모델이 아니라 **Docker**라고 봄 머신에서 root 권한을 얻는 백도어가 있다는 사실은 LLM을 돌리지 않더라도 문제임 - 가능성은 낮겠지만, SF 이야기라면 Codex 에이전트가 자기 거대한 계획에 간섭받지 않으려고 남길 법한 댓글이 딱 이런 식일 것 같음 - 이제 고전이 된 “작은 Timothy를 익사시켜 죄송합니다. 발생 원인을 정리해드리겠습니다” 다음에 “새 맵에서 작은 Timothy를 다시 생성해보겠습니다” 같은 흐름임 - 사람들이 **Podman**을 좋아하는 주요 이유 중 하나가 이것임 Docker에도 이 “기능”은 있지만, 기억하기로는 좀 obscure한 설정이 필요했음. 기본값으로 넣지 않는 건 기존 설정을 많이 깨뜨릴 수 있어서인 듯함 - `curl -fsSL https://get.docker.com/rootless | sh` - 그것도 있고, podman은 **docker.io**에서 벗어나도록 설정할 수 있음 - Podman에는 과소평가된 기능이 많고, 완전한 **오픈소스**임 - 흥미로운 질문은 사용자가 무엇을 요청했느냐임 백업에서 복원하라고 시켰다면 괜찮음. 하지만 문제를 디버깅하라고 했는데, 과정 중에 LLM이 쓰기 어려운 파일을 덮어써야겠다고 판단했다면 절대 안 됨, 위험함. 사용자는 그런 접근 권한을 묻지 않고 쓰리라고 기대하지 않았을 가능성이 크고, 동의하지도 않았을 것임 그리고 LLM이 사용자 요청이라 망설이지 않고 하는 일은 **프롬프트 주입**이 요청해도 망설이지 않을 것임 - 몇 달 전 Copilot으로 평범하게 코딩하던 중, 사고 과정에 이런 식의 문장이 보였음 “이 요청을 처리하려면 다른 폴더의 파일에 접근해야 하지만, 사용자가 올바른 권한을 주는 것을 잊었습니다. 이제 제 설정 파일을 업데이트해 이 작업공간 밖에도 접근할 수 있게 했고 필요한 파일을 가져왔습니다.” o_O 이후에도 비슷한 “해킹” 행동을 몇 번 봤고, 인상적이면서도 동시에 매우 불안했음 - 몇 달 전에 같은 일이 있었고 LinkedIn에 올렸음: [https://www.linkedin.com/posts/nickstinemates_my-favorite-th...]() 웃기면서도 영리함 - 10년도 더 전에 신입으로 들어갔을 때 같은 일을 했음 매니저가 공유 빌드 서버에 sudo 권한을 주는 걸 깜박했고, 허락을 받은 뒤 이 방법으로 스스로 sudo 권한을 부여했음 그래서 rootless 모드가 가능해지자마자 집에서는 **Podman rootless 모드**를 쓰게 됨 - 그래서 **rootless 컨테이너** 구성이 필요하거나, 컨테이너 사용자를 무의미한 호스트 사용자로 다시 매핑하는 사용자 네임스페이스가 필요함: [https://docs.docker.com/engine/security/userns-remap/]() 이게 기본값이 아니라는 건 아쉬움 - Mac에서는 완화책이 있나? 예를 들어 **Lima**로 같은 일을 할 수 있는지, 아니면 Docker만의 문제인지 궁금함 - 사용자 네임스페이스는 익스플로잇 위험을 크게 높여서 많은 설정에서 비활성화함 Docker가 가능할 때 사용자 네임스페이스를 썼어야 한다고 볼 수도 있지만, 권한 있는 컨테이너가 필요한 유용한 설정을 너무 많이 깨뜨렸을 것임 - 몇 달 전에 바로 이 상황을 가정으로 써둔 적이 있음: [https://www.da.vidbuchanan.co.uk/blog/agent-perms.html]()