ทำไม sudo -i ไม่ได้ตั้ง XDG_RUNTIME_DIR สำหรับผู้ใช้เป้าหมาย?

XDG_RUNTIME_DIRจำเป็นสำหรับsystemctl --userการทำงาน

ฉันได้เซ็ตอัพเซิร์ฟเวอร์ Ubuntu 16.04 เพื่อเรียกใช้เซสชันผู้ใช้ systemd ตอนนี้เมื่อพยายามที่จะจัดการพวกเขาฉันพบว่าเมื่อเปลี่ยนผู้ใช้ผ่านsudo -u $user -iหรือแม้กระทั่งsu - $userสภาพแวดล้อมไม่ได้XDG_RUNTIME_DIRตั้งค่าการป้องกันsystemctl --userจากการทำงาน อย่างไรก็ตามเมื่อฉันsshเข้าสู่ผู้ใช้นั้นจะถูกตั้งค่าอย่างถูกต้อง

หากฉันเข้าใจเอกสารอย่างถูกต้องควรตั้งค่านี้libpam-systemdเมื่อสร้างเซสชันผู้ใช้ ชิ้นส่วนของผู้ใช้เริ่มต้นอย่างถูกต้องเนื่องจากมีไดเรกทอรีที่XDG_RUNTIME_DIRควรชี้ ( /run/users/$uid) อยู่ ฉันลังเลที่จะใส่รหัสลงใน.bash_profileเพราะว่าดูเหมือนว่าแฮ็ก (แม้ว่าจะใช้งานได้) เมื่อแพมควรดูแลมัน

ฉันสามารถของหลักสูตรเพิ่มXDG_RUNTIME_DIRไปenv_keepในsudoersแต่ที่เพิ่งจะรักษาสภาพแวดล้อมของผู้ sudoing ซึ่งไม่ได้เป็นสิ่งที่ฉันต้องการ ฉันต้องการสภาพแวดล้อมของผู้ใช้เป้าหมาย

สิ่งที่ฉันสงสัยจริงๆคือทำไมเซสชั่นนี้ถูกตั้งค่าอย่างถูกต้องด้วยsshแต่ไม่ใช่suหรือsudo -i?

ฉันจำลองปัญหานี้ในระบบ Fedora 25 ของฉันแล้ว

ฉันพบเงื่อนไขที่น่าสงสัยมากในซอร์สโค้ด https://github.com/systemd/systemd/blob/f97b34a/src/login/pam_systemd.c#L439 มันดูราวกับว่ามันเป็นหนังสือที่เขียนด้วยตามปกติsudoในใจ sudo -u non-root-userแต่ไม่

machinectl shell --uid=non-root-user ทำงานตามที่คุณร้องขอ

systemd-run ดูเหมือนจะไม่ทำงานตามที่ต้องการแม้จะมีการอ้างอิงถึงในเอกสารประกอบการใช้งาน

บางคำสั่ง machinectl ไม่ทำงานถ้าคุณได้เปิดใช้งาน SELinux setenforce 0ในขณะนี้และคำสั่งเฉพาะเหล่านี้ไม่ได้ทำงานสำหรับฉันจนกว่าฉันจะทำ อย่างไรก็ตามฉันกำลังพยายามหาวิธีแก้ปัญหาเพื่อให้ machinectl ทำงานตามที่ฉันต้องการให้ wrt SELinux ดังนั้นจึงเป็นไปได้ว่าการเล่นซอของฉันเป็นสาเหตุที่ทำให้เกิดmachinectl shellการหมดเวลา

แก้ไข: ฉันคิดว่ารหัสนี้ถูกนำมาใช้หลังจากการสนทนานี้ เห็นได้ชัดว่าsu -/ sudo -iอาจจะทำให้การทำงาน แต่ไม่มีใครได้ใช้มัน (ยัง)

สิ่งที่ฉันสงสัยจริงๆคือทำไมเซสชั่นนั้นถูกตั้งค่าอย่างถูกต้องด้วย ssh แต่ไม่ใช่กับ su หรือ sudo -i?

https://github.com/systemd/systemd/issues/7451#issuecomment-346787237

ขออภัย แต่ "su" เป็นเครื่องมือสำหรับเปลี่ยนข้อมูลประจำตัวผู้ใช้และข้อมูลรับรองกระบวนการอื่น ๆ เพียงเล็กน้อยชั่วคราว ไม่ใช่เครื่องมือสำหรับเปิดเซสชันการเข้าสู่ระบบใหม่ทั้งหมด เซสชันการเข้าสู่ระบบใหม่มีการตั้งค่าที่ชัดเจนและเก่าแก่ไม่ได้สืบทอดสิ่งใดจากเซสชันอื่นใด ๆ แต่นี่ไม่ใช่กรณีของการเปลี่ยนแปลง "su" uid จริง ๆ : สภาพแวดล้อมการดำเนินการส่วนใหญ่สืบทอดมาในหลาย ๆ อย่างและไม่ชัดเจน วิธี, ตัวอย่างเช่นบริบท MAC, บริบทการตรวจสอบ, บริบทของ cgroup, บริบทของเนมสเปซ, การตั้งเวลา, ความละเอียดของตัวจับเวลา, ...

หากคุณต้องการเซสชั่นใหม่ให้ใช้ "machinectl login" หรือ "machinectl shell" ซึ่งจะทำให้คุณได้รับสภาพแวดล้อมที่สะอาดเป็นอิสระและแยกออกจากกันโดยไม่มีคุณสมบัติกระบวนการที่ซ่อนอยู่ซึ่งคุณเรียกมันว่า

logind session ส่วนใหญ่จะเกี่ยวข้องกับแนวคิดเซสชันการตรวจสอบและเซสชันการตรวจสอบยังคงไม่ได้รับผลกระทบจาก "su" ในความเป็นจริงพวกเขาถูกกำหนดให้เป็น "ถูกปิด" เช่นในวิธีที่ถ้ากระบวนการเข้าสู่เซสชันหนึ่งครั้ง กับมันและเช่นนั้นลูก ๆ ของมันจะเป็นวิธีเดียวที่จะได้รับเซสชันใหม่โดยการปิดบางสิ่งบางอย่างออกจาก PID 1 (หรือบางอย่างที่คล้ายกัน) ที่ไม่เคยเป็นส่วนหนึ่งของเซสชัน

หรือจะพูดแบบนี้แตกต่างกัน: สิ่งที่คุณเรียกใช้ผ่าน "su" จะปรากฏขึ้นได้ดีใน "loginctl" แต่มันยังคงเป็นส่วนหนึ่งของเซสชั่นเดิมของคุณคุณเข้าสู่ระบบเดิม คุณสามารถตรวจสอบว่าโดยการเรียกใช้ "loginctl สถานะ" ใน ID ของเซสชั่นเดิม (ซึ่งคุณสามารถดูผ่าน echo $ XDG_SESSION_ID)