sudo proxychains vs. proxychains sudo: რატომ აქვს რიგითობას მნიშვნელობა
გაიგეთ, რატომ შეიძლება proxychains sudo-მ დაკარგოს ჩარევის ბიბლიოთეკა, მაშინ როცა sudo proxychains გარსს სამიზნე შესრულების კონტექსტში იწყებს.
ამ ბრძანებებს შესრულების ერთი და იგივე საზღვარი არ აქვთ:
proxychains4 sudo command
sudo proxychains4 command
Proxychains-ng უზრუნველყოფს ბიბლიოთეკის წინასწარ ჩატვირთვას სამიზნე პროგრამაში. Linux-ში sudo-ს მსგავსი set-user-ID პროგრამის გაშვება ააქტიურებს ჩამტვირთველის უსაფრთხოების წესებს, რომლებიც შესაბამისი ბიბლიოთეკის ჩატვირთვის ცვლადებს შლიან მანამ, სანამ sudo შეძლებს მათ შენარჩუნებას.
შესაბამისად, „მეტი გარემოს შენარჩუნება" საიმედო გამოსწორება არ არის sudo-ს გარსის შიგნით მოსათავსებლად. sudoers-ის სახელმძღვანელო პირდაპირ აღწერს, რომ LD_*-ის მსგავსი ცვლადები sudo-ს დაწყებამდე იშლება.
თუ ბრძანებას ნამდვილად სჭირდება სამიზნე ანგარიში, გაუშვით გარსი სწორედ ამ ნებადართულ კონტექსტში. შემდეგ შეამოწმეთ, რომელ კონფიგურაციას კითხულობს: sudo-მ შეიძლება შეცვალოს HOME, PATH და მოქმედი მომხმარებლის ფაილი. წარმატებული არაპრივილეგირებული გამოძახება არ ამტკიცებს, რომ root-მა იგივე პროქსი-სია აირჩია.
უპირატესობა მიანიჭეთ პროგრამის საკუთარ პროქსი-ინტერფეისს, თუ ისეთს გვთავაზობს. ეს თავიდან გაგაშორებთ ჩარევაზე დამოკიდებულებას იმ მოთხოვნისთვის, რომლის მარშრუტიზაციაც პროგრამამ უკვე იცის.
ასევე გაითვალისწინეთ proxychains-ის დაფარვის საზღვრები. მისი გაშვების შეტყობინება ამტკიცებს, რომ გარსი დაიწყო; ის არ ამტკიცებს, რომ ნედლ პაკეტებს, მხარდაუჭერელ გამოძახებებს ან ცალკე გაშვებულ არსებულ აპლიკაციის პროცესს მისი ბიბლიოთეკა გამოუყენებია. დაადასტურეთ ის ქსელური ოპერაცია, რომლის ჩარევაც გსურდათ, ნაცვლად იმისა, რომ root-ის პრივილეგია ყოველი ოპერაციის ჩარევის მტკიცებულებად მიიჩნიოთ.