node.js를 사용하여 다중 사용자 웹 터미널 디스플레이를 구현하는 방법-JS 튜토리얼-php.cn

이 글에서는 다중 사용자 웹 터미널을 지원하는 node.js의 솔루션과 웹 터미널의 보안을 보장하는 솔루션을 주로 소개하고 참고하겠습니다.

터미널(명령줄)은 로컬 IDE의 공통 기능으로 프로젝트의 git 작업 및 파일 작업을 매우 강력하게 지원합니다. WebIDE의 경우 웹 의사 터미널이 없는 경우 캡슐화된 명령줄 인터페이스만 제공하는 것만으로는 개발자를 만족시킬 수 없습니다. 따라서 더 나은 사용자 경험을 제공하기 위해 웹 의사 터미널 개발이 시작되었습니다. 의제.

Research

우리가 아는 한 터미널은 일반 용어로 말하면 셸을 실행할 수 있는 프로세스입니다. 명령줄에 일련의 명령을 입력하고 Enter를 누를 때마다 터미널 프로세스는 자식 프로세스를 분기하여 입력된 명령을 실행합니다. 터미널 프로세스는 시스템 호출 wait4()를 통해 자식 프로세스의 종료를 모니터링하고 다음을 출력합니다. 노출된 stdout을 통해 이를 수행합니다.

웹 측에서 현지화와 유사한 터미널 기능을 구현하는 경우 네트워크 대기 시간 및 안정성 보장, 셸 사용자 경험을 현지화에 최대한 가깝게 만들고 웹 터미널 UI 너비 및 높이 조정 등 더 많은 작업이 필요할 수 있습니다. 정보 출력, 보안 접근 통제 및 권한 관리 등 웹 터미널을 구체적으로 구현하기 전에, 쉘의 기능적 구현, 사용자 경험, 보안(웹 터미널은 온라인 서버에서 제공하는 기능) 중 어떤 기능이 가장 핵심인지 평가할 필요가 있습니다. 이므로 보안이 보장되어야 합니다. 이 두 가지 기능을 보장한다는 전제 하에서만 웹 의사 터미널이 공식적으로 출시될 수 있습니다.

다음은 먼저 이 두 기능의 기술적 구현을 고려합니다(서버 측 기술은 nodejs를 사용함).

노드 네이티브 모듈은 대화형 입력 및 출력을 구현하는 데 사용할 수 있는 repl 모듈을 제공하고 탭 완성도 제공합니다. 출력 스타일 및 기타 기능을 사용자 정의하지만 노드 관련 명령만 실행할 수 있으므로 시스템 쉘 실행 목적을 달성할 수 없습니다. 노드 네이티브 모듈 child_porcess는 기본 libuv를 캡슐화하고 실행하는 uv_spawn 함수를 제공합니다. 하단 포크 및 execvp의 시스템 호출, 쉘 명령을 실행합니다. 그러나 탭 자동 완성, 과거 명령을 표시하는 화살표 키 등과 같은 의사 터미널의 다른 기능은 제공하지 않습니다.

따라서 서버는 노드의 기본 모듈을 사용하여 의사 터미널을 구현할 수 없습니다. 의사 터미널의 원리와 원리를 계속해서 탐구하는 것이 필요합니다. 노드 측의 구현 방향.

의사 터미널

의사 터미널은 실제 터미널이 아니라 커널에서 제공하는 "서비스"입니다. 터미널 서비스는 일반적으로 문자 장치에 제공되는 최상위 입력 및 출력 인터페이스, 중간 수준 회선 규율, 최하위 수준 하드웨어 드라이버의 세 가지 계층으로 구성됩니다. 그 중 최상위 인터페이스는 시스템 호출 기능을 통해 구현되는 경우가 많습니다. (읽기, 쓰기)와 같은 기본 하드웨어 드라이버는 커널에 의해 제공되는 의사 터미널의 마스터-슬레이브 장치 통신을 담당하지만 실제로는 기능적으로 다음을 담당합니다. 입력 및 출력 정보의 "처리" 예를 들어 입력 프로세스 중에 인터럽트 문자(ctrl + c) 및 일부 롤백 문자(백스페이스 및 삭제)를 처리하고 동시에 출력 개행 문자 n을 rn으로 변환합니다. 등.

의사 터미널은 마스터 장치와 슬레이브 장치의 두 부분으로 나누어지며 기본 라인 규칙을 구현하는 양방향 파이프(하드웨어 드라이버)를 통해 하단에 연결됩니다. 의사 터미널 마스터의 모든 입력은 슬레이브에 반영되며 그 반대의 경우도 마찬가지입니다. 슬레이브 장치의 출력 정보도 파이프를 통해 마스터 장치로 전송되므로 의사 터미널의 슬레이브 장치에서 쉘을 실행하여 터미널 기능을 완성할 수 있습니다.

의사 터미널의 슬레이브 장치는 터미널의 탭 완성 및 기타 셸 특수 명령을 실제로 시뮬레이션할 수 있습니다. 따라서 노드 네이티브 모듈이 요구 사항을 충족할 수 없다는 전제 하에 하위 계층에 집중하여 OS가 무엇인지 확인해야 합니다. 어떤 기능을 제공합니다. 현재 glibc 라이브러리는 posix_openpt 인터페이스를 제공하지만 프로세스가 약간 번거롭습니다.

posix_openpt를 사용하여 의사 터미널 마스터 장치를 엽니다. grantpt 슬레이브 장치의 권한을 설정합니다. Unlockpt 해당 슬레이브 장치를 잠금 해제하고 슬레이브 장치 이름을 얻습니다. to /dev/pts/123) 마스터(슬레이브) 장치 읽기, 쓰기 및 실행 작업

따라서 더 나은 캡슐화 기능을 갖춘 pty 라이브러리가 등장했으며 위의 모든 기능은 단지 forkpty 기능을 통해 달성할 수 있습니다. 노드 C++ 확장 모듈을 작성하고 pty 라이브러리를 사용하여 의사 터미널의 장치에서 명령줄을 실행하는 터미널을 구현합니다.

의사 터미널 보안 문제에 대해서는 기사 마지막 부분에서 논의하겠습니다.

의사 터미널 구현 아이디어

의사 터미널의 마스터 및 슬레이브 장치의 특성에 따라 마스터 장치가 위치한 상위 프로세스에서 의사 터미널의 수명주기 및 리소스를 관리하고, 슬레이브 장치가 위치한 자식 프로세스에서 실행하면 실행 과정 중의 정보와 결과는 양방향 파이프라인을 통해 메인 장치로 전달되고, 메인 장치가 위치한 프로세스는 stdout을 외부에 제공한다.

여기에서 pty.js 구현 아이디어를 알아보세요.

pid_t pid = pty_forkpty(&master, name, NULL, &winp);

 switch (pid) {
 case -1:
  return Nan::ThrowError("forkpty(3) failed.");
 case 0:
  if (strlen(cwd)) chdir(cwd);

  if (uid != -1 && gid != -1) {
  if (setgid(gid) == -1) {
   perror("setgid(2) failed.");
   _exit(1);
  }
  if (setuid(uid) == -1) {
   perror("setuid(2) failed.");
   _exit(1);
  }
  }

  pty_execvpe(argv[0], argv, env);

  perror("execvp(3) failed.");
  _exit(1);
 default:
  if (pty_nonblock(master) == -1) {
  return Nan::ThrowError("Could not set master fd to nonblocking.");
  }

  Local<Object> obj = Nan::New<Object>();
  Nan::Set(obj,
  Nan::New<String>("fd").ToLocalChecked(),
  Nan::New<Number>(master));
  Nan::Set(obj,
  Nan::New<String>("pid").ToLocalChecked(),
  Nan::New<Number>(pid));
  Nan::Set(obj,
  Nan::New<String>("pty").ToLocalChecked(),
  Nan::New<String>(name).ToLocalChecked());

  pty_baton *baton = new pty_baton();
  baton->exit_code = 0;
  baton->signal_code = 0;
  baton->cb.Reset(Local<Function>::Cast(info[8]));
  baton->pid = pid;
  baton->async.data = baton;

  uv_async_init(uv_default_loop(), &baton->async, pty_after_waitpid);

  uv_thread_create(&baton->tid, pty_waitpid, static_cast<void*>(baton));

  return info.GetReturnValue().Set(obj);
 }

로그인 후 복사

먼저 pty_forkpty(sunOS 및 unix와 같은 시스템과 호환되는 forkpty의 posix 구현)를 통해 마스터-슬레이브 장치를 생성한 다음 하위 프로세스에서 권한(setuid, setgid)을 설정하고 pty_execvpe 시스템 호출(execvpe 캡슐화)을 실행합니다. ), 그런 다음 마스터 장치 모든 입력 정보가 여기에서 실행됩니다(하위 프로세스에 의해 실행되는 파일은 sh이며 stdin을 수신합니다).

상위 프로세스는 관련 객체를 노드 계층에 노출합니다. 메인 장치(이 fd를 통해 net.Socket 객체가 생성될 수 있습니다. 양방향 데이터 전송), libuv의 메시지 큐 'baton->async를 등록합니다. 하위 프로세스가 종료되면 'baton->async 메시지가 트리거되고 pty_after_waitpid 함수가 실행됩니다.

마지막으로 상위 프로세스는 이전 하위 프로세스의 종료 메시지를 듣기 위해 uv_thread_create를 호출하여 하위 프로세스를 생성합니다(시스템 호출 wait4를 실행하여 특정 pid를 수신하는 프로세스를 차단하고 종료). 세 번째 매개변수에 정보가 저장됨) pty_waitpid 함수는 wait4 함수를 캡슐화함과 동시에 uv_async_send(>async 함수 끝에서) 트리거 메시지를 실행합니다.

하단 레이어에서 pty 모델을 구현한 후 노드 레이어에서 일부 stdio 작업을 수행해야 합니다. 상위 프로세스에서 시스템 호출을 실행하여 의사 터미널 주 장치가 생성되고, 주 장치의 파일 설명자가 fd를 통해 노드 계층에 노출되므로 의사 터미널의 입력과 출력도 읽고 파이프, FILE과 같은 해당 파일 형식을 생성하기 위해 fd에 따라 작성되었습니다. 실제로 OS 수준에서 의사 터미널 마스터 장치는 양방향 통신이 가능한 PIPE로 간주됩니다. 데이터 흐름의 양방향 IO를 실현하기 위해 net.Socket(fd)을 통해 노드 계층에 소켓을 생성합니다. 의사 터미널의 슬레이브 장치도 마스터 장치와 동일한 입력을 가지므로 해당 명령이 하위에서 실행됩니다. 프로세스 및 하위 프로세스의 출력도 PIPE를 통해 기본 장치에 반영된 다음 노드 계층 소켓 개체의 데이터 이벤트를 트리거합니다.

여기서 상위프로세스, 마스터디바이스, 하위프로세스, 슬레이브디바이스의 입출력에 대한 설명이 좀 헷갈려서 설명하겠습니다. 부모 프로세스와 메인 장치의 관계는 다음과 같습니다. 부모 프로세스는 시스템 호출(PIPE로 간주될 수 있음)을 통해 메인 장치를 생성하고 메인 장치의 fd를 얻습니다. 상위 프로세스는 fd의 연결 소켓을 생성하여 하위 프로세스(슬레이브 장치)에 대한 입출력을 실현합니다. forkpty를 통해 자식 프로세스가 생성된 후 login_tty 작업이 수행되고 자식 프로세스의 stdin, stderr, stderr이 재설정되고 모두 슬레이브 장치의 fd(PIPE 반대쪽)에 복사됩니다. 따라서 자식 프로세스의 입출력은 모두 슬레이브 장치의 fd와 연관되어 있으며, 자식 프로세스의 출력 데이터는 PIPE를 통해 전달되고, 부모 프로세스의 명령은 PIPE에서 읽혀집니다. 자세한 내용은 참고 문헌의 forkpty 구현을 참조하세요

또한 pty 라이브러리는 의사 터미널의 크기 설정을 제공하므로 매개 변수를 통해 의사 터미널 출력 정보의 레이아웃 정보를 조정할 수 있으므로 이 또한 제공합니다. 웹 측에서 명령줄 너비와 높이를 조정하는 기능은 pty 레이어에서 의사 터미널 창 크기를 설정하기만 하면 창이 문자로 표시됩니다.

웹 터미널 보안 보장

glibc에서 제공하는 pty 라이브러리를 기반으로 의사 터미널 배경을 구현할 때 보안 보장이 없습니다. 우리는 웹 터미널을 통해 서버의 디렉토리를 직접 운영하고 싶지만 의사 터미널 백그라운드를 통해 직접 루트 권한을 얻을 수 있습니다. 이는 서버의 보안에 직접적인 영향을 미치기 때문에 서비스에 허용되지 않습니다. is: 사용자가 동시에 온라인 상태이고, 각 사용자의 액세스 권한을 구성할 수 있고, 특정 디렉터리에 액세스할 수 있으며, bash 명령을 선택적으로 구성할 수 있고, 사용자가 서로 격리되어 있고, 사용자가 현재 상태를 인식하지 못하는 "시스템"입니다. 환경이 간단하고 배포가 쉽습니다.

가장 적합한 기술 선택은 docker입니다. 커널 수준 격리로 하드웨어 리소스를 최대한 활용할 수 있으며 호스트 관련 파일을 매핑하는 데 매우 편리합니다. 그러나 도커는 전능하지 않습니다. 프로그램이 도커 컨테이너에서 실행되면 각 사용자에게 컨테이너를 할당하는 것이 훨씬 더 복잡해지고 이를 운영 및 유지 관리 담당자의 통제를 받지 않게 됩니다. docker out of docker)--볼륨 "/usr/local/bin/docker"와 같은 바이너리 파일을 사용하고 호스트의 docker 명령을 사용하여 형제 이미지를 열어 빌드 서비스를 실행합니다. 업계, 특히 파일 시스템 수준에서 자주 논의되는 docker-in-docker 모드를 사용하는 데에는 많은 단점이 있으며 이는 참고 자료에서 확인할 수 있습니다. 따라서 Docker 기술은 이미 컨테이너에서 실행 중인 서비스에 대한 사용자 액세스 보안 문제를 해결하는 데 적합하지 않습니다.

다음 단계는 독립형 솔루션을 고려하는 것입니다. 현재 저자는 두 가지 해결책만 생각하고 있습니다.

명령 ACL, 명령 화이트리스트를 통해 제한된 bash chroot 구현, 각 사용자에 대한 시스템 사용자 생성, 사용자 액세스 범위 가두기

우선 명령 화이트리스트 방법은 다음과 같아야 합니다. 제외됨 우선, 서로 다른 Linux 릴리스의 bash가 동일하다는 보장이 없습니다. 둘째, 의사 터미널에서 제공하는 탭 명령 완성 기능과 존재로 인해 모든 명령을 효과적으로 소진하는 것이 불가능합니다. 삭제와 같은 특수 문자가 있으면 현재 입력된 명령을 효과적으로 일치시킬 수 없습니다. 따라서 화이트리스트 방식은 허점이 너무 많아 폐기해야 합니다.

/bin/bash -r에 의해 실행되는 제한된 bash는 사용자가 명시적으로 "cd 디렉터리"를 사용하지 못하도록 제한할 수 있지만 많은 단점이 있습니다.

완전히 신뢰할 수 없는 소프트웨어의 실행을 허용하기에는 충분하지 않습니다. 셸 스크립트인 것으로 확인된 명령이 실행되면 rbash는 스크립트를 실행하기 위해 셸에 생성된 모든 제한 사항을 해제합니다. 사용자가 rbash에서 bash 또는 dash를 실행하면 무제한 쉘이 제공됩니다. 쉽게 예측할 수 없는 제한된 bash 쉘에서 벗어나는 방법에는 여러 가지가 있습니다.

결국 해결책은 chroot 하나밖에 없는 것 같습니다. chroot는 사용자의 루트 디렉터리를 수정하고 지정된 루트 디렉터리에서 명령을 실행합니다. 지정된 루트 디렉터리에서 이동할 수 없으므로 원본 시스템의 모든 디렉터리에 동시에 액세스할 수 없습니다. chroot는 원본 시스템과 격리된 시스템 디렉터리 구조를 생성하므로 원본 시스템의 다양한 명령을 사용할 수 없습니다. "새 시스템"에서는 새롭고 비어 있기 때문에 여러 사용자가 사용할 때 격리되고 투명하여 우리의 요구 사항을 완전히 충족합니다.

그래서 우리는 마침내 웹 터미널 보안 솔루션으로 chroot를 선택했습니다. 그러나 chroot를 사용하려면 새 사용자 생성뿐만 아니라 명령 초기화를 포함하여 많은 추가 처리가 필요합니다. 위에서도 언급한 바와 같이 "새 시스템"은 비어 있고, "ls, pmd" 등 실행 가능한 바이너리 파일이 없으므로 "새 시스템"의 초기화가 필요합니다. 그러나 많은 바이너리 파일은 많은 라이브러리에 정적으로 링크될 뿐만 아니라 런타임 중에도 동적 링크 라이브러리(dll)에 의존하기 때문에 각 명령이 의존하는 많은 dll을 찾아야 하므로 매우 번거롭습니다. 사용자가 이 지루한 프로세스를 없애도록 돕기 위해 Jailkit이 탄생했습니다.

jailkit, 사용하기 매우 쉽습니다

jailkit은 이름에서 알 수 있듯이 사용자를 감옥에 가두는 데 사용됩니다. Jailkit은 내부적으로 chroot를 사용하여 사용자 루트 디렉터리를 생성하고 바이너리 파일과 모든 해당 dll을 초기화하고 복사하기 위한 일련의 지침을 제공합니다. 이러한 기능은 구성 파일을 통해 작동할 수 있습니다. 따라서 실제 개발에서는 파일 시스템 격리를 달성하기 위해 초기화 셸 스크립트와 함께 Jailkit을 사용합니다.

여기서 초기화 셸은 전처리 스크립트를 참조합니다. chroot는 각 사용자의 루트 디렉터리를 설정해야 하기 때문에 명령줄 권한을 사용하여 각 사용자의 셸에 해당 사용자가 생성되고 Jailkit 기본 바이너리 파일을 통해 복사됩니다. 기본 쉘 명령, git, vim, ruby 등과 같은 해당 dll은 마지막으로 특정 명령에 대해 추가 처리가 수행되고 권한이 재설정됩니다.

"새 시스템"과 원래 시스템 간의 파일 매핑을 처리하는 과정에서는 여전히 일부 기술이 필요합니다. 작성자는 chroot가 설정한 사용자 루트 디렉터리 이외의 디렉터리를 소프트링크 형태로 매핑한 적이 있는데, 감옥에 있는 소프트링크에 접속하면 여전히 오류가 보고되고 파일을 찾을 수 없었기 때문입니다. chroot의 특성은 루트 디렉터리 외부의 파일 시스템에 액세스할 수 있는 권한이 없습니다. 하드 링크를 통해 매핑이 설정된 경우 chroot가 설정한 사용자 루트 디렉터리의 하드 링크 파일을 수정할 수 있지만 삭제와 관련된 작업은 생성 등이 제대로 수행되지 않습니다. 원래 시스템의 디렉터리에 매핑되고 하드 링크가 해당 디렉터리에 연결되지 않아 최종적으로 mount --bind를 통해 구현됩니다. 예를 들어 mount --bind /home/ttt/abc /usr/local/abc는 마운트된 디렉터리(/usr/local/abc)의 디렉터리 정보(블록)로 보호되며, 마운트된 디렉터리와 디렉터리 간의 매핑 관계를 유지합니다. /usr/local/abc에 대한 액세스는 메모리를 통과합니다. 매핑 테이블은 /home/ttt/abc 블록을 쿼리한 다음 디렉터리 매핑을 달성하기 위한 작업을 수행합니다.

마지막으로 "새 시스템"을 초기화한 후 의사 터미널을 통해 감옥 관련 명령을 실행해야 합니다:

sudo jk_chrootlaunch -j /usr/local/jailuser/${creater} -u ${creater} -x /bin/ bashr

bash 프로그램을 오픈한 후, PIPE를 통해 메인 디바이스에서 받은 웹 터미널 입력(websocket을 통해)과 통신합니다.

위 내용은 제가 여러분을 위해 정리한 내용입니다. 앞으로 도움이 되길 바랍니다.