PrivateTmp: ჰუკმა ფაილი დაწერა, მაშინ სად წავიდა ის?

ჰუკები წარმატებას იუწყებიან, და იგივე გზა ჯერ კიდევ ცარიელად გამოიყურება ჭურვიდან. ორივე განცხადება ერთდროულად შეიძლება იყოს ჭეშმარიტი, რადგან systemd სერვისი შეიძლება ცხოვრობდეს საკუთარ mount სახელთა სივრცეში პირადი დროებითი დირექტორიით. როცა ეს გასაგები გახდება, საინტერესო კითხვა ხდება, საერთოდ წარმატებული იყო თუ არა ჩაწერა.

ორი დროებითი დირექტორია, ერთი გზა

იზოლაციის პარამეტრი ერთეულს დროებითი დირექტორიების პირად ხედს აძლევს, მათ მხოლოდ-წაკითხვად ქცევის ნაცვლად. ერთეულის გარეთ მყოფი პროცესები ვერ ხედავენ, რას წერს ის იქ, და ყველაფერი, რასაც ის ტოვებს, იყრება ერთეულის გაჩერებისას. ამიტომ ჰუკის მიერ დაბეჭდილი გზა და ჭურვიდან შემოწმებული გზა შეიძლება სხვადასხვა ობიექტს მიუთითებდეს იმავე სახელით.

ეს ხილვადობის პრობლემაა, და ის მონაცემთა დაკარგვის პრობლემას ჰგავს. არაფერი წაშლილა, რადგან ფაილი უბრალოდ სახელთა სივრცეშია, რომლის წევრიც ჭურვი არ არის. იგივე ბრძანება სხვაგვარად იქცევა, როცა მას ერთეულის შიგნით ასრულებენ, და სწორედ ეს დაკვირვება წყვეტს ჩვეულებრივ კამათს. წაიკითხეთ ერთეულის პარამეტრები, სანამ ჩაწერაზე რაიმეს დაასკვნით.

გამოყავით უხილავი დაუწერელისაგან

წარმატებული ჩაწერა და წარუმატებელი გახსნა სხვადასხვა მტკიცებულებას გვაძლევს, და ეს განსხვავება წყვეტს შეკეთებას. თუ ჰუკი ამბობს, რომ ფაილი შეიქმნა, მაგრამ გარე მკითხველი ვერ პოულობს მას, თქვენ სახელთა სივრცის კითხვა გაქვთ. თუ ჰუკი იუწყება ნებართვის შეცდომას ან წარუმატებელ გახსნას, ფაილი არასოდეს ჩაწერილა და სახელთა სივრცის ვერც ერთი ცვლილება ვერ დაეხმარება.

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-ის საკუთრებაში არსებული შემზღუდავი რეჟიმის დირექტორია სრულიად ხილულია დემონისთვის, რომელმაც უკვე დათმო უფლებამოსილებები, და მაინც დაუწერელია მისთვის. მაშინ შეცდომა იკითხება როგორც ნებართვის პრობლემა, თუმცა გზა ზუსტად იქ არსებობს, სადაც ელოდით. შეადარეთ დირექტორიის მფლობელი ჰუკის მიერ მითითებულ იდენტობას. როცა ისინი განსხვავდებიან, რეჟიმი არასოდეს ყოფილა კითხვა.

საკუთრების შეცვლამდე შეამოწმეთ, რომელი იდენტობით მუშაობს ჰუკი სინამდვილეში. დირექტორიის გასწორებისთვის სერვისის შესრულების მომხმარებლის შეცვლამ შეიძლება სხვაგან შეცვალოს მოწყობილობებზე წვდომა და ქსელური უფლებამოსილებები, რაც დიდი ფასია პატარა პრობლემისთვის.

შეამოწმეთ მთელი გადაცემა

ერთდროულად ოთხი რამ დაადასტურეთ: ჰუკი წერს თავისი ნამდვილი იდენტობით, განკუთვნილ მკითხველს ფაილის გამოყენება შეუძლია, უკავშირო მომხმარებლებს არ შეუძლიათ, და ერთეულის გაჩერება ასუფთავებს როგორც დაპროექტებულია. ფაილის გამოჩენა ჰოსტის საერთო დროებით დირექტორიაში მოთხოვნა არ არის, და ეს ჩვეულებრივ ნიშანია, რომ გაცვლამ არასოდეს მიიღო საკუთარი გზა. შეამოწმეთ მკითხველი გადაუშვის შემდეგ, და არა მხოლოდ პირველი გაშვების დროს. გასუფთავების ქცევა დიზაინის ნაწილია, ამიტომ დააკვირდით მას, ვიდრე ჩათვლით.

მუდმივი მდგომარეობა იმ ადგილს ეკუთვნის, სადაც სიცოცხლის ხანგრძლივობა ემთხვევა, რადგან მუშაობის დირექტორია გაქრობისთვისაა განკუთვნილი. აირჩიეთ ადგილი ხანგრძლივობის მიხედვით და არა მოხერხებულობის. ეს ჩვევა ხელს უშლის იგივე გამოძიების შემდეგ ვერსიას.