privatetmp=true仅提供基于挂载命名空间的基础临时目录隔离，不等同于强沙箱；它通过tmpfs绑定挂载实现服务间/tmp和/var/tmp隔离，但无法阻止root逃逸、不提供内存或策略增强，须配合protectsystem、nonewprivileges等选项才具备实际防护价值。
PrivateTmp=true 并不能提供“绝对安全”的隔离，它只是 systemd 提供的一种基础级别的临时目录隔离机制，能有效防止服务间通过 /tmp 互相干扰或窥探常规临时文件，但不等同于强沙箱或完全不可突破的隔离。
以下是关键事实和正确用法：
PrivateTmp 的本质是绑定挂载（bind mount）+ 挂载命名空间隔离
- 启用后，systemd 会为该服务创建一个独立的、空的 tmpfs 或目录（默认为 tmpfs），并将其挂载到服务进程的
/tmp和/var/tmp（若同时启用PrivateDevices=false且未显式禁用）； - 这个挂载仅对该服务的进程及其子进程可见，其他服务或主机系统无法直接访问该实例；
- 它依赖 Linux 的 mount namespace，属于用户空间隔离，不阻止 root 或 CAP_SYS_ADMIN 进程逃逸或重新挂载；
- 不提供内存隔离、SELinux/SMAP/AppArmor 等策略增强，也不加密或限制文件权限模型。
如何正确启用
在服务单元文件（如 /etc/systemd/system/myapp.service）中添加：
[Service] PrivateTmp=true # 可选：同时隔离 /var/tmp（默认不隔离） PrivateVarTmp=true
然后重载并重启服务：
Kadence Theme Design System
下载
使用 Kadence 主题作为 WordPress 项目的设计系统，涵盖设计令牌、布局系统、页头/页脚/导航设置以及页面/归档/单篇文章模板。
sudo systemctl daemon-reload sudo systemctl restart myapp.service
验证是否生效：
# 查看服务的 MountNamespace sudo cat /proc/$(systemctl show --property MainPID myapp.service | cut -d= -f2)/status | grep NSmount # 查看该进程看到的 /tmp 实际挂载点 sudo nsenter -t $(systemctl show --property MainPID myapp.service | cut -d= -f2) -m -- /bin/sh -c 'findmnt /tmp'
预期输出类似：
TARGET SOURCE FSTYPE OPTIONS /tmp tmpfs tmpfs rw,nosuid,nodev,relatime,seclabel
常见误区与限制
-
不是 chroot 或容器：进程仍可访问
/,/usr,/home等全局路径，仅/tmp和/var/tmp被重定向； - 不防 root 滥用：若服务以 root 运行，它仍可卸载自己的 PrivateTmp 并重新挂载任意内容；
-
tmpfs 无持久性：重启服务后内容丢失；若需保留，应改用
PrivateTmp=/var/lib/myapp/tmp（需手动创建并设权）并配合RuntimeDirectory=； -
不替代 proper sandboxing：高危服务（如解析不受信文件）应额外使用
RestrictSUIDSGID,NoNewPrivileges=true,CapabilityBoundingSet=,RestrictNamespaces=等组合加固。
进阶加固建议（非 PrivateTmp 本身，但必须配套）
- 使用
ProtectSystem=strict阻止写入系统目录； - 设置
ReadOnlyPaths=/+ReadWritePaths=/tmp（需与 PrivateTmp 协调）； - 启用
DynamicUser=true让 systemd 自动分配无特权 UID/GID； - 结合
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6限制套接字族； - 在支持 SELinux 的系统上，确保服务运行在受限域（如
system_u:system_r:myapp_t:s0）。
不复杂但容易忽略：PrivateTmp 是纵深防御中的一环，单独启用意义有限，必须结合其他限制才具备实际防护价值。
