1. 权限体系到底在解决什么问题很多人学Linux学到用户和权限这块就卡住了。倒不是说命令有多难背而是脑子里没有建立起一个完整的模型——为什么要设计用户和组rwx三件套到了目录上怎么解释为什么有时候明明有rwx权限程序还是跑不起来如果你也有这些困惑那这篇内容就是给你准备的。我会从权限体系的设计逻辑讲起把用户、组、文件权限这三块揉碎了串起来最后再带一个完整的实操案例不管是刚接触Linux的新手还是被权限问题折腾过的运维、开发同学都能从中拿到一些能直接用的东西。1.1 三个角色的划分逻辑Linux的权限模型本质上是一个“多用户隔离”的问题。一台服务器上可能同时跑着十几个人的任务有人在部署网站有人在跑数据分析还有人在改配置文件。如果所有人都是root那一个手滑就可能把别人的环境毁了。所以系统把“谁是谁”这件事拆成了三层文件所有者u、属组g、其他人o。这里的核心思想是每个文件必须有且只有一个所有者必须属于且只属于一个组然后剩下的访问者统统归类到“其他人”里。你做的事情就是给这三类角色分别设定权限。这个设计不是拍脑袋定的。它要解决两个现实问题第一一个人什么时候能读、能写、能执行某个文件系统需要一个明确的判断依据第二当多个用户需要协作访问同一批文件时怎么避免逐个去配权限的体力活。组的存在就是为了解决第二个问题的——把一批人归到一个组再给这个组统一授权比一个个加权限要高效得多。1.2 rwx三件套对文件和目录的意义完全不同r、w、x这三个字母大家都不陌生。但很多人踩坑就踩在用文件的思路去理解目录的权限。对文件来说r代表可以读取内容w代表可以修改内容x代表可以把它当作程序来执行。这个直觉是对的。但到了目录这里含义全变了r可以列出目录里有什么ls能出结果但能不能访问某个具体文件还要看后续权限。w可以在目录里新建、删除、重命名文件或子目录。注意是目录的写权限而不是文件本身的写权限。x表示能不能“穿过”这个目录也就是能不能进入目录去访问里面的内容。没有x权限就算你有r权限ls进去也可能报错。打个比方目录就像一栋楼的走廊门禁。r是能看楼层索引牌w是你有钥匙能开门放东西进去x是你有通行卡能走进走廊本身。只有r没有x你站在门口能看到里面大概有什么但进不去只有x没有r你能进去但像个没戴眼镜的人不知道里面具体有哪些房间。这个区别在排障时极其重要。最常见的一个坑就是你给了一个用户某个文件的读权限但文件所在目录的x权限没开用户照样访问不了。很多新人只盯着文件本身的权限调完全没意识到目录权限才是拦路虎。1.3 为什么Linux不直接给每个人单独配权限既然权限是围绕用户来的那为什么不干脆针对每个用户单独设置权限一些新版文件系统比如ZFS的ACL确实支持更细粒度的控制但传统Linux的POSIX权限模型一直坚持“用户、组、其他人”这种粗粒度设计核心原因有两个第一简单可靠。三组权限位一共9个比特位再加三个特殊位所有信息都能用一个短字符串表示也就能稳定地存储在各种文件系统上。这个模型从Unix时代用到现在说明它的底子足够扎实。第二符合大多数场景的实际需求。想想真实情况一台机器上的用户数一般远小于文件数而能访问同一批文件的人通常都属于同一个项目组或同一个业务团队。用“组”来做授权单位正好覆盖了绝大多数协作需求。当然粗粒度也带来一些别扭的地方。比如两个人要共享一个文件但只有这两个人能访问用传统权限就比较尴尬要么建个新组要么用ACL。这才有了ACL访问控制列表作为补充方案。你不需要把ACL当成日常主力工具但要意识到它是权限工具箱里的一员遇到精细授权需求时别忘了还有这个选项。2. 用户和组的管理先把“人”理清楚权限的载体是“用户”和“组”。所以第一步不是去改文件权限而是先把系统里的用户、组梳理明白。很多新手上来就chmod 777看着是解决问题了实际上是把系统的大门彻底敞开了毫无安全边界可言。2.1 用户、组、UID/GID的最小知识储备Linux里用户和组的本质不是一个名字而是一个数字ID。用户名只是给人看的系统真正识别的是UID组对应的则是GID。你可以通过id命令查看一个用户的完整身份信息$ id zhangsan uid1001(zhangsan) gid1001(zhangsan) groups1001(zhangsan),10(wheel)这里能看到三样东西用户自己的UID、主组GID以及附加组列表。理解“主组”和“附加组”的区别很重要。主组是用户创建文件时默认所属的组附加组是用户额外获得的组成员身份用于访问其他共享资源。一个人可以同时在多个附加组里但主组只有一个。系统用户和普通用户的UID范围也有讲究。一般约定0是root的UID1-999是系统服务用的虚拟用户1000以上才是普通用户。这个区分是为了防止普通程序意外拿到系统级别的文件访问权限。2.2 常用命令从创建到删除的完整链路用户和组的管理命令其实就那么几个但每个都有不少细节。我直接给一张速查表操作命令说明创建组groupadd devteam新建一个名为devteam的组创建用户并指定主组useradd -g devteam zhangsan用户zhangsan的主组是devteam创建用户并加入附加组useradd -G docker,devteam zhangsan用户额外加入docker和devteam组修改用户附加组usermod -aG docker zhangsan-a表示追加不加-a会覆盖原有附加组修改用户主组usermod -g devteam zhangsan把主组改为devteam删除用户userdel -r zhangsan-r会同时删除家目录和邮件池删除组groupdel devteam组里不能有用户的主组是它查看用户信息id zhangsan查看UID/GID和组信息修改密码passwd zhangsan设置或修改用户密码这里我特别提醒两个高频坑。第一个坑usermod不加-a。比如用户zhangsan原本在wheel组和docker组里你执行了usermod -G devteam zhangsan他的附加组会变成只有devteam原来那些全部被清掉。正确做法是usermod -aG devteam zhangsan这个-a表示append追加进去。我见过太多人因为漏了-a把一个用户从一堆重要组里踢出去然后发现sudo用不了了。第二个坑useradd和adduser在两个发行版上行为不同。CentOS/RHEL系里useradd是原生命令直接生效Debian/Ubuntu系里useradd也存在但adduser是更友好的封装会交互式地让你设置密码、填用户信息。如果你在Ubuntu上用useradd创建用户不主动指定选项这个用户可能连家目录都没有。比较稳妥的做法是创建后立即passwd设置密码并确认家目录存在。2.3 初次创建用户时最容易忽略的细节按惯例创建用户的完整流程我在生产环境里一般是这么写的供你参考# 1. 创建组 groupadd devteam # 2. 创建用户指定主组、家目录、Shell useradd -g devteam -m -d /home/zhangsan -s /bin/bash zhangsan # 3. 设置密码 passwd zhangsan # 4. 把用户加进附加组 usermod -aG wheel zhangsan # 5. 验证 id zhangsan这里有几个细节值得展开讲。第一-s /bin/bash要显式指定。有些系统默认Shell是nologin或sh用户登进来发现命令行难用得想哭还以为是系统坏了。第二-m -d /home/zhangsan表示创建家目录并指定位置。如果你的发行版useradd默认不创建家目录比如最小化安装的某些系统漏了这个选项会导致用户登录后落在根目录而且很多程序会行为异常。第三创建完立刻验证别等用户反馈问题了再回头看那就被动了。还有一个特别容易被忽略的点用户加入新组后如果已经登录了新组的身份不会立即生效。必须重新登录或者用newgrp切换一下才能拿到新组的访问权。这个不是系统出bug是会话里的凭证没有刷新而已。3. chmod/chown/chgrp文件权限的三板斧把用户和组理清楚之后就该动文件了。这一节是实际操作中最常用的部分也是问题最多的部分。chmod改权限、chown改属主属组、chgrp改属组这三条命令配合使用能解决绝大多数授权需求。3.1 数字法、符号法哪种更推荐chmod有两种语法风格数字法和符号法。两种都得会因为你会在各种脚本和文档里都遇到它们。数字法的逻辑是把rwx映射成二进制r4w2x1。每类角色的权限就是一个数字把三者相加得到0-7之间的值。比如7421rwx642rw-541r-x。最终一个完整的权限就是三个数字连起来比如chmod 750 file表示属主rwx、属组r-x、其他人没有任何权限。符号法则是直接用u/g/o/a指定角色用-设置权限操作比如chmod ux file给属主加执行权限chmod go-w file去掉属组和其他人的写权限。哪种更好我的看法是分场景想要明确设定一个文件的完整权限用数字法一眼就能看出来最终结果。只想改某个角色的某个权限位用符号法更安全因为它只动你指定的部分不会碰其他位。实际排障时我更喜欢先用ls -l看清楚现状然后根据“差什么补什么”用符号法做最小改动。这样既能解决问题又不会顺手把别的权限改错。3.2 到底该不该用chmod -Rchmod和chown都支持-R参数递归处理目录下的所有文件。看起来很方便但用起来要非常克制。比如遇到一个目录需要整个授权给某个用户很多人顺手就来一句:chown -R zhangsan:devteam /data/project/ chmod -R 755 /data/project/这么干的风险有两个。第一目录里的可执行文件可能原本有特定权限需求被强制改成统一值后可能跑不起来。第二目录里如果有敏感数据一刀切成755等于对所有人开放读权限安全隐患非常大。更稳妥的做法是把“目录本身”和“目录里的内容”分开处理。目录权限用find配合-type d批量设置文件用-type f单独设置find /data/project -type d -exec chmod 750 {} \; find /data/project -type f -exec chmod 640 {} \;这样目录是r-x文件是r-配合属主属组的规划比一刀切755合理得多。如果目录里的内容很多且结构复杂先跑一遍find ... -type f | wc -l看看数量再决定要不要分批跑避免一条命令执行半天甚至影响线上服务。3.3 umask新文件默认权限是怎么来的很多人不知道你新建一个文件或目录时它的默认权限已经由umask决定了。umask是一个掩码作用是“扣掉”某些权限位。Linux默认的基数是文件666、目录777。新建文件时系统会用基数的权限减去umask的值得到实际权限。所以如果umask是022那么新文件666 - 022 644属主读写其他人只读新目录777 - 022 755属主全部权限其他人读和x如果umask是077那新文件就是600新目录就是700其他人完全进不来。对于个人隐私数据或公司敏感信息的存放目录把umask调成077是很有必要的。查看和修改umask也很简单umask # 查看当前值通常输出 0022 或 022 umask 077 # 临时修改仅当前Shell生效如果想让某个用户登录后自动使用新的umask可以写到他的~/.bashrc或~/.profile里。注意umask临时修改只在当前会话生效不会持久化这也是一个常见的“重新登录后又变回原样”的原因。4. 实战搭建一个多人协作的共享目录这一节我拿一个实际场景来完整走一遍把前面说到的概念全部串起来。假设你手头有一台服务器要给三个开发人员建一个共享项目目录/data/project。需求是开发人员都能读写但不能互相乱删文件之外的东西其他无关用户完全不能访问项目文件要能被多人正常编辑。4.1 需求分析与方案设计先把需求翻译成权限语言三个开发人员建一个组叫devteam。共享目录属主可以设为root属组是devteam。目录权限属主rwx属组rwx其他人无权限即770。为了让新文件自动继承devteam组目录要加setgid位。为了防止用户不小心删掉别人创建的文件目录要加sticky bit位。setgid和sticky bit这两个特殊位稍后会单独解释现在先按这个方案往下走。4.2 从建组到授权完整操作实录假设系统里已经有三个用户zhangsan、lisi、wangwu。现在开始操作# 1. 创建共享组 groupadd devteam # 2. 把三个用户加入组 usermod -aG devteam zhangsan usermod -aG devteam lisi usermod -aG devteam wangwu # 3. 创建共享目录 mkdir -p /data/project # 4. 设置属主和属组 chown root:devteam /data/project # 5. 设置目录权限属主rwx属组rwx其他人无权限 chmod 770 /data/project # 6. 加setgid位让目录里新建的文件自动继承devteam组 chmod gs /data/project # 7. 加sticky bit位只有文件所有者或root才能删除别人的文件 chmod t /data/project # 8. 验证成果 ls -ld /data/project # 预期输出drwxrws--t. 2 root devteam 4096 ...看到没有这一串命令下来ls -ld的输出是drwxrws--t。权限位的顺序是属主rwx属组rwss就是setgid其他人--tt就是sticky bit。第三组权限里没有x显示为t而不是T说明既有sticky bit又有执行权限位。这里有个重要细节sticky bit写在“其他人”的执行位上。如果第三组里根本没有x权限它会显示成大写的T表示sticky bit虽然设了但没有执行权限等于半残废状态该限制的效果并不会正确生效。同理setgid如果没配上属组的x权限也会显示成S。4.3 特殊位的价值与风险setgid、sticky bit这两个特殊位在多人协作场景里几乎天天用到。setgid作用于目录时目录里新建的文件会自动继承目录的属组而不是创建者自己的主组。这样大家创建的文件都归devteam组彼此能正常协作不用每次创建后再手动chgrp。sticky bit最常见的例子是/tmp目录。它保证任何人都能在/tmp里创建文件但只有文件所有者和root能删除或重命名别人的文件。没有sticky bit的共享目录容易出现“我把代码提交到共享目录同事随手一个rm把整个项目给清了”的惨剧。有了它至少不会被非所有者误删。这两个位的设置命令也可以合在一起用八进制写setgid对应数字2sticky对应数字1如果同时要设置就在权限位前面加3比如chmod 3770 /data/project。拆分地写的好处是可读性强一点毕竟是运维同事要维护的东西不易产生误读。需要特别提醒的是sticky bit只限制“删除和重命名”不限制“修改内容”。用户对别人的共享文件依然有写权限的话可以把文件内容清空覆盖这照样会造成损失。所以真正重要的场景光靠文件权限是不足够的需要考虑备份、版本控制等机制兜底。4.4 目录重建时的权限坑共享目录往往不是创建一次就完事了。过段时间磁盘满了要换存储或者目录结构要调整很多人的做法是先rm -rf /data/project再mkdir /data/project。问题来了直接mkdir创建的新目录权限会受umask影响默认可能是755属主属组也变成了执行命令的人。之前精心设置的2770状态全没了。这一步出错时并不会马上报错而是等用户来访问时才发现权限不对。正确的做法是先备份、再删除、再创建目录后重新执行chown和chmod。或者干脆保留目录只清空里面的内容# 只删内容不删目录本身 find /data/project -mindepth 1 -delete这样目录的权限、属主、特殊位全都保留着不用重新配。类似的如果你用tar打包再解包也是同样的道理解包后务必检查一下目录的权限位。5. 常见问题排查权限报错与提权边界跑题一下其实Windows系统上“你需要来自trusted的权限才能对此文件进行更改”这类报错和Linux下的Permission denied本质上是同一个问题操作者没有足够的权限去访问目标资源。只不过Windows喜欢给你弹窗Linux喜欢在终端里静默地拒绝你。很多从Windows转过来的同学在Linux上遇到权限报错第一反应是到处找“管理员身份运行”但其实思路完全不一样Linux下你得想清楚自己是哪个角色文件属于哪个组该给谁开什么权限。5.1 高频权限报错速查表下面这些是我在排障中遇到最高频的几类问题整理成一张表方便你按图索骥报错信息原因解法Permission denied无权限访问文件或目录检查用户是否在属组里检查目录x权限Operation not permitted操作被系统拒绝需要rootsudo执行或调整能力位cannot open directory: Permission denied目录没有r/x权限给目录加rxchmod rx dirsudo: user not in the sudoers file用户不在sudo授权列表里root执行visudo添加用户su: Authentication failure密码错或用户被锁定确认密码或passwd -u 用户解锁chmod: changing permissions of xxx: Operation not permitted执行者不是文件属主或root换属主或使用root执行表格只能覆盖大方向实际排查时的思路我单独写一段。5.2 我排障时的常规套路遇到权限问题我一般按下面这个顺序走基本两分钟定位第一步先看当前用户是谁whoami id第二步看文件属主和属组ls -ld /path/to/file第三步从“目标用户是否能进入文件所在的所有上级目录”这条路开始看。路径上的每一层目录都需要x权限缺一个就访问不到最里层的文件。这一步是最容易漏的。很多人只检查了文件本身忽略了中间路径的目录权限。第四步看selinux有没有捣乱。在CentOS/RHEL系列的系统里就算文件权限全对SELinux策略也可能拦截访问。最直接的排查方法是看告警日志或者临时用setenforce 0关掉SELinux试试。如果这样就通了说明是策略问题再用chcon或restorecon调整文件上下文。注意SELinux关闭后别忘了恢复不然服务器重启后SELinux又自动打开了问题依旧。第五步看看是不是ACL在起作用。有时候你明明设置了正确的权限但ls -l输出末尾有个号说明文件有ACL规则覆盖了传统权限。用getfacl查看用setfacl调整。这套流程的核心思想就是不要凭感觉改权限先判断限制到底来自哪个环节再对症下药。5.3 提权与安全sudo的配置哲学最后讲一下提权。普通用户在某些场景下需要root权限常接触的是sudo。偶尔一次用root跑一下命令没问题但生产环境里“谁都用root操作”是非常危险的信号。正确做法是给需要临时提权的用户配置sudo白名单只开放实际操作需要的命令。经典的sudo配置方法是修改/etc/sudoers文件但绝对不要直接vim编辑它格式写错了可能会把整个sudo功能搞坏。必须用visudo命令来编辑它退出时会做语法检查有问题会提醒你避免你把自己锁在门外。一个最小化授权的例子# 让zhangsan能重启nginx服务 zhangsan ALL(ALL) /usr/bin/systemctl restart nginx # 让lisi能查看系统日志 lisi ALL(ALL) /usr/bin/tail /var/log/messages如果只希望用户能用sudo执行运维脚本而不是让他随意切换成任意用户操作可以在sudoers里严格控制命令路径和参数。这个文件是系统安全的关键口子我只建议root用户操作它。需要额外提醒的是sudo没有密码也可以配置成NOPASSWD但我不建议你图省事把密码验证去掉。密码验证虽然烦但在公共环境里是一道很基本的“不能随便冒充root执行高危命令”的防线。如果一定要NOPASSWD至少把可执行命令范围收敛到最小。结束前再分享一个我的习惯权限管理这件事越往后做越会发现它不只是“敲几条命令”的技巧而是你对自己服务器资产边界的一种盘点。我自己的习惯是每台服务器交付时都把用户列表、用户所属组、关键目录的权限位、sudo白名单整理成单独的文件存到项目文档里后续任何人修改了权限就在这份文档里留一条记录。这个习惯看起来不起眼但等系统里用户数量上来了线上出现权限故障需要快速回溯时这套记录能帮你省下大把排查时间。如果在实际使用中遇到过什么有趣的权限问题或发现某个权限位设置得很奇怪欢迎在评论区写出来大家一起拆一拆、理一理。踩过的坑多了慢慢就能摸清这套权限体系的脾气了。
1. 权限体系到底在解决什么问题很多人学Linux学到用户和权限这块就卡住了。倒不是说命令有多难背而是脑子里没有建立起一个完整的模型——为什么要设计用户和组rwx三件套到了目录上怎么解释为什么有时候明明有rwx权限程序还是跑不起来如果你也有这些困惑那这篇内容就是给你准备的。我会从权限体系的设计逻辑讲起把用户、组、文件权限这三块揉碎了串起来最后再带一个完整的实操案例不管是刚接触Linux的新手还是被权限问题折腾过的运维、开发同学都能从中拿到一些能直接用的东西。1.1 三个角色的划分逻辑Linux的权限模型本质上是一个“多用户隔离”的问题。一台服务器上可能同时跑着十几个人的任务有人在部署网站有人在跑数据分析还有人在改配置文件。如果所有人都是root那一个手滑就可能把别人的环境毁了。所以系统把“谁是谁”这件事拆成了三层文件所有者u、属组g、其他人o。这里的核心思想是每个文件必须有且只有一个所有者必须属于且只属于一个组然后剩下的访问者统统归类到“其他人”里。你做的事情就是给这三类角色分别设定权限。这个设计不是拍脑袋定的。它要解决两个现实问题第一一个人什么时候能读、能写、能执行某个文件系统需要一个明确的判断依据第二当多个用户需要协作访问同一批文件时怎么避免逐个去配权限的体力活。组的存在就是为了解决第二个问题的——把一批人归到一个组再给这个组统一授权比一个个加权限要高效得多。1.2 rwx三件套对文件和目录的意义完全不同r、w、x这三个字母大家都不陌生。但很多人踩坑就踩在用文件的思路去理解目录的权限。对文件来说r代表可以读取内容w代表可以修改内容x代表可以把它当作程序来执行。这个直觉是对的。但到了目录这里含义全变了r可以列出目录里有什么ls能出结果但能不能访问某个具体文件还要看后续权限。w可以在目录里新建、删除、重命名文件或子目录。注意是目录的写权限而不是文件本身的写权限。x表示能不能“穿过”这个目录也就是能不能进入目录去访问里面的内容。没有x权限就算你有r权限ls进去也可能报错。打个比方目录就像一栋楼的走廊门禁。r是能看楼层索引牌w是你有钥匙能开门放东西进去x是你有通行卡能走进走廊本身。只有r没有x你站在门口能看到里面大概有什么但进不去只有x没有r你能进去但像个没戴眼镜的人不知道里面具体有哪些房间。这个区别在排障时极其重要。最常见的一个坑就是你给了一个用户某个文件的读权限但文件所在目录的x权限没开用户照样访问不了。很多新人只盯着文件本身的权限调完全没意识到目录权限才是拦路虎。1.3 为什么Linux不直接给每个人单独配权限既然权限是围绕用户来的那为什么不干脆针对每个用户单独设置权限一些新版文件系统比如ZFS的ACL确实支持更细粒度的控制但传统Linux的POSIX权限模型一直坚持“用户、组、其他人”这种粗粒度设计核心原因有两个第一简单可靠。三组权限位一共9个比特位再加三个特殊位所有信息都能用一个短字符串表示也就能稳定地存储在各种文件系统上。这个模型从Unix时代用到现在说明它的底子足够扎实。第二符合大多数场景的实际需求。想想真实情况一台机器上的用户数一般远小于文件数而能访问同一批文件的人通常都属于同一个项目组或同一个业务团队。用“组”来做授权单位正好覆盖了绝大多数协作需求。当然粗粒度也带来一些别扭的地方。比如两个人要共享一个文件但只有这两个人能访问用传统权限就比较尴尬要么建个新组要么用ACL。这才有了ACL访问控制列表作为补充方案。你不需要把ACL当成日常主力工具但要意识到它是权限工具箱里的一员遇到精细授权需求时别忘了还有这个选项。2. 用户和组的管理先把“人”理清楚权限的载体是“用户”和“组”。所以第一步不是去改文件权限而是先把系统里的用户、组梳理明白。很多新手上来就chmod 777看着是解决问题了实际上是把系统的大门彻底敞开了毫无安全边界可言。2.1 用户、组、UID/GID的最小知识储备Linux里用户和组的本质不是一个名字而是一个数字ID。用户名只是给人看的系统真正识别的是UID组对应的则是GID。你可以通过id命令查看一个用户的完整身份信息$ id zhangsan uid1001(zhangsan) gid1001(zhangsan) groups1001(zhangsan),10(wheel)这里能看到三样东西用户自己的UID、主组GID以及附加组列表。理解“主组”和“附加组”的区别很重要。主组是用户创建文件时默认所属的组附加组是用户额外获得的组成员身份用于访问其他共享资源。一个人可以同时在多个附加组里但主组只有一个。系统用户和普通用户的UID范围也有讲究。一般约定0是root的UID1-999是系统服务用的虚拟用户1000以上才是普通用户。这个区分是为了防止普通程序意外拿到系统级别的文件访问权限。2.2 常用命令从创建到删除的完整链路用户和组的管理命令其实就那么几个但每个都有不少细节。我直接给一张速查表操作命令说明创建组groupadd devteam新建一个名为devteam的组创建用户并指定主组useradd -g devteam zhangsan用户zhangsan的主组是devteam创建用户并加入附加组useradd -G docker,devteam zhangsan用户额外加入docker和devteam组修改用户附加组usermod -aG docker zhangsan-a表示追加不加-a会覆盖原有附加组修改用户主组usermod -g devteam zhangsan把主组改为devteam删除用户userdel -r zhangsan-r会同时删除家目录和邮件池删除组groupdel devteam组里不能有用户的主组是它查看用户信息id zhangsan查看UID/GID和组信息修改密码passwd zhangsan设置或修改用户密码这里我特别提醒两个高频坑。第一个坑usermod不加-a。比如用户zhangsan原本在wheel组和docker组里你执行了usermod -G devteam zhangsan他的附加组会变成只有devteam原来那些全部被清掉。正确做法是usermod -aG devteam zhangsan这个-a表示append追加进去。我见过太多人因为漏了-a把一个用户从一堆重要组里踢出去然后发现sudo用不了了。第二个坑useradd和adduser在两个发行版上行为不同。CentOS/RHEL系里useradd是原生命令直接生效Debian/Ubuntu系里useradd也存在但adduser是更友好的封装会交互式地让你设置密码、填用户信息。如果你在Ubuntu上用useradd创建用户不主动指定选项这个用户可能连家目录都没有。比较稳妥的做法是创建后立即passwd设置密码并确认家目录存在。2.3 初次创建用户时最容易忽略的细节按惯例创建用户的完整流程我在生产环境里一般是这么写的供你参考# 1. 创建组 groupadd devteam # 2. 创建用户指定主组、家目录、Shell useradd -g devteam -m -d /home/zhangsan -s /bin/bash zhangsan # 3. 设置密码 passwd zhangsan # 4. 把用户加进附加组 usermod -aG wheel zhangsan # 5. 验证 id zhangsan这里有几个细节值得展开讲。第一-s /bin/bash要显式指定。有些系统默认Shell是nologin或sh用户登进来发现命令行难用得想哭还以为是系统坏了。第二-m -d /home/zhangsan表示创建家目录并指定位置。如果你的发行版useradd默认不创建家目录比如最小化安装的某些系统漏了这个选项会导致用户登录后落在根目录而且很多程序会行为异常。第三创建完立刻验证别等用户反馈问题了再回头看那就被动了。还有一个特别容易被忽略的点用户加入新组后如果已经登录了新组的身份不会立即生效。必须重新登录或者用newgrp切换一下才能拿到新组的访问权。这个不是系统出bug是会话里的凭证没有刷新而已。3. chmod/chown/chgrp文件权限的三板斧把用户和组理清楚之后就该动文件了。这一节是实际操作中最常用的部分也是问题最多的部分。chmod改权限、chown改属主属组、chgrp改属组这三条命令配合使用能解决绝大多数授权需求。3.1 数字法、符号法哪种更推荐chmod有两种语法风格数字法和符号法。两种都得会因为你会在各种脚本和文档里都遇到它们。数字法的逻辑是把rwx映射成二进制r4w2x1。每类角色的权限就是一个数字把三者相加得到0-7之间的值。比如7421rwx642rw-541r-x。最终一个完整的权限就是三个数字连起来比如chmod 750 file表示属主rwx、属组r-x、其他人没有任何权限。符号法则是直接用u/g/o/a指定角色用-设置权限操作比如chmod ux file给属主加执行权限chmod go-w file去掉属组和其他人的写权限。哪种更好我的看法是分场景想要明确设定一个文件的完整权限用数字法一眼就能看出来最终结果。只想改某个角色的某个权限位用符号法更安全因为它只动你指定的部分不会碰其他位。实际排障时我更喜欢先用ls -l看清楚现状然后根据“差什么补什么”用符号法做最小改动。这样既能解决问题又不会顺手把别的权限改错。3.2 到底该不该用chmod -Rchmod和chown都支持-R参数递归处理目录下的所有文件。看起来很方便但用起来要非常克制。比如遇到一个目录需要整个授权给某个用户很多人顺手就来一句:chown -R zhangsan:devteam /data/project/ chmod -R 755 /data/project/这么干的风险有两个。第一目录里的可执行文件可能原本有特定权限需求被强制改成统一值后可能跑不起来。第二目录里如果有敏感数据一刀切成755等于对所有人开放读权限安全隐患非常大。更稳妥的做法是把“目录本身”和“目录里的内容”分开处理。目录权限用find配合-type d批量设置文件用-type f单独设置find /data/project -type d -exec chmod 750 {} \; find /data/project -type f -exec chmod 640 {} \;这样目录是r-x文件是r-配合属主属组的规划比一刀切755合理得多。如果目录里的内容很多且结构复杂先跑一遍find ... -type f | wc -l看看数量再决定要不要分批跑避免一条命令执行半天甚至影响线上服务。3.3 umask新文件默认权限是怎么来的很多人不知道你新建一个文件或目录时它的默认权限已经由umask决定了。umask是一个掩码作用是“扣掉”某些权限位。Linux默认的基数是文件666、目录777。新建文件时系统会用基数的权限减去umask的值得到实际权限。所以如果umask是022那么新文件666 - 022 644属主读写其他人只读新目录777 - 022 755属主全部权限其他人读和x如果umask是077那新文件就是600新目录就是700其他人完全进不来。对于个人隐私数据或公司敏感信息的存放目录把umask调成077是很有必要的。查看和修改umask也很简单umask # 查看当前值通常输出 0022 或 022 umask 077 # 临时修改仅当前Shell生效如果想让某个用户登录后自动使用新的umask可以写到他的~/.bashrc或~/.profile里。注意umask临时修改只在当前会话生效不会持久化这也是一个常见的“重新登录后又变回原样”的原因。4. 实战搭建一个多人协作的共享目录这一节我拿一个实际场景来完整走一遍把前面说到的概念全部串起来。假设你手头有一台服务器要给三个开发人员建一个共享项目目录/data/project。需求是开发人员都能读写但不能互相乱删文件之外的东西其他无关用户完全不能访问项目文件要能被多人正常编辑。4.1 需求分析与方案设计先把需求翻译成权限语言三个开发人员建一个组叫devteam。共享目录属主可以设为root属组是devteam。目录权限属主rwx属组rwx其他人无权限即770。为了让新文件自动继承devteam组目录要加setgid位。为了防止用户不小心删掉别人创建的文件目录要加sticky bit位。setgid和sticky bit这两个特殊位稍后会单独解释现在先按这个方案往下走。4.2 从建组到授权完整操作实录假设系统里已经有三个用户zhangsan、lisi、wangwu。现在开始操作# 1. 创建共享组 groupadd devteam # 2. 把三个用户加入组 usermod -aG devteam zhangsan usermod -aG devteam lisi usermod -aG devteam wangwu # 3. 创建共享目录 mkdir -p /data/project # 4. 设置属主和属组 chown root:devteam /data/project # 5. 设置目录权限属主rwx属组rwx其他人无权限 chmod 770 /data/project # 6. 加setgid位让目录里新建的文件自动继承devteam组 chmod gs /data/project # 7. 加sticky bit位只有文件所有者或root才能删除别人的文件 chmod t /data/project # 8. 验证成果 ls -ld /data/project # 预期输出drwxrws--t. 2 root devteam 4096 ...看到没有这一串命令下来ls -ld的输出是drwxrws--t。权限位的顺序是属主rwx属组rwss就是setgid其他人--tt就是sticky bit。第三组权限里没有x显示为t而不是T说明既有sticky bit又有执行权限位。这里有个重要细节sticky bit写在“其他人”的执行位上。如果第三组里根本没有x权限它会显示成大写的T表示sticky bit虽然设了但没有执行权限等于半残废状态该限制的效果并不会正确生效。同理setgid如果没配上属组的x权限也会显示成S。4.3 特殊位的价值与风险setgid、sticky bit这两个特殊位在多人协作场景里几乎天天用到。setgid作用于目录时目录里新建的文件会自动继承目录的属组而不是创建者自己的主组。这样大家创建的文件都归devteam组彼此能正常协作不用每次创建后再手动chgrp。sticky bit最常见的例子是/tmp目录。它保证任何人都能在/tmp里创建文件但只有文件所有者和root能删除或重命名别人的文件。没有sticky bit的共享目录容易出现“我把代码提交到共享目录同事随手一个rm把整个项目给清了”的惨剧。有了它至少不会被非所有者误删。这两个位的设置命令也可以合在一起用八进制写setgid对应数字2sticky对应数字1如果同时要设置就在权限位前面加3比如chmod 3770 /data/project。拆分地写的好处是可读性强一点毕竟是运维同事要维护的东西不易产生误读。需要特别提醒的是sticky bit只限制“删除和重命名”不限制“修改内容”。用户对别人的共享文件依然有写权限的话可以把文件内容清空覆盖这照样会造成损失。所以真正重要的场景光靠文件权限是不足够的需要考虑备份、版本控制等机制兜底。4.4 目录重建时的权限坑共享目录往往不是创建一次就完事了。过段时间磁盘满了要换存储或者目录结构要调整很多人的做法是先rm -rf /data/project再mkdir /data/project。问题来了直接mkdir创建的新目录权限会受umask影响默认可能是755属主属组也变成了执行命令的人。之前精心设置的2770状态全没了。这一步出错时并不会马上报错而是等用户来访问时才发现权限不对。正确的做法是先备份、再删除、再创建目录后重新执行chown和chmod。或者干脆保留目录只清空里面的内容# 只删内容不删目录本身 find /data/project -mindepth 1 -delete这样目录的权限、属主、特殊位全都保留着不用重新配。类似的如果你用tar打包再解包也是同样的道理解包后务必检查一下目录的权限位。5. 常见问题排查权限报错与提权边界跑题一下其实Windows系统上“你需要来自trusted的权限才能对此文件进行更改”这类报错和Linux下的Permission denied本质上是同一个问题操作者没有足够的权限去访问目标资源。只不过Windows喜欢给你弹窗Linux喜欢在终端里静默地拒绝你。很多从Windows转过来的同学在Linux上遇到权限报错第一反应是到处找“管理员身份运行”但其实思路完全不一样Linux下你得想清楚自己是哪个角色文件属于哪个组该给谁开什么权限。5.1 高频权限报错速查表下面这些是我在排障中遇到最高频的几类问题整理成一张表方便你按图索骥报错信息原因解法Permission denied无权限访问文件或目录检查用户是否在属组里检查目录x权限Operation not permitted操作被系统拒绝需要rootsudo执行或调整能力位cannot open directory: Permission denied目录没有r/x权限给目录加rxchmod rx dirsudo: user not in the sudoers file用户不在sudo授权列表里root执行visudo添加用户su: Authentication failure密码错或用户被锁定确认密码或passwd -u 用户解锁chmod: changing permissions of xxx: Operation not permitted执行者不是文件属主或root换属主或使用root执行表格只能覆盖大方向实际排查时的思路我单独写一段。5.2 我排障时的常规套路遇到权限问题我一般按下面这个顺序走基本两分钟定位第一步先看当前用户是谁whoami id第二步看文件属主和属组ls -ld /path/to/file第三步从“目标用户是否能进入文件所在的所有上级目录”这条路开始看。路径上的每一层目录都需要x权限缺一个就访问不到最里层的文件。这一步是最容易漏的。很多人只检查了文件本身忽略了中间路径的目录权限。第四步看selinux有没有捣乱。在CentOS/RHEL系列的系统里就算文件权限全对SELinux策略也可能拦截访问。最直接的排查方法是看告警日志或者临时用setenforce 0关掉SELinux试试。如果这样就通了说明是策略问题再用chcon或restorecon调整文件上下文。注意SELinux关闭后别忘了恢复不然服务器重启后SELinux又自动打开了问题依旧。第五步看看是不是ACL在起作用。有时候你明明设置了正确的权限但ls -l输出末尾有个号说明文件有ACL规则覆盖了传统权限。用getfacl查看用setfacl调整。这套流程的核心思想就是不要凭感觉改权限先判断限制到底来自哪个环节再对症下药。5.3 提权与安全sudo的配置哲学最后讲一下提权。普通用户在某些场景下需要root权限常接触的是sudo。偶尔一次用root跑一下命令没问题但生产环境里“谁都用root操作”是非常危险的信号。正确做法是给需要临时提权的用户配置sudo白名单只开放实际操作需要的命令。经典的sudo配置方法是修改/etc/sudoers文件但绝对不要直接vim编辑它格式写错了可能会把整个sudo功能搞坏。必须用visudo命令来编辑它退出时会做语法检查有问题会提醒你避免你把自己锁在门外。一个最小化授权的例子# 让zhangsan能重启nginx服务 zhangsan ALL(ALL) /usr/bin/systemctl restart nginx # 让lisi能查看系统日志 lisi ALL(ALL) /usr/bin/tail /var/log/messages如果只希望用户能用sudo执行运维脚本而不是让他随意切换成任意用户操作可以在sudoers里严格控制命令路径和参数。这个文件是系统安全的关键口子我只建议root用户操作它。需要额外提醒的是sudo没有密码也可以配置成NOPASSWD但我不建议你图省事把密码验证去掉。密码验证虽然烦但在公共环境里是一道很基本的“不能随便冒充root执行高危命令”的防线。如果一定要NOPASSWD至少把可执行命令范围收敛到最小。结束前再分享一个我的习惯权限管理这件事越往后做越会发现它不只是“敲几条命令”的技巧而是你对自己服务器资产边界的一种盘点。我自己的习惯是每台服务器交付时都把用户列表、用户所属组、关键目录的权限位、sudo白名单整理成单独的文件存到项目文档里后续任何人修改了权限就在这份文档里留一条记录。这个习惯看起来不起眼但等系统里用户数量上来了线上出现权限故障需要快速回溯时这套记录能帮你省下大把排查时间。如果在实际使用中遇到过什么有趣的权限问题或发现某个权限位设置得很奇怪欢迎在评论区写出来大家一起拆一拆、理一理。踩过的坑多了慢慢就能摸清这套权限体系的脾气了。
