update sources to v12.1.2

[ceph.git] / ceph / doc / rados / operations / user-management.rst

diff --git a/ceph/doc/rados/operations/user-management.rst b/ceph/doc/rados/operations/user-management.rst
index efd92f730a927fb4b201946580ce54646b48a525..a4c5884004600a17de2bd5d327931ae4825921d6 100644 (file)
--- a/ceph/doc/rados/operations/user-management.rst
+++ b/ceph/doc/rados/operations/user-management.rst
@@ -98,29 +98,29 @@ capabilities when creating or updating a user.
 
 Capability syntax follows the form::
 
-       {daemon-type} 'allow {capability}' [{daemon-type} 'allow {capability}']
+       {daemon-type} '{capspec}[, {capspec} ...]'
 
-
-- **Monitor Caps:** Monitor capabilities include ``r``, ``w``, ``x`` and 
-  ``allow profile {cap}``. For example:: 
+- **Monitor Caps:** Monitor capabilities include ``r``, ``w``, ``x`` access
+  settings or ``profile {name}``. For example::
 
        mon 'allow rwx'
-       mon 'allow profile osd'
+       mon 'profile osd'
 
-- **OSD Caps:** OSD capabilities include ``r``, ``w``, ``x``, ``class-read``, 
-  ``class-write`` and ``profile osd``. Additionally, OSD capabilities also 
-  allow for pool and namespace settings. ::
+- **OSD Caps:** OSD capabilities include ``r``, ``w``, ``x``, ``class-read``,
+  ``class-write`` access settings or ``profile {name}``. Additionally, OSD
+  capabilities also allow for pool and namespace settings. ::
 
-       osd 'allow {capability}' [pool={poolname}] [namespace={namespace-name}]
+       osd 'allow {access} [pool={pool-name} [namespace={namespace-name}]]'
+       osd 'profile {name} [pool={pool-name} [namespace={namespace-name}]]'
 
 - **Metadata Server Caps:** Metadata server capability simply requires ``allow``, 
   or blank and does not parse anything further. :: 
-  
+
        mds 'allow'
 
 
 .. note:: The Ceph Object Gateway daemon (``radosgw``) is a client of the 
-          Ceph Storage Cluster, so it isn't represented as a Ceph Storage 
+          Ceph Storage Cluster, so it is not represented as a Ceph Storage 
           Cluster daemon type.
 
 The following entries describe each capability.
@@ -168,20 +168,20 @@ The following entries describe each capability.
               admin commands.
 
 
-``profile osd``
+``profile osd`` (Monitor only)
 
 :Description: Gives a user permissions to connect as an OSD to other OSDs or 
               monitors. Conferred on OSDs to enable OSDs to handle replication
               heartbeat traffic and status reporting.
 
 
-``profile mds``
+``profile mds`` (Monitor only)
 
 :Description: Gives a user permissions to connect as a MDS to other MDSs or 
               monitors.
 
 
-``profile bootstrap-osd``
+``profile bootstrap-osd`` (Monitor only)
 
 :Description: Gives a user permissions to bootstrap an OSD. Conferred on 
               deployment tools such as ``ceph-disk``, ``ceph-deploy``, etc.
@@ -189,13 +189,23 @@ The following entries describe each capability.
               bootstrapping an OSD.
 
 
-``profile bootstrap-mds``
+``profile bootstrap-mds`` (Monitor only)
 
 :Description: Gives a user permissions to bootstrap a metadata server. 
               Conferred on deployment tools such as ``ceph-deploy``, etc.
               so they have permissions to add keys, etc. when bootstrapping
               a metadata server.
 
+``profile rbd`` (Monitor and OSD)
+
+:Description: Gives a user permissions to manipulate RBD images. When used
+              as a Monitor cap, it provides the minimal privileges required
+              by an RBD client application. When used as an OSD cap, it
+              provides read-write access to an RBD client application.
+
+``profile rbd-read-only`` (OSD only)
+
+:Description: Gives a user read-only permissions to an RBD image.
 
 
 Pool
@@ -218,10 +228,10 @@ namespace such that reads and writes by the user take place only within the
 namespace. Objects written to a namespace within the pool can only be accessed
 by users who have access to the namespace.
 
-.. note:: Currently (i.e., ``firefly``), namespaces are only useful for 
-   applications written on top of ``librados``. Ceph clients such as block 
-   device, object storage and file system do not currently support this 
-   feature.
+.. note:: Namespaces are primarily useful for applications written on top of
+   ``librados`` where the logical grouping can alleviate the need to create
+   different pools. Ceph Object Gateway (from ``luminous``) uses namespaces for various
+   metadata objects.
 
 The rationale for namespaces is that pools can be a computationally expensive
 method of segregating data sets for the purposes of authorizing separate sets
@@ -251,10 +261,10 @@ List Users
 
 To list the users in your cluster, execute the following::
 
-       ceph auth list
+       ceph auth ls
 
 Ceph will list out all users in your cluster. For example, in a two-node
-exemplary cluster, ``ceph auth list`` will output something that looks like
+exemplary cluster, ``ceph auth ls`` will output something that looks like
 this::
 
        installed auth entries:
@@ -286,7 +296,7 @@ user of type ``osd`` and its ID is ``0``, ``client.admin`` is a user of type
 Note also that each entry has a ``key: <value>`` entry, and one or more
 ``caps:`` entries.
 
-You may use the ``-o {filename}`` option with ``ceph auth list`` to 
+You may use the ``-o {filename}`` option with ``ceph auth ls`` to 
 save the output to a file.
 
 
@@ -308,7 +318,7 @@ save the output to a file. Developers may also execute the following::
        ceph auth export {TYPE.ID}
 
 The ``auth export`` command is identical to ``auth get``, but also prints
-out the internal ``auid``, which isn't relevant to end users.
+out the internal ``auid``, which is not relevant to end users.