如果你刚接触Linux大概率会在一台服务器前面纠结过这种事明明数据就在 /home 下用别人的账号却进不去用 root 却畅通无阻新建了一个用户结果登录之后连命令都敲不了几条。这些现象背后全都是“用户与权限”在起作用。Linux被称为多用户多任务系统用户和权限是整个系统安全模型的地基每次敲错一个 chmod 或者漏配一行 sudoers都可能让你在深夜的运维现场焦头烂额。这篇文章会比较系统地梳理Linux下的用户体系、文件权限、日常操作命令和疑难排查适合刚把 Linux 装好、正在学基础操作或者经常帮人收拾服务器权限问题的朋友我会尽量用实际场景把概念讲透而不是简单罗列命令。1. 用户体系先搞清楚“你是谁”1.1 Linux天然是多人共用的系统Windows 给很多人的印象是一台电脑一个主人账号只是个“进入系统”的入口。Linux 从诞生起就面向多人多任务场景它把“人”抽象成用户把“权限”挂在用户身上每个进程执行时也带着用户的身份标识。这样设计的好处很明显不同用户之间互不干扰一台服务器可以同时跑着数据库、Web服务、开发者的测试程序如果有人搞坏了某个目录影响范围也能被限制在特定用户和文件范围内。在 Linux 中用户也不是只有“普通用户”和“管理员”两种。更细一点系统里通常有三类root超级管理员uid 为 0跳过几乎全部权限检查可以操作所有文件、修改内核参数、管理其他用户。日常操作我一般不建议长期用 root尤其是生产服务器一旦手滑删个关键目录没有后悔药。系统用户uid 通常在 1~999 之间不同发行版范围有差异比如 nginx、mysql、sshd 这些账户。它们不是给人登录用的而是给服务进程一个“安全身份”让跑服务时不要把权限放大到 root。普通用户uid 一般从 1000 开始就是咱们平时登录使用的账户能操作自己 home 目录和系统分配的可写位置。判断一个用户属于哪一类直接查 uid 即可。1.2 三个核心配置文件passwd、shadow、group用户信息不是乱存一气的只要你搞懂了三个文件用户管理基本就懂了一半。/etc/passwd存放用户基本信息。每一行代表一个用户格式为用户名:x:uid:gid:描述:家目录:登录shell。注意那个字段是x它只是占位符真正的密码不放在这里。/etc/shadow存放密码哈希和过期策略。只有 root 可读普通用户连看都看不见。里面除了密码哈希值还有上次修改密码日期、最短/最长使用天数、失效日期等字段。/etc/group存放用户组信息。格式是组名:x:gid:组成员列表。Linux 下“组”是批量授权的重要工具比如你想要几个同事都能读某个项目目录把他们放进同一个组然后用 chown 把目录的属组改成该组即可。我习惯用一个简单类比理解三者/etc/passwd像员工的工牌姓名、工号、部门/etc/shadow像保险柜钥匙验证密语/etc/group像会议室权限名单谁能预约哪间房。实际排错时很多“明明用户存在却无法登录”的问题就是三个文件之间信息不对应或者 shadow 里的账号行被加了!锁定标记排查时优先看这三个文件。2. 文件权限模型rwx到底在做什么2.1 读、写、执行在文件和目录上的含义完全不同你可以把 Linux 文件权限看成一张“门禁卡授权表”每份文件或目录都记录了“哪个用户和哪个组能干什么”。常见的rwx三个字母在文件与目录上的意思并不一样对文件r读可以查看内容比如用 cat 打开。w写可以修改文件内容但不代表能删除文件删除取决于目录权限。x执行可以把它当作命令或脚本运行。对目录r读可以列出目录下的文件名也就是能 ls。w写可以在目录里新建、删除、重命名文件或子目录即使你不拥有那些文件本身。x执行可以进入目录也就是能 cd 进去。很多人困惑“我明明可以对文件写为什么删不掉它”原因就在这里删除操作发生在目录层面你需要对所在目录有写和执行权限。这个特性常常是排查故障的盲区。权限数据在ls -l输出里长这样-rwxr-xr-- 1 zhangsan devops 2048 Jul 12 10:30 script.sh第一位-表示普通文件如果是d则是目录。接下来九个字符按三组排列拥有者owner、属组group、其他用户other。rwxr-xr-- 拥有者可读写执行组内成员可读可执行其他人只可读。后面跟着“拥有者用户名”和“所属组名”。2.2 数字权限以及特殊权限位用数字表示权限是ls -l之外最常用的写法。规则很简单r4w2x1然后相加。rwxr-xr--对应751因为拥有者 4217组 415其他人 44。除了基础 rwx还有三个特殊权限位在特定场景很有用setuid4如果在可执行文件上设置了 setuid普通用户运行这个程序时进程身份会临时变成文件属主。最典型的例子是/usr/bin/passwd普通用户修改密码需要写/etc/shadow正是通过 setuid 临时获得 root 能力。setgid2对文件使用运行时临时拥有文件属组权限。对目录使用会让新建出来的文件或子目录自动继承该目录的属组多人在公共项目目录里协作时尤其好用。sticky bit1主要用在/tmp这类公共目录设置了粘滞位后即便目录对其他用户是可写的用户也只能删除自己拥有的文件。目录末尾的t标志就是它。数字权限通常写成四位比如4755前面的 4 是 setuid。举例来看chmod 4755 /usr/local/bin/tool就是把 tool 设为“普通用户执行时拥有其属主身份”这是一个很有威力的设置使用前要确认是可信程序。2.3 umask为什么新建文件默认是644每次新建文件系统并不会直接给你 777而是先减去一个“默认屏蔽值”这个值就是 umask。执行umask命令可以看到当前值通常文件系统默认值是0022。计算逻辑文件的基准权限通常是666666目录是777。umask 的 022 表示屏蔽组和其他用户的写权限。所以新建文件默认为666 - 022 644新建目录默认为777 - 022 755。如果你的环境要求新建文件默认是640比如团队项目不希望其他组的人读可以在/etc/profile或~/.bashrc里加一句umask 0027。注意 umask 改的是“新建文件”的默认权限不会影响已存在的文件。3. 实操创建用户、切换身份、授予sudo3.1 useradd建用户的几个关键参数别漏了在运维时我创建用户用的命令是useradd不同发行版的默认行为略有差别建议每次手动指定关键参数不要依赖发行版默认值。常用参数如下参数作用示例-m创建家目录useradd -m zhangsan-u指定 uiduseradd -u 1500 zhangsan-g指定主组useradd -g devops zhangsan-G加入附加组useradd -G docker,www zhangsan-s指定登录 shelluseradd -s /bin/bash zhangsan-d指定家目录路径useradd -d /data/home/zhangsan-e设置账号过期时间useradd -e 2025-12-31 zhangsan一个实际完整的示例useradd -m -d /home/zhangsan -u 1501 -g devops -G docker,www -s /bin/bash zhangsan passwd zhangsan跑完useradd后一定还要passwd zhangsan设置初始密码否则账号无法登录。Debian/Ubuntu 环境里有adduser这个更友好的封装它会自动创建家目录、设置 shell、交互式改密码新手可以优先用它。我之前见过有人只用useradd zhangsan不加-m结果用户没有家目录登录后落在一堆报错里。3.2 usermod与userdel修改和删除用户用户建好了不代表不用改。改用户信息主要用usermod它支持修改多种属性usermod -aG docker zhangsan # 把 zhangsan 加入 docker 组注意要带 -a否则会覆盖原有附加组 usermod -s /bin/bash zhangsan # 修改 shell usermod -L zhangsan # 锁定账号禁止登录 usermod -U zhangsan # 解锁账号删除用户则用userdeluserdel zhangsan # 只删账号保留家目录 userdel -r zhangsan # 连家目录和邮件队列一起删-r是很危险的操作请在执行前确认用户数据已经备份。团队协作中我通常不会真的删用户而是先用usermod -L锁定观察一段时间没有存量业务依赖后再决定是否删除。3.3 su与sudo什么场景用哪个以及visudo配置切到 root 有两种常见方式su root和sudo。两者的差别非常实际su root需要输入 root 的密码会获得一个完整的 root 登录 shell之后所有命令都是 root 身份直到你exit。这种方式适合紧急维护但风险也大一个不小心就可能以 root 身份执行错误命令。而且多人共用服务器时共享 root 密码本身就是安全隐患。sudo使用当前用户自己的密码就能临时提权只在执行命令的那一刻以 root 身份运行权限更受控并且一切操作都可以被记录在/var/log/auth.log不同发行版日志路径有差异。这就是为什么生产环境都推荐 sudo 而不是直接给 root 密码。sudo 的授权配置在/etc/sudoers里改这个文件请务必用visudo命令打开编辑因为它会校验语法语法出错会导致 sudo 全部不可用。常见配置zhangsan ALL(ALL) ALL这行的意思是“zhangsan 在任何主机上可以以任何用户身份执行任何命令”。更精细的写法还有zhangsan ALL(root) /usr/bin/systemctl # 只能以 root 身份执行 systemctl 命令 %devops ALL(ALL) ALL # 组名前面加 %表示对整个组授权 zhangsan ALL(ALL:ALL) ALL # 允许切换到任意用户和任意组修改 sudoers 时的经验是永远开着另一个已确认有 sudo 权限的终端窗口一旦发现当前配置有问题还能用另一个会话补救。直接关闭唯一会话又改错 sudoers就只能在重启进单用户模式修复了。4. 权限修改与修复实战chmod、chown与常见场景4.1 chmod/chown/chgrp的参数组合一次讲清权限修改的三个命令是chmod # 修改读写执行权限rwx、数字表示法 chown # 修改文件的属主和属组 chgrp # 只修改文件的属组chown 可以替代最常见的操作chmod 755 script.sh # 设置成 755 chmod x script.sh # 只给所有用户增加执行权限 chmod -R 755 /data/www # 递归修改目录下所有文件 chown zhangsan:devops app.log # 把属主设置为 zhangsan属组设置为 devops chown -R zhangsan:devops /data/www # 递归修改整个目录的归属 chgrp -R devops /data/project # 递归把组改为 devops-R虽然好用但要注意如果目录树里既有文件又有目录统一设成 755 会让一些不该暴露的文件也被读了更精细的做法是分开处理——find /data/www -type d -exec chmod 755 {} \;和find /data/www -type f -exec chmod 644 {} \;。目录可执行文件不额外加执行权限是更省心的组合。4.2 典型修复案例网站目录与docker权限问题web 部署是权限问题的高发区。常见场景你用 root 把代码释放到/var/www/html结果 nginx 的工作进程以www-data用户运行读不了目录文件页面就给你一个 403。这时候不能图省事把整个网站目录改成 777正确做法是chown -R www-data:www-data /var/www/html find /var/www/html -type d -exec chmod 755 {} \; find /var/www/html -type f -exec chmod 644 {} \;只给进程实际需要的权限这是最基本的权限管理原则。另一个经常踩的坑是 docker 权限报错普通用户执行docker ps出现permission denied while trying to connect to the Docker daemon socket。这是因为/var/run/docker.sock的属组是docker普通用户不在该组里。解决办法是sudo usermod -aG docker $USER然后重新登录让组变更生效。这里要特别提醒加入 docker 组实际等同获得 root 能力因为 docker 容器可以挂载主机目录、执行特权操作只能在可信的单机环境或开发机里使用。4.3 修复权限的思路比命令更重要遇到权限问题我的排查套路通常是这样先看报错的是谁ls -l查看目标文件/目录的属主、属组和权限位。再确认执行者执行id查看当前用户的 uid、gid 和附加组。对照权限位我到底需要读、写还是执行当前用户是否属于那个组。根据最小权限原则修改属主能不能变组能不能加人用 chmod 还是调组变更后立刻验证拿执行者真实身份做一次操作不要用 root 自测。这套流程用在服务启动失败、文件上传失败、定时任务不执行这类问题里命中率非常高。5. 常见问题与排查技巧实录5.1 permission denied问题到底出在哪一层Permission denied是 Linux 里最经典的报错但它并不总是同一个原因。我整理过一张排查顺序表现象可能原因检查方法无法 cat 一个文件文件对当前用户没有读权限ls -l看 other 位是否有 r无法编辑文件文件没有写权限或文件所属目录没有写权限尝试touch 文件名看是否报错无法 cd 进目录目录没有执行权限ls -ld 目录看 x 位无法删除文件当前用户不拥有文件本身也没有目录写权限ls -ld 目录确认属主脚本无法运行文件没有执行权限或 shell 解释器路径不对chmod x 脚本head -1 脚本服务启动失败运行用户没有进入目录的权限sudo -u 服务用户 命令模拟执行提醒一句ls你能看到文件名并不能说明你能读文件内容。看到名字只需要有目录的读权限真的打开文件还需要文件本身的读权限。5.2 用户不在sudoers里以及sudo突然失效如果你收到xxx is not in the sudoers file. This incident will be reported.说明这个用户没有被授权 sudo。解决办法是先用 root 登录执行visudo # 添加一行你的用户名 ALL(ALL) ALL如果你用visudo改坏了语法所有 sudo 命令都会报错比如sudo: /etc/sudoers is world writable。这时候必须用 root 身份修复。Linux 在/etc/sudoers权限上有严格保护正常权限应为440属主 root、属组 root。如果因为误操作变成 777修复命令是chmod 440 /etc/sudoers另一个常见问题是密码正确但 sudo 仍然失败可以查看/var/log/auth.log里的具体错误条目通常能直接定位是 PAM 配置还是 sudoers 规则问题。5.3 无法删除文件先看看父目录和粘滞位网上常见的问题“我想删一个文件系统说没有权限”原因一般有三种文件本身只读不关键因为删除看的是文件所在目录的写权限。你的用户不是目录属主也没有目录写权限哪怕你是文件属主也删不了。目录被设置了粘滞位比如/tmp你只能删除自己创建的文件删其他人的文件就会被拒绝。如果确定要删除以 root 身份操作最直接但在业务目录里我更建议先把目录归属捋清楚确认没有服务正在使用再行动。ls -ld /tmp # 输出类似 drwxrwxrwt最后的 t 表示粘滞位5.4 用户登录被拒、切换失败su认证失败su: Authentication failure这个报错很容易误导人。它不是说系统不让你切换而是说明当前用户输入的密码不对或者 root 账号被锁定。在 Ubuntu 系列发行版里root 默认没有可用密码即使你执行su root并输入 root 相关密码也可能看到认证失败。正确做法是用sudo -i或者sudo su通过自己的 sudo 权限切换到 root。如果在 RHEL/CentOS 系列中想直接用 root 登录需要先设置 root 密码sudo passwd root安全起见我建议在需要 root 权限时始终走 sudo不要打开 root 直接登录的开关。5.5 批量修复整个目录权限慎用 chmod -R 777服务器上最让人头疼的收尾场景是“目录权限全乱了”。比如某个上线脚本把/data/www下的所有文件都改成了 777或者某些上传文件把属主改成乱七八糟的 uid。我推荐的修复步骤是先备份原权限状态ls -lR /data/www perm_backup.txt。定下目标规范目录 755普通文件 644需要被 webserver 写入的特定目录单独设为chmod 775。单独处理可执行文件find /data/www -name *.sh -exec chmod 755 {} \;。修复属主和属组chown -R 正确的用户:正确的组 /data/www。校验find /data/www -maxdepth 2 -name *.php -exec ls -l {} \;抽查关键文件。不要在修复过程中再叠加临时 777。机器上没有“临时 777”一说一旦留下安全隐患就是长期的。最后再分享一个实战中的小建议用户和权限这块内容我刚工作时也觉得命令太多记不住但后来发现真正有价值的不是背参数而是养成“最小权限”的直觉一个用户只需要能完成工作的权限一个进程只需要访问指定目录的权限一台服务器的 root 密码越少人知道越好。给团队加人的时候先想想他属于哪个组、需要哪些目录权限、是否真的需要 sudo再动手建号。印象里处理过的线上权限事故几乎都是因为当初图省事用了 777 或者批量 chown后面才引发连锁问题。Linux 的权限系统学起来有些繁琐但它是理解整个系统安全与协作的基础值得花时间研究透。如果能把这篇文章里的命令至少亲手敲上三遍再遇到权限类问题你基本都能自己定位了。