sudo-rs sa Ubuntu: Ano ang Nagbabago sa sudoers

Ano ang binabago ng sudo-rs sa Ubuntu

Ang Ubuntu 26.04 LTS ay may sudo-rs bilang default na sudo, kaya ang command na sudo sa isang bagong server ay nagpapatakbo ng Rust reimplementation sa halip na ng orihinal na C program. Patuloy na gagana ang karamihan sa mga sudoers file gaya ng dati. Ang panuntunang hindi gagana ay ang may wildcard sa loob ng mga argumento ng command, dahil hindi itinutugma ng sudo-rs ang mga glob pattern sa teksto ng mga argumento.

Unang ginawa ng Ubuntu 25.10 ang paglipat, at ipinagpatuloy ito ng 26.04 LTS. Hindi apektado ang Ubuntu 24.04 LTS, dahil ginagamit pa rin nito ang orihinal na sudo maliban kung manu-mano mong i-install ang sudo-rs. Nagiging mahalaga ito kapag nag-upgrade ka mula Ubuntu 24.04 patungong 26.04, o kapag gumawa ka ng bagong server gamit ang mas bagong release. Kung gumagamit ka rin ng interim releases, ipinapaliwanag ng kung paano nagkakaiba ang LTS at interim Ubuntu releases sa isang server kung aling machine ang unang makakaranas ng ganitong pagbabago.

Tingnan kung aling sudo ang aktuwal na pinapatakbo ng server

Huwag itong tukuyin batay sa release number. Tanungin mismo ang machine.

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

Mas mapagkakatiwalaan ang sudo --version sa sarili mong box kaysa sa anumang version table sa internet, kabilang ang pahinang ito. Ang update-alternatives --config sudo ang kabilang bahagi ng sagot: inililista nito ang lahat ng naka-install na provider ng /usr/bin/sudo at minamarkahan ang napili. Hindi nangangahulugang napili ang isang package dahil naka-install ito, kaya basahin ang selection, hindi ang package list.

Parehong bina-package ang dalawang implementation habang isinasagawa ang transition. Ang Rust na bersyon ay sudo-rs, na nasa version 0.2.13 sa 26.04 noong Agosto 2026. Ang orihinal, na pinananatili ni Todd C. Miller, ay nasa package na sudo; ang nagbago ay may .ws suffix ang mga program nito upang sabay na mai-install ang dalawa: /usr/bin/sudo.ws at /usr/bin/visudo.ws, kasama ng cvtsudoers.ws at sudoreplay.ws. Na-verify laban sa 26.04 archive noong Setyembre 2026: inililista ng dpkg -L sudo ang mga binary na may suffix, at sine-ship ng sudo-rs ang /usr/bin/sudo-rs kasama ng mga ito.

Bakit lumipat ang Ubuntu sa sudo-rs

Ang sudo ay setuid root. Maaaring patakbuhin ito ng sinumang user sa server, at nagsisimula ito na may buong privilege. Dahil dito, ang memory bug sa loob nito ay maaaring maging local root exploit. Ganoon mismo ang CVE-2021-3156: isang heap buffer overflow na maaaring maabot ng sinumang local user. Nasa inilabas na code ito nang humigit-kumulang sampung taon. Nahuhuli ng Rust ang ganitong klase ng bug sa compile time. Iyan ang pangunahing dahilan ng rewrite.

Ang ikalawang dahilan ay ang saklaw, at ito ang direktang nakaaapekto sa configuration mo. Sa loob ng tatlong dekada, nakabuo ang orihinal na sudo ng malaking set ng mga feature. Bawat feature ay nangangahulugan ng karagdagang code na tumatakbo bilang root. Sadyang subset lamang ang ipinapatupad ng sudo-rs. Hindi isinama ang mga feature na itinuring ng mga author na bihira gamitin o maaaring makasama. Dahil dito, maaaring wala na mismo ang sudoers construct na gumana nang maraming taon. Isa rito ang wildcard rule mo.

Tinatanggal ng memory safety ang isang klase ng bug. Hindi nito ginagawang walang bug ang program, at naglabas na rin ang sudo-rs ng sarili nitong security fixes mula nang maging default ito. I-patch ito gaya ng iba pang software.

Aling sudoers rules ang gumagana pa

Pareho pa rin ang file. Binabasa ng sudo-rs ang /etc/sudoers at ang mga drop-in file sa /etc/sudoers.d/, at sinusuportahan nito ang karaniwang isinusulat ng server operator:

• deploy ALL=(ALL:ALL) ALL, pati ang mga anyo para sa group gaya ng %sudo ALL=(ALL:ALL) ALL
• ang mga tag na NOPASSWD: at PASSWD:
• User_Alias, Runas_Alias, Host_Alias, at Cmnd_Alias
• isang command na may eksaktong listahan ng argument, gaya ng /usr/bin/systemctl restart app-api
• isang command na sinusundan ng "", na nagpapahintulot sa command lamang kapag walang anumang argument
• isang command na sinusundan ng * bilang huling argument nito, na nagpapahintulot sa anumang karagdagang argument
• isang directory path na nagtatapos sa /, na nagpapahintulot sa anumang command sa directory na iyon
• ! upang alisin ang isang command mula sa isang listahan
• isang kapaki-pakinabang na subset ng Defaults, kabilang ang secure_path, env_keep, env_check, timestamp_timeout, passwd_tries, editor, umask, targetpw, rootpw, at use_pty

Magkaiba ang gawi ng dalawang default at madalas itong nagdudulot ng kalituhan. Hindi maaaring i-off ang env_reset sa sudo-rs: palagi itong naka-on. Naka-on bilang default ang use_pty, kaya tumatakbo ang command sa sarili nitong pseudo-terminal.

Kung bakit hindi na tumutugma ang wildcard sudoers rule mo

Pinapayagan pa rin ang wildcards sa isang bahagi: sa file name ng command. Ang rule na %ops ALL = /sbin/fsck* ay pinapayagan pa rin ang sudo fsck at sudo fsck_exfat, dahil bahagi ng path ang * na itinutugma sa filesystem.

Sa loob ng argument list, dalawang espesyal na form lamang ang tinatanggap ng sudo-rs, at wala sa mga ito ang pattern. Ibig sabihin ng "" ay walang arguments. Ang panghuling * ay nangangahulugang anumang kasunod na arguments. Literal na text ang paghahambingan para sa lahat ng iba pang arguments. Kaya tama ang %ops ALL = /sbin/service ntp *, dahil literal ang ntp at nasa hulihan ang *. Ngunit walang ipinagkakaloob na dapat sana mong makuha ang ganitong rule:

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

Pattern sa gitna ng isang argument ang app-*. Hindi ito ine-expand ng sudo-rs, kaya hindi saklaw ng rule ang systemctl restart app-api at tinatanggihan ni sudo ang command. May dalawang command na nagpapakita ng aktuwal na epekto ng anumang rule sa sarili mong server: ang sudo -l -U deploy, na pinapatakbo bilang root, ay nagpi-print kung ano talaga ang maaaring patakbuhin ng account na iyon; at ipinapakita ng sudo visudo -c kung tama ang pag-parse ng file. Patakbuhin ang mga ito bago ka magsimulang mag-edit nang basta-basta.

Palaging may butas ang wildcard rule

Sa orihinal na sudo, pinagdurugtong sa isang string ang mga argument na tina-type mo, pagkatapos ay itinutugma ang mga ito sa argument string ng rule gamit ang glob. Tinutugma ng glob ang whitespace. Ito ang bahaging halos lahat ay nakakaligtaan.

Ipinapakita ito nang pinakamalinaw sa documentation ng sudo-rs. Pinahihintulutan din ng rule na /bin/rm *.txt ang sudo rm -rf /home .txt, dahil nilalamon ng isang * ang -rf /home , at nagtatapos pa rin sa .txt ang pinagdugtong na string. Ang ibig sabihin ng rule ay “mga text file lamang.” Sa aktuwal, ang ibig sabihin nito ay “anumang argumento, basta nagtatapos sa .txt ang linya.”

Ganito rin ang nangyayari sa halimbawa ng systemctl. Dahil inihahambing ang mga argumento bilang isang pinagdugtong na string, tinutugma rin ng pattern sa hulihan ang anumang idinagdag mo pagkatapos nito. Kaya saklaw ng restart app-* ang restart app-api pati ang anumang karagdagang argumentong idinagdag ng tumatawag. Kapag may pattern sa loob ng isang argumento, nailalantad nito ang mga argumentong nasa paligid nito, at nasa mga argumento ang kapangyarihan ng command. Tinatanggihan ng sudo-rs ang ganitong construct sa halip na subukang gawin itong ligtas, dahil walang pangkalahatang anyo nito na ligtas.

Palitan ang wildcard ng tahasang command list

Karamihan sa mga wildcard rule ay umiiral dahil ayaw ng isang tao na mag-type ng apat na linya. I-type ang apat na linya.

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

Itama ang path. Hindi kailanman tumutugma ang rule na tumutukoy sa /bin/systemctl kapag ang binary ay nasa /usr/bin/systemctl sa system. Magkapareho ang ipinapakitang failure nito at ng permissions problem. Kumpirmahin gamit ang command -v systemctl at i-paste ang output nito.

Ilagay ang rule sa sarili nitong drop-in file sa halip na sa /etc/sudoers, para hindi kailanman sumalungat ang package upgrade sa iyong edit:

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

Pangalanan ang file nang walang tuldok at walang trailing tilde. Binabalewala ng orihinal na sudo ang mga file sa sudoers.d na may tuldok sa pangalan, kaya klasikong tahimik na walang ginagawa ang 90-deploy.conf. Wala ring kapalit na halaga ang paglabag sa convention.

Gumamit ng wrapper na pagmamay-ari ng root kapag mahaba na ang listahan

Kapag masyadong malaki ang allowed set para ilista, ilipat ang desisyon mula sa sudoers papunta sa isang maliit na program na pagmamay-ari ng 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

Sa panig ng sudoers, isang command na lang ang ililista:

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

Katanggap-tanggap dito ang sumusunod na * dahil ang script, hindi ang sudo, ang nagpapasya kung ano ang pinapayagan. Nalalapat lamang ito habang pagmamay-ari ng root ang script at walang ibang account na maaaring sumulat dito. Kung maaaring sumulat sa file ang deploy, maaaring palitan ng deploy ang laman nito at magpatakbo ng anuman bilang root. Mas malala ito kaysa sa wildcard rule na inalis mo. Suriin ang mode gamit ang ls -l. Kung hindi malinaw sa iyo ang output, limang minuto lang ang kailangan upang matutunan ang pagbasa sa permission string na drwxr-xr-x. Nalalapat din ang parehong rule sa directory: hindi rin dapat maaaring sulatan ng account ang /usr/local/sbin, dahil kapag writable ang directory, maaaring palitan nang buo ang file.

Bigyan ang job ng sarili nitong account sa halip na sudo rule

Mas mainam na itanong muna kung bakit kailangan ng command ng root. Ang service na tumatakbo sa sarili nitong user ay maaaring i-manage ng user na iyon, kaya walang kailangang sudoers line. Para sa system units, ipinapasa na ng systemd ang desisyong ito sa polkit. Kaya maaaring magtakda ang isang rule ng isang unit at isang 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;
    }
});

I-save ito bilang /etc/polkit-1/rules.d/50-app-api.rules, at maaaring patakbuhin ng deploy ang systemctl restart app-api nang walang sudo. I-test ito mula sa eksaktong context na gagamit nito. Kailangang kumpirmahin ang isang rule na gumagana sa iyong SSH session mula sa cron bago ka umasa rito. Sa alinmang paraan, dapat umiiral ang account na nagsasagawa ng trabaho para sa gawaing iyon lamang. Ito rin ang batayan ng mga user account na sumusunod sa least privilege sa isang VPS.

Ano pa ang hindi kasama sa sudo-rs

Hindi ipinatutupad ang sudo -E. Sa halip, pangalanan ang mga variable na kailangan mo gamit ang Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY". Tandaan na palaging naka-enable ang env_reset, kaya binubura ang anumang hindi pinapanatili.

Wala na ang central sudoers storage sa LDAP. Hindi ipinatutupad ang sudoers.ldap at cvtsudoers, at inalis ang package na sudo-ldap sa 26.04. Gumagana pa rin ang LDAP authentication sa pamamagitan ng PAM o SSSD. Ang wala sa saklaw ay ang bahagi ng paglalagay ng policy sa directory.

Hindi ipinatutupad ang INTERCEPT, na sinubukang pigilan ang shell escapes mula sa isang pinayagang command. Hindi rin naman nito napipigilan ang determinadong user. Kung pinapayagan ng isang rule ang user na magpatakbo ng editor o interpreter bilang root, mayroon na siyang root access, at walang sudo option ang makapagbabago nito.

Hindi ipinatutupad ang session recording, kaya walang I/O log at walang sudoreplay. Sa syslog lamang ipinapadala ang logging. Wala ring logfile option para i-redirect ito sa ibang lokasyon, kaya napupunta ang sudo messages kung saan man ipinapadala ng system mo ang syslog.

Dapat ka bang bumalik sa sudo.ws?

Maaari kang bumalik, at sa panahon ng 26.04 cycle ay mananatiling naka-package ang orihinal sa mismong dahilang ito.

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

Kopyahin ang eksaktong mga path mula sa output ng --config sa halip na mula sa page na ito, dahil iyon ang listahang tatanggapin ng sarili mong system. Kung babalik ka sa sudo-rs sa susunod, itakda ang alternative sa binary path ng sudo-rs mula sa listahang iyon.

Panatilihing bukas ang isang pangalawang SSH session na naka-login at idle bago ka gumawa ng anumang nakaaapekto sa sudo. Kapag hindi ma-parse ang isang sudoers file, o nakaturo ang isang alternative sa binary na hindi naka-install, maaari kang mawalan ng paraan para maging root sa isang remote box. Bahagi ng routine na ito ang lahat ng iba mo pang ginagawa sa unang sampung minuto sa bagong VPS.

Ituring ang pagbabalik na ito bilang deadline, hindi bilang fix. Bibigyan ka nito ng isang linggo para maayos na isulat muli ang mga rule, at sulit gawin ang rewrite kahit wala ang deadline, dahil bawat wildcard rule na dine-delete mo ay nagbibigay ng higit na access kaysa sa ipinagpalagay ng may-akda nito.

FAQ

Bakit hindi na gumagana ang aking sudoers wildcard rule sa Ubuntu 26.04?

Dahil ginagamit ng Ubuntu 26.04 LTS ang sudo-rs bilang default na sudo, at hindi tinutugma ng sudo-rs ang wildcard pattern sa loob ng mga argument ng command. Pinapayagan nito ang wildcard sa file name ng command, ang "" para mangahulugang walang arguments, at isang * bilang huling argument. Ang rule na gaya ng /usr/bin/systemctl restart app-* ay naglalagay ng pattern sa gitna ng isang argument, kaya wala itong ibinibigay na pahintulot at tinatanggihan ang command. Patakbuhin ang sudo -l -U deploy bilang root upang makita ang aktuwal na pahintulot ng account, pagkatapos ay palitan ang rule ng mga eksaktong command o ng isang root-owned wrapper script.

Paano ako babalik sa orihinal na sudo sa Ubuntu 26.04?

Ang orihinal na sudo ay nasa sudo package, at may .ws suffix ang mga binary nito. I-install ito gamit ang sudo apt install sudo, pagkatapos ay ituro rito ang alternative gamit ang sudo update-alternatives --set sudo /usr/bin/sudo.ws. Patakbuhin muna ang update-alternatives --config sudo upang makita ang eksaktong mga path na available sa iyong system, at panatilihing bukas ang pangalawang SSH session habang binabago mo ito. Hindi nito ibinabalik ang sudo-ldap, na inalis sa 26.04 anuman ang implementation na piliin mo.

Binabasa ba ng sudo-rs ang parehong /etc/sudoers file?

Oo. Binabasa ng sudo-rs ang /etc/sudoers at ang mga drop-in file sa ilalim ng /etc/sudoers.d/, gamit ang parehong syntax para sa users, groups, aliases, run-as specifications, at NOPASSWD tag. Subset lamang ng sudoers language ang ipinapatupad nito, kaya lumilitaw ang mga pagkakaiba bilang mga construct na wala, hindi bilang mga construct na naiiba ang behavior. Mag-edit gamit ang sudo visudo, pagkatapos ay mag-verify gamit ang sudo visudo -c bago isara ang iyong session.

Ano ang pumapalit sa sudo -E sa sudo-rs?

Hindi ipinapatupad ang sudo -E, at dati na rin itong hindi inirerekomenda sa orihinal na sudo, dahil ang pagbibigay sa root process ng environment na kontrolado ng caller ay isang kilalang paraan upang mabago ang behavior ng process na iyon. Sa halip, pangalanan sa sudoers ang mga variable na talagang kailangan mo, gamit ang isang line gaya ng Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY". Palaging naka-enable ang env_reset sa sudo-rs at hindi ito maaaring i-disable, kaya nililinis ang bawat variable na hindi mo pinapanatili.