系统级备份脚本安全的核心是围绕“谁执行”“在哪执行”“谁能改它”构建权限与路径闭环：创建专用低权限用户backupuser，严格限制其权限；脚本及配置文件设600权限并分离存放；调度任务显式指定User=backupuser；定期校验权限与防护机制。
要让系统级备份脚本安全、可靠地运行，核心不是单纯给它加个 chmod +x，而是围绕“谁执行”“在哪执行”“谁能改它”三个问题做权限与路径的闭环控制。
明确脚本归属与最小权限执行用户
系统备份脚本不应由 root 直接执行（除非绝对必要），更不能用普通用户随意运行。推荐创建专用低权限用户（如 backupuser），仅赋予其访问源数据目录和目标备份路径的读写权限，不授予 shell 登录、sudo 或其他系统管理能力。
- 用
useradd -r -s /usr/sbin/nologin backupuser创建无登录能力的系统用户 - 用
chown -R backupuser:backupuser /path/to/backup-script.sh /backup/dest/归属关键路径 - 若需读取 root-owned 配置或数据库文件，通过
setfacl或group方式授权，避免直接 chmod 755 整个 /etc
锁定脚本自身路径与关键配置文件权限
脚本文件本身必须防篡改——攻击者一旦能修改备份逻辑，就可能跳过加密、漏传关键数据，甚至植入后门。路径保护重点在“不可写+不可遍历+不可覆盖”。
- 脚本文件设为
600（仅属主可读写），所在目录设为755且属主为 root，禁止 group/o 写权限 - 若含密码或密钥的配置文件（如
backup.conf），必须与脚本分离存放，并同样设为600，属主为backupuser - 禁用 world-writable 目录（如
/tmp）存放临时脚本或配置；确需临时文件，用mktemp -d创建私有目录并立即chmod 700
调度任务（cron/systemd）的权限上下文必须显式指定
crontab 或 systemd timer 若未明确指定运行用户，极易以 root 或当前用户身份误执行，绕过前面设置的权限隔离。调度器本身也是权限链的一环。
- 避免把脚本加到
/etc/crontab或用户 crontab 中；统一使用系统级定时器：/etc/cron.d/backup-job，首行注明SHELL=/bin/bash和执行用户，例如：0 2 * * * backupuser /opt/scripts/backup.sh > /var/log/backup.log 2>&1 - systemd 方式更可控：新建
/etc/systemd/system/backup.timer和.service，在 service 文件中设置User=backupuser、NoNewPrivileges=true、ProtectSystem=strict - 所有日志重定向路径（如
/var/log/backup.log）需提前由 root 创建并chown backupuser:backupuser，权限设为644或600
验证与持续防护建议
权限设置不是一次性操作。系统更新、管理员误操作、自动部署工具都可能悄悄改回宽松权限。需建立轻量但有效的检查机制。
- 每周运行一次校验脚本，检查：
ls -l /opt/scripts/backup.sh、stat -c "%U:%G %a %n" /backup/dest/、systemctl show backup.service | grep -E "(User|Protect)" - 在脚本开头加入基础防护检查，例如：
[[ "$(stat -c '%U:%G' "$0")" == "backupuser:backupuser" ]] || { echo "ERROR: script ownership invalid"; exit 1; } - 将脚本所在目录挂载为
noexec,nosuid,nodev（若不影响运行），进一步限制潜在恶意载荷执行能力
