Linux权限模型核心是“谁以什么身份访问时被允许做什么”，依赖文件/目录上固化三元权限位（u/g/o）实时比对；ls -l的10字符中首字符为类型，后9位按3+3+3分组表示所有者、所属组、其他人的rwx权限；目录需x位才能cd进入，故644不适用于目录而应选755；chmod符号法适合增量修改，数字法适合批量重置；目录的rwx含义与文件不同：r为ls列表、w为增删改文件、x为cd进入及访问元数据；权限生效取决于访问者身份（id）、资源归属（ls -l）和创建掩码（umask）三者共同作用。
u/g/o）实时比对决定放行与否。
ls -l 输出的10个字符到底在说什么
执行 ls -l file.txt 看到类似 -rw-r--r-- 这串字符，前1位是类型（-普通文件、d目录），后面9位才是权限，**严格按3+3+3分组**：
-
rw-→ 所有者（u）：可读可写，不可执行 -
r--→ 所属组（g）：只可读 -
r--→ 其他人（o）：只可读
⚠️ 容易踩的坑：chmod 644 看似“所有者读写、组和其他人只读”，但若目标是目录，644 会让组和其他人**无法 cd 进入**——因为目录需要 x（执行）位才可进入，而 4（r）不含 x。正确应为 755（目录）或 644（纯文本文件）。
chmod 符号法 vs 数字法：什么时候该用哪一种
符号法（如 chmod u+x script.sh）适合**增量修改**，语义清晰、不易误操作；数字法（如 chmod 755）适合**批量重置**，但容易因记混数值含义导致越权（比如把 777 当“安全默认值”用）。
- 数字法本质是八进制：每位 =
r(4) +w(2) +x(1)，例如6=4+2=rw- - 符号法支持
a（all）、u/g/o精准定位，还能用=强制覆盖（chmod go=r file） - 真实场景中，脚本部署常用符号法避免覆盖已有权限；初始化服务目录则倾向数字法统一收口
为什么改了文件权限，还是进不了目录？
目录的 r、w、x 含义和文件完全不同：
-
r→ 能否ls列出内容（看到有哪些文件） -
w→ 能否在目录内touch/rm/mv文件（**删除文件的权限由目录的w控制，而非文件自身权限！**） -
x→ 能否cd进入，以及能否访问其下文件的元数据（比如stat）
典型错误：给 /var/www/html 设置了 755，但 Web 服务器用户（如 www-data）不在该目录所属组里 → 实际生效的是 others 权限段，而 others 若无 x，连 open() 都会失败，报错 Permission denied。
chown 和 umask：权限的源头控制
权限不只是“改出来”的，更是“生出来”的：
-
chown user:group file改变属主和属组，直接影响u/g权限段是否生效 -
umask是创建文件/目录时的“权限屏蔽码”，比如umask 002表示新文件默认为664（666 & ~002），新目录为775（777 & ~002） - 注意：
umask不影响已有文件，也不影响root用户创建文件的默认行为（root的umask常为022，更保守）
真正难啃的点从来不是命令怎么敲，而是搞清“当前访问者是谁”（id 命令查 UID/GID）、“当前资源属谁”（ls -l）、“系统创建它时用了什么掩码”（umask）——这三者缺一不可。
