PrivateTmp: hook เขียนไฟล์แล้ว แต่มันหายไปไหน

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

ไดเรกทอรีชั่วคราวสองแห่ง หนึ่งเส้นทาง

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

นี่คือปัญหาการมองเห็น และดูเหมือนปัญหาข้อมูลสูญหาย ไม่มีอะไรถูกลบ เพราะไฟล์อยู่ในเนมสเปซที่เชลล์ไม่ได้เป็นสมาชิก คำสั่งเดิมทำงานต่างออกไปเมื่อรันภายในยูนิต และการสังเกตนั้นมักตัดสินข้อโต้แย้ง อ่านการตั้งค่าของยูนิตก่อนสรุปอะไรเกี่ยวกับการเขียน

แยกสิ่งที่มองไม่เห็นออกจากสิ่งที่เขียนไม่ได้

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

systemctl show [email protected] -p PrivateTmp -p User -p Group -p RuntimeDirectory
systemctl show [email protected] -p MainPID --value
sudo ls -l /proc/PID/root/tmp/client-state

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

ให้ตำแหน่งที่ชัดเจนกับข้อมูลที่แชร์

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

[Service]
RuntimeDirectory=openvpn-hook-office
RuntimeDirectoryMode=0750

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

เก็บไดเรกทอรีรันไทม์ใดก็ตามที่ยูนิตที่ติดตั้งต้องการอยู่แล้ว การแทนที่รายการแทนการเพิ่มเข้าไปเป็นวิธีที่พบบ่อยในการทำฟีเจอร์ที่ไม่เกี่ยวข้องพัง ซึ่งไม่มีใครเชื่อมโยงกับการเปลี่ยนแปลง

ชั้นสิทธิ์สองชั้นอาจไม่ตรงกัน

ตัวจัดการบริการสร้างไดเรกทอรีให้ผู้ใช้ที่กำหนดของยูนิต ขณะที่เดมอน VPN อาจลงไปยังบัญชีของตัวเองแยกต่างหากก่อนรันฮุกการเชื่อมต่อ สิ่งเหล่านี้เป็นชั้นที่ต่างกัน และอาจระบุตัวตนที่ต่างกัน

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

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

ตรวจสอบการส่งต่อทั้งหมด

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

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