上一篇
"小张,生产环境报表服务怎么挂了?"凌晨2点接到运维同事电话时,我正迷迷糊糊啃着面包,登录服务器一看——昨天部署脚本时图省事直接chmod 777
,结果某个关键目录被爬虫扫成了筛子...
这种血泪史在Linux系统管理中并不罕见,本文将用最直白的语言,带你掌握目录权限管理的核心技巧,避开那些年我们踩过的坑。
ls -l
的输出执行ls -l
时,开头的神秘字符串其实在说话:
drwxr-xr-- 2 root developers 4096 Aug 25 2025 project_docs ↑↑↑↑↑↑↑↑↑ ↑ ↑ ↑ ↑ ↑ ↑ │││││││││ │ │ │ │ │ └─ 目录/文件名 │││││││││ │ │ │ │ └─ 修改时间 │││││││││ │ │ │ └─ 文件大小(字节) │││││││││ │ │ └─ 所属用户组 │││││││││ │ └─ 所有者 │││││││││ └─ 硬链接数 │└┴┴┴┴┴┴┴─ 权限标识(9个字符分3组) └─ 文件类型(d=目录, -=文件, l=链接等)
权限三组含义:
字母对应关系:
r
= 读(4) w
= 写(2) x
= 执行(1) 与文件不同,目录的权限有独特行为:
权限 | 对文件的影响 | 对目录的影响 |
---|---|---|
r | 读取文件内容 | 仅列出文件名(需配合x权限) |
w | 修改文件内容 | 创建/删除文件(需配合x权限) |
x | 执行程序 | 进入目录(cd)或访问子项 |
关键区别:
x
=可执行,目录x
=可穿透 w
不带x
时无效 5
(r-x)可浏览但不可修改,7
(rwx)完全控制 # 字母形式(u=用户, g=组, o=其他人, a=所有) chmod g+w project_docs # 给组添加写权限 chmod o-rx confidential # 移除其他人的读和执行权限 # 数字形式(推荐记忆法:4读+2写+1执行) chmod 750 script.sh # 用户rwx, 组r-x, 其他人无权限
# 修改所有者 sudo chown deploy:devteam /opt/app # 同时修改用户和组 # 递归修改(慎用!) sudo chown -R nginx:nginx /var/www
passwd
命令) /tmp
) 设置方法:
chmod 2750 shared_dir # 添加SGID位 chmod +t /tmp # 设置Sticky Bit
典型场景:
chmod 777 /opt/app/logs # 但用户仍报"Permission denied"
原因排查:
x
权限(如/opt/app
需要至少--x
) getenforce
查看状态) getfacl /path
) 错误示范:
usermod -aG devteam user1 chmod 770 /project # 但user1仍无法写入
解决方案:
ls -ld /project
) newgrp devteam
临时切换主组 血泪案例:
sudo chmod -R 777 /etc/nginx # 导致SSL证书变为全局可读
安全建议:
/etc
、/usr
等系统目录 640
) find
针对性修改: find /var/www -type d -exec chmod 755 {} \; find /var/www -type f -exec chmod 644 {} \;
750
开始测试,而非直接777
755
(可执行但不可篡改) 775
(组用户可写入) 1770
(防其他用户删除) # 查找全局可写目录 find / -type d -perm -0002 ! -path "/proc/*" -exec ls -ld {} \; # 查找SUID文件 find / -perm -4000 -exec ls -ld {} \;
记住这三个数字,能解决90%的权限问题:
/tmp
)里各玩各的 下次再想输入chmod 777
时,不妨先喝口水冷静一下——你的未来运维同事会感谢这个决定。
本文由 盘瑜 于2025-08-02发表在【云服务器提供商】,文中图片由(盘瑜)上传,本平台仅提供信息存储服务;作者观点、意见不代表本站立场,如有侵权,请联系我们删除;若有图片侵权,请您准备原始证明材料和公证书后联系我方删除!
本文链接:https://vps.7tqx.com/wenda/514850.html
发表评论