前言
记得有一次，开发同事需要查看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就够了。
最终需求表：
| 目录/文件 | 属主:属组 | 权限 | 理由 |
|---|---|---|---|
/opt/ruoyi | ruoyi:ruoyi | 755 | 根目录，ruoyi完全控制，同组可查看，其他人可进入但不可增删 |
/opt/ruoyi/config | ruoyi:ruoyi | 750 | 保护敏感配置，仅ruoyi可写，组内只读，防止误操作和信息泄露 |
/opt/ruoyi/logs | ruoyi:ruoyi | 755 | 日志"宽进严出"，所有人可读，仅ruoyi可写 |
/opt/ruoyi/backend/*.jar | ruoyi: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(755) | /opt/ruoyi/config(750) |
|---|---|---|
| ruoyi（属主） | 读、写、进入 | 读、写、进入 |
| ruoyi组成员 | 读、进入、不可写 | 读、进入、不可写 |
| 其他用户 | 读、进入、不可写 | 不可读、不可进入、不可写 |
同样是普通用户，他能进入/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，属主属组正确。
六、汇总
核心操作就是五步：
| 步骤 | 命令 | 目的 |
|---|---|---|
| 1 | useradd ruoyi | 创建专用用户 |
| 2 | mkdir -p /opt/ruoyi/{config,logs,backend,frontend,backup} | 创建目录结构 |
| 3 | chown -R ruoyi:ruoyi /opt/ruoyi | 所有权全部交给 ruoyi |
| 4 | chmod 755 /opt/ruoyichmod 750 /opt/ruoyi/configchmod 755 /opt/ruoyi/logs | 分目录设置差异化权限 |
| 5 | ls -la /opt/ruoyi/ | 验证最终效果 |
最后再提一句：权限配置是防御性的。它不能保证系统绝对安全，但能防止大多数因"手滑"或"好奇"导致的意外——比如开发误改了配置文件、运维误删了日志目录。这些看似不起眼的小事，正是生产环境宕机的常见元凶。
现在，回到开头提到的三个重点检查项：
- ✅ 所有目录的属主属组都是
ruoyi:ruoyi - ✅
config目录的权限是drwxr-x---（750） - ✅ 其他目录的权限是
drwxr-xr-x（755）
如果这三项都通过了，恭喜你！你已经为若依项目搭建了一套既安全又实用的文件系统权限体系。
本文是"若依项目Linux生产环境治理"系列的第三篇。前两篇覆盖目录结构治理和用户体系治理，后续文章将深入 sudo 精细化权限管控、日志分析与正则实战、LVM 存储管理等进阶内容，构建一套从底层存储到上层审计的完整治理方法论，欢迎关注。