Существует ли способ изменить переменные среды другого процесса в Unix?
Указатель NULL - это тот, который указывает на никуда. Когда вы разыскиваете указатель p, вы говорите «дайте мне данные в месте, хранящемся в« p ». Когда p является нулевым указателем, местоположение, хранящееся в p, является nowhere, вы говорите «Дайте мне данные в месте« нигде ». Очевидно, он не может этого сделать, поэтому он выбрасывает NULL pointer exception.
В общем, это потому, что что-то не было правильно инициализировано.
9 ответов
Через gdb:
(gdb) attach process_id
(gdb) call putenv ("env_var_name=env_var_value")
(gdb) detach
Это - вполне противный взлом и должно только быть сделано в контексте сценария отладки, конечно.
Вероятно, можно сделать это технически (см. другие ответы), но это не могло бы помочь Вам.
Большинство программ будет ожидать, что огибающий Вар не может быть изменен с внешней стороны после запуска, следовательно большинство, вероятно, просто считает Вар, которым они интересуются при запуске и инициализируют на основе этого. Так изменение их впоследствии не будет иметь значения, так как программа никогда не будет перечитывать их.
при регистрации этого как конкретной проблемы необходимо, вероятно, проявить другой подход. Если это было только вне любопытства: Деликатный вопрос:-).
Существенно, нет. Если Вы имели необходимые полномочия (корень, или поблизости) и ввели по абсолютному адресу вокруг/dev/kmem (память ядра), и Вы внесли изменения в среду процесса, и если процесс на самом деле повторно сослался на переменную среды впоследствии (то есть, процесс уже не сделал копию огибающего var и не использовал просто, что копия), то, возможно, если Вы были удачливы и умны, и ветер, дул в правильном направлении и фазе луны, было корректно, возможно, Вы могли бы достигнуть чего-то.
Заключение в кавычки Jerry Peek:
Вы не можете преподавать старой собаке новые приемы.
единственная вещь, которую можно сделать, состоит в том, чтобы изменить переменную среды дочернего процесса прежде запуск его: это получает копию родительской среды, извините.
См. http://www.unix.com.ua/orelly/unix/upt/ch06_02.htm для деталей.
Просто комментарий к ответу об использовании/proc. В соответствии с Linux поддерживается/proc, но, это не работает, Вы не можете изменяться /proc/${pid}/environ файл, даже если Вы - корень: это абсолютно только для чтения.
Я мог думать о скорее изобретенном способе сделать это, и он не будет работать на произвольные процессы.
предположим, что Вы пишете свою собственную общую библиотеку, которая реализует 'символ *getenv'. Затем Вы настраиваете 'LD_PRELOAD' или огибающий Вар 'LD_LIBRARY_PATH' так, чтобы оба Ваших процесса были выполнены с Вашей общей предварительно загруженной библиотекой.
Таким образом, Вы будете по существу иметь контроль над кодом функции 'getenv'. Затем Вы могли сделать все виды противных приемов. Ваш 'getenv' мог консультироваться с внешним файлом конфигурации или сегментом SHM для альтернативных значений огибающего Вара. Или Вы могли сделать поиск/замену regexp на требуемых значениях. Или...
я не могу думать о простом способе сделать это для произвольных рабочих процессов (даже если Вы - корень), за исключением перезаписи динамического компоновщика (ld-linux.so).
Или заставьте свой процесс обновлять файл конфигурации для нового процесса и затем также:
- работают, уничтожение - ПОНУКАЮТ на новом процессе для перечитывания обновленного файла конфигурации, или
- имеют проверку процесса файл конфигурации для обновлений время от времени. Если изменения найдены, то перечитанными файл конфигурации.
Если Ваш Unix поддерживает/proc файловую систему, то это тривиально для ЧТЕНИЯ ENV - можно считать среду, командную строку и много других атрибутов любого процесса, Вы владеете тем путем. Изменение его... Ну, я могу думать о пути, но это - ПЛОХАЯ идея.
более общий случай... Я не знаю, но я сомневаюсь, что существует портативный ответ.
(Отредактированный: мой исходный ответ предположил, что OP хотел СЧИТАТЬ ENV, не изменить его)
Не, насколько я знаю. Действительно Вы пытаетесь связаться от одного процесса до другого, который призывает к одному из методов IPC (общая память, семафоры, сокеты, и т.д.). Получив данные одним из этих методов Вы могли тогда установить переменные среды или выполнить другие действия более непосредственно.
Не прямой ответ, но... у Raymond Chen было объяснение [на базе Windows] вокруг этого только на днях :-
... Хотя существуют, конечно, неподдерживаемые способы сделать его или пути, которые работают с помощью отладчика, there’s ничто, что поддерживается для программного доступа к другой process’s командной строке, по крайней мере ничему обеспеченному ядром....
, Что там isn’t является последствием принципа не отслеживания информации который Вы потребность don’t. Ядро не имеет никакой потребности получить командную строку другого процесса. Это берет командную строку, передал эти
CreateProcessфункция и копирует его в адресное пространство запускаемого процесса, в месте, где этиGetCommandLineфункция может получить его. Как только процесс может получить доступ к своей собственной командной строке, kernel’s обязанности сделаны., Так как командная строка копируется в process’s адресное пространство, процесс мог бы даже записать в память, которая содержит командную строку, и измените его. Если это происходит, то исходная командная строка потеряна навсегда; единственная известная копия была перезаписана.
, Другими словами, любые такие средства ядра были бы
- трудные реализовать
- потенциально проблема безопасности
Однако, наиболее вероятная причина состоит просто в том, что там ограничил варианты использования для такого средства.