การตั้งค่า sudo-rs บน Ubuntu และผลกระทบต่อไฟล์ sudoers

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

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

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

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

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

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 และโปรแกรมของมันจะมีส่วนต่อท้ายเป็น .ws ได้แก่ sudo.ws และ visudo.ws

เหตุผลที่ 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 ของตนเอง

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

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

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

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

app-* เป็น pattern ที่อยู่ตรงกลางของอาร์กิวเมนต์ sudo-rs จะไม่ขยายค่า (expand) 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 สำหรับ system units นั้น 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.ws
update-alternatives --config sudo
sudo update-alternatives --set sudo /usr/bin/sudo.ws

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

เปิดเซสชัน SSH ทิ้งไว้อีกหนึ่งเซสชันโดยล็อกอินค้างไว้ก่อนที่คุณจะดำเนินการใดๆ ที่ส่งผลต่อ sudo หากไฟล์ sudoers ไม่สามารถ parse ได้ หรือการตั้งค่า 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.ws ให้ติดตั้งด้วย sudo apt install sudo.ws จากนั้นชี้ค่า 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 และไม่สามารถปิดได้ ดังนั้นตัวแปรทุกตัวที่คุณไม่ได้เก็บไว้จะถูกล้างออกทั้งหมด