Mabadiliko ya sudo-rs kwenye Ubuntu 26.04 na sudoers

Mabadiliko ya sudo-rs kwenye Ubuntu

Ubuntu 26.04 LTS inasambaza sudo-rs kama sudo chaguo-msingi, kwa hivyo amri ya sudo kwenye seva mpya huendesha utekelezaji wa Rust badala ya programu ya asili ya C. Faili nyingi za sudoers zinaendelea kufanya kazi kama zilivyokuwa. Kanuni inayofeli ni ile yenye wildcard ndani ya hoja za amri, kwa sababu sudo-rs hailinganishi mifumo ya glob dhidi ya maandishi ya hoja.

Ubuntu 25.10 ilifanya mabadiliko hayo kwanza na 26.04 LTS ikayahifadhi. Ubuntu 24.04 LTS haijaathiriwa, kwa kuwa bado inachagua sudo ya asili isipokuwa uweke sudo-rs kwa mikono. Wakati huu unakuwa muhimu ni pale unapofanya upgrade kutoka Ubuntu 24.04 kwenda 26.04, au wakati unapounda seva mpya kwenye toleo jipya zaidi. Ikiwa unaendesha matoleo ya muda pia, jinsi matoleo ya LTS na ya muda ya Ubuntu yanavyotofautiana kwenye seva inaelezea ni mashine ipi inayokutana na mabadiliko kama haya kwanza.

Hakiki ni toleo gani la sudo ambalo seva yako inatumia kwa sasa

Usijaribu kubaini hili kupitia namba ya release. Iulize mashine yenyewe.

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

Iamini sudo --version iliyo kwenye seva yako kuliko jedwali lolote la matoleo kwenye Internet, ikiwemo ukurasa huu. update-alternatives --config sudo ni sehemu nyingine ya jibu: inaorodhesha kila mtoa huduma aliyewekwa wa /usr/bin/sudo na kuashiria ule ulioteuliwa. Kifurushi kuwa kimesakinishwa si sawa na kuwa kimechaguliwa, kwa hivyo soma uteuzi, si orodha ya vifurushi.

Utekelezaji wote miwili umewekwa kwenye vifurushi wakati wa kipindi hiki cha mpito. Toleo la Rust ni sudo-rs, likiwa katika toleo la 0.2.13 kwenye 26.04 kufikia Agosti 2026. Toleo asilia, linalosimamiwa na Todd C. Miller, bado ni kifurushi cha sudo; kilichobadilika ni kwamba programu zake zina kiambishi tamati cha .ws ili zote ziweze kusakinishwa kwa wakati mmoja: /usr/bin/sudo.ws na /usr/bin/visudo.ws, sambamba na cvtsudoers.ws na sudoreplay.ws. Imethibitishwa dhidi ya kumbukumbu ya 26.04 mnamo Septemba 2026: dpkg -L sudo inaorodhesha binary zenye viambishi tamati, na sudo-rs inatoa /usr/bin/sudo-rs kando yake.

Kwa nini Ubuntu ilihamia kwenye sudo-rs

sudo hutumia setuid root. Mtumiaji yeyote kwenye seva anaweza kuianzisha, na huanza ikiwa na marupurupu kamili, kwa hivyo hitilafu ya kumbukumbu (memory bug) ndani yake ni njia ya kupata root kienyeji. CVE-2021-3156 ilikuwa hasa hivyo: heap buffer overflow inayoweza kufikiwa na mtumiaji yeyote wa ndani, na ilikuwepo kwenye code iliyotolewa kwa takriban miaka kumi. Rust huzuia aina hiyo ya hitilafu wakati wa compile, na hiyo ndiyo hoja kuu ya kuandika upya programu hiyo.

Sababu ya pili ni upeo (scope), na hii ndiyo inayogusa usanidi wako. sudo ya asili imekusanya seti kubwa ya vipengele kwa miongo mitatu, na kila kipengele ni code zaidi inayofanya kazi kama root. sudo-rs hutekeleza sehemu ndogo tu kwa makusudi. Kila kitu ambacho waandishi wake walikiona kuwa cha nadra au chenye madhara kiliachwa nje, kwa hivyo muundo wa sudoers uliokuwa ukifanya kazi kwa miaka mingi unaweza tu kutokuwepo. Sheria yako ya wildcard ni mojawapo ya hayo.

Usalama wa kumbukumbu huondoa aina moja ya hitilafu. Haifanyi programu isiwe na hitilafu kabisa, na sudo-rs imetoa marekebisho yake ya usalama tangu ilipokuwa chaguo-msingi. Ifanyie patch kama programu nyingine yoyote.

Ni sheria zipi za sudoers zinazofanya kazi bado

Faili ni lilelile. sudo-rs inasoma /etc/sudoers na faili za ziada zilizopo kwenye /etc/sudoers.d/, na mambo ya kawaida ambayo msimamizi wa seva huandika yanaungwa mkono:

• deploy ALL=(ALL:ALL) ALL, na aina za vikundi kama vile %sudo ALL=(ALL:ALL) ALL
• vitambulishi vya NOPASSWD: na PASSWD:
• User_Alias, Runas_Alias, Host_Alias na Cmnd_Alias
• amri yenye orodha kamili ya hoja (arguments), kwa mfano /usr/bin/systemctl restart app-api
• amri inayofuatwa na "", ambayo inaruhusu amri hiyo bila hoja zozote
• amri inayofuatwa na * kama hoja yake ya mwisho, ambayo inaruhusu hoja zozote zinazofuata
• njia ya saraka (directory path) inayoishia na /, ambayo inaruhusu amri yoyote katika saraka hiyo
• ! ili kuondoa amri kutoka kwenye orodha
• sehemu muhimu ya Defaults, ikijumuisha secure_path, env_keep, env_check, timestamp_timeout, passwd_tries, editor, umask, targetpw, rootpw na use_pty

Mipangilio miwili ya msingi (defaults) hufanya kazi kwa njia tofauti na huwachanganya watu. env_reset haiwezi kuzimwa katika sudo-rs: inakuwa imewashwa kila wakati. use_pty imewashwa kwa chaguo-msingi, kwa hivyo amri huendeshwa katika pseudo-terminal yake yenyewe.

Kwa nini sheria yako ya wildcard katika sudoers imeacha kufanya kazi

Wildcards bado zinaruhusiwa katika sehemu moja: jina la faili la amri. Sheria ya %ops ALL = /sbin/fsck* bado inaruhusu sudo fsck na sudo fsck_exfat, kwa sababu * ni sehemu ya njia (path) inayolinganishwa na mfumo wa faili.

Ndani ya orodha ya argument, sudo-rs inakubali aina mbili tu maalum, na hakuna hata moja kati ya hizo iliyo pattern. "" inamaanisha hakuna argument. * ya mwisho inamaanisha argument yoyote inayofuata. Kila argument nyingine inalinganishwa kama maandishi halisi (literal text). Kwa hiyo %ops ALL = /sbin/service ntp * ni sawa, kwa sababu ntp ni maandishi halisi na * ipo mwisho. Hata hivyo, sheria kama hii haikupi kile ulichokusudia:

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

app-* ni pattern iliyo katikati ya argument. sudo-rs haipanui (expand) pattern hiyo, kwa hivyo sheria hiyo haijumuishi systemctl restart app-api na sudo inakataa amri hiyo. Amri mbili zinakuambia ukweli kuhusu sheria yoyote kwenye seva yako: sudo -l -U deploy, ikikimbizwa kama root, inaonyesha kile ambacho akaunti hiyo inaweza kukimbiza kihalisi, na sudo visudo -c inakuambia kama faili hilo linafanya parsing vizuri. Zikimbize kabla ya kuanza kuhariri bila mpangilio.

Sheria ya wildcard ilikuwa daima ni mwanya wa kiusalama

Chini ya sudo ya asili, hoja (arguments) unazochapa huunganishwa kuwa kamba moja (string) na kulinganishwa na kamba ya hoja ya sheria hiyo kwa kutumia glob. Glob inalingana na nafasi nyeupe (whitespace). Hiyo ndiyo sehemu ambayo karibu kila mtu huikosa.

Nyaraka za sudo-rs zinatoa maelezo ya wazi zaidi. Sheria ya /bin/rm *.txt inaruhusu pia sudo rm -rf /home .txt, kwa sababu * moja inameza -rf /home na kamba iliyounganishwa bado inaishia na .txt. Sheria hiyo inasomeka kama "faili za maandishi pekee". Inamaanisha "hoja yoyote ile, mradi mstari unaishia na .txt".

Hali hiyo hiyo inatumika kwa mfano wa systemctl. Kwa sababu hoja hulinganishwa kama kamba moja iliyounganishwa, muundo wa mwisho (trailing pattern) unalingana pia na chochote unachoongeza baada yake, kwa hivyo restart app-* inashughulikia restart app-api pamoja na hoja nyingine zozote ambazo mpigaji (caller) anaongeza. Muundo ndani ya hoja hufichua hoja zilizouzunguka, na hoja ndipo nguvu ya amri inapokaa. sudo-rs inakataa muundo huo badala ya kujaribu kuufanya kuwa salama, kwa sababu hakuna namna salama ya jumla ya kuutumia.

Badilisha wildcard na orodha ya amri mahususi

Sheria nyingi za wildcard zipo kwa sababu mtu hakutaka kuandika mistari minne. Andika mistari hiyo minne.

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

Pata njia (path) sahihi. Sheria inayotaja /bin/systemctl kwenye mfumo ambapo binary ni /usr/bin/systemctl haitawahi kufanana, na hitilafu hiyo inaonekana sawa na tatizo la ruhusa (permissions). Thibitisha kwa kutumia command -v systemctl na ubandike kile kinachochapishwa.

Weka sheria hiyo kwenye faili yake ya ziada (drop-in file) badala ya /etc/sudoers, ili uboreshaji wa kifurushi (package upgrade) usigongane na marekebisho yako:

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

Ipe faili jina lisilo na nukta na lisilo na tilde mwishoni. sudo ya asili hupuuza faili zilizomo kwenye sudoers.d ambazo majina yake yana nukta, kwa hivyo 90-deploy.conf ni mfano wa kawaida wa kitu kisichofanya kazi kimya kimya, na kufuata utaratibu huu hakugharimu chochote.

Tumia wrapper inayomilikiwa na root wakati orodha inapokuwa ndefu

Wakati seti ya amri zinazoruhusiwa ni kubwa mno kuorodheshwa, hamisha uamuzi kutoka kwenye sudoers na uweke kwenye programu ndogo inayomilikiwa na 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

Upande wa sudoers kisha hutaja amri moja:

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

Alama ya * mwishoni inakubalika hapa kwa sababu hati hiyo, si sudo, ndiyo inayoamua nini kinaruhusiwa. Hilo ni kweli tu ikiwa hati hiyo inamilikiwa na root na haiwezi kuandikwa na mtu mwingine yeyote. Ikiwa deploy anaweza kuandika kwenye faili hiyo, deploy anaweza kubadilisha yaliyomo na kuendesha chochote kama root, jambo ambalo ni hatari zaidi kuliko sheria ya wildcard uliyoondoa. Hakikisha mode kwa kutumia ls -l, na ikiwa matokeo si dhahiri kwako, kusoma mfuatano wa ruhusa wa drwxr-xr-x huchukua dakika tano kujifunza. Sheria hiyo hiyo inahusu saraka: /usr/local/sbin haipaswi kuandikika na akaunti hiyo pia, kwa sababu saraka inayoweza kuandikwa inamaanisha faili inaweza kubadilishwa kabisa.

Ipe kazi akaunti yake badala ya kutumia sudo rule

Swali bora mara nyingi ni kwa nini amri hiyo inahitaji root hata kidogo. Huduma inayojiendesha kama mtumiaji wake inaweza kusimamiwa na mtumiaji huyo, na hakuna mstari wa sudoers unaohusika. Kwa unit za mfumo, systemd tayari inakabidhi uamuzi huo kwa polkit, kwa hivyo rule inaweza kutaja unit moja na operator mmoja:

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;
    }
});

Hifadhi hiyo kama /etc/polkit-1/rules.d/50-app-api.rules na deploy inaweza kuendesha systemctl restart app-api bila sudo yoyote. Ijaribu kutoka kwenye muktadha kamili utakaotumika, kwa sababu rule inayofanya kazi kwenye SSH session yako inafaa kuthibitishwa kutoka cron kabla ya kuitegemea. Kwa vyovyote vile, akaunti inayofanya kazi hiyo inapaswa kuwepo kwa ajili ya kazi hiyo pekee, ambayo ndiyo hoja ileile nyuma ya akaunti za watumiaji wenye upendeleo mdogo kwenye VPS.

Mambo mengine ambayo sudo-rs haijajumuisha

sudo -E haijatekelezwa. Taja vigezo unavyohitaji kwa kutumia Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY" badala yake, na kumbuka kuwa env_reset imewashwa kila wakati, kwa hivyo chochote kisichohifadhiwa hufutwa.

Hifadhi ya kati ya sudoers katika LDAP haipo tena. sudoers.ldap na cvtsudoers hazijatekelezwa, na kifurushi cha sudo-ldap kiliondolewa katika toleo la 26.04. Uthibitishaji wa LDAP kupitia PAM au SSSD bado unafanya kazi. Sehemu ya sera-ndani-ya-saraka ndiyo iliyo nje ya upeo.

INTERCEPT, ambayo ilijaribu kuzuia shell escapes kutoka kwa amri iliyoruhusiwa, haijatekelezwa. Hata hivyo, haikuwahi kuzuia mtumiaji mwenye nia thabiti. Ikiwa sheria inamruhusu mtu kuendesha kihariri au mkalimani kama root, basi ana mamlaka ya root, na hakuna chaguo la sudo linaloweza kubadilisha hilo.

Kurekodi kwa vipindi (session recording) hakujatekelezwa, kwa hivyo hakuna logi ya I/O na hakuna sudoreplay. Uwekaji wa logi huenda kwenye syslog pekee, na hakuna chaguo la logfile la kuelekeza logi hizo mahali pengine, kwa hivyo ujumbe wa sudo hufika popote ambapo mfumo wako tayari unatuma syslog.

Je, unapaswa kurudi kwenye sudo.ws?

Unaweza, na wakati wa mzunguko wa 26.04 toleo asilia linabaki kwenye vifurushi kwa sababu hii hasa.

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

Nakili njia (paths) kamili kutoka kwenye matokeo ya --config badala ya ukurasa huu, kwa sababu hiyo ndiyo orodha ambayo mfumo wako utaikubali. Kurudi kwenye sudo-rs baadaye kunamaanisha kuweka alternative kwenye njia ya binary ya sudo-rs kutoka kwenye orodha hiyo hiyo.

Weka session ya pili ya SSH ikiwa wazi, umeingia na haifanyi kazi, kabla ya kugusa chochote kinachoathiri sudo. Faili la sudoers linaloshindwa kusomeka, au alternative inayoelekeza kwenye binary ambayo haijasakinishwa, inaweza kukuacha bila njia ya kuwa root kwenye seva ya mbali. Tabia hiyo inapaswa kwenda sambamba na kila kitu kingine unachofanya katika dakika kumi za kwanza kwenye VPS mpya.

Chukulia kurudi nyuma kama muda wa mwisho badala ya suluhisho. Inakupa wiki moja ya kuandika upya sheria ipasavyo, na uandishi huo una thamani yake, kwa sababu kila sheria ya wildcard unayofuta ilikuwa ikitoa ruhusa zaidi kuliko kile mwandishi wake alichokisoma ndani yake.

FAQ

Kwa nini sheria yangu ya wildcard ya sudoers imeacha kufanya kazi kwenye Ubuntu 26.04?

Hii inatokea kwa sababu Ubuntu 26.04 LTS inatumia sudo-rs kama sudo chaguo-msingi, na sudo-rs haitambui mifumo ya wildcard ndani ya hoja (arguments) za amri. Inaruhusu wildcard kwenye jina la faili la amri, "" kumaanisha hakuna hoja, na * moja kama hoja ya mwisho. Sheria kama /usr/bin/systemctl restart app-* huweka mfumo katikati ya hoja, kwa hivyo haitoi ruhusa yoyote na amri hukataliwa. Tekeleza sudo -l -U deploy kama root ili kuona kile akaunti inaruhusiwa kufanya, kisha badilisha sheria hiyo na amri kamili au hati ya wrapper inayomilikiwa na root.

Ninawezaje kurudi kwenye sudo ya asili kwenye Ubuntu 26.04?

Toleo la asili linapatikana katika kifurushi cha sudo, ambacho binaries zake zina kiambishi cha .ws. Kisakinishe kwa kutumia sudo apt install sudo, kisha uelekeze alternative kwake kwa kutumia sudo update-alternatives --set sudo /usr/bin/sudo.ws. Tekeleza update-alternatives --config sudo kwanza ili kusoma njia (paths) kamili ambazo mfumo wako unatoa, na uweke session ya pili ya SSH wazi wakati unafanya mabadiliko haya. Hii hairejeshi sudo-ldap, ambayo iliondolewa kwenye 26.04 bila kujali ni utekelezaji upi unaochagua.

Je, sudo-rs inasoma faili ileile ya /etc/sudoers?

Ndiyo. sudo-rs inasoma /etc/sudoers na faili za ziada zilizo chini ya /etc/sudoers.d/, kwa kutumia sintaksia ileile kwa watumiaji, vikundi, aliases, maelekezo ya run-as na tag ya NOPASSWD. Inatekeleza sehemu ndogo ya lugha ya sudoers, kwa hivyo tofauti huonekana kama vipengele vilivyokosekana badala ya vipengele vinavyofanya kazi kwa njia tofauti. Hariri kwa kutumia sudo visudo, kisha thibitisha kwa sudo visudo -c kabla ya kufunga session yako.

Ni nini kinachochukua nafasi ya sudo -E katika sudo-rs?

sudo -E haijatekelezwa, na ilikuwa tayari imeshauriwa kutotumika katika sudo ya asili, kwa sababu kumpa mchakato wa root mazingira (environment) ambayo anayepiga amri anayatawala ni njia inayojulikana ya kubadilisha jinsi mchakato huo unavyofanya kazi. Badala yake, taja vigezo (variables) unavyohitaji kweli katika sudoers, kwa mstari kama Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY". env_reset huwashwa kila wakati katika sudo-rs na haiwezi kuzimwa, kwa hivyo kila kigezo ambacho hukihifadhi hufutwa.