gzip不保存文件权限等元数据，必须用tar -p打包再gzip，解压时需sudo tar -xpf并验证setuid位是否为04000，同时确认文件系统未挂载nosuid。

gzip 本身不处理文件权限、属主或特殊位（如 setuid、sticky），它只压缩文件内容。真正影响权限保留的，是压缩前的文件读取方式和解压时的上下文。所谓“gzip导致权限丢失”，其实是误把 gzip 当作归档工具用了——它不是 tar，不存元数据。

要防止敏感密钥文件（如 /etc/ssh/host_key、/root/.pgpass）在压缩过程中隐式丢失 setuid、sticky、属主等关键属性，核心不是 gzip 做什么，而是怎么打包 + 怎么解压。

必须用 tar 封装后再 gzip，不能单独 gzip 文件

单独执行 gzip secret.key 只会生成 secret.key.gz，原始文件被重命名，权限信息彻底脱离上下文；解压后 gunzip secret.key.gz 得到的 secret.key 属主变成当前用户、所有特殊位清零——这是默认行为，且无提示。

正确做法是：

• 先用 tar 打包并保留元数据
• 再用 gzip 压缩归档包

# ✅ 正确：打包时带上 -p（保留权限）和 --owner=root --group=root（显式固定属主）
tar -cf - --owner=0 --group=0 -p /etc/ssh/host_key | gzip > ssh_keys_backup.tar.gz

# ❌ 错误：直接 gzip，丢权限、丢属主、丢 sticky/setuid
gzip /etc/ssh/host_key

解压时必须用 root + -xp 组合，否则权限仍会降级

即使归档里存了 UID 0/GID 0 和 setuid 位，普通用户解压：

• --same-owner 自动失效
• 所有文件属主静默变为当前用户
• setuid、sticky 位被内核忽略（即使 -p 写入也无效）

所以还原命令必须是：

sudo tar -xpf ssh_keys_backup.tar.gz -C /tmp/

其中：

• x：解包
• p：还原权限、所有者、特殊位（setuid/sticky）
• f：指定归档文件
• sudo：确保以 root 运行，使 --same-owner 生效

⚠️ 注意：如果目标系统没有对应 GID（比如归档里记的是 GID 1002，但 /etc/group 里没这组），tar 会回退为 nogroup 或数字 ID，需提前检查目标环境。

验证关键权限是否真被保留

解压后立即验证，别依赖“没报错就成功”：

# 查看是否带 setuid（显示为 s 而非 x）
ls -l /tmp/etc/ssh/host_key

# 查看完整权限位（含 setuid: 4000, sticky: 1000）
stat /tmp/etc/ssh/host_key | grep "Access:"

若 Access: 行显示 04000（即 rws------），说明 setuid 成功保留；若只是 0600，说明失败——大概率是没用 root 解压，或 tar 命令漏了 -p。

补充：密钥类文件还需注意挂载选项限制

即使权限还原成功，若目标目录所在文件系统挂载时用了 nosuid 或 noexec：

• setuid 位会被内核强制忽略（运行时无效）
• chmod u+s 也会静默失败

检查方法：

mount | grep "$(df . | tail -1 | awk '{print $1}')"
# 看输出是否含 nosuid、noexec

如需真正生效，得确保挂载选项允许 suid（默认一般开启，但安全加固后常关闭）。

不复杂但容易忽略