前言

记得有一次，开发同事需要查看application.yml里的数据库连接配置，看完之后顺手按了上下键，不小心执行了上一条vim application.yml，然后手滑按了几个键，保存退出了。等他反应过来，配置已经乱了，整个服务重启后连不上数据库，线上炸了半小时。

事后复盘，根因很简单：配置文件太"开放"了，任何能登录服务器的人都能改。

本文就来解决这个问题：为若依项目配置一套合理的文件系统权限。

一、需求分析

先从三个问题说起。

问题一：若依项目根目录归谁管？

/opt/ruoyi是整个项目的根。我的做法是：根目录的所有者和所属组都设为ruoyi，权限设为755。这样ruoyi用户拥有完整控制权，同组用户可以查看目录内容，其他用户可以进入目录但不能随意增删文件。

问题二：配置文件怎么保护？

这是最关键的问题。/opt/ruoyi/config/application.yml里存着数据库密码、Redis密码、加密密钥。如果任何登录服务器的人都能cat或vim它，敏感信息就等于公开了。

解决方案：把config目录的权限设为750——只有ruoyi用户能完全控制，ruoyi组的成员能读取但不能修改，其他用户直接进不了这个目录。

生产环境中，需要修改配置的人非常少，让组内其他人只能看不能改，既方便协作排查问题，又防止了误操作。

问题三：日志和程序包呢？

日志目录要"宽进严出"：所有人都能看日志，但只有ruoyi能写。755刚好满足这个要求。

JAR包是部署好的，不应该被随便替换，属主是ruoyi，权限644就够了。

最终需求表：

二、动手实战

开始之前有个小建议：如果你用虚拟机做实验，建议恢复到干净快照再开始，避免前面实验的配置互相干扰。

第1步：创建专用用户

[root@magedu ~]# useradd ruoyi

这个ruoyi用户就是若依应用的"主人"，所有项目文件都归它所有，应用进程也以它的身份运行。

第2步：创建目录结构

[root@magedu ~]# mkdir -p /opt/ruoyi/{config,logs,backend,frontend,backup}

创建完成后目录结构如下：

/opt/ruoyi/ ├── config/ # 配置文件（敏感） ├── logs/ # 应用日志 ├── backend/ # 后端JAR包 ├── frontend/ # 前端静态文件 └── backup/ # 备份文件

第3步：设置所有者和权限

# 设置根目录所有者为 ruoyi [root@magedu ~]# chown -R ruoyi:ruoyi /opt/ruoyi 设置根目录权限 [root@magedu ~]# chmod 755 /opt/ruoyi 设置 config 目录为 750（敏感目录，严格限制） [root@magedu ~]# chmod 750 /opt/ruoyi/config 设置其他目录为 755 [root@magedu ~]# chmod 755 /opt/ruoyi/logs [root@magedu ~]# chmod 755 /opt/ruoyi/backend [root@magedu ~]# chmod 755 /opt/ruoyi/frontend [root@magedu ~]# chmod 755 /opt/ruoyi/backup

第4步：验证结果

[root@magedu ~]# ls -la /opt/ruoyi/ drwxr-xr-x 6 ruoyi ruoyi 4096 Jul 19 17:00 . drwxr-xr-x 4 root root 4096 Jul 19 16:55 .. drwxr-x--- 2 ruoyi ruoyi 4096 Jul 19 17:00 config drwxr-xr-x 2 ruoyi ruoyi 4096 Jul 19 17:00 logs drwxr-xr-x 2 ruoyi ruoyi 4096 Jul 19 17:00 backend drwxr-xr-x 2 ruoyi ruoyi 4096 Jul 19 17:00 frontend drwxr-xr-x 2 ruoyi ruoyi 4096 Jul 19 17:00 backup

注意config目录的权限是drwxr-x---（750），这是本配置中最关键的安全设防点。

三、理解 755 和 750 的实际效果

同样是普通用户，他能进入/opt/ruoyi查看目录结构，但cd config时会直接报Permission denied。这就是我们想要的效果：目录结构可以看，敏感内容不能碰。

四、关于最小权限原则

通过这篇文章，我想传递一个比技术操作更重要的理念：最小权限原则——只授予完成工作所必需的最少权限，不多给一分。

例如config目录设置为750而不是755，多出来的那一点限制——不让"其他人"进入——恰恰是保护了配置文件不被非授权用户看到。

权限管理其实就是在做减法：默认不给权限，只开最小的口子。

五、验证权限是否生效

测试一：普通用户尝试进入 config 目录

[root@magedu ~]# su - ruoyi-admin [ruoyi-admin@magedu ~]$ cd /opt/ruoyi/config -bash: cd: /opt/ruoyi/config: Permission denied

预期结果：报错Permission denied，说明750生效了。

测试二：确认文件归属

[root@magedu ~]# ls -l /opt/ruoyi/backend/ruoyi-admin.jar -rw-r--r-- 1 ruoyi ruoyi 123456 Jul 19 17:00 /opt/ruoyi/backend/ruoyi-admin.jar

预期结果：显示ruoyi ruoyi，属主属组正确。

六、汇总

核心操作就是五步：

最后再提一句：权限配置是防御性的。它不能保证系统绝对安全，但能防止大多数因"手滑"或"好奇"导致的意外——比如开发误改了配置文件、运维误删了日志目录。这些看似不起眼的小事，正是生产环境宕机的常见元凶。

现在，回到开头提到的三个重点检查项：

• ✅ 所有目录的属主属组都是ruoyi:ruoyi
• ✅config目录的权限是drwxr-x---（750）
• ✅ 其他目录的权限是drwxr-xr-x（755）

如果这三项都通过了，恭喜你！你已经为若依项目搭建了一套既安全又实用的文件系统权限体系。

本文是"若依项目Linux生产环境治理"系列的第三篇。前两篇覆盖目录结构治理和用户体系治理，后续文章将深入 sudo 精细化权限管控、日志分析与正则实战、LVM 存储管理等进阶内容，构建一套从底层存储到上层审计的完整治理方法论，欢迎关注。