วิธีตั้งค่า sudoers เมื่อ Ubuntu 26.04 เปลี่ยนใช้ sudo-rs

สิ่งที่ sudo-rs เปลี่ยนแปลงบน Ubuntu

Ubuntu 26.04 LTS ใช้ sudo-rs เป็น sudo เริ่มต้น ดังนั้นคำสั่ง sudo บนเซิร์ฟเวอร์ที่ติดตั้งใหม่จะรันโปรแกรมที่เขียนด้วย Rust แทนโปรแกรม C ดั้งเดิม ไฟล์ sudoers ส่วนใหญ่ยังคงทำงานได้ตามปกติ กฎที่ใช้งานไม่ได้คือการใช้ wildcard ภายในอาร์กิวเมนต์ของคำสั่ง เนื่องจาก sudo-rs ไม่จับคู่รูปแบบ glob กับข้อความในอาร์กิวเมนต์

Ubuntu 25.10 เป็นรุ่นแรกที่เปลี่ยนมาใช้ และ 26.04 LTS ยังคงใช้ต่อ ส่วน Ubuntu 24.04 LTS ไม่ได้รับผลกระทบเนื่องจากยังคงเลือกใช้ sudo ดั้งเดิม เว้นแต่คุณจะติดตั้ง sudo-rs ด้วยตนเอง ช่วงเวลาที่เรื่องนี้มีความสำคัญคือตอนที่คุณ อัปเกรดจาก Ubuntu 24.04 เป็น 26.04 หรือตอนที่คุณสร้างเซิร์ฟเวอร์ใหม่บนรุ่นที่ใหม่กว่า หากคุณใช้งานรุ่นระหว่างกาลด้วย ความแตกต่างระหว่าง Ubuntu รุ่น LTS และรุ่นระหว่างกาลบนเซิร์ฟเวอร์ จะอธิบายว่าเครื่องใดจะได้รับผลกระทบจากการเปลี่ยนแปลงนี้ก่อน

ตรวจสอบว่าเซิร์ฟเวอร์ของคุณกำลังรัน sudo ตัวใดอยู่

อย่าตัดสินจากเลขเวอร์ชันของระบบปฏิบัติการ ให้สอบถามจากตัวเครื่องโดยตรง

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

จงเชื่อถือ sudo --version บนเครื่องของคุณเองมากกว่าตารางเวอร์ชันใดๆ บนอินเทอร์เน็ต รวมถึงหน้านี้ด้วย update-alternatives --config sudo คืออีกครึ่งหนึ่งของคำตอบ โดยจะแสดงรายการผู้ให้บริการ /usr/bin/sudo ที่ติดตั้งอยู่ทั้งหมดและระบุตัวที่ถูกเลือกใช้งานอยู่ การที่แพ็กเกจถูกติดตั้งไว้ไม่ได้หมายความว่าแพ็กเกจนั้นถูกเลือกใช้งาน ดังนั้นให้ตรวจสอบที่การเลือก ไม่ใช่รายการแพ็กเกจ

การใช้งานทั้งสองแบบถูกจัดทำเป็นแพ็กเกจในช่วงเปลี่ยนผ่าน ตัวที่เขียนด้วย Rust คือ sudo-rs ซึ่งอยู่ที่เวอร์ชัน 0.2.13 ใน 26.04 ณ เดือนสิงหาคม 2026 ส่วนตัวดั้งเดิมที่ดูแลโดย Todd C. Miller ยังคงเป็นแพ็กเกจ sudo สิ่งที่เปลี่ยนไปคือโปรแกรมของมันจะมีส่วนต่อท้าย .ws เพื่อให้สามารถติดตั้งทั้งสองตัวพร้อมกันได้ ได้แก่ /usr/bin/sudo.ws และ /usr/bin/visudo.ws ควบคู่ไปกับ cvtsudoers.ws และ sudoreplay.ws จากการตรวจสอบกับคลังแพ็กเกจ 26.04 ในเดือนกันยายน 2026 พบว่า dpkg -L sudo แสดงรายการไบนารีที่มีส่วนต่อท้าย และ sudo-rs จัดส่ง /usr/bin/sudo-rs ไว้ข้างๆ กัน

เหตุผลที่ Ubuntu เปลี่ยนมาใช้ sudo-rs

sudo ทำงานด้วยสิทธิ์ setuid root ผู้ใช้ทุกคนบนเครื่องสามารถเรียกใช้งานได้ และโปรแกรมจะเริ่มทำงานด้วยสิทธิ์สูงสุด ดังนั้นข้อผิดพลาดด้านหน่วยความจำภายในโปรแกรมจึงกลายเป็นช่องโหว่ที่ทำให้ผู้ใช้ทั่วไปยกระดับสิทธิ์เป็น root ได้โดยตรง ช่องโหว่ CVE-2021-3156 คือตัวอย่างที่ชัดเจน ซึ่งเป็นปัญหา heap buffer overflow ที่ผู้ใช้ในเครื่องทุกคนสามารถเข้าถึงได้ และช่องโหว่นี้แฝงอยู่ในโค้ดที่ปล่อยออกมานานถึงสิบปี ภาษา Rust สามารถตรวจจับข้อผิดพลาดประเภทนี้ได้ตั้งแต่ขั้นตอนการคอมไพล์ ซึ่งเป็นเหตุผลหลักในการเขียนโปรแกรมนี้ขึ้นมาใหม่

เหตุผลประการที่สองคือขอบเขตการทำงาน ซึ่งเป็นส่วนที่ส่งผลกระทบต่อการตั้งค่าของคุณ sudo เวอร์ชันดั้งเดิมได้รวบรวมฟีเจอร์จำนวนมากไว้ตลอดระยะเวลาสามทศวรรษ และทุกฟีเจอร์หมายถึงโค้ดที่ต้องทำงานด้วยสิทธิ์ root เพิ่มขึ้น sudo-rs จึงถูกออกแบบมาให้รองรับฟีเจอร์เพียงบางส่วนเท่านั้น สิ่งใดที่ผู้พัฒนาเห็นว่าเฉพาะทางเกินไปหรืออาจก่อให้เกิดอันตรายจะถูกตัดออก ดังนั้นกฎใน sudoers ที่คุณเคยใช้งานได้มาหลายปีอาจไม่มีอยู่ในเวอร์ชันนี้ ซึ่งกฎแบบ wildcard ของคุณก็เป็นหนึ่งในนั้น

ความปลอดภัยด้านหน่วยความจำช่วยกำจัดข้อผิดพลาดได้เพียงประเภทเดียวเท่านั้น ไม่ได้ทำให้โปรแกรมปราศจากบั๊กโดยสิ้นเชิง และ sudo-rs เองก็มีการปล่อยแพตช์ความปลอดภัยออกมาตั้งแต่เริ่มถูกนำมาใช้เป็นค่าเริ่มต้น ดังนั้นคุณควรหมั่นอัปเดตแพตช์เช่นเดียวกับซอฟต์แวร์อื่นๆ

กฎ sudoers ใดบ้างที่ยังคงใช้งานได้

ไฟล์ดังกล่าวเป็นไฟล์เดียวกัน sudo-rs อ่านค่าจาก /etc/sudoers และไฟล์ที่อยู่ใน /etc/sudoers.d/ โดยรองรับคำสั่งทั่วไปที่ผู้ดูแลระบบเขียนไว้ ดังนี้:

• deploy ALL=(ALL:ALL) ALL และรูปแบบกลุ่ม เช่น %sudo ALL=(ALL:ALL) ALL
• แท็ก NOPASSWD: และ PASSWD:
• User_Alias, Runas_Alias, Host_Alias และ Cmnd_Alias
• คำสั่งที่ระบุรายการอาร์กิวเมนต์แบบเจาะจง ตัวอย่างเช่น /usr/bin/systemctl restart app-api
• คำสั่งที่ตามด้วย "" ซึ่งอนุญาตให้ใช้คำสั่งนั้นได้เฉพาะกรณีที่ไม่มีอาร์กิวเมนต์ใดๆ เลย
• คำสั่งที่ตามด้วย * เป็นอาร์กิวเมนต์สุดท้าย ซึ่งอนุญาตให้มีอาร์กิวเมนต์ต่อท้ายใดๆ ก็ได้
• พาธของไดเรกทอรีที่ลงท้ายด้วย / ซึ่งอนุญาตให้ใช้คำสั่งใดก็ได้ภายในไดเรกทอรีนั้น
• ! เพื่อยกเว้นคำสั่งออกจากรายการ
• ชุดย่อยที่มีประโยชน์ของ Defaults รวมถึง secure_path, env_keep, env_check, timestamp_timeout, passwd_tries, editor, umask, targetpw, rootpw และ use_pty

มีค่าเริ่มต้นสองรายการที่ทำงานต่างออกไปและมักทำให้ผู้ใช้งานสับสน env_reset ไม่สามารถปิดการใช้งานใน sudo-rs ได้ โดยจะเปิดใช้งานอยู่เสมอ ส่วน use_pty จะถูกเปิดใช้งานเป็นค่าเริ่มต้น ดังนั้นคำสั่งจะทำงานภายใน pseudo-terminal ของตนเอง

เหตุใดกฎ wildcard ใน sudoers ของคุณจึงไม่ทำงาน

Wildcard ยังคงอนุญาตให้ใช้ได้ในตำแหน่งเดียว คือชื่อไฟล์ของคำสั่ง กฎของ %ops ALL = /sbin/fsck* ยังคงอนุญาตให้ใช้ sudo fsck และ sudo fsck_exfat ได้ เนื่องจาก * เป็นส่วนหนึ่งของพาธที่ถูกนำไปตรวจสอบกับระบบไฟล์

ภายในรายการอาร์กิวเมนต์ sudo-rs ยอมรับรูปแบบพิเศษเพียงสองแบบเท่านั้น และไม่มีรูปแบบใดที่เป็น pattern เลย "" หมายถึงไม่มีอาร์กิวเมนต์ ส่วน * ที่อยู่ท้ายสุดหมายถึงอาร์กิวเมนต์ใดๆ ที่ตามมา อาร์กิวเมนต์อื่นๆ ทั้งหมดจะถูกเปรียบเทียบเป็นข้อความตัวอักษรตรงตัว ดังนั้น %ops ALL = /sbin/service ntp * จึงใช้งานได้ปกติ เพราะ ntp เป็นข้อความตรงตัวและ * อยู่ในตำแหน่งสุดท้าย อย่างไรก็ตาม กฎในลักษณะนี้จะไม่ให้สิทธิ์ตามที่คุณต้องการ:

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

app-* เป็น pattern ที่อยู่ตรงกลางของอาร์กิวเมนต์ sudo-rs จะไม่ขยายผล pattern นี้ ดังนั้นกฎดังกล่าวจึงไม่ครอบคลุมถึง systemctl restart app-api และ sudo จะปฏิเสธการรันคำสั่งนั้น มีคำสั่งสองคำสั่งที่จะบอกความจริงเกี่ยวกับกฎบนเซิร์ฟเวอร์ของคุณ: sudo -l -U deploy เมื่อรันด้วยสิทธิ์ root จะแสดงรายการคำสั่งที่บัญชีนั้นสามารถรันได้จริง และ sudo visudo -c จะบอกคุณว่าไฟล์ดังกล่าวสามารถอ่านค่า (parse) ได้หรือไม่ ให้รันคำสั่งเหล่านี้ก่อนที่คุณจะเริ่มแก้ไขไฟล์แบบสุ่ม

กฎ wildcard เป็นช่องโหว่มาโดยตลอด

ภายใต้ sudo แบบดั้งเดิม อาร์กิวเมนต์ที่คุณพิมพ์จะถูกรวมเข้าเป็นสตริงเดียวและนำไปจับคู่กับสตริงอาร์กิวเมนต์ของกฎด้วย glob ซึ่ง glob นั้นสามารถจับคู่กับช่องว่างได้ นี่คือส่วนที่เกือบทุกคนมองข้าม

เอกสารประกอบของ sudo-rs ได้แสดงตัวอย่างที่ชัดเจนที่สุด กฎ /bin/rm *.txt ยังอนุญาตให้ใช้ sudo rm -rf /home .txt ได้ด้วย เนื่องจาก * ตัวเดียวจะกลืน -rf /home เข้าไป และสตริงที่รวมกันนั้นยังคงลงท้ายด้วย .txt กฎนี้ดูเหมือนจะเป็น "ไฟล์ข้อความเท่านั้น" แต่ในความเป็นจริงมันหมายถึง "อาร์กิวเมนต์ใดๆ ก็ได้ ตราบใดที่บรรทัดลงท้ายด้วย .txt"

กรณีเดียวกันนี้ใช้กับตัวอย่างของ systemctl เนื่องจากอาร์กิวเมนต์ถูกเปรียบเทียบในรูปแบบสตริงเดียวที่รวมกันแล้ว รูปแบบที่อยู่ท้ายสุดจึงจับคู่กับสิ่งใดก็ตามที่คุณเพิ่มต่อท้ายเข้าไปด้วย ดังนั้น restart app-* จึงครอบคลุมถึง restart app-api บวกกับอาร์กิวเมนต์เพิ่มเติมใดๆ ที่ผู้เรียกเพิ่มเข้ามา รูปแบบที่อยู่ภายในอาร์กิวเมนต์จะเปิดเผยอาร์กิวเมนต์ที่อยู่รอบๆ และอาร์กิวเมนต์คือจุดที่อำนาจของคำสั่งนั้นดำรงอยู่ sudo-rs จึงปฏิเสธโครงสร้างดังกล่าวแทนที่จะพยายามทำให้มันปลอดภัย เพราะไม่มีรูปแบบทั่วไปใดที่ปลอดภัยสำหรับโครงสร้างนี้

แทนที่ wildcard ด้วยรายการคำสั่งที่ระบุชัดเจน

กฎ wildcard ส่วนใหญ่เกิดขึ้นเพราะผู้ใช้ไม่ต้องการพิมพ์สี่บรรทัด ให้คุณพิมพ์สี่บรรทัดนั้นลงไปแทน

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 ให้ถูกต้อง กฎที่อ้างถึง /bin/systemctl บนระบบที่ไฟล์ binary อยู่ที่ /usr/bin/systemctl จะไม่มีทางตรงกัน และความล้มเหลวที่เกิดขึ้นจะมีลักษณะเหมือนปัญหาเรื่องสิทธิ์การเข้าถึง ให้ยืนยันด้วย command -v systemctl แล้วคัดลอกสิ่งที่คำสั่งแสดงผลออกมา

ให้ใส่กฎไว้ในไฟล์ drop-in ของตัวเองแทนที่จะใส่ใน /etc/sudoers เพื่อป้องกันไม่ให้การอัปเกรดแพ็กเกจไปทับซ้อนกับการแก้ไขของคุณ:

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

ตั้งชื่อไฟล์โดยไม่มีจุดและไม่มีเครื่องหมาย tilde ต่อท้าย sudo เวอร์ชันดั้งเดิมจะเพิกเฉยต่อไฟล์ใน sudoers.d ที่มีชื่อประกอบด้วยจุด ดังนั้น 90-deploy.conf จึงเป็นสิ่งที่ไม่มีผลใดๆ โดยที่คุณไม่รู้ตัว การปฏิบัติตามธรรมเนียมนี้ไม่มีค่าใช้จ่ายใดๆ เพิ่มเติม

ใช้ wrapper ที่ root เป็นเจ้าของเมื่อรายการคำสั่งยาวเกินไป

เมื่อชุดคำสั่งที่อนุญาตมีจำนวนมากเกินกว่าจะระบุไว้ในรายการ ให้ย้ายการตัดสินใจออกจาก 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 ให้ระบุเพียงคำสั่งเดียว:

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

การใช้ * ปิดท้ายในกรณีนี้ถือว่ายอมรับได้ เพราะสคริปต์จะเป็นตัวตัดสินว่าอนุญาตให้ทำอะไรได้บ้าง ไม่ใช่ sudo เงื่อนไขนี้จะเป็นจริงก็ต่อเมื่อสคริปต์นั้นถูกถือครองโดย root และไม่มีผู้ใช้อื่นสามารถเขียนทับได้เท่านั้น หาก deploy สามารถเขียนไฟล์นี้ได้ deploy ก็จะสามารถแก้ไขเนื้อหาภายในและรันคำสั่งใดๆ ในฐานะ root ได้ ซึ่งเลวร้ายยิ่งกว่ากฎ wildcard ที่คุณเพิ่งลบออกไป ให้ตรวจสอบโหมดของไฟล์ด้วย ls -l และหากคุณไม่เข้าใจผลลัพธ์ที่แสดง การอ่านสตริงสิทธิ์ drwxr-xr-x ใช้เวลาเรียนรู้เพียงห้านาที กฎเดียวกันนี้ยังครอบคลุมไปถึงไดเรกทอรีด้วย: /usr/local/sbin จะต้องไม่เปิดให้บัญชีผู้ใช้นั้นเขียนได้เช่นกัน เพราะหากไดเรกทอรีสามารถเขียนได้ ก็หมายความว่าไฟล์ภายในสามารถถูกแทนที่ได้ทั้งหมด

กำหนดบัญชีผู้ใช้เฉพาะสำหรับงานแทนการใช้กฎ sudo

คำถามที่ดีกว่ามักจะเป็นเหตุผลว่าทำไมคำสั่งนั้นจึงจำเป็นต้องใช้สิทธิ์ root บริการที่รันด้วยบัญชีผู้ใช้ของตนเองสามารถจัดการได้โดยผู้ใช้นั้นโดยตรง และไม่จำเป็นต้องแก้ไขไฟล์ sudoers สำหรับ unit ของ systemd นั้น systemd ได้มอบหมายการตัดสินใจดังกล่าวให้แก่ polkit อยู่แล้ว ดังนั้นกฎจึงสามารถระบุ unit หนึ่งรายการและผู้ดำเนินการหนึ่งคนได้:

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 จะสามารถรัน systemctl restart app-api ได้โดยไม่ต้องใช้ sudo เลย ให้ทดสอบจากบริบทเดียวกับที่จะใช้งานจริง เนื่องจากกฎที่ทำงานได้ใน SSH session ของคุณควรได้รับการยืนยันจาก cron ก่อนที่คุณจะพึ่งพามัน ไม่ว่าจะด้วยวิธีใด บัญชีที่ทำงานนั้นควรมีไว้สำหรับงานดังกล่าวเพียงอย่างเดียว ซึ่งเป็นเหตุผลเดียวกันกับแนวคิดเรื่อง บัญชีผู้ใช้ที่มีสิทธิ์จำกัดบน VPS

สิ่งที่ sudo-rs ตัดออกไป

sudo -E ยังไม่ได้ถูกนำมาใช้งาน ให้ระบุตัวแปรที่คุณต้องการด้วย Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY" แทน และโปรดจำไว้ว่า env_reset จะเปิดใช้งานอยู่เสมอ ดังนั้นข้อมูลใดที่ไม่ได้ถูกเก็บไว้จะถูกล้างออก

การจัดเก็บ sudoers ไว้ที่ศูนย์กลางใน LDAP ถูกยกเลิกไปแล้ว sudoers.ldap และ cvtsudoers ยังไม่ได้ถูกนำมาใช้งาน และแพ็กเกจ sudo-ldap ได้ถูกถอดออกในเวอร์ชัน 26.04 การยืนยันตัวตนผ่าน LDAP โดยใช้ PAM หรือ SSSD ยังคงใช้งานได้ตามปกติ ส่วนที่ถูกตัดออกไปคือส่วนของการกำหนดนโยบายผ่านไดเรกทอรี

INTERCEPT ซึ่งพยายามป้องกันการหลบเลี่ยงเชลล์ (shell escapes) จากคำสั่งที่ได้รับอนุญาตนั้น ยังไม่ได้ถูกนำมาใช้งาน เนื่องจากฟีเจอร์นี้ไม่สามารถป้องกันผู้ใช้ที่มีความตั้งใจจริงได้อยู่แล้ว หากกฎอนุญาตให้ใครบางคนรันโปรแกรมแก้ไขข้อความหรืออินเทอร์พรีเตอร์ในฐานะ root ผู้นั้นก็จะมีสิทธิ์ root ทันที และไม่มีตัวเลือกใดของ sudo ที่จะเปลี่ยนแปลงความจริงข้อนี้ได้

การบันทึกเซสชันยังไม่ได้ถูกนำมาใช้งาน ดังนั้นจึงไม่มี I/O log และไม่มี sudoreplay การบันทึกเหตุการณ์จะส่งไปยัง syslog เท่านั้น และไม่มีตัวเลือก logfile สำหรับเปลี่ยนเส้นทางไปยังที่อื่น ดังนั้นข้อความจาก sudo จะถูกส่งไปยังปลายทางที่ระบบของคุณกำหนดให้ syslog ส่งไปตามปกติอยู่แล้ว

คุณควรเปลี่ยนกลับไปใช้ sudo.ws หรือไม่?

คุณสามารถทำได้ และในระหว่างรอบการพัฒนา 26.04 ตัวดั้งเดิมจะยังคงถูกจัดเตรียมไว้ด้วยเหตุผลนี้โดยเฉพาะ

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

ให้คัดลอกพาธที่ถูกต้องจากผลลัพธ์ของ --config แทนการคัดลอกจากหน้านี้ เนื่องจากนั่นคือรายการที่ระบบของคุณยอมรับ การเปลี่ยนกลับไปใช้ sudo-rs ในภายหลังหมายถึงการตั้งค่า alternative ให้ชี้ไปยังพาธของไบนารี sudo-rs จากรายการเดียวกัน

เปิดเซสชัน SSH ทิ้งไว้อีกหนึ่งเซสชันโดยล็อกอินค้างไว้ ก่อนที่คุณจะดำเนินการใดๆ ที่ส่งผลต่อ sudo ไฟล์ sudoers ที่ประมวลผลไม่ผ่าน หรือการตั้งค่า alternative ที่ชี้ไปยังไบนารีที่ไม่ได้ติดตั้ง อาจทำให้คุณไม่สามารถเข้าถึงสิทธิ์ root บนเซิร์ฟเวอร์ระยะไกลได้ นิสัยนี้ควรเป็นส่วนหนึ่งของสิ่งที่คุณทำใน สิบนาทีแรกบน VPS ใหม่

ให้มองว่าการเปลี่ยนกลับเป็นเพียงการซื้อเวลามากกว่าการแก้ไขปัญหาถาวร วิธีนี้ช่วยให้คุณมีเวลาหนึ่งสัปดาห์ในการเขียนกฎใหม่ให้ถูกต้อง และการเขียนใหม่นั้นคุ้มค่าที่จะทำ เพราะกฎแบบ wildcard ทุกข้อที่คุณลบออกไปนั้น ได้ให้สิทธิ์เกินกว่าที่ผู้เขียนกฎตั้งใจไว้ในตอนแรก

FAQ

ทำไมกฎ wildcard ใน sudoers ของฉันถึงใช้งานไม่ได้บน Ubuntu 26.04?

เนื่องจาก Ubuntu 26.04 LTS เลือกใช้ sudo-rs เป็น sudo เริ่มต้น และ sudo-rs ไม่รองรับการจับคู่รูปแบบ wildcard ภายในอาร์กิวเมนต์ของคำสั่ง โดยจะอนุญาตให้ใช้ wildcard ได้เฉพาะในชื่อไฟล์ของคำสั่งเท่านั้น ส่วน "" หมายถึงไม่มีอาร์กิวเมนต์ และ * หมายถึงอาร์กิวเมนต์ตัวสุดท้ายเพียงตัวเดียว กฎอย่างเช่น /usr/bin/systemctl restart app-* นั้นวางรูปแบบไว้ตรงกลางอาร์กิวเมนต์ จึงไม่ได้รับสิทธิ์ใดๆ และคำสั่งจะถูกปฏิเสธ ให้รัน sudo -l -U deploy ในฐานะ root เพื่อตรวจสอบสิทธิ์ที่บัญชีนั้นได้รับจริง จากนั้นให้เปลี่ยนกฎเป็นคำสั่งที่ระบุเจาะจง หรือใช้ wrapper script ที่เป็นของ root แทน

ฉันจะเปลี่ยนกลับไปใช้ sudo ตัวเดิมบน Ubuntu 26.04 ได้อย่างไร?

sudo ตัวเดิมถูกรวมอยู่ในแพ็กเกจ sudo ซึ่งไฟล์ไบนารีจะมี suffix เป็น .ws ให้ติดตั้งด้วย sudo apt install sudo จากนั้นชี้ค่า alternative ไปที่ไฟล์ดังกล่าวด้วย sudo update-alternatives --set sudo /usr/bin/sudo.ws ให้รัน update-alternatives --config sudo ก่อนเพื่ออ่าน path ที่ถูกต้องในระบบของคุณ และควรเปิด SSH session สำรองไว้ในขณะที่ทำการเปลี่ยนแปลง วิธีนี้จะไม่นำ sudo-ldap กลับมา เนื่องจากถูกถอดออกจาก 26.04 แล้วไม่ว่าคุณจะเลือกใช้ sudo ตัวใดก็ตาม

sudo-rs อ่านไฟล์ /etc/sudoers ไฟล์เดียวกันหรือไม่?

ใช่ sudo-rs อ่านไฟล์ /etc/sudoers และไฟล์ย่อยภายใต้ /etc/sudoers.d/ โดยใช้ไวยากรณ์เดียวกันสำหรับผู้ใช้, กลุ่ม, alias, การระบุสิทธิ์ run-as และแท็ก NOPASSWD ทั้งนี้ sudo-rs รองรับภาษา sudoers เพียงบางส่วน ดังนั้นความแตกต่างที่พบจะเป็นลักษณะของฟีเจอร์ที่ขาดหายไปมากกว่าการทำงานที่ผิดเพี้ยนไปจากเดิม ให้แก้ไขด้วย sudo visudo และตรวจสอบความถูกต้องด้วย sudo visudo -c ก่อนปิด session ของคุณ

อะไรมาแทนที่ sudo -E ใน sudo-rs?

sudo -E ไม่ถูกนำมาใช้งาน และใน sudo ตัวเดิมก็ไม่แนะนำให้ใช้อยู่แล้ว เนื่องจากการส่ง environment ที่ผู้เรียกควบคุมได้ให้กับกระบวนการ root เป็นวิธีที่ทราบกันดีในการเปลี่ยนพฤติกรรมของกระบวนการนั้น ให้ระบุชื่อตัวแปรที่คุณต้องการใช้งานจริงใน sudoers แทน ด้วยบรรทัดเช่น Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY" ส่วน env_reset จะถูกเปิดใช้งานเสมอใน sudo-rs และไม่สามารถปิดได้ ดังนั้นตัวแปรทุกตัวที่คุณไม่ได้เก็บไว้จะถูกล้างออกทั้งหมด