]> git.proxmox.com Git - pve-docs.git/blobdiff - pveum.adoc
remove first person reference
[pve-docs.git] / pveum.adoc
index f68b243cf4962bc7700fb52509564b413448ae74..522da4de89fe2dd8715c6ba9523f1721380c1642 100644 (file)
@@ -32,7 +32,8 @@ Active Directory, LDAP, Linux PAM or the integrated Proxmox VE
 authentication server.
 
 By using the role based user- and permission management for all
 authentication server.
 
 By using the role based user- and permission management for all
-objects (VM´s, storages, nodes, etc.) granular access can be defined.
+objects (VMs, storages, nodes, etc.) granular access can be defined.
+
 
 Authentication Realms
 ---------------------
 
 Authentication Realms
 ---------------------
@@ -66,9 +67,11 @@ This is a unix like password store
 (`/etc/pve/priv/shadow.cfg`). Password are encrypted using the SHA-256
 hash method. Users are allowed to change passwords.
 
 (`/etc/pve/priv/shadow.cfg`). Password are encrypted using the SHA-256
 hash method. Users are allowed to change passwords.
 
+
 Terms and Definitions
 ---------------------
 
 Terms and Definitions
 ---------------------
 
+
 Users
 ~~~~~
 
 Users
 ~~~~~
 
@@ -85,12 +88,14 @@ We store the following attribute for users (`/etc/pve/user.cfg`):
 * flag to enable/disable account
 * comment
 
 * flag to enable/disable account
 * comment
 
+
 Superuser
 ^^^^^^^^^
 
 The traditional unix superuser account is called `root@pam`. All
 system mails are forwarded to the email assigned to that account.
 
 Superuser
 ^^^^^^^^^
 
 The traditional unix superuser account is called `root@pam`. All
 system mails are forwarded to the email assigned to that account.
 
+
 Groups
 ~~~~~~
 
 Groups
 ~~~~~~
 
@@ -99,6 +104,7 @@ way to organize access permissions. You should always grant permission
 to groups instead of using individual users. That way you will get a
 much shorter access control list which is easier to handle.
 
 to groups instead of using individual users. That way you will get a
 much shorter access control list which is easier to handle.
 
+
 Objects and Paths
 ~~~~~~~~~~~~~~~~~
 
 Objects and Paths
 ~~~~~~~~~~~~~~~~~
 
@@ -108,6 +114,7 @@ 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.
 
 address those objects. Those paths form a natural tree, and
 permissions can be inherited down that hierarchy.
 
+
 Privileges
 ~~~~~~~~~~
 
 Privileges
 ~~~~~~~~~~
 
@@ -157,6 +164,7 @@ Storage related privileges::
 * `Datastore.AllocateTemplate`: allocate/upload templates and iso images 
 * `Datastore.Audit`: view/browse a datastore
 
 * `Datastore.AllocateTemplate`: allocate/upload templates and iso images 
 * `Datastore.Audit`: view/browse a datastore
 
+
 Roles
 ~~~~~
 
 Roles
 ~~~~~
 
@@ -200,10 +208,11 @@ 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.
 
 the roles assigned to that subject (using the object path). The set of
 roles defines the granted privileges.
 
+
 Inheritance
 ^^^^^^^^^^^
 
 Inheritance
 ^^^^^^^^^^^
 
-As mentioned earlier, object paths forms a filesystem like tree, and
+As mentioned earlier, object paths form a file system like tree, and
 permissions can be inherited down that tree (the propagate flag is set
 by default). We use the following inheritance rules:
 
 permissions can be inherited down that tree (the propagate flag is set
 by default). We use the following inheritance rules:
 
@@ -211,12 +220,14 @@ by default). We use the following inheritance rules:
 * permission for groups apply when the user is member of that group.
 * permission set at higher level always overwrites inherited permissions.
 
 * permission for groups apply when the user is member of that group.
 * permission set at higher level always overwrites inherited permissions.
 
+
 What permission do I need?
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The required API permissions are documented for each individual
 method, and can be found at http://pve.proxmox.com/pve-docs/api-viewer/
 
 What permission do I need?
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The required API permissions are documented for each individual
 method, and can be found at http://pve.proxmox.com/pve-docs/api-viewer/
 
+
 Pools
 ~~~~~
 
 Pools
 ~~~~~
 
@@ -230,10 +241,9 @@ Command Line Tool
 
 Most users will simply use the GUI to manage users. But there is also
 a full featured command line tool called `pveum` (short for ``**P**roxmox
 
 Most users will simply use the GUI to manage users. But there is also
 a full featured command line tool called `pveum` (short for ``**P**roxmox
-**VE** **U**ser **M**anager''). I will use that tool in the following
-examples. Please note that all Proxmox VE command line tools are
-wrappers around the API, so you can also access those function through
-the REST API.
+**VE** **U**ser **M**anager''). Please note that all Proxmox VE command
+line tools are wrappers around the API, so you can also access those
+function through the REST API.
 
 Here are some simple usage examples. To show help type:
 
 
 Here are some simple usage examples. To show help type:
 
@@ -274,11 +284,12 @@ Create a new role:
 Real World Examples
 -------------------
 
 Real World Examples
 -------------------
 
+
 Administrator Group
 ~~~~~~~~~~~~~~~~~~~
 
 One of the most wanted features was the ability to define a group of
 Administrator Group
 ~~~~~~~~~~~~~~~~~~~
 
 One of the most wanted features was the ability to define a group of
-users with full administartor rights (without using the root account).
+users with full administrator rights (without using the root account).
 
 Define the group:
 
 
 Define the group:
 
@@ -312,6 +323,7 @@ Example1: Allow user `joe@pve` to see all virtual machines
 [source,bash]
  pveum aclmod /vms -user joe@pve -role PVEAuditor
 
 [source,bash]
  pveum aclmod /vms -user joe@pve -role PVEAuditor
 
+
 Delegate User Management
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 Delegate User Management
 ~~~~~~~~~~~~~~~~~~~~~~~~