0Pricing
Linux Command Line & Bash Scripting Mastery · บทเรียน

การทำงานด้วยสิทธิ์น้อยที่สุดและวินัยในการใช้ sudo

ลดสิทธิ์ กำหนดขอบเขตกฎ sudo อย่างรัดกุม และตรวจสอบ UID ที่มีผลก่อนการดำเนินการที่มีความเสี่ยง

การทำงานด้วยสิทธิ์น้อยที่สุดและวินัยในการใช้ sudo เป็นบทเรียน Linux Command Line & Bash Scripting Mastery ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Linux Command Line & Bash Scripting Mastery และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Linux Command Line & Bash Scripting Mastery มีบทเรียนทั้งหมด 4 บทเรียน

เหตุใดสิทธิ์เท่าที่จำเป็นจึงสำคัญในสคริปต์เชลล์

การละเมิดความปลอดภัยส่วนใหญ่ในการทำงานอัตโนมัติเกิดขึ้นไม่ใช่เพราะช่องโหว่พิสดาร แต่เพราะสคริปต์ทำงานด้วยสิทธิ์มากเกินความจำเป็น งาน cron ที่ทำงานในฐานะ root ทั้งที่ต้องการเพียงหมุนเวียนไฟล์บันทึก เป็นเหตุร้ายที่รอเกิดขึ้น

หลักการสิทธิ์เท่าที่จำเป็นระบุว่า: ทุกโพรเซสควรทำงานโดยใช้เฉพาะสิทธิ์ที่จำเป็นต่อหน้าที่ของตน — และไม่มากไปกว่านั้น สำหรับการเขียนสคริปต์ Bash หมายถึง:

  • ทำงานในฐานะผู้ใช้ที่ไม่มีสิทธิ์พิเศษเมื่อเป็นไปได้
  • ยกระดับเป็น root เฉพาะคำสั่งที่จำเป็นต้องใช้เท่านั้น
  • ลดสิทธิ์ทันทีที่งานซึ่งต้องใช้สิทธิ์สูงเสร็จสิ้น
  • อย่าจัดเก็บหรือสืบทอดข้อมูลรับรองเกินขอบเขตการใช้งาน

บทเรียนนี้จะอธิบายเทคนิคที่ใช้ได้จริง ได้แก่ การกำหนดขอบเขต sudo การลดสิทธิ์ด้วย su ตัวป้องกันตรวจสอบ UID และการเสริมความแข็งแกร่งของ sudoers เพื่อสร้างแบบจำลองสิทธิ์ที่มีวินัยสำหรับสคริปต์ใช้งานจริง

ตรวจสอบ UID ที่มีผลก่อนการดำเนินการเสี่ยง

ก่อนบล็อกโค้ดใด ๆ ที่จำเป็นต้องใช้ root อย่างแท้จริง สคริปต์ควรตรวจสอบว่าโพรเซสทำงานด้วย UID ที่มีผลตามที่คาดไว้ อย่าคาดเดา ให้ตรวจยืนยันเสมอ

$EUID คือตัวแปรพิเศษของ Bash ที่เก็บ ID ผู้ใช้ที่มีผลของโพรเซสปัจจุบัน root จะมี EUID เป็น 0 เสมอ การตรวจสอบที่ต้นสคริปต์ — หรือรอบบล็อกที่ใช้สิทธิ์สูง — จะป้องกันการทำงานโดยใช้ตัวตนที่ไม่ถูกต้องโดยไม่ตั้งใจ

ใช้รูปแบบตัวป้องกันนี้:

#!/usr/bin/env bash
set -euo pipefail

# Guard: this script must NOT run as root.
if [[ "$EUID" -eq 0 ]]; then
  echo "ERROR: Do not run this script as root. Use a normal user account." >&2
  exit 1
fi

echo "Running as UID $EUID — proceeding safely."

ยืนยันการใช้ root เฉพาะเมื่อจำเป็น

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

การรวมการออกจากการทำงานตั้งแต่เนิ่น ๆ กับข้อความแนะนำการใช้งานที่เข้าใจง่าย ทำให้สคริปต์อธิบายวิธีใช้งานตัวเองได้:

#!/usr/bin/env bash
set -euo pipefail

require_root() {
  if [[ "$EUID" -ne 0 ]]; then
    echo "ERROR: $(basename "$0") must be run as root." >&2
    echo "  Try: sudo $(basename "$0") $*" >&2
    exit 1
  fi
}

require_root "$@"

echo "Root confirmed (EUID=0). Starting privileged work..."

กำหนดขอบเขต sudo ให้เฉพาะคำสั่งเดียว

ข้อผิดพลาดที่พบบ่อยที่สุดคือวาง sudo ไว้ต้นสคริปต์ แล้วเรียกใช้ทุกอย่างในฐานะ root ให้ใช้ sudo เฉพาะกับคำสั่งที่ต้องการสิทธิ์สูงอย่างแน่ชัดเท่านั้น ส่วนอื่น ๆ ให้ทำงานในฐานะผู้ใช้ปกติของคุณ

วิธีนี้จำกัดขอบเขตความเสียหาย: หากผู้โจมตีแทรกโค้ดในสคริปต์ของคุณ พวกเขาจะเรียกใช้ด้วยสิทธิ์ root ได้เฉพาะส่วนที่มี sudo นำหน้าเท่านั้น

เปรียบเทียบรูปแบบทั้งสองด้านล่าง รูปแบบที่สองปลอดภัยกว่ามาก:

#!/usr/bin/env bash
set -euo pipefail

# BAD: escalate early, do everything as root (avoid this)
# sudo bash -c '
#   cp config.conf /etc/app/config.conf
#   chown app:app /etc/app/config.conf
#   systemctl restart app
# '

# GOOD: escalate only for the commands that require it
LOCAL_CONF="./config.conf"
DEST="/etc/app/config.conf"

# Unprivileged: validate the config before touching anything as root
if ! grep -q '^[[:space:]]*\[main\]' "$LOCAL_CONF"; then
  echo "ERROR: config.conf is missing [main] section" >&2
  exit 1
fi

# Privileged: only these three commands run under sudo
sudo cp "$LOCAL_CONF" "$DEST"
sudo chown app:app "$DEST"
sudo systemctl restart app

echo "Config deployed and service restarted."

เขียนกฎ sudoers ที่รัดกุม

การเรียก sudo somecommand ในสคริปต์จะปลอดภัยก็ต่อเมื่อไฟล์ sudoers ได้รับการกำหนดให้อนุญาตเฉพาะคำสั่งนั้น — และไม่อนุญาตสิ่งอื่น หลีกเลี่ยงกฎอย่าง ALL=(ALL) NOPASSWD: ALL สำหรับบัญชีบริการ

ให้จำกัดกฎไว้ที่คำสั่งเฉพาะพร้อมอาร์กิวเมนต์เฉพาะ โดยใช้ไวยากรณ์ที่ปลอดภัยสำหรับ visudo ฟิลด์สำคัญในกฎ sudoers:

  • ผู้ใช้ — ผู้ที่สามารถเรียกใช้ sudo
  • โฮสต์ — เครื่องที่อนุญาตให้ใช้ (ใช้ ALL เพื่อให้พกพาได้)
  • RunAs — ตัวตนที่ต้องการสวมสิทธิ์ (เกือบ всегдаใช้ root)
  • คำสั่ง — เส้นทางเต็มแบบสัมบูรณ์ พร้อมอาร์กิวเมนต์ตามตัวอักษรได้

ตัวอย่างกฎที่รัดกุมสำหรับบัญชีบริการนำส่ง (deployer):

# /etc/sudoers.d/deployer  (edit with: sudo visudo -f /etc/sudoers.d/deployer)
#
# Allow 'deployer' to restart exactly one service — nothing else
deployer ALL=(root) NOPASSWD: /usr/bin/systemctl restart app

# Allow copying a config file to a fixed destination only
deployer ALL=(root) NOPASSWD: /usr/bin/cp /home/deployer/staging/config.conf /etc/app/config.conf

# Allow chown of that specific file only
deployer ALL=(root) NOPASSWD: /usr/bin/chown app\:app /etc/app/config.conf

# NEVER do this — gives full root shell:
# deployer ALL=(ALL) NOPASSWD: ALL

ลดสิทธิ์ด้วย su และ runuser

เมื่อสคริปต์เริ่มทำงานในฐานะ root (เช่น ถูกเรียกโดยระบบเริ่มต้นหรือ cron ที่ทำงานในฐานะ root) แต่งานส่วนใหญ่ควรทำในฐานะผู้ใช้ที่ไม่มีสิทธิ์พิเศษ ให้ลดสิทธิ์อย่างชัดเจน แทนการเรียกใช้สคริปต์ทั้งหมดในฐานะ root

เครื่องมือสำหรับทำเช่นนี้มีสองรายการ:

  • su -s /bin/bash -c 'command' username — สร้างเชลล์ในฐานะ username และเรียกใช้คำสั่ง
  • runuser -u username -- command args — เป็นตัวเลือกที่แนะนำบน Linux สำหรับสลับผู้ใช้ภายในสคริปต์ที่เป็นของ root สะอาดกว่า su

รูปแบบด้านล่างแสดงตัวห่อหุ้มการนำส่งที่เป็นของ root และลดสิทธิ์ลงเป็นผู้ใช้ app สำหรับตรรกะของแอปพลิเคชันจริง:

#!/usr/bin/env bash
# This script is called by systemd as root during pre-deployment
set -euo pipefail

APP_USER="app"
DEPLOY_DIR="/opt/myapp"

# Step 1: privileged — fix ownership of deploy directory
chown -R "${APP_USER}:${APP_USER}" "$DEPLOY_DIR"

# Step 2: drop to app user for the actual migration/startup logic
# runuser is available on most modern Linux systems
runuser -u "$APP_USER" -- bash -c "
  cd $DEPLOY_DIR
  ./bin/migrate.sh
  ./bin/start.sh
"

echo "Deploy complete. Privileged wrapper exiting."

ใช้ sudo -u เพื่อเรียกใช้คำสั่งเดียวในฐานะผู้ใช้อื่น

คุณไม่จำเป็นต้องลดสิทธิ์ลงไปเป็นเซสชันเชลล์เต็มรูปแบบเสมอไป sudo -u username command จะเรียกใช้คำสั่งเดียวในฐานะผู้ใช้ที่ระบุ จากนั้นจึงกลับไปยังตัวตนของผู้เรียก วิธีนี้มีประโยชน์สำหรับการแก้ไขไฟล์ที่เป็นของบัญชีบริการ โดยไม่ให้บัญชีนั้นเข้าถึงแบบโต้ตอบได้

ใช้ร่วมกับกฎ sudoers ที่อนุญาตเฉพาะคู่ผู้ใช้/คำสั่งดังกล่าว:

#!/usr/bin/env bash
set -euo pipefail

# Scenario: deploy script runs as 'deployer'; DB migrations must run as 'postgres'
# sudoers entry needed:
#   deployer ALL=(postgres) NOPASSWD: /opt/app/bin/run_migrations.sh

DB_MIGRATION_SCRIPT="/opt/app/bin/run_migrations.sh"

if [[ ! -x "$DB_MIGRATION_SCRIPT" ]]; then
  echo "ERROR: migration script not found or not executable: $DB_MIGRATION_SCRIPT" >&2
  exit 1
fi

echo "Running DB migrations as postgres user..."
sudo -u postgres "$DB_MIGRATION_SCRIPT"

echo "Migrations done. Returning to deployer context (EUID=$EUID)."

หลีกเลี่ยงการยกระดับสิทธิ์ผ่านตัวแปรสภาพแวดล้อม

พื้นผิวการโจมตีที่แนบเนียนอย่างหนึ่งคือตัวแปรสภาพแวดล้อมที่สืบทอดโดยเซสชัน sudo โดยค่าเริ่มต้น sudo จะรีเซ็ตสภาพแวดล้อม แต่การตั้งค่า env_keep หรือการแทนที่ env_reset ที่ไม่ปลอดภัยอาจส่งต่อตัวแปรที่ผู้โจมตีควบคุมได้ เช่น LD_PRELOAD, PATH หรือ PYTHONPATH ไปยังคำสั่งที่ใช้สิทธิ์สูง

แนวปฏิบัติที่ดี:

  • ใช้เส้นทางสัมบูรณ์ในสคริปต์ที่ทำงานภายใต้ sudo เสมอ — อย่าพึ่งพา $PATH
  • ส่งเฉพาะตัวแปรที่ต้องการอย่างชัดเจน: sudo env VAR=value /path/to/cmd
  • ใน sudoers ให้หลีกเลี่ยง env_keep += PATH หรือ env_keep += LD_*
  • ใช้ sudo -E เฉพาะเมื่อคุณควบคุมและเชื่อถือสภาพแวดล้อมของผู้เรียกได้ทั้งหมด
#!/usr/bin/env bash
set -euo pipefail

# BAD: relies on $PATH — attacker who controls PATH can hijack 'cp'
# sudo cp config.conf /etc/app/

# GOOD: absolute paths for every command called under elevated context
SUDO_BIN="/usr/bin/sudo"
CP_BIN="/usr/bin/cp"
CHOWN_BIN="/usr/bin/chown"
SYSTEMCTL_BIN="/usr/bin/systemctl"

"$SUDO_BIN" "$CP_BIN" ./config.conf /etc/app/config.conf
"$SUDO_BIN" "$CHOWN_BIN" app:app /etc/app/config.conf
"$SUDO_BIN" "$SYSTEMCTL_BIN" restart app

echo "Deployed with hardened absolute-path invocations."

ล็อก sudo ด้วยการตรวจสอบอาร์กิวเมนต์ของคำสั่ง

แม้กฎ sudoers จะอนุญาตสคริปต์เฉพาะตัวหนึ่ง แต่ก็ยังสามารถส่งอาร์กิวเมนต์ใด ๆ ให้สคริปต์ได้ เว้นแต่จะล็อกอาร์กิวเมนต์เหล่านั้นด้วย จุดพลาดที่พบบ่อยคือ:

deployer ALL=(root) NOPASSWD: /opt/scripts/manage.sh

กฎนี้อนุญาต sudo /opt/scripts/manage.sh restart — แต่ก็อนุญาต sudo /opt/scripts/manage.sh --arbitrary-flag ด้วย หาก manage.sh ส่งอาร์กิวเมนต์ต่อไปยังคำสั่งย่อยที่ใช้สิทธิ์สูงโดยไม่ตรวจสอบ คุณก็จะมีปัญหา

ป้องกันแบบหลายชั้น: ตรวจสอบอาร์กิวเมนต์ภายในสคริปต์ที่ใช้สิทธิ์สูง รวมถึงใน sudoers ด้วย:

#!/usr/bin/env bash
# /opt/scripts/manage.sh — called via sudo; must validate its own args
set -euo pipefail

# Allowlist of valid actions
declare -A ALLOWED_ACTIONS=(
  [restart]=1
  [status]=1
  [reload]=1
)

ACTION="${1:-}"

if [[ -z "$ACTION" ]]; then
  echo "Usage: $(basename "$0") <restart|status|reload>" >&2
  exit 1
fi

if [[ -z "${ALLOWED_ACTIONS[$ACTION]:-}" ]]; then
  echo "ERROR: Unknown action '${ACTION}'. Allowed: ${!ALLOWED_ACTIONS[*]}" >&2
  exit 2
fi

/usr/bin/systemctl "$ACTION" app
echo "Action '$ACTION' executed successfully."

การยกระดับสิทธิ์ชั่วคราวด้วยกับดักเก็บกวาด

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

รูปแบบด้านล่างจะสร้างไฟล์ชั่วคราวในฐานะ root ใช้งานไฟล์ แล้วลบออก โดยมี trap บน EXIT รับรองว่าจะดำเนินการดังกล่าว:

#!/usr/bin/env bash
set -euo pipefail

# Must run as root for this demo
if [[ "$EUID" -ne 0 ]]; then
  echo "Run as root" >&2; exit 1
fi

TMP_SECRET=""

cleanup() {
  local exit_code=$?
  if [[ -n "$TMP_SECRET" && -f "$TMP_SECRET" ]]; then
    # Overwrite before deletion to reduce forensic recovery risk
    shred -u "$TMP_SECRET" 2>/dev/null || rm -f "$TMP_SECRET"
    echo "[cleanup] Removed privileged temp file." >&2
  fi
  exit "$exit_code"
}

trap cleanup EXIT INT TERM

# Create a root-owned temp file for a short-lived secret
TMP_SECRET="$(mktemp /tmp/deploy_secret.XXXXXXXX)"
chmod 600 "$TMP_SECRET"

# Simulate fetching a secret into the temp file
echo "super-secret-token" > "$TMP_SECRET"

# Use the secret (e.g., pass to a sub-command via file descriptor)
/usr/bin/some-privileged-tool --key-file "$TMP_SECRET"

echo "Privileged operation complete."

การตรวจสอบและบันทึกการดำเนินการที่มีสิทธิ์สูง

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

  1. ตัว sudo เอง — /var/log/auth.log (Debian/Ubuntu) หรือ /var/log/secure (RHEL) จะบันทึกการเรียกใช้ sudo ทุกครั้งโดยอัตโนมัติ
  2. บันทึกการตรวจสอบระดับสคริปต์ — เขียนรายการแบบมีโครงสร้างเมื่อเริ่มฟังก์ชันที่มีสิทธิ์สูงทุกฟังก์ชัน เพื่อบันทึกเจตนาไว้ควบคู่กับบันทึกของระบบ

การใช้ฟังก์ชันบันทึกแบบมีโครงสร้างที่เรียบง่ายช่วยให้ร่องรอยการตรวจสอบมีรูปแบบสม่ำเสมอและค้นหาด้วย grep ได้ง่าย:

#!/usr/bin/env bash
set -euo pipefail

AUDIT_LOG="/var/log/app_deploy_audit.log"

log_privileged_action() {
  local action="$1"
  local reason="${2:-unspecified}"
  local ts
  ts="$(date -u '+%Y-%m-%dT%H:%M:%SZ')"
  printf '{"ts":"%s","user":"%s","euid":%d,"action":"%s","reason":"%s"}\n' \
    "$ts" "${SUDO_USER:-$USER}" "$EUID" "$action" "$reason" \
    | sudo tee -a "$AUDIT_LOG" > /dev/null
}

# Each privileged step is logged before execution
log_privileged_action "cp_config" "deploy release v2.4.1"
sudo /usr/bin/cp ./config.conf /etc/app/config.conf

log_privileged_action "chown_config" "ensure app user owns config"
sudo /usr/bin/chown app:app /etc/app/config.conf

log_privileged_action "restart_service" "activate new config"
sudo /usr/bin/systemctl restart app

echo "Deployment complete. Audit entries written to $AUDIT_LOG"

ตรวจสอบความรู้: การกำหนดขอบเขต sudo

ทดสอบความเข้าใจของคุณเกี่ยวกับการทำงานด้วยสิทธิ์น้อยที่สุดในสคริปต์ Bash

ทบทวน: การทำงานด้วยสิทธิ์น้อยที่สุดและวินัยในการใช้ sudo

ในบทเรียนนี้ คุณได้เรียนรู้เทคนิคการเรียกใช้สคริปต์ Bash ด้วยสิทธิ์เท่าที่จำเป็นในแต่ละขั้นตอน ต่อไปนี้คือสรุปหลักการสำคัญโดยย่อ:

  • ตรวจสอบด้วย $EUID — หยุดทำงานอย่างรวดเร็วหากสคริปต์กำลังทำงานด้วยข้อมูลประจำตัวที่ไม่ถูกต้อง ไม่ว่าจะเป็นกรณีที่ห้ามใช้ root หรือกรณีที่จำเป็นต้องใช้ root
  • กำหนดขอบเขตของ sudo ให้แต่ละคำสั่ง — อย่ายกระดับสิทธิ์ให้ทั้งสคริปต์ ให้ใช้ sudo เฉพาะบรรทัดที่จำเป็นจริง ๆ
  • เขียนกฎ sudoers ให้รัดกุม — ระบุเส้นทางสัมบูรณ์แบบเต็มและอาร์กิวเมนต์ตามตัวอักษร หลีกเลี่ยงอักขระแทนและ ALL
  • ลดสิทธิ์ด้วย runuser หรือ sudo -u — เมื่อสคริปต์ที่เริ่มทำงานในฐานะ root ต้องส่งต่องานให้ผู้ใช้ที่ไม่มีสิทธิ์สูง ให้ใช้เครื่องมือที่เหมาะสมแทนการเรียกใช้ทุกอย่างในฐานะ root
  • ใช้เส้นทางสัมบูรณ์ — อย่าพึ่งพา $PATH ภายในโค้ดที่มีสิทธิ์สูง ให้ระบุเส้นทางไบนารีตายตัวเพื่อป้องกันการยึดเส้นทาง
  • ตรวจสอบอาร์กิวเมนต์ภายในสคริปต์ที่มีสิทธิ์สูง — กฎ sudoers เป็นแนวป้องกันด่านแรก ไม่ใช่ด่านเดียว ให้ใช้รายการที่อนุญาต
  • ดักจับและเก็บกวาด — ใช้ trap cleanup EXIT เพื่อรับรองว่าทรัพยากรชั่วคราวที่มีสิทธิ์สูงจะถูกทำลายแม้เกิดข้อผิดพลาด
  • บันทึกการยกระดับสิทธิ์ทุกครั้ง — รายการตรวจสอบแบบมีโครงสร้างที่ใช้ร่วมกับ syslog ของ sudo ในตัวจะช่วยให้ติดตามการดำเนินการที่มีสิทธิ์สูงได้ทุกครั้ง

เมื่อนำแนวปฏิบัติเหล่านี้ไปใช้อย่างสม่ำเสมอ พื้นที่โจมตีของระบบอัตโนมัติจะลดลงจาก root-ตลอดเวลา เป็น root-เฉพาะจุดที่พิสูจน์แล้วว่าจำเป็น ซึ่งเป็นคุณลักษณะสำคัญของ Bash ระดับใช้งานจริงที่ผ่านการเสริมความปลอดภัย

คำถามที่พบบ่อย

บทเรียน “การทำงานด้วยสิทธิ์น้อยที่สุดและวินัยในการใช้ sudo” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การทำงานด้วยสิทธิ์น้อยที่สุดและวินัยในการใช้ sudo” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Linux Command Line & Bash Scripting Mastery ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Linux Command Line & Bash Scripting Mastery มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การทำงานด้วยสิทธิ์น้อยที่สุดและวินัยในการใช้ sudo”

ลดสิทธิ์ กำหนดขอบเขตกฎ sudo อย่างรัดกุม และตรวจสอบ UID ที่มีผลก่อนการดำเนินการที่มีความเสี่ยง คุณปฏิบัติ Linux Command Line & Bash Scripting Mastery ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Linux Command Line & Bash Scripting Mastery หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Linux Command Line & Bash Scripting Mastery บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน

บทเรียน “การทำงานด้วยสิทธิ์น้อยที่สุดและวินัยในการใช้ sudo” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Linux Command Line & Bash Scripting Mastery นี้ได้ไหม

ได้ บทเรียน Linux Command Line & Bash Scripting Mastery ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การป้องกันการแทรกคำสั่งและอาร์กิวเมนต์
  2. การจัดการความลับอย่างปลอดภัยและสุขอนามัยของสภาพแวดล้อม
  3. การทำงานด้วยสิทธิ์น้อยที่สุดและวินัยในการใช้ sudo
  4. การวิเคราะห์แบบสถิตและการตรวจสอบด้วย ShellCheck
← กลับไปที่ Linux Command Line & Bash Scripting Mastery