前言记得有一次开发同事需要查看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/ruoyiruoyi:ruoyi755根目录ruoyi完全控制同组可查看其他人可进入但不可增删/opt/ruoyi/configruoyi:ruoyi750保护敏感配置仅ruoyi可写组内只读防止误操作和信息泄露/opt/ruoyi/logsruoyi:ruoyi755日志宽进严出所有人可读仅ruoyi可写/opt/ruoyi/backend/*.jarruoyi:ruoyi644程序包不应被随意替换属主可读写其他只读二、动手实战开始之前有个小建议如果你用虚拟机做实验建议恢复到干净快照再开始避免前面实验的配置互相干扰。第1步创建专用用户[rootmagedu ~]# useradd ruoyi这个ruoyi用户就是若依应用的主人所有项目文件都归它所有应用进程也以它的身份运行。第2步创建目录结构[rootmagedu ~]# mkdir -p /opt/ruoyi/{config,logs,backend,frontend,backup}创建完成后目录结构如下/opt/ruoyi/ ├── config/ # 配置文件敏感 ├── logs/ # 应用日志 ├── backend/ # 后端JAR包 ├── frontend/ # 前端静态文件 └── backup/ # 备份文件第3步设置所有者和权限# 设置根目录所有者为 ruoyi [rootmagedu ~]# chown -R ruoyi:ruoyi /opt/ruoyi 设置根目录权限 [rootmagedu ~]# chmod 755 /opt/ruoyi 设置 config 目录为 750敏感目录严格限制 [rootmagedu ~]# chmod 750 /opt/ruoyi/config 设置其他目录为 755 [rootmagedu ~]# chmod 755 /opt/ruoyi/logs [rootmagedu ~]# chmod 755 /opt/ruoyi/backend [rootmagedu ~]# chmod 755 /opt/ruoyi/frontend [rootmagedu ~]# chmod 755 /opt/ruoyi/backup第4步验证结果[rootmagedu ~]# 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 目录[rootmagedu ~]# su - ruoyi-admin [ruoyi-adminmagedu ~]$ cd /opt/ruoyi/config -bash: cd: /opt/ruoyi/config: Permission denied预期结果报错Permission denied说明750生效了。测试二确认文件归属[rootmagedu ~]# 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属主属组正确。六、汇总核心操作就是五步步骤命令目的1useradd ruoyi创建专用用户2mkdir -p /opt/ruoyi/{config,logs,backend,frontend,backup}创建目录结构3chown -R ruoyi:ruoyi /opt/ruoyi所有权全部交给 ruoyi4chmod 755 /opt/ruoyichmod 750 /opt/ruoyi/configchmod 755 /opt/ruoyi/logs分目录设置差异化权限5ls -la /opt/ruoyi/验证最终效果最后再提一句权限配置是防御性的。它不能保证系统绝对安全但能防止大多数因手滑或好奇导致的意外——比如开发误改了配置文件、运维误删了日志目录。这些看似不起眼的小事正是生产环境宕机的常见元凶。现在回到开头提到的三个重点检查项✅ 所有目录的属主属组都是ruoyi:ruoyi✅config目录的权限是drwxr-x---750✅ 其他目录的权限是drwxr-xr-x755如果这三项都通过了恭喜你你已经为若依项目搭建了一套既安全又实用的文件系统权限体系。本文是若依项目Linux生产环境治理系列的第三篇。前两篇覆盖目录结构治理和用户体系治理后续文章将深入 sudo 精细化权限管控、日志分析与正则实战、LVM 存储管理等进阶内容构建一套从底层存储到上层审计的完整治理方法论欢迎关注。