用户、组、角色与权限路径

PVE 的权限系统只有一句话：在某个路径上，给某个用户或组，授予某个角色。这篇把四个概念拆开讲，再给出实际分配权限的步骤。

为什么需要它

装完 PVE，root@pam 拥有一切权限。这在只有你一个人管理的时候没问题。一旦有第二个人需要登录——哪怕只是看看备份状态——就要决定「他能看到什么、能做什么」，而不是给一个同样万能的账号。

开始之前

先完成认证域的选择：用户从 pam、pve 还是 LDAP/AD 来。
需要 Sysadmin 或 PVEUserAdmin 权限来管理用户和授权。
建议先建好一个测试用户，方便每改一次权限就登录验证一次。

四个核心概念

概念	说明
用户 / 组 (User / Group)	`alice@pve` 这样的账号标识。权限优先授予组，用户加入组即可，日后增删人员不用重新配一遍
角色 (Role)	一组权限 (privilege) 的集合。权限本身不能直接授予，必须通过角色
路径 (Path)	权限作用的范围，例如 `/vms/100`（某台虚拟机）、`/storage/local`（某个存储）、`/`（全局）
权限条目 (ACL)	三元组：路径 + 用户/组/Token + 角色。这就是一条完整的授权

用资源池 (Pool) 简化按项目授权

如果想让某个用户只看到「他负责的那几台虚拟机」，与其在每台虚拟机路径上单独授权，不如先建一个资源池（数据中心 → 资源池），把相关虚拟机、容器、存储都拖进去，再对 /pool/<池名> 这一个路径授权一次。

内置角色

PVE 自带这些角色，PVE 前缀是保留字，自定义角色不能用这个前缀：

角色	大致用途
`Administrator`	等同该路径下的完全控制
`NoAccess`	显式拒绝，用来在某个子路径上撤销继承来的权限
`PVEAdmin`	除了修改权限系统本身之外的全部管理操作
`PVEAuditor`	只读，适合监控账号、只看不改
`PVEVMAdmin` / `PVEVMUser`	虚拟机和容器的管理 / 使用权限
`PVEDatastoreAdmin` / `PVEDatastoreUser`	存储的管理 / 使用权限
`PVEPoolAdmin` / `PVEPoolUser`	资源池的管理 / 使用权限
`PVESysAdmin`	系统层面的管理（网络、时间等），不含权限系统
`PVEUserAdmin`	管理用户、组、权限本身
`PVETemplateUser`	从模板克隆的权限
`PVEMappingAdmin` / `PVEMappingUser`	资源映射（USB/PCI 设备映射）的管理 / 使用
`PVESDNAdmin` / `PVESDNUser`	SDN 相关的管理 / 使用

需要更细的粒度时，数据中心 → 权限 → 角色 → 创建自定义角色，勾选具体权限（如只给 VM.PowerMgmt 和 VM.Console，做一个只能开关机、连控制台但不能改配置的角色）。

操作步骤

1. 建组

数据中心 → 权限 → 组 → 创建，或者：

# 宿主机 shell
pveum group add vm-operators --comment "日常开关机操作员"

2. 把用户加进组

创建用户时直接选组，或者事后：

pveum user modify alice@pve --group vm-operators

3. 在具体路径上给组授权

数据中心 → 权限 → 添加 → 组权限：选路径、选组、选角色。命令行等价操作：

# 给 vm-operators 组在 /vms 路径下 PVEVMUser 角色
# （可以看到并操作所有虚拟机，但不能改存储、网络等系统配置）
pveum acl modify /vms --groups vm-operators --roles PVEVMUser

# 只想管某一台虚拟机，路径改精确一点即可
pveum acl modify /vms/100 --groups vm-operators --roles PVEVMAdmin

Propagate 决定权限是否向下继承

默认 --propagate 1，/vms 上的权限会作用到 /vms 下所有虚拟机。关掉传播（--propagate 0）只让权限停在这一层，不影响子路径——不常用，但排查「为什么这台机器权限不对」时要想到这个开关。

4. 理解权限如何叠加

几条规则决定最终生效的权限：

用户自己路径上的权限，替换（不是叠加）从组继承来的同路径权限。
更深路径上的权限，替换从更浅路径继承来的权限。
NoAccess 会取消该路径上其他角色赋予的所有权限，用来在例外情况下明确拒绝。

权限不是越多角色叠加越强

在同一路径上同时给一个用户和它所在的组分配不同角色，生效的是用户自己的那条，组的会被忽略——这和很多人以为的「取并集」不一样。想清楚权限归属再动手，改完立刻用测试账号验证。

检查结果

pveum user permissions alice@pve --path /vms：查看某用户在某路径下的最终生效权限。
用测试账号实际登录一次，确认能看到、看不到的东西符合预期。
故意尝试一个不该被允许的操作（比如删除存储），确认界面拒绝并提示权限不足。

常见问题

给组授权了，但某个组员看不到资源。 检查这个用户是否在其他路径上有单独的 ACL——用户自己的条目会覆盖组的条目。

删除了用户还能看到它触发的任务在跑。 PVE 不会自动终止已经在执行的任务，pveum user delete 只影响之后的登录和授权。

想让用户只操作自己创建的虚拟机，做不到。 PVE 的权限按路径分配，不区分「谁创建的」，需要靠资源池或者手动按虚拟机分别授权来实现类似效果。

用户、组、角色与权限路径 ​

为什么需要它 ​

开始之前 ​

四个核心概念 ​

内置角色 ​

操作步骤 ​

1. 建组 ​

2. 把用户加进组 ​

3. 在具体路径上给组授权 ​

4. 理解权限如何叠加 ​

检查结果 ​

常见问题 ​

参考资料 ​