Есть ли способ изменить переменные окружения другого процесса в Unix?

linux shell unix gdb environment-variables

32286 просмотра

10 ответа

9310 Репутация автора

В Unix, есть ли способ, которым один процесс может изменить переменные окружения другого (при условии, что все они запускаются одним и тем же пользователем)? Общее решение было бы лучше, но если нет, то как насчет конкретного случая, когда один является ребенком другого?

Редактировать: Как насчет через GDB?

Автор: raldi Источник Размещён: 15.10.2008 03:02

Ответы (10)


1 плюс

1612 Репутация автора

Если ваш unix поддерживает файловую систему / proc, то ПРОЧИТАТЬ env - вы можете прочитать окружение, командную строку и многие другие атрибуты любого процесса, которым вы владеете. Менять это ... Ну, я могу придумать способ, но это ПЛОХАЯ идея.

Более общий случай ... Я не знаю, но я сомневаюсь, что есть портативный ответ.

(Отредактировано: мой первоначальный ответ предполагал, что ОП хотел ПРОЧИТАТЬ env, а не изменить его)

Автор: Mike G. Размещён: 15.10.2008 03:05

6 плюса

11591 Репутация автора

Цитирую Джерри Пика:

Вы не можете научить старую собаку новым трюкам.

Единственное, что вы можете сделать, это изменить переменную окружения дочернего процесса перед его запуском: извините, он получает копию родительской среды.

См. Http://www.unix.com.ua/orelly/unix/upt/ch06_02.htm для получения подробной информации.

Просто комментарий к ответу об использовании / proc. Под linux / proc поддерживается, но он не работает, вы не можете изменить /proc/${pid}/environфайл, даже если вы являетесь пользователем root: он абсолютно доступен только для чтения.

Автор: Davide Размещён: 15.10.2008 03:07

2 плюса

46367 Репутация автора

Не так далеко, как я знаю. На самом деле вы пытаетесь связываться от одного процесса к другому, который вызывает один из методов IPC (разделяемая память, семафоры, сокеты и т. Д.). Получив данные одним из этих методов, вы можете установить переменные окружения или выполнить другие действия более напрямую.

Автор: Stephen Darlington Размещён: 15.10.2008 03:10

3 плюса

30366 Репутация автора

Или попросите ваш процесс обновить файл конфигурации для нового процесса, а затем либо:

  • выполнить kill -HUP для нового процесса, чтобы перечитать обновленный файл конфигурации, или
  • пусть процесс проверяет файл конфигурации на наличие обновлений время от времени. Если изменения найдены, перечитайте файл конфигурации.
Автор: Rob Wells Размещён: 15.10.2008 03:10

6 плюса

5120 Репутация автора

Я мог бы придумать довольно надуманный способ сделать это, и он не будет работать для произвольных процессов.

Предположим, что вы пишете свою собственную разделяемую библиотеку, которая реализует 'char * getenv'. Затем вы устанавливаете 'LD_PRELOAD' или 'LD_LIBRARY_PATH' env. vars, чтобы оба ваших процесса запускались с предварительно загруженной общей библиотекой.

Таким образом, вы по существу будете иметь контроль над кодом функции 'getenv'. Тогда вы могли бы сделать все виды неприятных трюков. Ваш 'getenv' может обратиться к внешнему файлу конфигурации или сегменту SHM для альтернативных значений переменных env. Или вы можете выполнить поиск / замену регулярных выражений для запрошенных значений. Или же ...

Я не могу придумать простой способ сделать это для произвольных запущенных процессов (даже если вы являетесь пользователем root), если не считать переписывания динамического компоновщика (ld-linux.so).

Автор: ADEpt Размещён: 15.10.2008 03:54

13 плюса

582538 Репутация автора

По существу, нет. Если у вас были достаточные привилегии (root или около того) и вы искали / dev / kmem (память ядра), и вы внесли изменения в среду процесса, и если после этого процесс фактически ссылался на переменную среды (то есть процесс еще не взял копию env var и не использовал только эту копию), тогда, может быть, если вам повезло и умно, и ветер дул в правильном направлении, и фаза Луны была правильной, возможно, Вы могли бы чего-то достичь.

Автор: Jonathan Leffler Размещён: 16.10.2008 05:50

124 плюса

6155 Репутация автора

Решение

Через GDB:

(gdb) attach process_id

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

(gdb) detach

Это довольно неприятный взлом, и, конечно, его следует делать только в контексте сценария отладки.

Автор: An̲̳̳drew Размещён: 17.10.2008 04:19

21 плюса

59665 Репутация автора

Вы, вероятно, можете сделать это технически (см. Другие ответы), но это может вам не помочь.

Большинство программ ожидает, что env-переменные не могут быть изменены извне после запуска, поэтому большинство, вероятно, просто прочитают интересующие их при запуске и инициализируют на основе этого. Поэтому изменение их впоследствии не будет иметь никакого значения, так как программа никогда не будет перечитывать их.

Если вы разместили это как конкретную проблему, вы, вероятно, должны использовать другой подход. Если это было просто из любопытства: Хороший вопрос :-).

Автор: sleske Размещён: 27.02.2009 09:43

1 плюс

45094 Репутация автора

Не прямой ответ, но ... У Раймонда Чена было [на основе Windows] обоснование этого только на днях :

... Хотя, безусловно, существуют неподдерживаемые способы сделать это или способы, которые работают с помощью отладчика, нет ничего, что поддерживалось бы для программного доступа к командной строке другого процесса, по крайней мере, ничего, предоставляемого ядром. ...

То, что нет, является следствием принципа не отслеживать информацию, которая вам не нужна. Ядру не нужно получать командную строку другого процесса. Он принимает командную строку, переданную CreateProcessфункции, и копирует ее в адресное пространство запускаемого процесса, в место, где GetCommandLineфункция может получить его. Как только процесс получит доступ к своей собственной командной строке, обязанности ядра будут выполнены.

Поскольку командная строка копируется в адресное пространство процесса, процесс может даже записать в память, в которой хранится командная строка, и изменить ее. Если это произойдет, то оригинальная командная строка будет потеряна навсегда; единственная известная копия была перезаписана.

Другими словами, любые такие возможности ядра будут

  • сложно реализовать
  • потенциально проблема безопасности

Однако наиболее вероятная причина заключается в том, что есть случаи ограниченного использования для такого объекта.

Автор: Ruben Bartelink Размещён: 27.02.2009 09:50

1 плюс

1095 Репутация автора

UNIX полон межпроцессного взаимодействия. Проверьте, есть ли у вашего целевого экземпляра. Dbus становится стандартом в «настольном» IPC.

Я изменяю переменные среды внутри оконного менеджера Awesome, используя awesome-client с помощью Dbus-«отправителя» кода lua.

Автор: dvd Размещён: 31.05.2011 12:52
Вопросы из категории :
32x32