मैं किसी स्क्रिप्ट के अंदर 'sudo' कमांड कैसे चला सकता हूं?


84

मैन्युअल रूप से एक पैच करने के लिए मुझे यह कमांड टाइप करना होगा

sudo ./playback_delete_data_patch.sh 09_delete_old_data_p.sql  

09 से ठीक पहले एक जगह है:

sudo ./playback_delete_data_patch.sh [space] 09_delete_old_data_p.sql

मैं इसे एक स्क्रिप्ट के अंदर कैसे चला सकता हूं?

कई अन्य कमांड भी हैं लेकिन यह एक परेशानी दे रहा है।


2
बस इसे स्क्रिप्ट में रखो, क्या समस्या है?
रेयान

6
@LieRyan - sudo पासवर्ड - यदि कोई व्यक्ति इसे दर्ज करने के लिए नहीं है, तो स्क्रिप्ट पूरी तरह से नहीं चल पाएगी।
विल्फ

मेरा सिस्टम सिर्फ उन्हें बिना संकेत दिए ठीक चलाता है। अक्टूबर 2017 में Ubuntu 16.04। आपने अपना sudoersसेटअप गड़बड़ कर दिया है । कोई बड़ी बात नहीं। इसे बस तय करने की जरूरत है।
22

1
@SDsolar आपका सिस्टम वह है जो गड़बड़ है; यह पासवर्ड के लिए संकेत नहीं करने के लिए एक मामूली सुरक्षा भेद्यता है (उपयोगकर्ताओं को कुछ प्रकार के सामाजिक इंजीनियरिंग हमलों के लिए अधिक संवेदनशील बनाता है)।
wizzwizz4

जवाबों:


107

sudoलिपियों के अंदर होना शायद ही एक अच्छा विचार है । इसके बजाय, sudoस्क्रिप्ट से निकालें और स्क्रिप्ट को स्वयं चलाएं sudo:

sudo myscript.sh

इस तरह, स्क्रिप्ट के भीतर सभी कमांड रूट विशेषाधिकारों के साथ चलेंगे और स्क्रिप्ट लॉन्च करते समय आपको केवल पासवर्ड देना होगा। यदि आपको sudoविशेषाधिकारों के बिना चलाने के लिए स्क्रिप्ट के भीतर एक विशेष कमांड की आवश्यकता है , तो आप इसे एक नियमित उपयोगकर्ता के रूप में चला सकते हैं (धन्यवाद लाइ रयान ):

sudo -u username command 

अंतरिक्ष अप्रासंगिक है, इसे कुछ भी प्रभावित नहीं करना चाहिए, हमेशा एक कमांड और उसके तर्कों के बीच एक स्थान होता है।


30
स्क्रिप्ट में ऐसे कमांड हो सकते हैं जिन्हें रूट विशेषाधिकार की आवश्यकता नहीं है, आप उन कमांड के लिए अस्थायी रूप से sudo -u यूजरनेम का उपयोग करके ड्रॉप विशेषाधिकार को छोड़ सकते हैं
रेयान

48
मेरे द्वारा लिखी गई बहुत सारी स्क्रिप्ट उपयोगकर्ता सहभागिता और / या त्रुटि जाँच का एक पूरा समूह है। फिर अंत में एक कमांड - rsync जैसे कुछ - को रूट के रूप में चलाने की आवश्यकता है। क्यों मैं पूरी बात को उन्नत बनाना चाहता हूं और अपने आप को कोड की कई पंक्तियों के लिए खुला छोड़ देना चाहता हूं जिसमें रूट एक्सेस के साथ गंभीर त्रुटियां या कमजोरियां हो सकती हैं - विशेष रूप से डिबगिंग करते समय - जब केवल एक या कुछ आदेशों तक उस पहुंच की आवश्यकता होती है?
जो

2
@ जो मेला काफी "एक अच्छा विचार" को "शायद ही कभी" में बदल दिया।
terdon

10
@ जोए यहाँ एक बहुत अच्छी बात है। जब कोई कहता है कि ऐसा मत करो , तो यह जानना अच्छा होगा कि वास्तव में ऐसा क्यों है, या कम से कम, किस संदर्भ में मुझे ऐसा नहीं करना चाहिए और क्यों
10:24

10
@terdon आप सुन नहीं रहे हैं। मुझे पता है कि यदि आप स्क्रिप्ट को रूट के रूप में चलाते हैं तो यह आपको सूडो के लिए प्रेरित नहीं करेगा। मैं तुलना कर रहा हूं कि स्क्रिप्ट को रूट के रूप में नहीं चलाने और इसके बजाय स्क्रिप्ट में स्पष्ट sudoकॉल डालने के लिए, क्योंकि पूरे स्क्रिप्ट को रूट में ऊंचा करना एक भयानक विचार हो सकता है यदि केवल मुट्ठी भर संकीर्ण क्रियाएं हैं जो रूट की आवश्यकता होती हैं। उस संदर्भ में मैं विशेष रूप से आपकी टिप्पणी का जवाब दे रहा था: "बहुत अजीब है क्योंकि इसका मतलब है कि आप स्क्रिप्ट को स्वचालित रूप से नहीं चला सकते हैं क्योंकि आपको हर बार जब भी आपसे पूछा जाएगा पासवर्ड दर्ज करने की आवश्यकता होगी।"
BeeOnRope

41

आप संभवतः sudoersफ़ाइल को संशोधित कर सकते हैं ।

भागो sudo visudo

अपने उपयोगकर्ता नाम और उस स्क्रिप्ट के लिए एक प्रविष्टि जोड़ें जिसे आप पासवर्ड के लिए पूछे बिना चलाना चाहते हैं।

username ALL=(ALL) NOPASSWD: /path/to/script

2
मेरे लिए काम नहीं किया, लेकिन धन्यवाद, यह जानने के लिए अच्छा है। शायद मुझे वाक्य रचना गलत लगी।
क्रिस के

5
यह निश्चित नहीं है कि किसी ने इसका उल्लेख किया है, लेकिन sudoersफ़ाइल को संपादित करने के बाद आपको उस उपयोगकर्ता के सभी लॉगिन सत्रों को समाप्त करना होगा ।
बचो-llc

1
बस यह स्पष्ट करने के लिए कि यह वह स्क्रिप्ट नहीं है जिसमें "sudo ./playback_delete_data_patch.sh 09_delete_old_data_p.sql" पंक्ति है जो कि sudo फ़ाइल में निर्दिष्ट होनी चाहिए, लेकिन प्लेबैक_delete_data_patch.sh स्क्रिप्ट या अन्य कमांड जिसे आप उपयोगकर्ता या उपयोगकर्ता चाहते हैं। स्क्रिप्ट एक पासवर्ड निर्दिष्ट किए बिना sudo के माध्यम से चलाने में सक्षम होने के लिए।
मत्तजॉकी

19

आप कुछ इस तरह की कोशिश कर सकते हैं:

echo "PASSWORD" | sudo -S ./playback_delete_data_patch.sh 09_delete_old_data_p.sql

यह सबसे सुरक्षित बात नहीं है क्योंकि आप सादे पाठ में एक sudoer पासवर्ड लिख रहे हैं। इसे थोड़ा और सुरक्षित बनाने के लिए आप एक वेरिएबल बना सकते हैं और वेरिएबल में sudo पासवर्ड को पढ़ सकते हैं और फिर आप कमांड को निष्पादित कर सकते हैं:

echo $PASSWORD | sudo -S ./playback_delete_data_patch.sh 09_delete_old_data_p.sql

इसके अलावा, यदि आप अपने सभी आदेशों को जड़ के रूप में निष्पादित नहीं करते हैं, तो आप sudoपहले से सुझाए अनुसार अपनी स्क्रिप्ट का उपयोग करके सरल रूप से निष्पादित कर सकते हैं ।

sudo ./myscript

पासवर्ड को वेरिएबल में सुरक्षित रूप से पढ़ना:read -s PASSWORD
टोबियास उहमान

10

यह उत्तर टेर्डन के उत्तर के समान है । मैं मुख्य स्क्रिप्ट चलाने का सुझाव भी दूंगा sudoताकि स्क्रिप्ट अपने निष्पादन के दौरान उपयोगकर्ता का पासवर्ड पूछे बिना चल सके ।

हालाँकि, यदि आप कुछ विशेष कमांड्स को रूट विशेषाधिकारों को छोड़ना चाहते हैं और उन्हें वास्तविक उपयोगकर्ता के रूप में चलाना sudoचाहते हैं, तो आप कमांड $SUDO_USERको मूल उपयोगकर्ता का पता लगाने के लिए चर के लिए देख सकते हैं।

यह एक उदाहरण स्क्रिप्ट है कि आप इसे कैसे प्राप्त कर सकते हैं:

#!/bin/bash

# ref: https://askubuntu.com/a/30157/8698
if ! [ $(id -u) = 0 ]; then
   echo "The script need to be run as root." >&2
   exit 1
fi

if [ $SUDO_USER ]; then
    real_user=$SUDO_USER
else
    real_user=$(whoami)
fi

# Commands that you don't want running as root would be invoked
# with: sudo -u $real_user
# So they will be run as the user who invoked the sudo command
# Keep in mind if the user is using a root shell (they're logged in as root),
# then $real_user is actually root
# sudo -u $real_user non-root-command

# Commands that need to be ran with root would be invoked without sudo
# root-command

4

ऐसा करने का वास्तव में बहुत सरल तरीका है। पोर्टेबिलिटी के लिए, यह मेरा कार्यान्वयन है लेकिन अपनी ज़रूरत के अनुरूप इसे हेरफेर करने के लिए स्वतंत्र महसूस करें।

स्क्रिप्ट शुरू करते समय एक पैरामीटर के रूप में अपना sudo पासवर्ड दर्ज करें, इसे कैप्चर करें, और इसे प्रत्येक कमांड के साथ गूंजें जो sudo पासवर्ड के लिए संकेत देगा।

#!/bin/bash

PW=$1
echo $PW | ./playback_delete_data_patch.sh 09_delete_old_data_p.sql  
./command_wo_sudo.sh <param>
echo $PW | ./other_command_requires_sudo.sh <param>

स्क्रिप्ट के बंद होने के बाद आप एक संकेत जोड़ सकते हैं और कैप्चर कर सकते हैं:

echo "enter the sudo password, please"
read PW

लेकिन अगर कोई और नज़र रखता है कि नोड पर क्या चल रहा है; इसके द्वारा बनाए गए लॉग तक पहुंच है; या जब आप एक परीक्षण चलाते हैं, तो बेतरतीब ढंग से आपके ऊपर देखना चाहिए, जो सुरक्षा से समझौता कर सकता है।

यह रनिंग कमांड / स्क्रिप्ट के साथ भी काम करता है जिसे जारी रखने के लिए हां की आवश्यकता होती है:

echo $PW | yes | ./install.sh

इको एक प्रॉम्प्ट की प्रतिक्रिया में है, इसलिए आप अपनी ज़रूरत की किसी भी चीज़ का उपयोग कर सकते हैं, यदि आप अन्य स्क्रिप्ट चला रहे हैं, जो क्रमिक क्रम में प्रगति के लिए संकेत देती हैं। सुनिश्चित करें कि आप उस आदेश को जानते हैं, हालांकि, या बुरी चीजें हो सकती हैं।


यह बहुत अधिक सुरुचिपूर्ण और सरल है, मुझे खुशी है कि मैंने सभी तरह से नीचे स्क्रॉल किया! संपादित करें: प्रतीक्षा करें, यह मेरे टर्मिनल इतिहास के पासवर्ड को जोड़ देगा
अय्यूब

1
उपयोगकर्ता नाम पूछने के लिए कैसे / के साथ पासवर्ड read: ryanstutorials.net/bash-scripting-tutorial/bash-input.php कि इस मुद्दे से बचना चाहिए
नौकरी

3
#!/bin/bash
# this declares that current user is a sudoer
sudo tee /etc/sudoers.d/$USER <<END
END

# write the content of your script here
sudo npm install hexo-cli -g
mkdir Untitled
sudo apt-get install python

# then to remove the sudo access from the current user
sudo /bin/rm /etc/sudoers.d/$USER
sudo -k

0

आप स्क्रिप्ट चलाने वाले उपयोगकर्ता को sudoers फ़ाइल में जोड़ने का प्रयास कर सकते हैं:

#give permissions to the file
sudo chmod 700 /etc/sudoers.d/useradm

sudo visudo /etc/sudoers.d/useradm

#add the following text, changing "user" but your desired user
user ALL=(ALL)NOPASSWD:ALL

#return the right permissions to the file
sudo chmod 440 /etc/sudoers.d/useradm

आम तौर पर यह एक खराब तरीका है। यदि आप NOPASSWD sudo नियमों को जोड़ने जा रहे हैं, विशेष रूप से उन खातों के लिए जो स्वचालन चलाते हैं, तो आपको कम से कम उन्हें सटीक कमांड तक ही सीमित रखना चाहिए जो कि चलाया जाता है (और सभी नहीं)
क्रिस्टोफर हंटर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.