共享内存本身不提供用户隔离，权限控制依赖 shmget 的 shmflg 参数（如 0600 或 0644）结合 uid/gid、系统策略及 selinux 等机制实现安全隔离。
服务器共享内存本身不提供用户隔离能力，它只是进程间通信的高效通道；真正的权限隔离靠操作系统级机制实现。关键在于：共享内存段创建时设好权限位，再配合用户身份控制、进程属主限制和文件系统策略，才能既让合法进程通信，又阻止越权访问。
共享内存段的权限设置
使用 shmget() 创建共享内存时，第三个参数 shmflg 必须包含权限位（如 0600 或 0644），这决定了哪些用户能附加（shmat）该段：
- 0600：仅创建者（UID）可读写，最安全，适合单用户多进程场景
- 0644：创建者可读写，同组用户只读，适用于需组内协作的业务
- 权限位生效前提是 key 对应的共享内存段由指定用户创建，且其他进程以相同 UID/GID 运行或明确被授权
用户与进程层面的隔离保障
光靠共享内存权限不够，必须结合系统级身份控制：
- 每个进程启动时应以专属系统用户运行（如 appuser1、appuser2），避免全部用 root 或同一普通用户
- 用 id 和 ps -eo pid,user,comm 确认进程真实 UID，防止伪装
- 禁止非必要用户执行 shmat —— 可通过 sudoers 限制或容器环境强制 drop capabilities（如 IPC_LOCK）
配套的文件系统与内核防护
共享内存段在内核中表现为 IPC 对象，其访问受全局策略约束：
- 检查 /proc/sys/kernel/shmmax 和 /proc/sys/kernel/shmall，避免资源耗尽影响其他服务
- 用 ipcs -m 查看所有共享内存段，确认 owner 和 perms 列符合预期
- 敏感服务建议搭配 ACL 或 SELinux/AppArmor 策略，例如限制某用户只能 attach 指定 key 的 shm 段
- 定期用 ipcrm -m
清理无主段，防止残留内存泄露或被滥用
Windows 服务器上的等效实践
Windows 没有直接对应的 System V 共享内存，但类似需求常通过命名共享内存对象（CreateFileMapping + SECURITY_DESCRIPTOR）实现：
- 创建时用 LPSECURITY_ATTRIBUTES 显式设置 DACL，只允许特定用户/组访问
- 共享文件夹权限 ≠ 内存对象权限，两者独立；若用文件映射模拟共享内存，需同时配置 NTFS 权限和共享权限
- 域环境下推荐用 AD 组策略统一管控，例如限制“应用服务组”仅能打开预定义名称的共享内存对象
