关于/var/log/snort-*下alert文件权限自动变更的技术问询

看起来你遇到了Snort日志文件权限在更新后自动变化的问题——手动设置750权限后，新生成或轮转的alert文件权限变成了755或其他值。这通常和进程UMASK设置、logrotate日志轮转配置有关，下面是具体的排查和解决步骤：

一、排查核心原因 #

1. Snort进程的UMASK值 #

当Snort创建新的alert文件时，会使用自身进程的UMASK来计算默认权限。UMASK是权限掩码，会从默认权限（普通文件666、可执行文件777）中减去对应数值。比如：

• 如果UMASK是002，普通文件权限会是664，可执行文件是775
• 如果UMASK是022，普通文件权限会是644，可执行文件是755

你看到的755权限，大概率是Snort进程的UMASK为022导致的。

2. Logrotate日志轮转配置 #

Snort的日志通常由logrotate管理，当日志轮转时，logrotate会创建新的日志文件。如果logrotate配置中没有指定create选项，新文件会继承logrotate进程的UMASK权限，这也会导致权限不符合预期。

二、具体解决步骤 #

1. 调整Snort进程的UMASK #

对于Systemd服务（主流Linux发行版）：

编辑Snort的systemd服务文件（通常是/etc/systemd/system/snort.service或/lib/systemd/system/snort.service），在[Service]段添加：

UMask=0027

这个值对应八进制027，计算后普通文件权限为666-027=640，可执行文件为777-027=750，正好符合你的需求。

然后重新加载systemd并重启Snort：

systemctl daemon-reload
systemctl restart snort

对于SysVinit脚本：

找到Snort的启动脚本（比如/etc/init.d/snort），在脚本开头添加：

umask 027

然后重启Snort服务。

2. 配置Logrotate强制设置权限 #

编辑Snort的logrotate配置文件（通常在/etc/logrotate.d/snort），在配置块中添加create选项，指定权限和属主属组：

/var/log/snort-*/alert /var/log/snort/alert {
    # 保留原有配置（比如daily、rotate等）
    create 750 snort snort
    # 其他已有配置
}

这个配置会让logrotate在轮转日志时，直接创建权限为750、属主属组为snort:snort的新文件，避免继承UMASK的影响。

3. 验证效果 #

手动触发一次日志轮转测试：

logrotate -f /etc/logrotate.d/snort

然后检查新生成的alert文件权限：

find /var/log/ -name "alert" | xargs ls -ltr

确认权限已经固定为750。

额外说明 #

你看到的不同文件权限差异（有的750、有的755），可能是因为部分文件是在UMASK调整前创建的，或者logrotate轮转时使用了不同的配置。调整完上述设置后，后续生成的文件都会保持750权限。

内容的提问来源于stack exchange，提问作者chandu