ls -z用于显示文件selinux安全上下文，格式为用户:角色:类型:级别，其中类型字段（如httpd_sys_content_t）是访问控制关键；若输出为空或为?，表明selinux未启用或文件系统未启用扩展属性。
直接用 ls -Z 就能看到，不需要额外安装或启用特殊模块——但必须确认 SELinux 已启用且文件系统已打标签，否则输出中类型字段为空或显示问号。
为什么 ls -z 和 ls -Z 都能用，但推荐 ls -Z
早期某些发行版（如 RHEL 5）支持 ls -z，但现代系统（RHEL 7+、CentOS Stream、Fedora、Rocky）统一使用 ls -Z。GNU coreutils 自 8.24 版起已弃用 -z，改用 -Z 输出完整上下文（含用户、角色、类型、级别）。运行 ls -z 可能报错或静默忽略该选项。
-
ls -Z /etc/hosts显示单个文件上下文 -
ls -Zd /var/www/html查看目录自身（不递归子项），关键用于验证 Web 根路径是否为httpd_sys_content_t -
ls -ZR /opt/app | head -20递归查看并限制输出行数，避免卡顿
ls -Z 输出字段含义与排查重点
典型输出：-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html
其中第四段 httpd_sys_content_t 是决定访问权限的核心——它不是“所有者”或“组”，而是 SELinux 的“类型（type）”。进程能否读取该文件，取决于其域类型（如 httpd_t）是否被策略允许访问 httpd_sys_content_t。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 第一段（
unconfined_u）：SELinux 用户，普通用户登录 shell 多为unconfined_u，不影响文件访问控制 - 第二段（
object_r）：角色，对文件固定为object_r，可忽略 - 第三段（
httpd_sys_content_t）：类型，必须与服务进程域类型匹配，是排查 403/Permission denied 的首要比对项 - 第四段（
s0）：敏感度，MLS 策略下才需关注，targeted 策略下基本恒为s0
常见错误现象与对应操作
执行 ls -Z 后发现字段缺失、全为问号或类型明显不对（如 Web 文件显示 default_t），通常不是命令问题，而是环境或配置异常：
- 输出中类型字段为空或显示
?：说明 SELinux 未启用（getenforce返回Disabled）或文件系统未启用扩展属性（XATTR），常见于挂载时漏加context=...或使用了noatime,nodiratime等屏蔽 XATTR 的选项 - Web 文件类型是
default_t而非httpd_sys_content_t：说明该路径未被 SELinux 策略覆盖，需用semanage fcontext -a -t httpd_sys_content_t '/opt/myapp(/.*)?'+restorecon -Rv /opt/myapp永久修复 - 修改过文件（如
cp或mv从非 SELinux 文件系统复制进来）：默认继承目标目录的父级上下文，或回退为default_t，此时ls -Z会暴露不一致，应优先用restorecon -v重置
别把 id -Z 当成查文件上下文的命令
id -Z 完全无关——它只输出当前 shell 的 SELinux 用户身份（如 unconfined_u:unconfined_r:unconfined_t:s0），和你 ls 的那个文件毫无关系。有人误以为“用户上下文 = 文件上下文”，结果在 id -Z 里找 httpd_sys_content_t，注定找不到。
真正要对比的是：ps -Z -C httpd 输出的第三段（进程域类型）和 ls -Z /var/www/html/index.html 输出的第三段（文件类型）。这两者不匹配，才是 SELinux 拒绝访问的根本原因，而 ls -Z 就是你确认后者的唯一可靠入口。
