前言
记得有一次,开发同事需要查看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 存储管理等进阶内容,构建一套从底层存储到上层审计的完整治理方法论,欢迎关注。