/boot/grub权限配置的核心是守护系统启动安全：grub.cfg须设为644且不可手动修改，/etc/default/grub建议600或644，/etc/grub.d/脚本需755执行权限；误改将导致启动失败。
理解 /boot/grub 目录的权限配置，本质是守护系统启动入口的安全底线。这个目录里存着 GRUB 的核心配置和引导逻辑，一旦被误改或恶意篡改，轻则开机卡在菜单、进不了系统，重则完全无法启动——连修复都得靠 Live CD 或救援环境。
/boot/grub 下关键文件的权限逻辑
权限不是越严越好，而是要匹配实际使用场景：
-
/boot/grub/grub.cfg：这是 GRUB 实际加载的最终配置，由工具自动生成。它必须是root:root所有者，且权限设为644（即-rw-r--r--）——可读但不可写，防止用户或程序意外覆盖；绝对不能设为 755 或更宽松，否则任意用户都能修改它，等于把启动钥匙交出去。 -
/etc/default/grub：这是你真正该编辑的“源配置”。建议保持644或更保守的600（仅 root 可读写），尤其当系统有多个管理员时，避免他人无意改动默认启动项或内核参数。 -
/etc/grub.d/目录及其中脚本：这些是生成grub.cfg的模板。它们需要执行权限（755），因为update-grub会运行它们；但内容本身不应包含敏感信息，所以目录权限建议755，文件权限统一设为755即可。
为什么不能直接改 grub.cfg？
这不是“规定”，而是设计使然：
- 它开头明确写着
## DO NOT EDIT THIS FILE，且被标记为只读——这是系统级防护机制，不是提示语。 - 每次运行
sudo update-grub（或grub-mkconfig），都会用/etc/default/grub和/etc/grub.d/重新生成整个grub.cfg，任何手动修改都会被清空。 - 若强行
chmod +w并编辑它，下次内核更新或配置变更后，你的修改就丢了，还可能因语法错误导致启动失败。
常见权限误操作与修复建议
实战中容易踩坑的地方不多，但后果明显：
- 误将
/boot/grub/grub.cfg权限改为666或777：立即执行sudo chmod 644 /boot/grub/grub.cfg恢复。 - 编辑
/etc/default/grub后忘记运行sudo update-grub：改了白改，系统仍按旧配置启动。 - 用普通用户身份尝试写入
/boot/grub/下任意文件：会被拒绝——这反而是正常表现，说明权限机制在起作用。 - 误删
/etc/grub.d/10_linux等核心脚本：会导致update-grub生成不全，缺内核选项。可从同版本系统复制，或重装grub-pc（Debian/Ubuntu）或grub2-tools（RHEL/CentOS）包恢复。
权限之外：几个关键安全习惯
权限只是基础，配合以下做法才能真正稳住启动环节：
- 修改
/etc/default/grub前，先备份：sudo cp /etc/default/grub /etc/default/grub.bak。 - 调整
GRUB_TIMEOUT或GRUB_HIDDEN_TIMEOUT时，注意值为0代表跳过菜单直接启动，默认项必须可用，否则可能黑屏卡住。 - 生产服务器上，建议禁用恢复模式（
GRUB_DISABLE_RECOVERY=true），减少非必要入口点。 - 云服务器或 VPS 环境中，特别留意
initrd加载路径和驱动模块是否完整，权限正确但 initramfs 缺失同样无法挂载根分区。
