GNU Screen에서 발견된 여러 보안 문제

 (openwall.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • GNU Screen 보안 검토에서 Screen 5.0.0과 setuid-root 설치를 중심으로 로컬 권한 상승, TTY 하이재킹, 정보 노출, 시그널 전송 경쟁 조건, 명령 전송 크래시가 확인됨
  • 가장 심각한 CVE-2025-23395는 logfile_reopen()이 사용자 제공 경로를 root 권한으로 처리해, 임의 위치에 root 소유 파일을 만들거나 기존 파일에 로그를 덧붙일 수 있게 함
  • 멀티유저 모드의 오래된 동작도 문제로 드러났으며, Attach()가 TTY를 일시적으로 0666으로 바꾸면서 다른 사용자의 읽기·쓰기와 입력 주입 가능성이 생김
  • 배포판별 위험은 설치 방식에 따라 갈리며, Arch Linux와 NetBSD 10.1은 Screen 5.0.0을 setuid-root로 제공해 주요 취약점 영향을 크게 받음
  • 현재 권고는 Screen을 setuid-root로 설치하지 않는 것이며, 멀티유저 기능은 신뢰 그룹 기반 opt-in과 기본 권한 강등, 제한적 권한 상승, 환경 변수 정리가 필요함

공개 배경과 패치

  • 2024년 7월 upstream Screen 관리자가 현재 코드베이스 검토를 요청했고, 실제 보안 검토는 2025년 1월 시작됨
  • 검토 결과 Screen 5.0.0 주요 업데이트에서 setuid-root 배포판에 영향을 주는 로컬 root 익스플로잇이 발견됨
  • 추가로 더 낮은 심각도의 문제들이 확인됐으며, 일부는 다수 배포판에 남아 있는 Screen 4.9.1 및 이전 버전에도 영향을 줌
  • 문제들은 2025년 4월 30일 distros 메일링 리스트에 공유됐고, 2025년 5월 12일 공개됨
  • 보고에는 버전별 패치 묶음이 첨부됨

Screen 구성과 멀티유저 모드

  • Screen 5.0.0은 2024년 8월 upstream에서 주요 릴리스로 공개됐고, Arch Linux, Fedora 42, NetBSD 10.1이 이 버전을 제공함
  • 다수 Linux 및 UNIX 배포판은 작성 시점에 여전히 Screen 4.9.1을 사용함
  • Screen의 멀티유저 모드는 적절한 자격 증명이 있을 때 다른 사용자가 소유한 Screen 세션에 attach할 수 있게 함
    • 이 기능은 Screen이 setuid-root 비트로 설치된 경우에만 사용 가능함
    • 복잡한 Screen 코드가 root 권한으로 실행되므로 공격 표면이 커짐
  • 검토 대상 시스템 중 Arch Linux, FreeBSD, NetBSD는 Screen을 setuid-root로 설치함
  • Gentoo Linux는 "multiuser" USE 플래그가 설정되면 setuid-root 비트가 적용됨
  • 일부 배포판은 setuid 대신 setgid를 사용함
    • Gentoo Linux 기본값은 setgid-utmp로, Screen이 시스템 전체 utmp 데이터베이스에 로그인 기록을 만들 수 있음
    • Fedora Linux는 setgid-screen으로, Screen이 /run/screen의 시스템 전체 디렉터리에 소켓을 둘 수 있음

CVE-2025-23395: logfile_reopen() 로컬 root 익스플로잇

  • CVE-2025-23395는 Screen 5.0.0이 setuid-root 권한으로 실행될 때 영향을 줌
  • logfile_reopen() 함수가 사용자 제공 경로를 처리하면서 권한을 강등하지 않음
  • 비권한 사용자는 임의 위치에 다음 속성의 파일을 만들 수 있음
    • 소유자: root
    • 그룹: 호출 사용자의 실제 그룹
    • 파일 모드: 0644
  • 이미 존재하는 파일도 악용 가능함
    • Screen PTY에 쓰인 데이터가 해당 파일에 append됨
    • 기존 파일의 모드와 소유권은 변경되지 않음
  • Screen은 로그 파일을 처음 열 때는 권한을 올바르게 강등하지만, 로그 파일을 다시 열어야 한다고 판단하는 순간 권한 상승 가능성이 생김
  • stolen_logfile() 검사에서 원래 로그 파일의 link count가 0이 되거나 크기가 예기치 않게 변하면 logfile_reopen()이 호출됨
  • 이 조건은 비권한 사용자가 의도적으로 유발할 수 있음
  • Screen 5.0.0용 patch 0001은 로그 파일 reopen 과정에서 안전한 파일 처리를 다시 도입함
  • 이 문제는 오래된 commit 441bca708bd에서 lf_secreopen()이 제거되며 생겼고, 해당 변경이 5.0.0 릴리스에 포함됨

CVE-2025-46802: 멀티유저 세션 attach 중 TTY 하이재킹

  • CVE-2025-46802는 multiattach 플래그가 설정된 Attach() 함수에서 발생함
  • Screen은 멀티유저 세션 attach 시 현재 TTY에 대해 chmod()로 모드를 0666으로 변경함
  • TTY 경로는 /dev 아래인지와 isatty() 조건 등으로 검증되므로, 이 동작만으로 별도 로컬 root 익스플로잇이 되지는 않음
  • 문제는 TTY 권한이 일시적으로 완화되는 동안 다른 사용자가 해당 TTY를 읽고 쓸 수 있는 경쟁 조건이 생긴다는 점임
  • Linux inotify API 기반 간단한 테스트에서는 Python 스크립트가 매 두세 번 시도마다 영향을 받는 TTY를 열 수 있었음
  • 공격자는 다음을 할 수 있음
    • TTY에 입력되는 데이터를 가로챔
    • TTY에 데이터를 주입함
    • 사용자가 비밀번호를 입력하도록 오도함
    • 제어 시퀀스를 주입해 피해자를 혼란스럽게 하거나 관련 터미널 에뮬레이터 문제를 노림
  • Attach()의 일부 return 경로에서는 원래 TTY 모드가 복원되지 않음
    • 예: 대상 세션을 찾지 못했고 "quiet" 인자가 설정된 경우
  • 패치는 임시 chmod()를 제거함
    • Screen 4.9.1용 patch 0001
    • Screen 5.0.0용 patch 0004
  • 공개 직전 이 패치가 일부 reattach 사용 사례를 깨뜨릴 가능성이 확인됐지만, 해당 사용 사례는 Screen 4.9.1에서도 이미 깨져 있던 것으로 확인됨
  • 이 문제는 최소 2005년 이후 Screen 버전에 존재했으며, setuid-root로 멀티유저 지원을 제공하는 Linux 배포판과 BSD에 영향을 줌
  • setuid-root가 아닌 경우에도 사용자가 자기 TTY의 모드를 바꿀 권한은 있으므로 이론적으로 영향을 받지만, Screen은 다른 사용자의 세션에 root 권한 없이 계속 진행하지 않음

CVE-2025-46803: Screen 5.0.0의 world-writable PTY 기본값

  • CVE-2025-46803은 Screen 5.0.0에서 Screen이 할당하는 PTY 기본 모드가 0620에서 0622로 바뀐 문제임
  • 이 기본값에서는 시스템 내 누구나 Screen PTY에 쓸 수 있음
  • 보안상 CVE-2025-46802와 유사한 문제가 생기지만, 정보 유출 측면은 제외됨
  • Screen 4.9.1에서는 코드 레벨 기본값이 0622였지만 autotools 구성의 기본값 0620이 적용되어 안전한 기본값이 사용됨
  • Screen 5.0.0에서는 configure.ac가 다시 작성되며 autoconf 레벨의 0620 기본값이 사라졌고, 이후 pty-mode configure 스위치가 기본 0622로 재도입됨
  • 5.0.0 릴리스 노트는 확인되지 않았고 ChangeLog 일부 항목만 있었으며, PTY 모드 기본값 변경은 의도적 결정으로 보이지 않음
  • Screen 5.0.0용 patch 0002는 configure.ac에서 안전한 기본 PTY 모드를 복원함
    • 변경을 적용하려면 autoreconf 실행이 필요함
  • 패키저에게는 --with-pty-mode=0620 configure 스위치를 명시적으로 전달할 것이 권고됨
  • Gentoo Linux와 Fedora Linux는 안전한 --with-pty-mode를 명시적으로 전달함
  • Arch Linux와 NetBSD는 해당 스위치를 전달하지 않아 새 기본값이 적용되고 취약함

CVE-2025-46804: 소켓 경로 오류 메시지를 통한 파일 존재 여부 노출

  • CVE-2025-46804는 Screen이 setuid-root 권한으로 실행될 때 발생하는 경미한 정보 유출임
  • older Screen 버전과 5.0.0 모두에서 확인됨
  • Screen은 SocketPath를 root 권한으로 검사하고, 비권한 사용자가 일반적으로 알 수 없는 경로 정보를 오류 메시지로 노출함
  • SCREENDIR 환경 변수를 사용하면 다음 정보를 추론할 수 있음
    • /root/.lesshst가 일반 파일인지
    • /root/.cache 디렉터리가 존재하는지
    • /root/test 경로가 존재하지 않는지
  • 패치는 setuid-root 설치에서 대상 경로가 프로세스의 실제 UID에 의해 제어되지 않을 때 일반적인 오류 메시지만 출력하도록 바꿈
    • Screen 4.9.1용 patch 0002
    • Screen 5.0.0용 patch 0005
  • 검토한 모든 배포판이 영향을 받음

CVE-2025-46805: 시그널 전송 TOCTOU 경쟁 조건

  • CVE-2025-46805는 setuid-root 문맥에서 사용자 제공 PID에 시그널을 보낼 때 생기는 TOCTOU 경쟁 조건임
  • CheckPid()는 실제 사용자 ID로 권한을 낮춘 뒤 커널이 대상 PID에 시그널 전송을 허용하는지 검사함
  • 실제 시그널은 나중에 Kill()을 통해 보내지며, 이때 root 권한이 사용될 수 있음
  • 검사와 실제 전송 사이에 이전에 검사한 PID가 다른 privileged process로 대체될 수 있음
  • privileged Screen daemon 프로세스가 자기 자신에게 시그널을 보내도록 속일 가능성도 있음
  • 현재는 SIGCONT와 SIGHUP만 보낼 수 있어 영향은 로컬 서비스 거부 또는 경미한 무결성 침해 영역일 가능성이 큼
  • 이 문제는 CVE-2023-24626의 불완전한 수정에서 비롯됨
    • 해당 수정 전에는 경쟁 조건 없이도 임의 프로세스에 해당 시그널을 보낼 수 있었음
  • 패치는 실제 시그널도 CheckPid()처럼 실제 UID 권한으로 보내도록 바꿈
    • Screen 4.9.1용 patch 0003
    • Screen 5.0.0용 patch 0006
  • 검토한 모든 배포판이 영향을 받음

Screen 5.0.0의 strncpy() 사용으로 인한 명령 전송 크래시

  • Screen 5.0.0에는 보안 이슈로 보지는 않지만 우선 수정해야 하는 strncpy() 관련 문제가 있음
  • commit 0dc67256에서 여러 strcpy() 호출이 strncpy()로 교체됨
  • strncpy()는 안전한 문자열 처리를 위한 함수가 아니라 고정 길이 버퍼를 0으로 패딩하는 함수이므로, 첫 \0 바이트 뒤에도 대상 버퍼 끝까지 0을 씀
  • attacher.c의 명령줄 인자 처리 루프에서 첫 반복 이후에도 MAXPATHLEN을 목적지 크기로 전달함
  • 포인터 p가 이미 증가한 뒤에도 같은 크기를 넘기므로, 이후 strncpy() 호출은 버퍼 끝을 넘어 \0 바이트를 씀
  • Arch Linux에서 실행 중인 Screen 세션에 둘 이상의 명령 인자를 보내면 _FORTIFY_SOURCE가 켜진 빌드에서 다음 오류가 관찰됨
    • *** buffer overflow detected***: terminated
    • Aborted (core dumped)
  • _FORTIFY_SOURCE가 없으면 가시적 오류가 없을 수 있고, -fsanitize=address에서도 오류가 보이지 않을 수 있음
  • 호출자는 cmd 버퍼 뒤의 MAXPATHLEN 바이트를 0으로 덮을 수 있지만, 뒤에 같은 크기의 writeback[MAXPATHLEN] 버퍼가 있어 공격자에게 유리하게 악용할 가능성은 없을 것으로 판단됨
  • Screen 5.0.0용 patch 0003은 strncpy()를 snprintf()로 바꾸고 남은 대상 버퍼 크기를 정확히 전달함
  • Screen 5.0.0을 제공하는 모든 배포판이 영향을 받음

배포판별 영향 범위

시스템 Screen 버전 특수 권한 영향
Arch Linux 5.0.0 setuid-root 3.a, 3.b, 3.c, 3.d, 3.e, 3.f
Debian 12.10 4.9.0 없음 3.b 일부
Ubuntu 24.04.2 4.9.1 없음 3.b 일부
Fedora 42 5.0.0 setgid-screen 3.b 일부, 3.f
Gentoo 4.9.1 setgid-utmp, multiuser USE 플래그 설정 시 setuid-root 3.b 일부
openSUSE TW 4.9.1 없음 3.b 일부
FreeBSD 14.2 4.9.1 setuid-root 3.b, 3.d, 3.e
NetBSD 10.1 5.0.0 setuid-root 3.a, 3.b, 3.c, 3.d, 3.e, 3.f
OpenBSD 7.7 4.9.1 없음 3.b 일부

setuid-root 설계에 대한 우려와 권고

  • Screen 멀티유저 모드에는 세 가지 UID가 관련됨
    • privileged operation을 위한 effective UID 0
    • 세션을 만든 사용자의 실제 UID
    • 세션에 attach하는 사용자의 실제 UID
  • 현재 Screen 코드는 이 구분을 적절히 반영하기 어려운 구조로 보임
  • root가 만든 Screen 멀티유저 세션은 세션 생성자의 실제 UID인 0으로 “권한 강등”하므로, 실질적으로 권한 강등이 일어나지 않음
  • Screen 5.0.0의 리팩터링 과정에서 오랫동안 존재하던 보안 로직이 깨졌고, 그 결과 CVE-2025-23395와 CVE-2025-46803이 발생함
  • 추가 리팩터링 전에는 구현의 보안 속성을 검증할 수 있는 테스트 스위트가 필요함
  • setuid-root 바이너리를 다루는 개발자는 해당 영역의 위험을 이해해야 함
  • Screen은 상승 권한으로 계속 실행하다가 위험하다고 보는 작업에서만 선택적으로 권한을 낮춤
  • 견고한 setuid-root 프로그램은 기본적으로 권한을 낮추고, 실제로 상승 권한이 필요한 작업에서만 권한을 올리는 방식이어야 함
  • setuid-root 문맥에서는 명시적으로 허용된 환경 변수만 남기고 제거하는 로직이 필요함
  • PATH 같은 환경 변수는 신뢰할 수 있는 시스템 디렉터리만 가리키도록 정리해야 함
  • 현재는 Screen 5.0.0뿐 아니라 이전 4.9 계열도 setuid-root로 설치하지 않는 것이 권고됨
  • 대안으로 멀티유저 기능을 opt-in 방식으로 제공하고, 신뢰된 그룹 구성원만 멀티유저 버전 Screen을 실행하게 할 수 있음

공개 조율 과정과 upstream 상태

  • 2025년 2월 Screen upstream에 비공개로 문제를 보고하고 조율 공개를 제안함
  • upstream은 공개 전 버그 수정을 위해 문제를 비공개로 유지하는 데 관심을 보였고, 1~2개월이 필요하다고 전달함
  • 약 한 달 뒤 upstream 측 활동과 패치 논의가 시작됐지만, 논의는 충분히 생산적이지 않았음
  • 최대 90일 embargo 기간이 가까워진 시점까지 추가 소통이 없었고, 그 사이 NetBSD 같은 배포판이 Screen 5.0.0으로 업데이트되어 CVE-2025-23395에 완전히 영향받게 됨
  • upstream이 Screen 코드베이스에 충분히 익숙하지 않고 보고된 보안 문제를 완전히 이해하지 못한다는 판단이 내려짐
  • upstream은 일부 문제가 미해결인 상태에서 더 이른 공개를 원했고, 이에 따라 distros 메일링 리스트에 초안이 빠르게 전달됨
  • 이후 SUSE 측이 누락된 수정 사항을 직접 개발하고, upstream에서 초안 형태로 논의된 패치도 조정 및 문서화함
  • 전용 upstream 역량이 있었다면 조율 공개 절차는 약 2주 내 완료 가능했을 것으로 판단됨
  • Screen upstream은 인력과 전문성 부족을 겪는 것으로 보이며, 널리 쓰이는 오픈소스 유틸리티라는 점에서 우려가 큼

주요 일정

  • 2024-07-01: upstream의 검토 요청 전달
  • 2025-01-08: 보안 검토 작업 시작
  • 2025-02-07: Screen upstream에 비공개 보고 및 조율 공개 제안
  • 2025-02-11: GNU Savannah 버그 트래커에 비공개 버그 생성
  • 2025-04-30: CVE 할당 결정 및 distros 메일링 리스트에 초안 공유
  • 2025-05-07: Screen 4.9.1 및 5.0.0용 패치 완성본을 distros 메일링 리스트와 upstream에 공유
  • 2025-05-12: 보고서가 블로그와 oss-security 메일링 리스트에 공개됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Screen에 이런 다중 사용자 모드가 있는 줄 몰랐지만, tmate 같은 도구가 가능해지는 이유가 아마 이 기능일 듯함
    적절한 자격 증명이 있으면 다른 사용자가 소유한 Screen 세션에 붙을 수 있고, 이 기능은 Screen이 setuid-root로 설치된 경우에만 가능하다고 함
    그래서 tmux도 같은 종류의 취약점에 영향을 받는지 궁금해짐

    • tmux는 Unix 도메인 소켓을 쓰기 때문에 해당되지 않음
      screen이 왜 여기서 setuid 방식을 택했는지는 모르겠고, root 권한이 전혀 필요 없어 보임
      글 아래쪽을 보면 현재 screen 개발자들이 코드베이스에 완전히 익숙하지 않다는 그럴듯한 설명이 나오는데, 그렇다면 기능을 동작시키기 위한 가장 쉬운 방법이 setuid-root였을 가능성이 있음
    • 꽤 훌륭한 기능임
      교육 세션에서 학생마다 내 노트북에 로그인 계정을 주고, SSH 셸을 screen -x로 제한한 뒤 screen의 접근 제어 목록으로 각 학생이 자기 창만 쓰게 한 적이 있음
      실습 중에는 내가 screen 소유자로서 각 학생의 화면을 프로젝터에 띄워 반 전체가 결과를 볼 수 있었음
      보안 구멍이 많다고 해도 놀랍지는 않음
    • 맞음, screen -x

  • Debian에서는 GNU screen이 setuid-root 권한으로 설치되지 않음

    • Debian Stable, 즉 bookworm의 패키지는 너무 오래돼서 5.0.0 취약점의 영향을 받지 않음
      예전에는 Debian이 늘 소프트웨어 버전이 뒤처지는 게 싫었지만, 이제는 브라우저처럼 정말 오래된 소프트웨어에 의존하고 싶지 않은 몇몇 앱만 다른 패키지 소스를 쓰고 나머지는 오래된 패키지로 잘 지내는 중임
    • Slackware 15에서는 /usr/bin/screen이 screen-4.9.0을 가리키고, 실행 파일도 suid가 아님
    • Gentoo도 마찬가지임
      다만 Gentoo에서는 utmp 그룹에 대해 SETGID가 붙어 있는데, 그 영향이 무엇인지는 잘 모르겠음
    • Fedora에서는 setuid-root로 보임

  • 렌더링된 블로그 글은 여기 있음: https://security.opensuse.org/2025/05/12/screen-security-iss...

  • GNU Screen 작성자에게 파일 로깅 기능 문서가 제대로 없다고 이메일을 보낸 적이 있음: http://www.zoobab.com/screenrc
    GNU에는 더 나은 이슈 추적 시스템이 필요함

    • Tmux 작성자와의 Q&A가 있었는데, 약 16년 전에도 문서 부족을 불평하고 있었음
      https://undeadly.org/cgi?action=article&sid=20090712190402
    • GNU screen 매뉴얼에 자세히 문서화되어 있음: https://www.gnu.org/software/screen/manual/screen.html#Log
    • 오래된 프로젝트 상당수는 이슈가 색인되지 않은 메일링 리스트의 끝없는 깊이에 묻혀버리는 문제가 있음
      Discord가 이런 정보를 접근 불가능하게 만든다고 비판받는 건 타당하지만, 일부 프로젝트가 아직 쓰는 IRC는 사실상 그보다 두 배는 더 나쁨
      이런 프로젝트들이 Gitea, Forgejo, Codeberg, GitLab, GitHub 같은 곳으로 옮겨서 관련 내용을 한데 모으고 발견 가능성을 확보했으면 좋겠음

  • Zellij는 screen과 tmux의 현대적인 대안으로 꽤 좋고, 기본값도 훌륭하며 UI를 쉽게 발견할 수 있게 잘 만들어졌음
    터미널 멀티플렉서의 노력 대비 효용이 애매하다고 느꼈던 사람에게 추천함
    https://zellij.dev
    https://github.com/zellij-org/zellij

    • 몇 년 전에 써봤는데 꽤 매끈했음
      하지만 tmux에 비해 지연 시간이 눈에 띄었고, 지금도 tmux를 계속 쓰고 있음
      당시 이미 지연이 있는 연결을 쓰고 있어서 내가 좀 민감했던 면도 있음
    • 마지막으로 Zellij를 봤을 때 멀티플렉서 생태계의 훌륭한 새 프로젝트처럼 보였지만, 순수하게 키보드 기반 복사/붙여넣기 메커니즘을 지원하지 않았음
      그 기능을 아주 많이 쓰기 때문에 없이는 못 쓰고, 추가되기 전까지는 tmux를 쓸 수밖에 없음
    • 좋긴 한데, screen을 정말 좋아하고 명령들이 이미 근육 기억에 박혀 있음
      20년 넘게 써왔음

  • 업스트림이 여기에 관여했다는 게 놀라움
    5년쯤 전에 GNU screen 개발이 완전히 멈췄다고 슬프게 결론 내렸는데, 아직도 그렇지는 않은 건지 궁금함
    screen에는 아직도 기존 screen에 붙지 않고 새 창을 추가하는 기능이 있는지 모르겠음

    • 업스트림이 SUSE 팀에 살펴봐 달라고 요청했음
      개발 인력이 부족하고, 업스트림이 제대로 유지보수할 전문성이 없을 수도 있어 보임
      사실이라면 슬픈 일임. tmux와 다른 대안이 있다는 건 알지만, 많은 사람이 Screen을 아주 오랫동안 써왔고 도구가 서서히 썩어가는 건 안타까움
    • 업스트림과의 소통이 어려워서 그쪽에서 낸 버그 수정과 릴리스에 대한 상세 정보를 현재 갖고 있지 않다고 되어 있음
      보안 검토를 요청하긴 했지만 계속 연락을 유지하기 어려웠던 듯하고, 전체 사정은 잘 모르겠음
    • 관여라고 해도 setuid-root로 배포했다는 정도임
      이렇게 설정한 배포판은 취약하고, 그렇지 않은 배포판은 취약하지 않음
      아주 얕은 관여라고 봄. 업스트림이 너무 느리면 배포판이 패치함
    • GNU 도구 개발이 멈추는 게 반드시 슬픈 일은 아님. 물론 버그 수정은 제외하고임
      기본적으로 완성된 도구라는 신호로 받아들일 수 있음
    • 오픈소스에는 한 소프트웨어가 끝나고 이를 대체할 다른 소프트웨어가 만들어질 때 관성이 생기는 문제가 있음
      즉시 전환할 유인이 없는데, 그건 업데이트가 아니라 전환이기 때문임
      반대로 누군가 기존 소프트웨어의 상표를 사서 Audacity 때처럼 완전히 다른 것으로 바꿔버리는 것도 나쁨
      그래서 좋은 해법이 없어 보임

  • 렌더링된 버전: https://security.opensuse.org/2025/05/12/screen-security-iss...

  • tmux는 기억이 맞다면 OpenBSD 4.6부터 기본 시스템에 들어갔고 감사를 받았거나 받아온 도구임
    조금 더 안전한 대안을 원하는 사람에게 좋음

    • screen이 다시 보이는 걸 보니, 한때 tmux로 갈아탄 뒤 screen을 잊고 지냈던 때가 떠오름

  • 관찰된 동작은 적어도 2005년 이후 Screen 버전에 있었고, 그만큼 오래전부터 안티패턴이었으며 rkhunter 같은 도구도 다뤄왔음
    그래도 screen은 90년대에도 setuid root였던 것 같음

  • 가장 인기 있는 오픈소스 도구들을 실제로 몇 명의 개발자가 운영하고 있는가?
    그 도구들을 쓰는 산업에는 돈이 얼마나 많은가?

답변달기