Ubuntu 26.04 मध्ये sudo-rs साठी sudoers बदल

Ubuntu वर sudo-rs मध्ये झालेले बदल

Ubuntu 26.04 LTS मध्ये sudo-rs हे default sudo म्हणून समाविष्ट आहे. त्यामुळे नवीन सर्व्हरवरील sudo command मूळ C program ऐवजी Rust reimplementation चालवतो. बहुतेक sudoers files पूर्वीप्रमाणेच कार्य करतात. मात्र command च्या arguments मध्ये wildcard असलेला rule कार्य करत नाही, कारण sudo-rs argument text विरुद्ध glob patterns जुळवत नाही.

Ubuntu 25.10 मध्ये हा बदल प्रथम करण्यात आला आणि Ubuntu 26.04 LTS मध्ये तो कायम ठेवण्यात आला. Ubuntu 24.04 LTS वर याचा परिणाम होत नाही, कारण तुम्ही sudo-rs manually install करेपर्यंत तेथे मूळ sudo निवडले जाते. Ubuntu 24.04 वरून 26.04 वर upgrade करण्याची वेळ आली किंवा नवीन release वर नवीन server build केला, तेव्हा हा बदल महत्त्वाचा ठरतो. तुम्ही interim releases देखील चालवत असल्यास, server वर LTS आणि interim Ubuntu releases मध्ये काय फरक आहे यामध्ये अशा बदलाचा परिणाम कोणत्या machine वर प्रथम होतो हे स्पष्ट केले आहे.

तुमचा सर्व्हर प्रत्यक्षात कोणता sudo चालवत आहे ते तपासा

हे release number वरून ठरवू नका. मशीनलाच विचारा.

sudo --version
update-alternatives --config sudo
dpkg -l 'sudo*'

इंटरनेटवरील कोणत्याही version table पेक्षा, या पृष्ठावरील table सह, तुमच्या स्वतःच्या box वरील sudo --version वर विश्वास ठेवा. update-alternatives --config sudo हा या उत्तराचा दुसरा भाग आहे: तो /usr/bin/sudo पुरवणारे सर्व installed provider दाखवतो आणि निवडलेला provider चिन्हांकित करतो. एखादे package installed असणे आणि ते selected असणे एकच नाही. त्यामुळे package list नव्हे, तर selection वाचा.

Transition दरम्यान दोन्ही implementations चे packages उपलब्ध आहेत. Rust implementation म्हणजे sudo-rs. August 2026 पर्यंत 26.04 मध्ये त्याची आवृत्ती 0.2.13 आहे. Todd C. Miller यांनी देखरेख केलेली मूळ implementation sudo.ws या package स्वरूपात उपलब्ध आहे. तिच्या programs च्या शेवटी .ws suffix असतो: sudo.ws आणि visudo.ws.

Ubuntu ने sudo-rs कडे का वळले

sudo हे setuid root आहे. सिस्टमवरील कोणताही user ते सुरू करू शकतो आणि ते पूर्ण privileges सह सुरू होते. त्यामुळे त्यातील memory bug हा local root exploit ठरतो. CVE-2021-3156 हे याचेच उदाहरण होते: कोणत्याही local user ला उपलब्ध असलेला heap buffer overflow सुमारे दहा वर्षे released code मध्ये राहिला. Rust अशा प्रकारच्या bug ला compile time वर पकडते. sudo चे rewrite करण्यामागील मुख्य कारण हेच आहे.

दुसरे कारण scope आहे. याचा थेट परिणाम तुमच्या config वर होतो. मूळ sudo मध्ये तीन दशकांत मोठा feature set जमा झाला आहे. प्रत्येक feature म्हणजे root म्हणून चालणारा अधिक code. sudo-rs जाणीवपूर्वक त्यातील subset लागू करते. लेखकांनी niche किंवा सक्रियपणे हानिकारक मानलेली वैशिष्ट्ये वगळली आहेत. त्यामुळे अनेक वर्षे चालणारा sudoers construct आता पूर्णपणे अनुपलब्ध असू शकतो. तुमचा wildcard rule त्यापैकी एक आहे.

Memory safety मुळे एका प्रकारचे bug दूर होतात. त्यामुळे program पूर्णपणे bug-free होत नाही. sudo-rs default झाल्यापासून त्यासाठीही security fixes released झाले आहेत. इतर कोणत्याही software प्रमाणे त्यालाही patch करा.

कोणते sudoers नियम अजूनही कार्यरत आहेत

ही तीच फाइल आहे. sudo-rs /etc/sudoers आणि /etc/sudoers.d/ मधील drop-in फाइल्स वाचते. सर्व्हर ऑपरेटर सामान्यतः लिहित असलेल्या नियमांना समर्थन दिले जाते:

• deploy ALL=(ALL:ALL) ALL आणि %sudo ALL=(ALL:ALL) ALL सारखे group forms
• NOPASSWD: आणि PASSWD: tags
• User_Alias, Runas_Alias, Host_Alias आणि Cmnd_Alias
• अचूक argument list असलेली command, उदाहरणार्थ /usr/bin/systemctl restart app-api
• "" नंतर दिलेली command. यामुळे ती command कोणतेही arguments नसतानाच चालवता येते
• अंतिम argument म्हणून * नंतर दिलेली command. यामुळे त्यानंतरचे कोणतेही arguments देता येतात
• / ने समाप्त होणारा directory path. यामुळे त्या directory मधील कोणतीही command चालवता येते
• यादीमधून एखादी command वगळण्यासाठी !
• Defaults च्या उपयुक्त subset ला समर्थन दिले जाते. त्यात secure_path, env_keep, env_check, timestamp_timeout, passwd_tries, editor, umask, targetpw, rootpw आणि use_pty यांचा समावेश आहे

दोन defaults वेगळ्या पद्धतीने कार्य करतात आणि त्यामुळे गोंधळ होऊ शकतो. sudo-rs मध्ये env_reset बंद करता येत नाही; ते नेहमी सुरू असते. use_pty default ने सुरू असते. त्यामुळे command स्वतःच्या pseudo-terminal मध्ये चालते.

तुमचा wildcard sudoers नियम जुळणे का थांबले

Wildcard अजूनही एका ठिकाणी वापरता येतात: command च्या file name मध्ये. %ops ALL = /sbin/fsck* चा नियम अजूनही sudo fsck आणि sudo fsck_exfat ला परवानगी देतो, कारण * हा filesystem शी जुळवला जाणाऱ्या path चा भाग आहे.

Argument list मध्ये sudo-rs फक्त दोन विशेष प्रकार स्वीकारते आणि त्यांपैकी एकही pattern नाही. "" म्हणजे कोणतेही arguments नाहीत. शेवटचा * म्हणजे त्यानंतर येणारे कोणतेही arguments. इतर प्रत्येक argument ची literal text म्हणून तुलना केली जाते. त्यामुळे %ops ALL = /sbin/service ntp * योग्य आहे, कारण ntp literal आहे आणि * शेवटी आहे. मात्र, खालीलप्रमाणे नियम तुम्हाला अपेक्षित कोणतीही परवानगी देत नाही:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart app-*

app-* हा argument च्या मध्यभागी असलेला pattern आहे. sudo-rs त्याचा विस्तार करत नाही. त्यामुळे हा नियम systemctl restart app-api वर लागू होत नाही आणि sudo ती command नाकारते. तुमच्या स्वतःच्या server वरील कोणत्याही नियमाबद्दल सत्य सांगणाऱ्या दोन commands आहेत: root म्हणून चालवलेली sudo -l -U deploy त्या account ला प्रत्यक्षात कोणत्या commands चालवता येतात ते दाखवते, आणि sudo visudo -c file चे parsing होते की नाही ते सांगते. अंदाजाने संपादन सुरू करण्यापूर्वी या commands चालवा.

वाइल्डकार्ड नियम सुरुवातीपासूनच एक सुरक्षा-त्रुटी होता

मूळ sudo मध्ये तुम्ही टाइप केलेले arguments एका string मध्ये जोडले जातात आणि glob वापरून नियमातील argument string शी त्यांची जुळवणी केली जाते. Glob whitespace शीही जुळतो. हा मुद्दा जवळपास सर्वांच्या लक्षात येत नाही.

sudo-rs documentation मध्ये याचे सर्वांत स्पष्ट उदाहरण दिले आहे. /bin/rm *.txt या नियमामुळे sudo rm -rf /home .txt देखील अनुमत होते, कारण एक * -rf /home गिळून टाकतो आणि जोडलेली string शेवटी .txt वरच संपते. या नियमाचा अर्थ "फक्त text files" असा दिसतो. प्रत्यक्षात त्याचा अर्थ "ओळ शेवटी .txt ने संपत असेल, तर कोणतेही arguments चालतील" असा होतो.

हेच systemctl उदाहरणालाही लागू होते. Arguments एका joined string म्हणून तपासले जात असल्यामुळे, शेवटचा pattern त्यानंतर तुम्ही जोडलेल्या कोणत्याही मजकुराशीही जुळतो. त्यामुळे restart app-* मध्ये restart app-api तसेच caller ने जोडलेले पुढील कोणतेही arguments समाविष्ट होतात. एखाद्या argument मध्ये pattern दिल्यास त्याच्या आजूबाजूचे argumentsही अनियंत्रित होतात; आणि command ची प्रत्यक्ष क्षमता arguments मध्येच असते. sudo-rs ही रचना सुरक्षित करण्याचा प्रयत्न करण्याऐवजी नाकारते, कारण तिचे सुरक्षित सामान्य रूप उपलब्ध नाही.

वाइल्डकार्डऐवजी स्पष्ट command list वापरा

बहुतेक वाइल्डकार्ड नियम अस्तित्वात असतात कारण कोणाला चार ओळी टाइप करायच्या नसतात. त्या चार ओळी टाइप करा.

Cmnd_Alias APP_RESTART = /usr/bin/systemctl restart app-api, /usr/bin/systemctl restart app-worker
Cmnd_Alias APP_STATUS = /usr/bin/systemctl status app-api, /usr/bin/systemctl status app-worker
deploy ALL=(root) NOPASSWD: APP_RESTART, APP_STATUS

योग्य path वापरा. binary /usr/bin/systemctl येथे असलेल्या system वर /bin/systemctl नमूद करणारा नियम कधीही जुळत नाही. त्याचे अपयश permissions समस्येसारखेच दिसते. command -v systemctl वापरून पडताळणी करा आणि त्याने दाखवलेला output पेस्ट करा.

हा नियम /etc/sudoers मध्ये न ठेवता स्वतंत्र drop-in file मध्ये ठेवा. त्यामुळे package upgrade तुमच्या बदलाशी कधीही संघर्ष करणार नाही:

sudo visudo -f /etc/sudoers.d/90-deploy
sudo visudo -c
sudo -l -U deploy

file चे नाव dot शिवाय आणि शेवटी tilde न ठेवता द्या. मूळ sudo sudoers.d मधील नावात dot असलेल्या files दुर्लक्षित करते. त्यामुळे 90-deploy.conf ही नेहमीची silent no-op चूक ठरते. ही naming convention पाळण्यात काहीही अतिरिक्त लागत नाही.

यादी मोठी झाल्यास root-मालकीचा wrapper वापरा

परवानगी असलेला संच सूचीबद्ध करण्यासाठी खूप मोठा असल्यास, हा निर्णय sudoers मधून काढून root-मालकीच्या छोट्या प्रोग्राममध्ये ठेवा.

sudo tee /usr/local/sbin/app-restart >/dev/null <<'EOF'
#!/bin/sh
set -eu
case "${1:-}" in
  app-api|app-worker) ;;
  *) echo "app-restart: not allowed: ${1:-}" >&2; exit 1 ;;
esac
exec /usr/bin/systemctl restart "$1"
EOF
sudo chown root:root /usr/local/sbin/app-restart
sudo chmod 0755 /usr/local/sbin/app-restart
ls -l /usr/local/sbin/app-restart

त्यानंतर sudoers मध्ये एकच command नमूद करा:

deploy ALL=(root) NOPASSWD: /usr/local/sbin/app-restart *

शेवटी असलेले * येथे स्वीकार्य आहे, कारण काय परवानगी आहे हे sudo नव्हे, तर script ठरवते. मात्र script root च्या मालकीची आणि इतर कोणालाही लिहिता न येणारी असेपर्यंतच हे सुरक्षित आहे. deploy ला file मध्ये लिहिता येत असल्यास, deploy तिचा मजकूर बदलून root म्हणून काहीही चालवू शकते. तुम्ही काढून टाकलेल्या wildcard नियमापेक्षा ही स्थिती अधिक धोकादायक आहे. ls -l वापरून mode तपासा. output तुम्हाला स्पष्ट दिसत नसल्यास, drwxr-xr-x permission string वाचणे शिकण्यासाठी पाच मिनिटे पुरेशी आहेत. हाच नियम directory लाही लागू होतो: /usr/local/sbin या account ला directory मध्ये लिहिता येता कामा नये, कारण writable directory असल्यास file पूर्णपणे बदलता येते.

sudo नियमाऐवजी job साठी स्वतंत्र account द्या

अनेकदा command ला root अधिकारांची गरजच का आहे, हा अधिक योग्य प्रश्न असतो. स्वतःच्या user म्हणून चालणारी service त्या user कडून व्यवस्थापित करता येते आणि sudoers मधील कोणतीही ओळ आवश्यक राहत नाही. System units साठी systemd हा निर्णय polkit कडे आधीच सोपवतो. त्यामुळे rule मध्ये एक unit आणि एक operator नमूद करता येतो:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units" &&
        action.lookup("unit") == "app-api.service" &&
        subject.user == "deploy") {
        return polkit.Result.YES;
    }
});

हे /etc/polkit-1/rules.d/50-app-api.rules म्हणून जतन करा. deploy कोणतेही sudo न वापरता systemctl restart app-api चालवू शकतो. ज्यातून ही सुविधा वापरली जाणार आहे, त्याच अचूक context मधून तिची चाचणी घ्या. तुमच्या SSH session मध्ये चालणारा rule cron मधूनही चालतो याची खात्री करून घेतल्याशिवाय त्यावर अवलंबून राहू नका. कोणत्याही परिस्थितीत, काम करणारे account केवळ त्या कामासाठीच असावे. VPS वरील किमान विशेषाधिकार असलेल्या user accounts मागील तत्त्वही हेच आहे.

sudo-rs मध्ये समाविष्ट नसलेल्या इतर गोष्टी

sudo -E लागू केलेले नाही. त्याऐवजी आवश्यक variables ला Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY" वापरून नाव द्या. तसेच env_reset नेहमी सुरू असते, हे लक्षात ठेवा. त्यामुळे ज्या गोष्टी ठेवलेल्या नाहीत त्या साफ केल्या जातात.

LDAP मधील केंद्रीय sudoers storage काढून टाकण्यात आले आहे. sudoers.ldap आणि cvtsudoers लागू केलेले नाहीत. sudo-ldap package 26.04 मध्ये काढून टाकण्यात आले. PAM किंवा SSSD द्वारे LDAP authentication अजूनही कार्य करते. मात्र directory मध्ये policy ठेवण्याचा भाग या व्याप्तीबाहेर आहे.

परवानगी असलेल्या command मधून shell escapes रोखण्याचा प्रयत्न करणारे INTERCEPT लागू केलेले नाही. ठामपणे प्रयत्न करणाऱ्या user विरुद्ध ते आधीही प्रभावी नव्हते. एखाद्या rule मुळे कोणी editor किंवा interpreter root म्हणून चालवू शकत असेल, तर त्या user कडे root access आहे. कोणताही sudo option ही बाब बदलू शकत नाही.

Session recording लागू केलेले नाही. त्यामुळे I/O log किंवा sudoreplay उपलब्ध नाही. Logging फक्त syslog कडे जाते. ते इतरत्र वळवण्यासाठी logfile option उपलब्ध नाही. त्यामुळे sudo messages तुमचे system syslog जिथे पाठवते तिथेच पोहोचतात.

sudo.ws वर परत जावे का?

होय, तुम्ही परत जाऊ शकता. 26.04 cycle दरम्यान मूळ आवृत्ती package स्वरूपात ठेवण्याचे नेमके हेच कारण आहे.

sudo apt install sudo.ws
update-alternatives --config sudo
sudo update-alternatives --set sudo /usr/bin/sudo.ws

--config च्या output मधील अचूक paths वापरा. या पृष्ठावरील paths वापरू नका, कारण तुमची स्वतःची system स्वीकारेल ती यादी output मध्येच आहे. नंतर sudo-rs वर परत जायचे असल्यास, त्याच यादीतील sudo-rs binary path कडे alternative सेट करा.

sudo वर परिणाम करणारे कोणतेही बदल करण्यापूर्वी दुसरे SSH session उघडे, logged in आणि idle ठेवा. parse न होणारी sudoers file किंवा install न केलेल्या binary कडे निर्देश करणारे alternative यामुळे remote box वर root बनण्याचा कोणताही मार्ग उरू शकत नाही. नवीन VPS वरच्या पहिल्या दहा मिनिटांतील इतर सर्व कामांप्रमाणे ही सवयही आवश्यक आहे.

परत करण्याच्या या बदलाकडे fix म्हणून नव्हे, तर deadline म्हणून पाहा. यामुळे rules योग्य प्रकारे पुन्हा लिहिण्यासाठी तुम्हाला एक आठवडा मिळतो. हे rewrite स्वतंत्रपणेही करणे योग्य आहे, कारण तुम्ही delete केलेला प्रत्येक wildcard rule त्याच्या लेखकाने त्यात अभिप्रेत ठेवलेल्यापेक्षा अधिक अधिकार देत होता.

FAQ

माझा sudoers wildcard नियम Ubuntu 26.04 मध्ये कार्य करणे का थांबले?

Ubuntu 26.04 LTS मध्ये sudo-rs हे default sudo म्हणून निवडले जाते. sudo-rs कमांडच्या arguments मधील wildcard patterns शी जुळवणी करत नाही. कमांडच्या file name मध्ये wildcard वापरता येतो, "" चा अर्थ कोणतेही arguments नाही असा होतो आणि अंतिम argument म्हणून एकच * वापरता येतो. /usr/bin/systemctl restart app-* सारख्या नियमात argument च्या मध्यभागी pattern असतो. त्यामुळे तो कोणतीही परवानगी देत नाही आणि कमांड नाकारली जाते. account कडे प्रत्यक्षात कोणत्या परवानग्या आहेत हे पाहण्यासाठी root म्हणून sudo -l -U deploy चालवा. त्यानंतर नियमाऐवजी अचूक commands किंवा root-owned wrapper script वापरा.

Ubuntu 26.04 मध्ये मूळ sudo वर पुन्हा कसे स्विच करावे?

मूळ sudo हे sudo.ws या package मध्ये उपलब्ध आहे. ते sudo apt install sudo.ws ने install करा. त्यानंतर sudo update-alternatives --set sudo /usr/bin/sudo.ws ने alternative त्याकडे निर्देशित करा. तुमच्या system वर उपलब्ध असलेले अचूक paths प्रथम पाहण्यासाठी update-alternatives --config sudo चालवा. बदल करताना दुसरे SSH session उघडे ठेवा. यामुळे sudo-ldap पुन्हा उपलब्ध होत नाही. तुम्ही कोणतीही implementation निवडली तरी ते 26.04 मधून काढून टाकण्यात आले आहे.

sudo-rs त्याच /etc/sudoers file मधून configuration वाचते का?

होय. sudo-rs /etc/sudoers आणि /etc/sudoers.d/ अंतर्गत असलेल्या drop-in files वाचते. users, groups, aliases, run-as specifications आणि NOPASSWD tag यांच्यासाठी तीच syntax वापरली जाते. sudo-rs sudoers language च्या मर्यादित भागाची अंमलबजावणी करते. त्यामुळे फरक वेगळ्या प्रकारे वागणाऱ्या constructs पेक्षा उपलब्ध नसलेल्या constructs स्वरूपात दिसतात. sudo visudo वापरून file edit करा. Session बंद करण्यापूर्वी sudo visudo -c वापरून पडताळणी करा.

sudo-rs मध्ये sudo -E ऐवजी काय वापरले जाते?

sudo -E ची अंमलबजावणी केलेली नाही. मूळ sudo मध्येही त्याचा वापर आधीपासूनच निरुत्साहित केला जात होता. याचे कारण असे की caller नियंत्रित करत असलेले environment root process ला देणे, त्या process चे वर्तन बदलण्याचा सर्वपरिचित मार्ग आहे. sudoers मध्ये तुम्हाला प्रत्यक्षात आवश्यक असलेले variables स्पष्टपणे नमूद करा. त्यासाठी Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY" सारखी line वापरता येते. sudo-rs मध्ये env_reset नेहमी enabled असते आणि ते disabled करता येत नाही. त्यामुळे तुम्ही ठेवलेला प्रत्येक variable वगळता बाकी सर्व variables clear केले जातात.