★ FEATURED ARTICLE 1. Linux账号体系先搞清楚系统里到底有谁很多刚接触Linux的朋友第一反应是把账号理解成“登录用户名”这没错但太片面了。在Linux里账号的本质是一组数字标识加上对应的权限集合系统用它来判断“你是谁、你能干什么、你不能干什么”。整个权限体系的基础就是UID用户ID和GID组ID它们像身份证号一样贯穿了文件、进程、服务的每一次交互。理解账号体系从三个层面切入最清晰用户账号代表一个独立的操作主体。普通用户有用户名、UID、家目录、默认Shell等属性权限有限操作范围基本被限制在自己的家目录和系统允许的区域。用户组是多个用户账号的集合。设组的核心目的不是“分组管理好看”而是为了共享权限。比如某公司有个数据分析部门想把一份原始数据集只给部门成员读取就建一个组把成员都拉进去再给文件设成“组可读”其他系统用户一律拒绝。角色与特殊账号root是超级管理员UID固定为0理论上可以无视所有常规权限检查。除此之外还有大量系统账号比如daemon、bin、nobody它们没有真实登录Shell只是为了以最小权限运行后台服务防止服务被攻破后整个系统沦陷。多提一句UID的划分规则这个容易被忽略。传统Linux发行版里UID 0是root1到999一般是系统账号1000及以上才是普通用户。但现在很多新版本在安装时会把第一个普通用户的UID设为1000后续创建的用户依次递增。你执行id命令时看到的输出就是印证这套规则最直接的方式$ id uid1000(alice) gid1000(alice) groups1000(alice),4(adm),27(sudo)这行输出包含了用户UID、主组GID和附属组列表。很多人看groups列会疑惑为什么同一个用户既在alice组又在adm组和sudo组因为一个用户可以同时属于多个组。主组是用户创建文件时默认归属的组附属组则是额外赋予的权限容器。理解这一点后面管理共享目录时会少踩很多坑。账号体系里还有一个概念容易被忽略叫伪用户或系统账号。它们没有家目录、没有可用Shell、不能用来登录存在的意义完全是为了隔离服务进程的权限。举个例子某网站后端服务如果以root身份跑一旦被利用攻击者就直接拿到了系统最高权限。但如果用nobody或专用系统账号跑即使出问题能破坏的范围也极其有限。这是Linux“最小权限”思想的直接体现也是账号管理的核心逻辑——不是给得越多越好而是刚够用就行。从管理角度看所有账号信息集中在三个文件里用户信息在/etc/passwd密码加密串在/etc/shadow组信息在/etc/group。这三个文件我建议每个人都手动打开看一遍格式一眼就能看懂。比如/etc/passwd里每一行用冒号分隔成七个字段alice:x:1000:1000:Alice:/home/alice:/bin/bash依次是用户名、密码占位符、UID、GID、注释信息、家目录、登录Shell。注意第二个字段是x真正的密码哈希根本不在这个文件里而在/etc/shadow中这就是Linux把密码独立出来并进行权限隔离的设计——/etc/passwd必须允许所有用户读取很多程序需要查用户名和UID但/etc/shadow只有root能读从而避免哈希被轻易拿走暴力破解。2. 账号管理实操创建、修改、删除的完整套路账号管理命令看起来就那几个useradd、usermod、userdel真上手之后你会发现细节特别多。比如useradd的参数顺序、默认值是否生效、家目录模板从哪来这些不搞清楚很容易创建出“半残”账号。先说说创建用户最常见的问题为什么我加了用户却用密码登录不了大概率是因为你只执行了useradd没设置密码。useradd创建的账号默认是锁定的必须用passwd命令显式设置密码才能登录。这个设计虽然多了一步但避免了系统自动生成弱密码也算用心良苦。实际操作一般是这样# 新建用户指定家目录、Shell和附加组 sudo useradd -m -d /home/frank -G developers -s /bin/bash frank # 设置密码 sudo passwd frank逐个解释这些参数。-m表示如果家目录不存在就自动创建-d指定家目录路径-G把用户加入附加组-s指定Shell。如果你不写-m某些发行版默认不创建家目录后面用户登录时连cd ~都会报错排查起来很莫名其妙。还有一点容易踩坑如果手动用mkdir创建家目录而不指定属主目录可能是root的用户虽然能进去但自己写不了文件看着就头疼。我强烈建议创建完用户后立刻检查两件事# 确认用户和组信息已写入 grep frank /etc/passwd /etc/shadow /etc/group # 确认家目录权限正确 ls -ld /home/frank正常情况应该是/home/frank的属主是frank、属组是frank权限为drwxr-xr-x。如果属主不对用一条命令纠正sudo chown -R frank:frank /home/frank修改用户信息主要用usermod。它的常用场景我列一下把用户加入sudo组sudo usermod -aG sudo frank注意-aappend必须配合-G使用如果漏了-a用户会被移出原有的所有附加组只保留你指定的组这是典型的生产事故级失误。修改用户家目录sudo usermod -m -d /data/frank frank-m会把原家目录的文件迁移到新家目录。锁定账号sudo usermod -L frank与-L对应的是-U解锁。修改账号过期时间sudo usermod -e 2026-12-31 frank适合给临时外包人员设置访问期限。删除用户更要谨慎。userdel frank只删除用户信息但家目录和邮件池通常还留在磁盘上。如果你确定要彻底清理用sudo userdel -r frank-r参数会连家目录和邮件池一并删除。问题在于很多情况下你不想删家目录因为里面还有项目数据那就先做备份再决定别手抖。实际生产环境中更稳妥的做法是“先锁后删”——先锁定账号观察一段时间确认没有依赖该账号的定时任务、服务进程或文件属主之后再做最终删除。你可以在删除前搜索一下该用户拥有的文件sudo find / -user frank -not -path /proc/* -not -path /sys/* 2/dev/null如果结果还有重要数据chown给接手的用户比直接删用户再慢慢申请恢复快得多。关于用户组的管理几个常用命令也一并交代。创建组用groupadd比如sudo groupadd developers。删除组用groupdel developers但注意如果组是某用户的主组不能直接删。要把组里的用户全部调整到别的组后才行。查看组成员可以直接读/etc/group也可以用getent group developers后者会读取系统的所有账号数据源更规范。有一个操作我做过很多次也见别人翻过车把用户加入一个组后让该用户立刻生效。usermod -aG执行完用户如果已经登录当前会话不会自动刷新组信息必须重新登录或者执行newgrp developers切换当前会话的组身份否则会提示权限不够。这个坑很多人事后查半天才反应过来写出来给大家提个醒。3. 权限机制深度拆解rwx、属主属组与特殊权限Linux权限模型可以用一句话概括文件系统为每个文件记录三类操作者属主、属组、其他用户和三类基本操作读、写、执行的组合。ls -l输出里的-rw-r--r--就是从右向左解读——第一位是文件类型后面每三位一组分别代表属主、属组、其他的权限。读为r数值4、写为w数值2、执行为x数值1所以rwx等于7r-x等于5。这套十进制换算是所有权限操作的基础闭着眼也得记住。但很多人不知道rwx对文件和目录的含义完全不同。对文件来说r表示能读取内容w表示能修改内容x表示能作为程序执行。对目录来说r表示能列出目录里有哪些名字w表示能在目录里创建、删除、改名文件注意这是目录级的写权限和文件本身的写权限无关x表示能进入目录或者说能“穿过”目录访问其中已知名字的文件。如果你只有r没有xls能看到文件名但cd进不去这个状态很尴尬。如果你只有x没有r能进去访问已知文件但无法列出目录内容。绕不开的子目录穿透问题也在这套机制下解释得很清楚对目录有x权限意味着你可以跨过它访问里面的子项。真正决定能否删除某个文件的不是文件自身的权限而是它所在目录的写权限。这个设计常常让人迷惑但它保证了文件内容修改和文件本身被删除是两码事也解释了为什么一个r--r--r--的文件可能被其他人删除——只要能写它的目录即可。实际操作中最常用的命令还是chmod和chown。chmod有两种用法数字模式和符号模式。数字模式最直接比如要给脚本设置属主可读写执行、组可读执行、其他人什么都不可做就是chmod 750 script.sh。符号模式更适合精细调整比如给所有用户加上执行权限chmod ax script.sh给属主去掉写权限chmod u-w file。我个人的建议是初期用数字模式建立直觉熟练后用符号模式做定向修改两者都要会读。**一个容易忽略的细节目录权限设置时机。**比如说你想建一个共享目录让某个组可以读写大多数人直接chmod 770 /data/share这没错。但如果你在设置权限之前已经把文件建进去了父目录的权限不会自动应用到子文件和子目录你需要用chmod -R递归处理。递归处理也是双刃剑如果目录结构里混着需要不同权限的可执行文件、脚本或者敏感配置文件一条chmod -R 777下来整个目录的权限语义就全乱了。所以做递归前一定先看看目录树里都有什么我的习惯是先用find /data/share -maxdepth 2 -type f -o -type d列出来心里有数再动手。再补一个很多人没认真对待的点chown改变文件属主或属组。chown alice file改变属主chown :developers file只改属组chown alice:developers file两个一起改。注意改属主需要root权限普通用户即使拥有文件也不能把文件“送”给别人。这是因为Linux认为文件属主变更属于特权操作防止有人通过转移归属来规避配额或审计。谈完常规权限不得不提三种特殊权限位它们才是让Linux权限模型真正强大的地方。SetUID文件上的特殊权限用s表示在属主执行位上-rwsr-xr-x。它的作用是当普通用户执行这个文件时进程的有效UID变成文件属主的UID而不是执行者自己的UID。典型例子是/usr/bin/passwd它需要修改/etc/shadow该文件只有root能写所以passwd程序必须临时获得root权限。你执行ls -l /usr/bin/passwd会看到-rwsr-xr-x root root那个s就是SetUID标志。这个机制极其危险凡是能被任何人执行的SetUID root文件都是攻击者提权的首选目标。安全巡检时优先筛查全系统的SetUID文件一条命令就能定位sudo find / -perm /4000 -type f 2/dev/nullSetGID如果作用在文件上进程的有效GID变成文件属组的GID如果作用在目录上目录内新建文件或子目录的属组自动继承父目录的属组而不是创建者的主组。第二个特性的价值在团队协作场景中体现得淋漓尽致你建一个共享目录/data/team属组设为developers再执行chmod gs /data/team此后无论哪个成员在里面创建文件文件属组都会保持developers省去了每个文件都要手动改组的麻烦。Sticky Bit粘滞位用t表示在其他用户执行位上比如/tmp目录的drwxrwxrwt。它的约束是在设置了Sticky Bit的目录里只有文件属主、目录属主或root才能删除或重命名文件。普通用户哪怕对目录有完全写权限也无法动别人的文件。系统中默认启用Sticky Bit的/tmp目录就是靠这个机制避免用户互相删除临时文件的。**权限检查的优先级也值得记牢**Linux按“属主身份、属组身份、其他人身份”依次匹配只要命中前两层当中的一个就不会再继续往下检查。比如文件属主对文件是rwx但属组和其他人只有r如果root之外的属主用户执行该文件直接按rwx处理不再看属组和其他人的权限。如果不记得这条规则你会发现明明把文件给了其他人rwx属主自己却执行不了这很可能是因为属主本身的rwx缺了x。3.2 特殊权限在实际项目中的合理用法**接下来说说我实际维护的一个共享项目目录的完整搭建过程方便你直接抄作业。**假设团队里有几位开发者都在一个组devteam里需要一个目录/srv/project让他们自由读写新创建的文件自动归组所有同时防止任何人随意删除别人的文件。第一步建组并添加成员sudo groupadd devteam sudo usermod -aG devteam alice sudo usermod -aG devteam bob sudo usermod -aG devteam carol第二步创建目录并设置权限sudo mkdir -p /srv/project sudo chown root:devteam /srv/project sudo chmod 2770 /srv/project这里2770的含义是2是SetGID位770是属主root和属组devteam都读写执行其他人没有权限。设置完之后任何devteam组成员在该目录下创建的文件或子目录属组都会自动变成devteam。第三步验证效果# 用alice身份创建测试文件 sudo -u alice touch /srv/project/test.txt ls -l /srv/project/test.txt你会发现输出是-rw-r--r-- 1 alice devteam文件属组自动是devteam而且因为创建时目录有SetGID新建的子目录还会继承SetGID标志权限会一直延续下去。很多团队协作目录用这套配置跑两年都没出过权限问题关键就在于把“目录权限设计”前置而不是每个文件手动调整。如果在共享目录上还想防误删就再加Sticky Bitsudo chmod 3770 /srv/project3由2SetGID和1Sticky Bit组成。这样组成员之间可以互相编辑对方的文件需要文件本身允许写但不能删除别人创建的文件。注意如果文件本身的权限是644组成员还是无法编辑所以共享目录里文件创建时应该默认带组写权限这又牵涉到umask的设置。4. umask、默认权限与文件创建掩码umask这个词在初学阶段经常被忽略但它直接影响你每次新建文件和目录时的默认权限。它的工作原理是系统从完整权限中“扣除”某些位留下的就是新建文件的默认权限。规则用数值表示零填充常见默认值022。完整权限对文件是666对目录是777。为什么文件不是777因为文件默认不设置执行权限这样能防止刚创建出来的文件意外可执行。umask 022相当于扣掉组的写权限和其他的写权限所以新建文件权限是644新建目录权限是755。**但现在的发行版默认umask常是002甚至007。**002意味着组内的用户建的文件默认就是rw-rw-r--其他用户能读007意味着其他用户完全不可见。如果你在团队共享目录工作系统umask是022那你新创建的文件的组权限就没有写权限别人只能看不能改共享目录形同虚设。解决办法不是每次手工chmod而是把用户级的umask设置为002或更严格的值。设置方法写在用户家目录的~/.bashrc或者系统全局的/etc/profile里# 在 ~/.bashrc 中加入一行 umask 002不过umask影响的是整个会话的所有新建文件如果只是某个共享目录需要特殊权限那在当前目录里临时设一下更安全cd /srv/project umask 002 touch test.txt ls -l test.txt # 实际权限是 -rw-rw-r--真的要彻底解决共享目录权限问题最省心的方案还是我在上一节说的SetGID配合组权限目录为2770再设置组内默认umask为002或007从源头保证每个新文件都恰好是需要的权限。需要提一句umask 002和umask 007的选择取决于目录是否需要开放给同一组的成员都读写——如果希望组里的人在共享目录互相协作002就够了如果目录数据不能泄露给其他任何系统用户就选007。**还有一类场景必须调整umask写脚本自动生成文件。**如果你有一个脚本来生成报告它在root用户下运行而root的umask通常也是022生成的报告其他人可能就能读了。如果报告需要保密脚本开始处主动调用umask 077最稳妥这样所有新建文件和目录权限都是600或700不会被误开放。5. sudo机制授权但不放任在Linux服务器上直接以root登录是高风险行为一来容易误删系统文件二来操作记录难以追溯。Linux的通行做法是给普通用户授予sudo权限让它临时以root身份执行特定命令所有操作都会被记录到日志通常是/var/log/auth.log或/var/log/secure。**sudo的权限配置核心文件是/etc/sudoers。**官方要求绝不能用普通文本编辑器直接改必须用visudo命令——它会在保存前做语法检查防止你写错语法导致sudo整个失效。配置文件语法最典型的一行是frank ALL(ALL:ALL) ALL分字段解读frank是用户名ALL表示在任意主机上都能执行(ALL:ALL)表示可以以任意用户和任意组的身份执行最后一个ALL表示可以执行所有命令。这一行其实就是把root权限完全交给了frank跟让frank直接登录root没本质区别只是多了日志和密码确认。如果只允许特定命令更精细的写法是这样frank ALL(root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx这样frank只能重启和查看nginx服务其他root级操作一概不行。生产环境里给开发人员开“服务控制权”时我就是用这种方式从根本上限制影响面。**sudoers里使用别名会让配置更清晰。**比如定义命令别名Cmnd_Alias SERVICE_CMDS /usr/bin/systemctl restart nginx, /usr/bin/systemctl restart php-fpm frank ALL(root) SERVICE_CMDS后续如果还要再加一个服务只改别名那一行不用改用户配置维护起来心智负担小很多。**sudo运行的原理值得知道**当你执行sudo command时sudo会先校验当前用户是否在sudoers里有对应权限再检查用户输入的密码部分配置可以免密密码正确后fork一个子进程并调用setuid(0)把有效UID切换成0然后执行目标命令。目标命令在以root身份运行时宿主的普通用户环境变量大部分会被清除换用sudo中指定的默认环境。所以如果你在普通用户Shell里导出了某个JAVA_HOMEsudo后大概率会丢除非配置了env_keep。**补充一个安全设置限制sudo使用者的最小权限与可见范围。**常用手段是在/etc/sudoers里追加Defaults secure_path/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin Defaults requirettysecure_path限制了sudo执行时可用的PATH防止攻击者通过修改普通用户PATH把恶意程序伪装成系统命令等sudo一调就中招requiretty则强制只有存在终端时才能用sudo防止通过某些服务间接调用sudo完成提权。这两项属于基础加固手段在小型团队服务器上建议直接加上。**sudo审计别忽略。**每次某人用sudo执行了什么系统都会写下来。你可以随时翻日志sudo grep sudo /var/log/auth.log | tail -20想要更细的录屏式审计可以使用sudo配合journalctl或单独配置auditd但中小团队其实用默认日志就够日常排查了。关键是有这个意识sudo授权不等于放任所有操作必须可追溯。6. 文件属主与组chown/chgrp的精细控制如果不想每次都用root去改属主理解chgrp会方便很多。普通用户可以更改自己拥有的文件的属组但只能改成自己所属的组不能任意指定。比如alice创建了一个文件她想把它放到devteam组共享执行chgrp devteam report.txt前提是alice自己必须是devteam组的成员否则会报Operation not permitted。这个规则挺合理防止有人把文件归到一个他根本不属于的组然后在组内安插后门。改变文件属主通常需要root或sudo chown。实际工作中常见场景把某个网站目录从用户A转给用户Bsudo chown -R B:B /var/www/mysite把临时迁移来的文件统一归属sudo chown -R 1000:1000 /data/import只改属组不动属主sudo chown :developers /data/files注意chown时如果只写冒号不写用户名比如chown :developers file属主保持不变只改属组。这个方法比单独敲chgrp省事也更直观。还有一点chown不会自动递归到子文件除非加-R这个我前面提过但仍值得再强调一次因为几乎每周都能碰到有人因为漏了-R然后到处找文件权限问题。**还有一个常被问的问题为什么chown能改变文件属主而普通用户却做不到**从安全模型角度属主信息属于文件系统元数据修改它可能影响审计、配额和访问控制所以必须由特权进程完成。这也意味着如果你收到了一个属主是某个已删除用户的文件不要试着用该用户名切身份去改权限——该用户已经没了只用root账号去chown即可。如果某个目录下文件太多想快速批量修改属主和属组我通常写一个循环而不是直接chown -R避免误伤符号链接find /data/project -exec chown alice:devteam {} \;加不加-h取决于是否要同时修改符号链接本身的属主默认情况下chown会解引用符号链接直接修改目标文件的属主。如果符号链接指向的位置不在目标范围内你想保留链接本身归属就需要chown -h。这个细节很冷门但在处理复杂目录树时能避免很多困惑。7. 权限管理实操三板斧查看、排查、恢复日常运维里权限问题占了排查工作量的很大一块。我给自己的排查流程做了个三板斧遇到权限相关报错按顺序套用大部分问题十分钟内能定位。**第一板斧确认“我是谁”。**先执行id、whoami、groups搞清楚当前用户是谁、属于哪些组、有效UID是多少。遇到过太多次“明明显示用户是alice权限却奇怪”的案例结果一查是sudo子shell或者su环境没退出进程真实身份和用户预期不一致。第二板斧确认“文件长什么样”。ls -l和stat双管齐下。ls -l能快速看权限位和属主属组stat能给出更完整的inode信息包括修改时间、文件类型、挂载点等。一个常见问题是ls -l显示权限没问题但程序还是报权限不足。这时候要查文件的父目录、路径上每一级目录的x权限比如文件在/opt/app/data/cache.txt那么/opt、/opt/app、/opt/app/data三层目录都要有足够的x权限让用户“穿过”。有一条常用检查命令namei -l /opt/app/data/cache.txt它会输出路径上每一层的权限和属主信息一眼就能定位是哪级目录卡住了。**第三板斧确认“有没有隐藏限制”。**文件权限只是访问控制的一环还有可能卡在SELinux或者AppArmor上。SELinux的上下文标签如果不对即使rwx全对程序依然会被拒绝。检查方式ls -lZ file.conf # 或 semanage fcontext -l | grep nginx如果发现SELinux拦截用chcon或restorecon修正上下文而不是粗暴关闭SELinux。关闭强制访问控制等于拆除了一整层防护在合规环境中通常不被允许。**权限恢复是另一个常见需求。**备份恢复后文件属主和权限常常乱掉一般策略是系统文件恢复权限rpm --setperms基于包管理器校验RPM系发行版可用或debsumsDebian系可用家目录恢复chown -R --frombackup user:user /home/user通用检查find /srv -type f -perm /0022 -exec ls -l {} \;查找可能被错误开放写权限的文件我最常用的恢复思路是按需设置而不是一刀切。比如恢复一个网站目录find /var/www -type f -exec chmod 644 {} \;find /var/www -type d -exec chmod 755 {} \;可执行文件再单独处理这样批量操作后权限语义是清晰的。8. 常见权限问题的排查实例与速查表案例一用户无法写入自己的家目录现象frank登录后touch ~/test提示Permission denied。检查ls -ld /home/frank发现目录属主是root权限是drwxr-xr-x。原因创建用户时漏了-m后来手动建目录也没chown。解决sudo chown frank:frank /home/frank sudo chmod 700 /home/frank。处理完再验证一次能否写入。案例二脚本提示“Permission denied”但文件明明有x权限现象./deploy.sh报权限错误但ls -l看到-rwxr-xr-x。检查脚本第一行是否有解释器路径shebang如果没有内核会尝试用当前Shell执行脚本但脚本内部又调用了不存在的命令或语法错误。另一个常见原因是脚本所在目录如/tmp挂载了noexec选项这时候即使有x权限也无法执行。检查挂载选项mount | grep /tmp如果看到noexec把脚本移到允许执行的分区即可。案例三普通用户通过sudo执行命令时找不到命令现象sudo systemctl restart myapp提示command not found。原因是sudo的secure_path没包含该命令所在目录或者命令装在/usr/local/bin但secure_path没包含它。解决编辑/etc/sudoers在Defaults secure_path后追加对应路径。这比每次用绝对路径执行更彻底也适合长期管理。案例四共享目录新文件权限不对现象目录设了SetGID但alice创建的文件属组是alice而不是devteam。检查alice的主组是否是devteam以及目录的SetGID位是否被后续chmod覆盖。正确检查方式ls -ld /srv/project stat -c %a %U %G /srv/project输出应该是2770 root devteam。如果输出是770 root devteam说明SetGID没了重新chmod gs /srv/project即可。我把高频问题整理成一个速查表方便大家快速定位问题现象可能原因快速排查命令常见解决方式文件有r权限但cat报权限不足路径上某级目录缺少x权限namei -l /path/to/file逐级修复目录权限用户删不掉别人的文件所在目录没有Sticky Bit或用户不是目录所有者ls -ld /dir让文件属主或用root删除新建文件权限多出可写umask过宽松umask设置合适的umask002/022/077sudo执行程序找不到命令secure_path不包含路径sudo strace -f command或sudo which command修改sudoers secure_path脚本无法执行目录挂载noexec或脚本无x权限mount | grep -E /tmp ls -l script.sh去其他分区或加x权限SELinux拒绝服务访问上下文标签错误ls -Z /pathrestorecon -Rv /path用户无法切换ShellShell不存在或passwd中Shell无效grep user /etc/passwdusermod -s /bin/bash userchmod -R后目录不可读误把目录权限设成600find /dir -type d -ls目录恢复为755或750**最后一个冷门但非常实用的排查技能利用strace跟踪系统调用。**比如某个程序读取文件失败你无法从应用日志看出是权限还是路径问题就运行strace -e openat,access,stat -f ./your_program 21 | grep -E Permission denied|No such filestrace会直接打印内核为每个系统调用返回的错误码EACCES就是权限拒绝ENOENT是文件不存在。有了这层信息权限问题基本能水落石出比自己盲猜高效得多。9. 安全加固建议账号管理和权限控制的纵深防御账号和权限的常规管理做完剩下的就是能不能长期守住的问题。我根据自己的维护经验把几个实用加固建议按优先级列出来。**第一个建议定期审计系统账号。**很多系统装了服务就忘了管一堆长期不用的账号躺在/etc/passwd里。审计策略是定期扫描哪些账号有可用Shell、哪些密码哈希过期、哪些sudo权限给得过多。可用Shell的账号列表可以用一条命令拎出来awk -F: $31000 $7~/(bash|sh|zsh)$/ {print $1, $3, $7} /etc/passwd看看里面有没有不该存在的管理员账号特别是UID 0的账号再查一遍awk -F: $30 {print $1, $7} /etc/passwd正常情况下只有root一行。如果多出来一个普通用户UID也是0那基本等于系统已经被人置入了后门必须立刻处理。**第二个建议禁用不必要的root远程登录。**服务器日常管理推荐用普通用户加sudoroot只在控制台或紧急维护时才使用。具体做法是修改/etc/ssh/sshd_config设置PermitRootLogin no然后重启服务。这样即使有人暴力破解到了某普通用户密码也还要再过sudo这一关才能提权而root密码即使被猜中也无法直接远程登录阻断了一条高价值攻击链路。**第三个建议给sudo授权留出克制的口子。**新员工入职时慷慨地把ALL(ALL) ALL给他用过段时间离职人走茶不凉账号依然有权限。所以用户权限要跟着角色变建议每个季度过一遍sudoers问自己几个问题这个人还需要这个权限吗他上次用是什么时候授权范围能不能再缩小一点很多公司安全审计时发现长期闲置的高权限账号基本都是因为这些检查不够频繁。**第四个建议充分利用密码策略和锁定策略。**在/etc/login.defs和/etc/pam.d/common-password中设置密码最小长度、密码过期周期、连续失败次数锁定。常见的组合是PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_WARN_AGE 7再在/etc/pam.d/common-auth或/etc/pam.d/system-auth中启用pam_faillock限制连续认证失败5次后账户锁定10分钟或者需要管理员解锁。这些配置在教科书里经常被跳过但实际上它们在暴力破解、社会工程、离职交接等场景下都有效减少了风险敞口。**第五个建议别忽视新文件/新目录被“顺手”开放权限的问题。**很多团队习惯在项目启动时把目录设为777为的是省去权限问题。短期确实方便长期就是灾难。攻击者一旦拿到任意一个低权限账号就能在777目录里写入恶意脚本再借助定时任务或web服务执行。正确姿势是宁愿多配几个组、多设几个目录也要按数据范围严格收敛权限。如果实在要给一个目录开放写权限务必配合Sticky Bit和精确的属组控制。**第六个建议日志集中和监控要早做。**单机环境下日志散落在/var/log/auth.log、/var/log/secure、/var/log/syslog里平时只看得到但事后回溯时很花时间。小团队可以用logrotate定期转储再通过tail或简单的ELK栈收集起来。最重要的不是日志工具多高级而是定期扫一眼。如果某天突然有人在凌晨三点连续尝试登录失败那就说明有人在扫你们家大门该上门加固了。10. 写在最后的实操心得我在帮别人调试账号权限问题时感受最深的一点大多数Linux权限故障不是系统复杂而是操作动作没有对齐。很多人用root把目录和文件权限调好了但忘了用户是否真的在给定组里有人把文件给了所有人写权限却没考虑这恰恰是攻击面最大化的行为。这里分享几个我从实战里沉淀下来的小习惯希望能帮你减少踩坑频率。第一操作前先看一眼当前用户和目录状态。我的习惯是执行id、whoami、pwd三条命令再检查ls -ld当前的属主属组。很多问题在动手前就已经能预判出来。第二涉及权限变更的命令先用--dry-run或者echo代替真正执行比如find定位文件时先输出列表确认识别无误后再接chmod避免批量操作把不该改的文件一并改了。第三养成写变更记录的习惯。也许你不需要每个操作都写文档但至少记录一下变更了哪些目录、用的什么权限数字、为什么这么设几个月后再排查时这些记录比任何文档都顶用。我自己最常用的一句话说给新手听权限管理不是一次性的配置工作而是一个持续判断的工作——这个账号还活着吗它还应该拥有这些权限吗这个目录还需要对外开放写权限吗每隔一段时间过一遍这三个问题服务器的安全基线就能一直保持在一个健康的状态。如果这篇文章让你对Linux账号和权限管理有了更清晰的画面那就从把自己服务器上一个常年在用的账号“翻出来”开始练手——看看它的所属组、家目录权限、sudo授权范围再顺手把不需要的权限收紧一档。这大概就是入门Linux权限管理最实在的第一步。
阅读完成 · 觉得有帮助？
