X-Git-Url: https://git.proxmox.com/?a=blobdiff_plain;f=pveum.adoc;h=cb9ebfb4ac3141e4a9a4fc126f079f664466fc83;hb=dd284d25699bfa222b38e8a30b5e507e475a249d;hp=36426cf8fdc3acbde4cee50107b67e3877d730e2;hpb=0e1fda7000f9fc5bf24685350d99a852665356f4;p=pve-docs.git

diff --git a/pveum.adoc b/pveum.adoc
index 36426cf..cb9ebfb 100644
--- a/pveum.adoc
+++ b/pveum.adoc
@@ -1,7 +1,8 @@
 ifdef::manvolnum[]
-PVE({manvolnum})
-================
+pveum(1)
+========
 include::attributes.txt[]
+:pve-toplevel:
 
 NAME
 ----
@@ -9,7 +10,7 @@ NAME
 pveum - Proxmox VE User Manager
 
 
-SYNOPSYS
+SYNOPSIS
 --------
 
 include::pveum.1-synopsis.adoc[]
@@ -24,6 +25,9 @@ User Management
 ===============
 include::attributes.txt[]
 endif::manvolnum[]
+ifdef::wiki[]
+:pve-toplevel:
+endif::wiki[]
 
 // Copied from pve wiki: Revision as of 16:10, 27 October 2015
 
@@ -229,16 +233,6 @@ pveum roleadd Sys_Power-only -privs "Sys.PowerMgmt Sys.Console"
 ----
 
 
-Objects and Paths
-~~~~~~~~~~~~~~~~~
-
-Access permissions are assigned to objects, such as a virtual machines
-(`/vms/{vmid}`) or a storage (`/storage/{storeid}`) or a pool of
-resources (`/pool/{poolname}`). We use file system like paths to
-address those objects. Those paths form a natural tree, and
-permissions can be inherited down that hierarchy.
-
-
 Privileges
 ~~~~~~~~~~
 
@@ -290,18 +284,33 @@ Storage related privileges::
 * `Datastore.Audit`: view/browse a datastore
 
 
-Permissions
-~~~~~~~~~~~
-
-Permissions are the way we control access to objects. In technical
-terms they are simply a triple containing `<path,user,role>`. This
-concept is also known as access control lists. Each permission
-specifies a subject (user or group) and a role (set of privileges) on
-a specific path.
+Objects and Paths
+~~~~~~~~~~~~~~~~~
 
-When a subject requests an action on an object, the framework looks up
-the roles assigned to that subject (using the object path). The set of
-roles defines the granted privileges.
+Access permissions are assigned to objects, such as a virtual machines,
+storages or pools of resources.
+We use file system like paths to address these objects. These paths form a
+natural tree, and permissions of higher levels (shorter path) can
+optionally be propagated down within this hierarchy.
+
+[[templated-paths]]
+Paths can be templated. When an API call requires permissions on a
+templated path, the path may contain references to parameters of the API
+call. These references are specified in curly braces. Some parameters are
+implicitly taken from the API call's URI. For instance the permission path
+`/nodes/{node}` when calling '/nodes/mynode/status' requires permissions on
+`/nodes/mynode`, while the path `{path}` in a PUT request to `/access/acl`
+refers to the method's `path` parameter.
+
+Some examples are:
+
+* `/nodes/{node}`: Access to {pve} server machines
+* `/vms`: Covers all VMs
+* `/vms/{vmid}`: Access to specific VMs
+* `/storage/{storeid}`: Access to a storages
+* `/pool/{poolname}`: Access to VMs part of a <<resource-pools,pool>
+* `/access/groups`: Group administration
+* `/access/realms/{realmid}`: Administrative access to realms
 
 
 Inheritance