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

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

Ubuntu 26.04 LTS मध्ये sudo-rs हे default sudo म्हणून समाविष्ट आहे. त्यामुळे नवीन server वर sudo command चालवल्यावर मूळ C program ऐवजी Rust पुनर्रचना चालते. बहुतेक 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 स्वतः install केल्याशिवाय तेथे मूळ sudo निवडले जाते. हा बदल तेव्हा महत्त्वाचा ठरतो, जेव्हा तुम्ही Ubuntu 24.04 वरून Ubuntu 26.04 वर upgrade करता, किंवा नवीन release वर नवीन box तयार करता. तुम्ही interim releases देखील चालवत असल्यास, server वर LTS आणि interim Ubuntu releases मध्ये काय फरक आहे या स्पष्टीकरणातून असा बदल कोणत्या machine वर आधी लागू होतो हे समजते.

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

हे release number वरून ठरवू नका. मशीनकडून थेट माहिती घ्या.

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

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

या transition दरम्यान दोन्ही implementations package स्वरूपात उपलब्ध आहेत. Rust-आधारित implementation म्हणजे sudo-rs; August 2026 पर्यंत 26.04 मध्ये त्याची आवृत्ती 0.2.13 आहे. Todd C. Miller यांनी विकसित केलेले आणि maintained असलेले मूळ implementation अजूनही sudo package आहे. बदल एवढाच आहे की त्याच्या programs ला .ws suffix दिला जातो, त्यामुळे दोन्ही एकाच वेळी स्थापित करता येतात: /usr/bin/sudo.ws आणि /usr/bin/visudo.ws, तसेच cvtsudoers.ws आणि sudoreplay.ws. September 2026 मध्ये 26.04 archive विरुद्ध पडताळले: dpkg -L sudo suffixed binaries दाखवतो आणि sudo-rs त्यांच्यासोबत /usr/bin/sudo-rs उपलब्ध करून देतो.

Ubuntu ने sudo-rs का वापर का सुरू केला

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

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

Memory safety मुळे दोषांची एक श्रेणी दूर होते. त्यामुळे program bug free होत नाही. default झाल्यानंतर sudo-rs मध्येही स्वतःचे security fixes जारी झाले आहेत. इतर कोणत्याही software प्रमाणे त्याचेही patches लागू करा.

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

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

• deploy ALL=(ALL:ALL) ALL आणि %sudo ALL=(ALL:ALL) ALL सारखे गट-आधारित प्रकार
• NOPASSWD: आणि PASSWD: टॅग
• 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 मधील उपयुक्त पर्यायांचा संच. यात secure_path, env_keep, env_check, timestamp_timeout, passwd_tries, editor, umask, targetpw, rootpw आणि use_pty यांचा समावेश आहे

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

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

Wildcards अजूनही एका ठिकाणी अनुमत आहेत: 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 वापरून rule मधील argument string शी त्यांची तुलना केली जाते. Glob whitespace शी जुळतो. हा मुद्दा जवळजवळ सर्वांच्या लक्षात येत नाही.

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

हेच systemctl उदाहरणालाही लागू होते. Arguments एकाच joined string म्हणून तपासले जात असल्यामुळे, शेवटी असलेला pattern त्यानंतर जोडलेल्या कोणत्याही मजकुराशीही जुळतो. त्यामुळे restart app-* मध्ये restart app-api सोबत caller ने जोडलेले पुढील कोणतेही arguments समाविष्ट होतात. एखाद्या argument मधील pattern त्याच्या आजूबाजूचे argumentsही असुरक्षित करतो, आणि command ची शक्ती arguments मध्येच असते. हा construct सुरक्षित करण्याचा प्रयत्न करण्याऐवजी 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 तुमच्या edit शी कधीही संघर्ष करणार नाही:

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 ही नेहमी आढळणारी, कोणताही error न दाखवणारी निष्फळ मांडणी ठरते. ही 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 rule पेक्षा ही परिस्थिती अधिक धोकादायक आहे. ls -l वापरून mode तपासा. Output तुम्हाला स्पष्ट दिसत नसेल, तर drwxr-xr-x permission string वाचणे शिकण्यासाठी पाच मिनिटे पुरेशी आहेत. हाच नियम directory लाही लागू होतो: /usr/local/sbin ही account लिहू शकणार नाही अशी असली पाहिजे, कारण writable directory असल्यास संपूर्ण file बदलता येते.

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

अनेकदा अधिक योग्य प्रश्न असा असतो की त्या command ला root ची गरजच का आहे. स्वतःच्या user म्हणून चालणारी service त्या user कडून व्यवस्थापित करता येते आणि sudoers मधील कोणतीही line आवश्यक राहत नाही. 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 दरम्यान मूळ पॅकेज समाविष्ट ठेवण्याचे नेमके हेच कारण आहे.

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

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

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

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

FAQ

Ubuntu 26.04 मध्ये माझा sudoers wildcard नियम का काम करेनासा झाला?

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

sudo-rs समान /etc/sudoers file वाचते का?

होय. sudo-rs /etc/sudoers आणि /etc/sudoers.d/ अंतर्गत drop-in files वाचते. Users, groups, aliases, run-as specifications आणि NOPASSWD tag यांच्यासाठी समान syntax वापरले जाते. sudoers language चा केवळ काही भाग sudo-rs मध्ये लागू आहे. त्यामुळे फरक constructs वेगळ्या प्रकारे वागण्यात नसून काही constructs उपलब्ध नसण्यात दिसतात. sudo visudo वापरून 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 काढून टाकले जाते.