node.js는 여러 사용자를 위한 웹 터미널 작업을 구현합니다.-JS 튜토리얼-php.cn

이번에는 다중 사용자 웹 터미널 작업을 구현하기 위한 node.js를 가져오겠습니다. 다중 사용자 웹 터미널 작업을 구현하기 위해 node.js를 사용하는 주의사항은 무엇입니까? 다음은 실제 사례입니다. .

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

연구

터미널은 일반인의 관점에서 보면 명령줄 도구와 유사하며 쉘을 실행할 수 있는 프로세스입니다. 명령줄에 일련의 명령을 입력하고 Enter를 누를 때마다 터미널 프로세스는 자식 프로세스를 분기하여 입력된 명령을 실행합니다. 터미널 프로세스는 시스템 호출 wait4()를 통해 자식 프로세스의 종료를 모니터링하고 다음을 출력합니다. 노출된 stdout을 통해 이를 수행합니다.

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

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

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

따라서 서버 측에서 노드의 네이티브 모듈을 사용하여 의사 터미널을 구현하는 것은 불가능합니다. 의사 터미널의 원리와 노드 측 구현 방향에 대한 지속적인 탐구가 필요합니다.

의사 터미널

의사 터미널은 실제 터미널이 아니라 커널이 제공하는 "서비스"입니다. 터미널 서비스는 일반적으로 세 가지 계층으로 구성됩니다.

문자 장치, 중간 수준 라인 규율 및 하위 수준 하드웨어 드라이버에 제공되는 최상위 수준 입출력 인터페이스

그중 최상위 인터페이스는 종종 (읽기, 쓰기)와 같은 시스템 호출 기능을 통해 구현되는 반면, 기본 하드웨어 드라이버는 커널에서 제공하는 의사 터미널의 마스터-슬레이브 장치 통신을 담당합니다. 라인 규율은 상대적으로 추상적으로 보이지만 실제로 기능적으로 말하면 입력 프로세스 중 인터럽트 문자(ctrl)를 처리하는 등 입력 및 출력 정보의 "처리"를 담당합니다. + c) 및 일부 백스페이스 문자(백스페이스 및 삭제) 등, 출력 개행 문자 n을 rn 등으로 변환하는 동안

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

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

posix_openpt를 사용하여 의사 터미널 마스터 장치를 엽니다. grantpt는 슬레이브 장치 Unlockpt의 권한을 설정하여 해당 슬레이브 장치를 잠금 해제하고 슬레이브 장치 이름을 가져옵니다(/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와 호환되는 forkpty의 posix 구현 및 Unix 및 기타 시스템) 마스터-슬레이브 장치를 생성한 후 자식 프로세스(setuid, setgid)에서 권한을 설정한 후 시스템 호출 pty_execvpe(execvpe의 캡슐화)를 실행하면 마스터 장치의 입력 정보는 다음과 같습니다. 여기에서 실행됩니다(sh의 경우 하위 프로세스에 의해 실행되는 파일, stdin이 수신됩니다). 상위 프로세스는 주 장치의 fd(양방향 데이터 전송을 위해 net.Socket 객체를 생성할 수 있음)와 같은 관련 객체를 노드 계층에 노출하는 동시에 libuv의 메시지 큐&baton-> 자식 프로세스가 종료될 때 트리거되는 async -> async 메시지, pty_after_waitpid 함수 실행

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

맨 아래 레이어에서 pty 모델을 구현한 후 노드 레이어에서 일부 stdio 작업을 수행해야 합니다. 의사 터미널의 주 장치는 상위 프로세스에서 시스템 호출을 실행하여 생성되고, 주 장치의 파일 디스크립터는 fd를 통해 노드 계층에 노출되므로 의사 터미널의 입력과 출력도 파이프, 파일과 같은 해당 파일 형식을 생성하기 위해 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 명령을 선택적으로 구성할 수 있고, 사용자가 서로 격리되어 있고, 사용자가 현재 상태를 인식하지 못하는 "시스템"입니다. 환경이 간단하고 배포가 쉽습니다.

가장 적합한 기술 선택은 커널 수준 격리로서 하드웨어 리소스를 최대한 활용할 수 있으며 호스트의

관련 파일

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

다음으로 단일 시스템에 대한 솔루션을 고려해야 합니다. 현재 저자는 두 가지 옵션만 생각합니다:

화이트리스트 제한 bash chroot 명령을 통해 구현된 명령 ACL은 각 사용자에 대한 시스템 사용자를 생성하고 사용자 액세스 범위를 제한합니다

우선, 명령 화이트리스트 방법을 제거해야 합니다. 우선, 다른 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가 설정한 사용자 루트 디렉터리의 하드 링크 파일을 수정할 수 있지만 삭제와 관련된 작업은 생성 등이 올바르게 수행될 수 없습니다. 원래 시스템의 디렉토리에 매핑되어 있으며 하드 링크가 해당 디렉토리에 연결할 수 없으므로 마운트를 통해 최종적으로 하드 링크가 요구 사항을 충족하지 않습니다. --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을 통해)과 통신합니다.

이 기사의 사례를 읽은 후 방법을 마스터했다고 생각합니다. 더 흥미로운 정보를 보려면 PHP 중국어 웹사이트의 다른 관련 기사를 주목하세요!