मुझे एक setuid-root सी प्रोग्राम के भीतर setuid (0) की आवश्यकता क्यों है जो सिस्टम() के साथ एक व्यवस्थापकीय प्रोग्राम को कॉल करता है?

Question

मुझे किसी के लिए एक गंदे लिनक्स हैक करना था ताकि वे गैर-रूट उपयोगकर्ता होने पर cupsenable printername शेल कमांड के साथ प्रिंटर प्रारंभ कर सकें। मैं नहीं चाहता था कि वे रूट के रूप में cupsenable सिंटैक्स की पूरी तरह से उपयोग करने में सक्षम हों, इसलिए मैंने अभी एक सी रैपर लिखा है जो argv[1] में इनपुट को स्वच्छ करता है और system("cupsenable sanitizedprintername") पर कॉल करता है।

मैंने प्रोग्राम सेटूइड रूट बनाया है, लेकिन फिर भी, cupsenable "अनुमति अस्वीकार" के साथ विफल रहा। फिर मैंने से पहले setuid(0) कॉल डाला और, लो और देखो, यह काम किया।

उपयोगकर्ताओं को प्रिंटर पर नियंत्रण देने का एक बेहतर तरीका होने के मुद्दे को अनदेखा करें। शायद एक बेहतर तरीका है। क्या मैं में दिलचस्पी रखता हूँ chmod u+s बनाम setuid(0) बनाम system() की पेचीदगियों को कर रहे हैं। यह इस तरह से व्यवहार क्यों किया?

Answer 1

man system से

:

सेट उपयोगकर्ता के आईडी या सेट-समूह-आईडी विशेषाधिकारों के साथ एक कार्यक्रम से system() का उपयोग न करें, क्योंकि कुछ वातावरण चर के लिए अजीब मूल्य प्रणाली अखंडता को नष्ट करने का इस्तेमाल किया जा सकता है। इसके बजाए exec(3) फ़ंक्शन के परिवार का उपयोग करें, लेकिन execlp(3) या execvp(3) नहीं। system() वास्तव में, सिस्टम-सेट-उपयोगकर्ता-आईडी या सेट-समूह-आईडी विशेषाधिकारों के साथ प्रोग्राम से ठीक से काम नहीं करेगा, जिस पर /bin/sh बैश संस्करण 2 है, क्योंकि स्टार्टअप पर बैश 2 ड्रॉप विशेषाधिकार है।

और man bash से:

खोल प्रभावी उपयोगकर्ता (समूह) आईडी वास्तविक उपयोगकर्ता (समूह) आईडी, और -p विकल्प के बराबर नहीं के साथ शुरू किया गया है, तो नहीं दिया जाता है, कोई स्टार्टअप फाइलें पढ़ी जाती हैं, शेल फ़ंक्शंस को पर्यावरण से विरासत में नहीं मिला है, SHELLOPTS वैरिएबल, यदि यह पर्यावरण में दिखाई देता है, तो अनदेखा किया जाता है, और प्रभावी उपयोगकर्ता आईडी वास्तविक उपयोगकर्ता आईडी पर सेट होती है।

ऐसा लगता है कि आपकी setuid(0) कॉल उस सुरक्षा को बाधित करती है।