มีวิธีเปลี่ยนตัวแปรสภาพแวดล้อมของกระบวนการอื่นใน Unix หรือไม่?

ใน Unix มีวิธีใดบ้างที่กระบวนการหนึ่งสามารถเปลี่ยนแปลงตัวแปรสภาพแวดล้อมของอีกกระบวนการหนึ่ง (สมมติว่าพวกเขาทั้งหมดถูกเรียกใช้โดยผู้ใช้คนเดียวกัน) วิธีแก้ปัญหาทั่วไปจะดีที่สุด แต่ถ้าไม่แล้วกรณีเฉพาะที่คนหนึ่งเป็นลูกของอีกฝ่ายล่ะ?

แก้ไข: แล้วทาง gdb ล่ะ

ผ่าน gdb:

(gdb) attach process_id

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

(gdb) detach

นี่เป็นการแฮ็กที่ค่อนข้างน่ารังเกียจและควรทำในบริบทของสถานการณ์การดีบักเท่านั้น

คุณอาจทำได้ในทางเทคนิค (ดูคำตอบอื่น ๆ ) แต่อาจไม่ช่วยคุณ

โปรแกรมส่วนใหญ่จะคาดหวังว่า env vars ไม่สามารถเปลี่ยนแปลงได้จากภายนอกหลังจากเริ่มต้นดังนั้นส่วนใหญ่อาจจะอ่าน vars ที่พวกเขาสนใจเมื่อเริ่มต้นและเริ่มต้นตามนั้น ดังนั้นการเปลี่ยนหลังจากนั้นจะไม่สร้างความแตกต่างเนื่องจากโปรแกรมจะไม่อ่านซ้ำ

หากคุณโพสต์สิ่งนี้เป็นปัญหาที่เป็นรูปธรรมคุณควรใช้แนวทางอื่น ถ้ามันเป็นเพียงแค่ความอยากรู้: คำถามที่ดี :-)

อย่างมีสาระสำคัญไม่มี หากคุณมีสิทธิ์เพียงพอ (รูทหรือแถวนั้น) และโผล่รอบ ๆ / 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' จากนั้นคุณตั้งค่า env "LD_PRELOAD" หรือ "LD_LIBRARY_PATH" vars เพื่อให้ทั้งสองกระบวนการของคุณทำงานด้วยไลบรารีที่แชร์ของคุณที่โหลดไว้ล่วงหน้า

ด้วยวิธีนี้คุณจะสามารถควบคุมโค้ดของฟังก์ชัน 'getenv' ได้เป็นหลัก จากนั้นคุณสามารถใช้กลอุบายที่น่ารังเกียจได้ทุกประเภท 'getenv' ของคุณสามารถปรึกษาไฟล์ config ภายนอกหรือเซ็กเมนต์ SHM สำหรับค่าทางเลือกของ env vars หรือคุณสามารถค้นหา / แทนที่ regexp ตามค่าที่ร้องขอ หรือ ...

ฉันไม่สามารถนึกถึงวิธีง่ายๆในการทำเช่นนั้นสำหรับกระบวนการทำงานโดยพลการ (แม้ว่าคุณจะเป็นรูทก็ตาม) โดยย่อมาจาก dynamic linker (ld-linux.so)

หรือรับกระบวนการของคุณเพื่ออัปเดตไฟล์กำหนดค่าสำหรับกระบวนการใหม่จากนั้น:

• ทำการ kill -HUP ในกระบวนการใหม่เพื่ออ่านไฟล์กำหนดค่าที่อัพเดตหรือ
• ให้กระบวนการตรวจสอบไฟล์กำหนดค่าสำหรับการอัปเดตเป็นระยะ ๆ หากพบการเปลี่ยนแปลงให้อ่านไฟล์กำหนดค่าอีกครั้ง

ไม่เท่าที่ฉันรู้ จริงๆแล้วคุณกำลังพยายามสื่อสารจากกระบวนการหนึ่งไปยังอีกกระบวนการหนึ่งซึ่งเรียกร้องให้ใช้วิธีใดวิธีหนึ่งของ IPC (หน่วยความจำที่ใช้ร่วมกันเซมาโฟร์ซ็อกเก็ต ฯลฯ ) เมื่อได้รับข้อมูลโดยวิธีใดวิธีหนึ่งเหล่านี้คุณสามารถตั้งค่าตัวแปรสภาพแวดล้อมหรือดำเนินการอื่น ๆ ได้โดยตรงมากขึ้น

ดูเหมือนว่าputenvจะไม่ทำงานในตอนนี้ แต่setenvทำ ฉันกำลังทดสอบคำตอบที่ยอมรับในขณะที่พยายามตั้งค่าตัวแปรในเชลล์ปัจจุบันโดยไม่ประสบความสำเร็จ

$] sudo gdb -p $$
(gdb) call putenv("TEST=1234")
$1 = 0
(gdb) call (char*) getenv("TEST")
$2 = 0x0
(gdb) detach
(gdb) quit
$] echo "TEST=$TEST"
TEST=

และตัวแปรวิธีการทำงาน:

$] sudo gdb -p $$
(gdb) call (int) setenv("TEST", "1234", 1)
$1 = 0
(gdb) call (char*) getenv("TEST")
$2 = 0x55f19ff5edc0 "1234"
(gdb) detach
(gdb) quit
$] echo "TEST=$TEST"
TEST=1234

หาก unix ของคุณรองรับระบบไฟล์ / proc การอ่าน env ก็เป็นเรื่องเล็กน้อย - คุณสามารถอ่านสภาพแวดล้อม commandline และคุณลักษณะอื่น ๆ ของกระบวนการที่คุณเป็นเจ้าของด้วยวิธีนั้น การเปลี่ยนมัน ... ฉันคิดวิธีได้ แต่มันเป็นความคิดที่ไม่ดี

กรณีทั่วไป ... ฉันไม่รู้ แต่ฉันสงสัยว่ามีคำตอบแบบพกพา

(แก้ไข: คำตอบเดิมของฉันถือว่า OP ต้องการอ่าน env ไม่เปลี่ยนแปลง)

UNIX เต็มไปด้วยการสื่อสารระหว่างกระบวนการ ตรวจสอบว่าอินสแตนซ์เป้าหมายของคุณมีบ้างไหม Dbus กำลังกลายเป็นมาตรฐานใน IPC "เดสก์ท็อป"

ฉันเปลี่ยนตัวแปรสภาพแวดล้อมภายในตัวจัดการหน้าต่าง Awesome โดยใช้ไคลเอนต์ที่น่ากลัวด้วยคือ Dbus "ผู้ส่ง" ของรหัส lua

ไม่ใช่คำตอบโดยตรง แต่ ... Raymond Chen มีเหตุผล [ที่ใช้ Windows] ในวันอื่น ๆ เท่านั้น : -

... แม้ว่าจะมีวิธีที่ไม่ได้รับการสนับสนุนอย่างแน่นอนในการดำเนินการหรือวิธีที่ทำงานร่วมกับความช่วยเหลือของดีบักเกอร์ แต่ก็ไม่มีสิ่งใดที่ได้รับการสนับสนุนสำหรับการเข้าถึงแบบเป็นโปรแกรมไปยังบรรทัดคำสั่งของกระบวนการอื่นอย่างน้อยก็ไม่มีอะไรมาจากเคอร์เนล ...

นั่นไม่ได้เป็นผลมาจากหลักการของการไม่ติดตามข้อมูลที่คุณไม่ต้องการ เคอร์เนลไม่จำเป็นต้องขอรับบรรทัดคำสั่งของกระบวนการอื่น ใช้บรรทัดคำสั่งส่งผ่านไปยังCreateProcessฟังก์ชันและคัดลอกลงในพื้นที่แอดเดรสของกระบวนการที่กำลังเรียกใช้ในตำแหน่งที่GetCommandLineฟังก์ชันสามารถดึงข้อมูลได้ เมื่อกระบวนการสามารถเข้าถึงบรรทัดคำสั่งของตัวเองได้ความรับผิดชอบของเคอร์เนลจะเสร็จสิ้น

เนื่องจากบรรทัดคำสั่งถูกคัดลอกไปยังพื้นที่แอดเดรสของกระบวนการกระบวนการอาจเขียนไปยังหน่วยความจำที่เก็บบรรทัดคำสั่งและแก้ไขได้ หากเป็นเช่นนั้นบรรทัดคำสั่งเดิมจะหายไปตลอดกาล สำเนาเดียวที่รู้จักถูกเขียนทับ

กล่าวอีกนัยหนึ่งสิ่งอำนวยความสะดวกเคอร์เนลดังกล่าวจะเป็น

• ใช้งานยาก
• อาจเป็นปัญหาด้านความปลอดภัย

อย่างไรก็ตามสาเหตุที่เป็นไปได้มากที่สุดก็คือมีกรณีการใช้งานที่ จำกัด สำหรับสถานที่ดังกล่าว