Jinsi sudo-rs inavyobadilisha sudoers kwenye Ubuntu 26.04

Mabadiliko ya sudo-rs kwenye Ubuntu

Ubuntu 26.04 LTS inakuja na 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 kawaida. Kanuni inayoshindwa kufanya kazi ni ile yenye wildcard ndani ya hoja (arguments) za amri, kwa sababu sudo-rs hailinganishi mifumo ya glob dhidi ya maandishi ya hoja.

Ubuntu 25.10 ilifanya mabadiliko haya kwanza na 26.04 LTS ikaendeleza. Ubuntu 24.04 LTS haiathiriwi, 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 unapoandaa seva mpya kwenye toleo jipya zaidi. Ikiwa unaendesha matoleo ya mpito, jinsi matoleo ya LTS na ya mpito ya Ubuntu yanavyotofautiana kwenye seva inaelezea ni mashine ipi inayokutana na mabadiliko kama haya kwanza.

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

Usijaribu kubaini hili kwa kutumia namba ya toleo la mfumo. Iulize mashine yenyewe.

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

Amini sudo --version kwenye seva yako mwenyewe kuliko jedwali lolote la matoleo kwenye mtandao, 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 wawili 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, limefungashwa kama sudo.ws, na programu zake hubeba kiambishi .ws: sudo.ws na visudo.ws.

Kwa nini Ubuntu ilihamia kwenye sudo-rs

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

Sababu ya pili ni wigo (scope), na hii ndiyo inayogusa usanidi wako. sudo ya asili imekusanya seti kubwa ya vipengele kwa miongo mitatu, na kila kipengele ni msimbo zaidi unaoendeshwa kama root. sudo-rs hutekeleza sehemu ndogo ya vipengele hivyo kwa makusudi. Kila kitu ambacho waandishi wake walikiona kuwa ni cha kipekee au chenye madhara kiliachwa, kwa hivyo kanuni ya sudoers iliyofanya kazi kwa miaka inaweza tu kutokuwepo. Kanuni 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 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 za ziada
• njia ya saraka (directory path) inayoishia na /, ambayo inaruhusu amri yoyote iliyo ndani ya 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 huwakanganya watumiaji. 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 inayotumia 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 * iko mwishoni. Hata hivyo, sheria kama hii haikupi chochote 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 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, inachapisha kile ambacho akaunti hiyo inaweza kukimbiza kihalisi, na sudo visudo -c inakuambia kama faili inasomeka (parse) vizuri. Zikimbize kabla ya kuanza kuhariri bila mpangilio.

Sheria ya wildcard ilikuwa daima ni mwanya

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

Nyaraka za sudo-rs hutoa maelezo yaliyo wazi zaidi. Sheria ya /bin/rm *.txt pia inaruhusu 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 tu mstari uishie na .txt".

Hali hiyo hiyo inatumika kwa mfano wa systemctl. Kwa sababu hoja hulinganishwa kama kamba moja iliyounganishwa, muundo wa mwisho pia hulingana na chochote unachoongeza baada yake, kwa hivyo restart app-* inashughulikia restart app-api pamoja na hoja nyingine zozote ambazo mpigaji huongeza. Muundo ndani ya hoja hufichua hoja zinazouzunguka, na hoja ndipo nguvu ya amri ilipo. sudo-rs hukataa muundo huo badala ya kujaribu kuufanya kuwa salama, kwa sababu hakuna umbo la jumla lililo salama la muundo huo.

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 sahihi ya faili (path). Sheria inayotaja /bin/systemctl kwenye mfumo ambapo binary ni /usr/bin/systemctl haitawahi kufanana, na hitilafu hiyo inaonekana kama tatizo la ruhusa (permissions). Thibitisha kwa kutumia command -v systemctl na ubandike kile inachochapisha.

Weka sheria hiyo kwenye faili yake ya pekee ya drop-in 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. sudoers.d ya asili hupuuza faili ambazo majina yake yana nukta, kwa hivyo 90-deploy.conf ni mfano wa kawaida wa kitu kisichofanya kazi kimyakimya, 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 script, si sudo, ndiyo inayoamua nini kinaruhusiwa. Hii ni kweli tu ikiwa script 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. Hakiki mode kwa kutumia ls -l, na ikiwa matokeo si dhahiri kwako, kusoma kamba ya ruhusa ya 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 unaohitajika. Kwa ajili ya system units, systemd tayari hukabidhi 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 katika muktadha kamili utakaotumika, kwa sababu rule inayofanya kazi katika SSH session yako inafaa kuthibitishwa kutoka cron kabla hujaitegemea. Kwa vyovyote vile, akaunti inayofanya kazi hiyo inapaswa kuwepo kwa ajili ya kazi hiyo pekee, ambayo ndiyo hoja ile ile iliyo 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 26.04. Uthibitishaji wa LDAP kupitia PAM au SSSD bado unafanya kazi. Sehemu ya sera-ndani-ya-saraka ndiyo iliyo nje ya wigo huu.

INTERCEPT, ambayo ilijaribu kuzuia shell escapes kutoka kwa amri iliyoruhusiwa, haijatekelezwa. Haikuwahi kuzuia mtumiaji aliyedhamiria hata hivyo. Ikiwa sheria inamruhusu mtu kuendesha kihariri au mkalimani kama root, ana root, na hakuna chaguo la sudo linaloweza kubadilisha hilo.

Kurekodi kwa kipindi (session recording) hakujatekelezwa, kwa hivyo hakuna I/O log na hakuna sudoreplay. Uwekaji kumbukumbu (logging) huenda kwenye syslog pekee, na hakuna chaguo la logfile la kuelekeza kwingine, kwa hivyo ujumbe wa sudo hufika popote ambapo mfumo wako tayari hutuma syslog.

Je, unapaswa kurudi kwenye sudo.ws?

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

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

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

Weka kikao cha pili cha SSH kikiwa wazi, kimeingia na kutokuwa na shughuli, kabla ya kugusa chochote kinachoathiri sudo. Faili la sudoers linaloshindwa kusomeka, au mbadala unaoelekeza kwenye binary ambayo haijasakinishwa, linaweza kukuacha bila njia ya kuwa root kwenye seva ya mbali. Tabia hiyo inapaswa kuwa sehemu ya kila kitu unachofanya katika dakika kumi za kwanza kwenye VPS mpya.

Chukulia kurudi nyuma kama muda wa mwisho badala ya suluhisho. Hii 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 ilivyokusudiwa na mwandishi wake.

FAQ

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

Kwa sababu Ubuntu 26.04 LTS inachagua sudo-rs kama sudo chaguo-msingi, na sudo-rs hailingani na mifumo ya wildcard ndani ya hoja (arguments) za amri. Inaruhusu wildcard katika jina la faili la amri, "" kumaanisha hakuna hoja, na * moja kama hoja ya mwisho. Sheria kama /usr/bin/systemctl restart app-* huweka muundo katikati ya hoja, kwa hivyo haitoi ruhusa yoyote na amri hukataliwa. Tekeleza sudo -l -U deploy kama root ili kuona kile akaunti inacho kweli, 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 limefungashwa kama sudo.ws. Iweke kwa kutumia sudo apt install sudo.ws, kisha uelekeze alternative kwake kwa kutumia sudo update-alternatives --set sudo /usr/bin/sudo.ws. Tekeleza update-alternatives --config sudo kwanza ili kusoma njia kamili ambazo mfumo wako unatoa, na uweke kikao cha pili cha SSH wazi wakati unafanya mabadiliko hayo. Hii hairejeshi sudo-ldap, ambayo iliondolewa kwenye 26.04 bila kujali utekelezaji 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, alias, 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 tofauti. Hariri kwa kutumia sudo visudo, kisha thibitisha kwa sudo visudo -c kabla ya kufunga kikao chako.

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

sudo -E haijatekelezwa, na ilikuwa tayari imekatishwa tamaa katika sudo ya asili, kwa sababu kumpa mchakato wa root mazingira ambayo anayepiga amri anayadhibiti ni njia inayojulikana ya kubadilisha jinsi mchakato huo unavyofanya kazi. Taja vigezo (variables) unavyohitaji kweli katika sudoers badala yake, kwa mstari kama Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY". env_reset inafanya kazi kila wakati katika sudo-rs na haiwezi kuzimwa, kwa hivyo kila kigezo ambacho hukiweki hufutwa.