如何设置系统级备份脚本的执行权限及路径保护实战指南-安全-PHP中文网

系统级备份脚本安全的核心是围绕“谁执行”“在哪执行”“谁能改它”构建权限与路径闭环：创建专用低权限用户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

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（若不影响运行），进一步限制潜在恶意载荷执行能力