문제

UNIX에서 한 프로세스가 다른 프로세스의 환경 변수를 변경할 수있는 방법이 있습니까 (모두 같은 사용자가 실행한다고 가정)? 일반적인 해결책이 가장 좋지만 그렇지 않은 경우 하나는 다른 사람의 자녀 인 특정 사례는 어떻습니까?

편집 : GDB를 통한 것은 어떻습니까?

도움이 되었습니까?

해결책

GDB를 통해 :

(gdb) attach process_id

(gdb) call putenv ("env_var_name=env_var_value")

(gdb) detach

이것은 상당히 불쾌한 해킹이며 물론 디버깅 시나리오의 맥락에서만 이루어져야합니다.

다른 팁

기술적으로 할 수 있지만 (다른 답변 참조) 도움이되지 않을 수도 있습니다.

대부분의 프로그램은 시작 후 ENV VAR이 외부에서 변경 될 수 없을 것으로 예상되므로 대부분은 시작시에 관심이있는 VAR을 읽고이를 기반으로 초기화 할 것입니다. 따라서 프로그램이 다시 읽지 않기 때문에 나중에 변경해도 차이가되지 않습니다.

이 문제를 구체적인 문제로 게시 한 경우 다른 접근 방식을 취해야 할 것입니다. 그것이 호기심에서 벗어난다면 : 좋은 질문 :-).

실질적으로, 아니요. 충분한 권한 (루트 또는 그에 따라)가 있고 /dev /kmem (커널 메모리) 주위를 찌르고 프로세스의 환경을 변경하고 프로세스가 실제로 환경 변수를 다시 재 융자 한 경우 (즉, 프로세스. 이미 Env var의 사본을 가져 가지 않았고 그 사본 만 사용하지 않았다), 아마도 운이 좋고 영리했고 바람이 올바른 방향으로 불고 있었고 달의 단계가 정확했을 수도있다. 당신은 무언가를 성취 할 수 있습니다.

Jerry Peek 인용 :

당신은 오래된 개 새로운 트릭을 가르 칠 수 없습니다.

당신이 할 수있는 유일한 일은 아동 프로세스의 환경 변수를 변경하는 것입니다. ~ 전에 시작 : 부모 환경의 사본을 얻습니다. 죄송합니다.

보다 http://www.unix.com.ua/orelly/unix/upt/ch06_02.htm 자세한 내용은.

사용 /Proc. Linux /Proc에서는 지원되지만 작동하지 않습니다. 할 수 없습니다 변경 /proc/${pid}/environ 루트 인 경우에도 파일 : 물론 읽기 전용.

나는 그렇게하는 다소 만족스러운 방법을 생각할 수 있었고, 그것은 임의의 프로세스에서는 효과가 없을 것입니다.

'char *getenv'를 구현하는 자신의 공유 라이브러리를 작성한다고 가정 해 봅시다. 그런 다음 'ld_preload'또는 'ld_library_path'env를 설정합니다. 공유 라이브러리가 사전로드 된 상태에서 두 프로세스를 모두 실행하도록 VAR.

이런 식으로, 당신은 본질적으로 'getenv'함수의 코드를 제어 할 수 있습니다. 그런 다음 모든 종류의 불쾌한 트릭을 할 수 있습니다. 'getenv'는 ENV vars의 대체 값에 대해 외부 구성 파일 또는 SHM 세그먼트를 참조 할 수 있습니다. 또는 요청 된 값에 대해 Regexp 검색/교체를 수행 할 수 있습니다. 또는 ...

임의의 실행 프로세스 (루트 인 경우에도)을 위해 쉽게 수행 할 수있는 방법을 생각할 수 없으며 동적 링커 (LD-Linux.so)를 재 작성하지 않습니다.

또는 프로세스가 새 프로세스의 구성 파일을 업데이트 한 다음 다음 중 하나를 업데이트하십시오.

  • 새 프로세스에서 킬 -hup을 수행하여 업데이트 된 구성 파일을 다시 읽거나
  • 프로세스에 매번 구성 파일을 확인하십시오. 변경 사항이 발견되면 구성 파일을 다시 읽으십시오.

내가 아는 한 멀지 않습니다. 실제로 IPC 방법 중 하나 (공유 메모리, 세마포어, 소켓 등)를 요구하는 한 프로세스에서 다른 프로세스로 의사 소통하려고합니다. 이러한 방법 중 하나에 의해 데이터를 수신 한 다음 환경 변수를 설정하거나 다른 작업을보다 직접 수행 할 수 있습니다.

UNIX가 /Proc 파일 시스템을 지원하는 경우 ENV를 읽는 것이 중요합니다. 환경, CommandLine 및 귀하가 소유 한 모든 프로세스의 기타 여러 속성을 읽을 수 있습니다. 그것을 바꾸는 ... 글쎄, 나는 방법을 생각할 수 있지만 나쁜 생각입니다.

더 일반적인 경우 ... 모르겠지만 휴대용 답변이 의심됩니다.

(편집 : 내 원래 대답은 OP가 ENV를 읽고 싶지 않고 변경하지 않기를 원한다고 가정했습니다)

UNIX는 프로세스 간 통신으로 가득합니다. 대상 인스턴스에 일부가 있는지 확인하십시오. DBUS는 "데스크탑"IPC의 표준이되었습니다.

나는 Awesome Window Manager의 환경 변수를 사용하여 환경 변수를 변경합니다. 굉장한 클라이언트 LUA 코드의 DBUS "발신자"입니다.

직접적인 답변은 아니지만 ... Raymond Chen은 다른 날에만 [Windows 기반] 근거를 가졌습니다. :-

... 확실히 지원되지 않는 방법이나 디버거의 도움으로 작동하는 방법이 있지만 다른 프로세스의 명령 줄에 대한 프로그래밍 방식으로 지원되는 것은 없습니다. 최소한 커널에서 제공하지 않습니다. ...

필요하지 않은 정보를 추적하지 않는 원칙의 결과는 없습니다. 커널은 다른 프로세스의 명령 줄을 얻을 필요가 없습니다. 명령 줄을 전달합니다 CreateProcess 작동하고 시작되는 프로세스의 주소 공간으로 복사합니다. GetCommandLine 함수는 그것을 검색 할 수 있습니다. 프로세스가 자체 명령 줄에 액세스 할 수 있으면 커널의 책임이 수행됩니다.

명령 줄이 프로세스의 주소 공간에 복사되므로 프로세스는 명령 줄을 보유하고 수정하는 메모리에 쓸 수도 있습니다. 이런 일이 발생하면 원래 명령 줄은 영원히 손실됩니다. 알려진 유일한 사본이 덮어 쓰여졌습니다.

다시 말해, 그러한 커널 시설은

  • 구현하기 어렵습니다
  • 잠재적으로 보안 문제

그러나 가장 큰 이유는 단순히 그러한 시설에 대한 사용 사례가 제한되어 있기 때문입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top