+.. _ceph-dokan:
+
=======================
Mount CephFS on Windows
=======================
+.. _cephfs-top:
+
==================
CephFS Top Utility
==================
+.. _snap-schedule:
+
==========================
Snapshot Scheduling Module
==========================
governance
foundation
ceph-volume/index
+ security/index
releases/general
releases/index
+ security/index
Glossary <glossary>
**block (data) only**
^^^^^^^^^^^^^^^^^^^^^
If all devices are the same type, for example all rotational drives, and
-there are no fast devices to use for metadata, it makes sense to specifiy the
+there are no fast devices to use for metadata, it makes sense to specify the
block device only and to not separate ``block.db`` or ``block.wal``. The
:ref:`ceph-volume-lvm` command for a single ``/dev/sda`` device looks like::
specific partition / LV sizes that correspond to sums of L0, L0+L1, L1+L2,
etc. sizes, which with default settings means roughly 3 GB, 30 GB, 300 GB, and
so forth. Most deployments will not substantially benefit from sizing to
-accomodate L3 and higher, though DB compaction can be facilitated by doubling
+accommodate L3 and higher, though DB compaction can be facilitated by doubling
these figures to 6GB, 60GB, and 600GB.
Improvements in releases beginning with Nautilus 14.2.12 and Octopus 15.2.6
``bluestore_cache_meta_ratio`` and ``bluestore_cache_kv_ratio`` options are
used as fallbacks.
-``bluestore_cache_autotune``
-
-:Description: Automatically tune the space ratios assigned to various BlueStore
- caches while respecting minimum values.
-:Type: Boolean
-:Required: Yes
-:Default: ``True``
-
-``osd_memory_target``
-
-:Description: When TCMalloc is available and cache autotuning is enabled, try to
- keep this many bytes mapped in memory. Note: This may not exactly
- match the RSS memory usage of the process. While the total amount
- of heap memory mapped by the process should usually be close
- to this target, there is no guarantee that the kernel will actually
- reclaim memory that has been unmapped. During initial development,
- it was found that some kernels result in the OSD's RSS memory
- exceeding the mapped memory by up to 20%. It is hypothesised
- however, that the kernel generally may be more aggressive about
- reclaiming unmapped memory when there is a high amount of memory
- pressure. Your mileage may vary.
-:Type: Unsigned Integer
-:Required: Yes
-:Default: ``4294967296``
-
-``bluestore_cache_autotune_chunk_size``
-
-:Description: The chunk size in bytes to allocate to caches when cache autotune
- is enabled. When the autotuner assigns memory to various caches,
- it will allocate memory in chunks. This is done to avoid
- evictions when there are minor fluctuations in the heap size or
- autotuned cache ratios.
-:Type: Unsigned Integer
-:Required: No
-:Default: ``33554432``
-
-``bluestore_cache_autotune_interval``
-
-:Description: The number of seconds to wait between rebalances when cache autotune
- is enabled. This setting changes how quickly the allocation ratios of
- various caches are recomputed. Note: Setting this interval too small
- can result in high CPU usage and lower performance.
-:Type: Float
-:Required: No
-:Default: ``5``
-
-``osd_memory_base``
-
-:Description: When TCMalloc and cache autotuning are enabled, estimate the minimum
- amount of memory in bytes the OSD will need. This is used to help
- the autotuner estimate the expected aggregate memory consumption of
- the caches.
-:Type: Unsigned Integer
-:Required: No
-:Default: ``805306368``
-
-``osd_memory_expected_fragmentation``
-
-:Description: When TCMalloc and cache autotuning is enabled, estimate the
- percentage of memory fragmentation. This is used to help the
- autotuner estimate the expected aggregate memory consumption
- of the caches.
-:Type: Float
-:Required: No
-:Default: ``0.15``
-
-``osd_memory_cache_min``
-
-:Description: When TCMalloc and cache autotuning are enabled, set the minimum
- amount of memory used for caches. Note: Setting this value too
- low can result in significant cache thrashing.
-:Type: Unsigned Integer
-:Required: No
-:Default: ``134217728``
-
-``osd_memory_cache_resize_interval``
-
-:Description: When TCMalloc and cache autotuning are enabled, wait this many
- seconds between resizing caches. This setting changes the total
- amount of memory available for BlueStore to use for caching. Note
- that setting this interval too small can result in memory allocator
- thrashing and lower performance.
-:Type: Float
-:Required: No
-:Default: ``1``
-
-
Manual Cache Sizing
===================
The data fraction can be calculated by
``<effective_cache_size> * (1 - bluestore_cache_meta_ratio - bluestore_cache_kv_ratio)``
-``bluestore_cache_size``
-
-:Description: The amount of memory BlueStore will use for its cache. If zero,
- ``bluestore_cache_size_hdd`` or ``bluestore_cache_size_ssd`` will
- be used instead.
-:Type: Unsigned Integer
-:Required: Yes
-:Default: ``0``
-
-``bluestore_cache_size_hdd``
-
-:Description: The default amount of memory BlueStore will use for its cache when
- backed by an HDD.
-:Type: Unsigned Integer
-:Required: Yes
-:Default: ``1 * 1024 * 1024 * 1024`` (1 GB)
-
-``bluestore_cache_size_ssd``
-
-:Description: The default amount of memory BlueStore will use for its cache when
- backed by an SSD.
-:Type: Unsigned Integer
-:Required: Yes
-:Default: ``3 * 1024 * 1024 * 1024`` (3 GB)
-
-``bluestore_cache_meta_ratio``
-
-:Description: The ratio of cache devoted to metadata.
-:Type: Floating point
-:Required: Yes
-:Default: ``.4``
-
-``bluestore_cache_kv_ratio``
-
-:Description: The ratio of cache devoted to key/value data (RocksDB).
-:Type: Floating point
-:Required: Yes
-:Default: ``.4``
-
-``bluestore_cache_kv_max``
-
-:Description: The maximum amount of cache devoted to key/value data (RocksDB).
-:Type: Unsigned Integer
-:Required: Yes
-:Default: ``512 * 1024*1024`` (512 MB)
-
-
Checksums
=========
ceph osd pool set <pool-name> csum_type <algorithm>
-``bluestore_csum_type``
-
-:Description: The default checksum algorithm to use.
-:Type: String
-:Required: Yes
-:Valid Settings: ``none``, ``crc32c``, ``crc32c_16``, ``crc32c_8``, ``xxhash32``, ``xxhash64``
-:Default: ``crc32c``
-
Inline Compression
==================
ceph osd pool set <pool-name> compression_min_blob_size <size>
ceph osd pool set <pool-name> compression_max_blob_size <size>
-``bluestore_compression_algorithm``
-:Description: The default compressor to use (if any) if the per-pool property
- ``compression_algorithm`` is not set. Note that ``zstd`` is *not*
- recommended for BlueStore due to high CPU overhead when
- compressing small amounts of data.
-:Type: String
-:Required: No
-:Valid Settings: ``lz4``, ``snappy``, ``zlib``, ``zstd``
-:Default: ``snappy``
+.. _bluestore-rocksdb-sharding:
-``bluestore_compression_mode``
+RocksDB Sharding
+================
-:Description: The default policy for using compression if the per-pool property
- ``compression_mode`` is not set. ``none`` means never use
- compression. ``passive`` means use compression when
- :c:func:`clients hint <rados_set_alloc_hint>` that data is
- compressible. ``aggressive`` means use compression unless
- clients hint that data is not compressible. ``force`` means use
- compression under all circumstances even if the clients hint that
- the data is not compressible.
-:Type: String
-:Required: No
-:Valid Settings: ``none``, ``passive``, ``aggressive``, ``force``
-:Default: ``none``
+Internally BlueStore uses multiple types of key-value data,
+stored in RocksDB. Each data type in BlueStore is assigned a
+unique prefix. Until Pacific all key-value data was stored in
+single RocksDB column family: 'default'. Since Pacific,
+BlueStore can divide this data into multiple RocksDB column
+families. When keys have similar access frequency, modification
+frequency and lifetime, BlueStore benefits from better caching
+and more precise compaction. This improves performance, and also
+requires less disk space during compaction, since each column
+family is smaller and can compact independent of others.
-``bluestore_compression_required_ratio``
+OSDs deployed in Pacific or later use RocksDB sharding by default.
+If Ceph is upgraded to Pacific from a previous version, sharding is off.
-:Description: The ratio of the size of the data chunk after
- compression relative to the original size must be at
- least this small in order to store the compressed
- version.
+To enable sharding and apply the Pacific defaults, stop an OSD and run
-:Type: Floating point
-:Required: No
-:Default: .875
+ .. prompt:: bash #
-``bluestore_compression_min_blob_size``
+ ceph-bluestore-tool \
+ --path <data path> \
+ --sharding="m(3) p(3,0-12) O(3,0-13)=block_cache={type=binned_lru} L P" \
+ reshard
-:Description: Chunks smaller than this are never compressed.
- The per-pool property ``compression_min_blob_size`` overrides
- this setting.
-:Type: Unsigned Integer
-:Required: No
-:Default: 0
+Throttling
+==========
-``bluestore_compression_min_blob_size_hdd``
-
-:Description: Default value of ``bluestore compression min blob size``
- for rotational media.
-
-:Type: Unsigned Integer
-:Required: No
-:Default: 128K
-
-``bluestore_compression_min_blob_size_ssd``
-
-:Description: Default value of ``bluestore compression min blob size``
- for non-rotational (solid state) media.
-
-:Type: Unsigned Integer
-:Required: No
-:Default: 8K
-
-``bluestore_compression_max_blob_size``
-
-:Description: Chunks larger than this value are broken into smaller blobs of at most
- ``bluestore_compression_max_blob_size`` bytes before being compressed.
- The per-pool property ``compression_max_blob_size`` overrides
- this setting.
-
-:Type: Unsigned Integer
-:Required: No
-:Default: 0
-
-``bluestore_compression_max_blob_size_hdd``
-
-:Description: Default value of ``bluestore compression max blob size``
- for rotational media.
-
-:Type: Unsigned Integer
-:Required: No
-:Default: 512K
-
-``bluestore_compression_max_blob_size_ssd``
-
-:Description: Default value of ``bluestore compression max blob size``
- for non-rotational (SSD, NVMe) media.
-
-:Type: Unsigned Integer
-:Required: No
-:Default: 64K
SPDK Usage
==================
and then set::
- bluestore_block_path = spdk:0000:01:00.0
+ bluestore_block_path = "spdk:trtype:PCIe traddr:0000:01:00.0"
Where ``0000:01:00.0`` is the device selector found in the output of ``lspci``
command above.
+You may also specify a remote NVMeoF target over the TCP transport as in the
+following example::
+
+ bluestore_block_path = "spdk:trtype:TCP traddr:10.67.110.197 trsvcid:4420 subnqn:nqn.2019-02.io.spdk:cnode1"
+
To run multiple SPDK instances per node, you must specify the
amount of dpdk memory in MB that each instance will use, to make sure each
-instance uses its own dpdk memory
+instance uses its own DPDK memory.
In most cases, a single device can be used for data, DB, and WAL. We describe
this strategy as *colocating* these components. Be sure to enter the below
Otherwise, the current implementation will populate the SPDK map files with
kernel file system symbols and will use the kernel driver to issue DB/WAL IO.
+
+Minimum Allocation Size
+========================
+
+There is a configured minimum amount of storage that BlueStore will allocate on
+an OSD. In practice, this is the least amount of capacity that a RADOS object
+can consume. The value of `bluestore_min_alloc_size` is derived from the
+value of `bluestore_min_alloc_size_hdd` or `bluestore_min_alloc_size_ssd`
+depending on the OSD's ``rotational`` attribute. This means that when an OSD
+is created on an HDD, BlueStore will be initialized with the current value
+of `bluestore_min_alloc_size_hdd`, and SSD OSDs (including NVMe devices)
+with the value of `bluestore_min_alloc_size_ssd`.
+
+Through the Mimic release, the default values were 64KB and 16KB for rotational
+(HDD) and non-rotational (SSD) media respectively. Octopus changed the default
+for SSD (non-rotational) media to 4KB, and Pacific changed the default for HDD
+(rotational) media to 4KB as well.
+
+These changes were driven by space amplification experienced by Ceph RADOS
+GateWay (RGW) deployments that host large numbers of small files
+(S3/Swift objects).
+
+For example, when an RGW client stores a 1KB S3 object, it is written to a
+single RADOS object. With the default `min_alloc_size` value, 4KB of
+underlying drive space is allocated. This means that roughly
+(4KB - 1KB) == 3KB is allocated but never used, which corresponds to 300%
+overhead or 25% efficiency. Similarly, a 5KB user object will be stored
+as one 4KB and one 1KB RADOS object, again stranding 4KB of device capcity,
+though in this case the overhead is a much smaller percentage. Think of this
+in terms of the remainder from a modulus operation. The overhead *percentage*
+thus decreases rapidly as user object size increases.
+
+An easily missed additional subtlety is that this
+takes place for *each* replica. So when using the default three copies of
+data (3R), a 1KB S3 object actually consumes roughly 9KB of storage device
+capacity. If erasure coding (EC) is used instead of replication, the
+amplification may be even higher: for a ``k=4,m=2`` pool, our 1KB S3 object
+will allocate (6 * 4KB) = 24KB of device capacity.
+
+When an RGW bucket pool contains many relatively large user objects, the effect
+of this phenomenon is often negligible, but should be considered for deployments
+that expect a signficiant fraction of relatively small objects.
+
+The 4KB default value aligns well with conventional HDD and SSD devices. Some
+new coarse-IU (Indirection Unit) QLC SSDs however perform and wear best
+when `bluestore_min_alloc_size_ssd`
+is set at OSD creation to match the device's IU:. 8KB, 16KB, or even 64KB.
+These novel storage drives allow one to achieve read performance competitive
+with conventional TLC SSDs and write performance faster than HDDs, with
+high density and lower cost than TLC SSDs.
+
+Note that when creating OSDs on these devices, one must carefully apply the
+non-default value only to appropriate devices, and not to conventional SSD and
+HDD devices. This may be done through careful ordering of OSD creation, custom
+OSD device classes, and especially by the use of central configuration _masks_.
+
+Quincy and later releases add
+the `bluestore_use_optimal_io_size_for_min_alloc_size`
+option that enables automatic discovery of the appropriate value as each OSD is
+created. Note that the use of ``bcache``, ``OpenCAS``, ``dmcrypt``,
+``ATA over Ethernet``, `iSCSI`, or other device layering / abstraction
+technologies may confound the determination of appropriate values. OSDs
+deployed on top of VMware storage have been reported to also
+sometimes report a ``rotational`` attribute that does not match the underlying
+hardware.
+
+We suggest inspecting such OSDs at startup via logs and admin sockets to ensure that
+behavior is appropriate. Note that this also may not work as desired with
+older kernels. You can check for this by examining the presence and value
+of ``/sys/block/<drive>/queue/optimal_io_size``.
+
+You may also inspect a given OSD:
+
+ .. prompt:: bash #
+
+ ceph osd metadata osd.1701 | grep rotational
+
+This space amplification may manifest as an unusually high ratio of raw to
+stored data reported by ``ceph df``. ``ceph osd df`` may also report
+anomalously high ``%USE`` / ``VAR`` values when
+compared to other, ostensibly identical OSDs. A pool using OSDs with
+mismatched ``min_alloc_size`` values may experience unexpected balancer
+behavior as well.
+
+Note that this BlueStore attribute takes effect *only* at OSD creation; if
+changed later, a given OSD's behavior will not change unless / until it is
+destroyed and redeployed with the appropriate option value(s). Upgrading
+to a later Ceph release will *not* change the value used by OSDs deployed
+under older releases or with other settings.
+
+DSA (Data Streaming Accelerator Usage)
+======================================
+
+If you want to use the DML library to drive DSA device for offloading
+read/write operations on Persist memory in Bluestore. You need to install
+`DML`_ and `idxd-config`_ library in your machine with SPR (Sapphire Rapids) CPU.
+
+.. _DML: https://github.com/intel/DML
+.. _idxd-config: https://github.com/intel/idxd-config
+
+After installing the DML software, you need to configure the shared
+work queues (WQs) with the following WQ configuration example via accel-config tool::
+
+$ accel-config config-wq --group-id=1 --mode=shared --wq-size=16 --threshold=15 --type=user --name="MyApp1" --priority=10 --block-on-fault=1 dsa0/wq0.1
+$ accel-config config-engine dsa0/engine0.1 --group-id=1
+$ accel-config enable-device dsa0
+$ accel-config enable-wq dsa0/wq0.1
+.. _s3-select-feature-table:
Features Support
----------------
-.. _feature-table:
-
| Currently only part of `AWS select command <https://docs.aws.amazon.com/AmazonS3/latest/dev/s3-glacier-select-sql-reference-select.html>`_ is implemented, table bellow describes what is currently supported.
| The following table describes the current implementation for s3-select functionalities:
.. toctree::
:maxdepth: 1
+.. _active-releases:
+
Active Releases
---------------
.. toctree::
:maxdepth: 1
+ Pacific <pacific>
Octopus <octopus>
Nautilus <nautilus>
- OSD: disk replacement, display status of ongoing deletion, and improved
health/SMART diagnostics reporting.
-* Official :ref:`mgr ceph api`:
+* Official :ref:`mgr-ceph-api`:
- OpenAPI v3 compliant.
- Stability commitment starting from Pacific release.
--- /dev/null
+.. _CVE-2021-20288:
+
+CVE-2021-20288: Unauthorized global_id reuse in cephx
+=====================================================
+
+* `NIST information page <https://nvd.nist.gov/vuln/detail/CVE-2021-20288>`_
+
+Summary
+-------
+
+Ceph was not ensuring that reconnecting/renewing clients were
+presenting an existing ticket when reclaiming their global_id value.
+An attacker that was able to authenticate could claim a global_id in
+use by a different client and potentially disrupt
+other cluster services.
+
+Background
+----------
+
+Each authenticated client or daemon in Ceph is assigned a numeric
+global_id identifier. That value is assumed to be unique across the
+cluster. When clients reconnect to the monitor (e.g., due to a
+network disconnection) or renew their ticket, they are supposed to
+present their old ticket to prove prior possession of their global_id
+so that it can be reclaimed and thus remain constant over the lifetime
+of that client instance.
+
+Ceph was not correctly checking that the old ticket was valid, allowing
+an arbitrary global_id to be reclaimed, even if it was in use by another
+active client in the system.
+
+Attacker Requirements
+---------------------
+
+Any potential attacker must:
+
+* have a valid authentication key for the cluster
+* know or guess the global_id of another client
+* run a modified version of the Ceph client code to reclaim another client's global_id
+* construct appropriate client messages or requests to disrupt service or exploit
+ Ceph daemon assumptions about global_id uniqueness
+
+Impact
+------
+
+Confidentiality Impact
+______________________
+
+None
+
+Integrity Impact
+________________
+
+Partial. An attacker could potentially exploit assumptions around
+global_id uniqueness to disrupt other clients' access or disrupt
+Ceph daemons.
+
+Availability Impact
+___________________
+
+High. An attacker could potentially exploit assumptions around
+global_id uniqueness to disrupt other clients' access or disrupt
+Ceph daemons.
+
+Access Complexity
+_________________
+
+High. The client must make use of modified client code in order to
+exploit specific assumptions in the behavior of other Ceph daemons.
+
+Authentication
+______________
+
+Yes. The attacker must also be authenticated and have access to the
+same services as a client it is wishing to impersonate or disrupt.
+
+Gained Access
+_____________
+
+Partial. An attacker can partially impersonate another client.
+
+Affected versions
+-----------------
+
+All prior versions of Ceph monitors fail to ensure that global_id reclaim
+attempts are authentic.
+
+In addition, all user-space daemons and clients starting from Luminous v12.2.0
+were failing to securely reclaim their global_id following commit a2eb6ae3fb57
+("mon/monclient: hunt for multiple monitor in parallel").
+
+All versions of the Linux kernel client properly authenticate.
+
+Fixed versions
+--------------
+
+* Pacific v16.2.1 (and later)
+* Octopus v15.2.11 (and later)
+* Nautilus v14.2.20 (and later)
+
+
+Fix details
+-----------
+
+#. Patched monitors now properly require that clients securely reclaim
+ their global_id when the ``auth_allow_insecure_global_id_reclaim``
+ is ``false``. Initially, by default, this option is set to
+ ``true`` so that existing clients can continue to function without
+ disruption until all clients have been upgraded. When this option
+ is set to false, then an unpatched client will not be able to reconnect
+ to the cluster after an intermittent network disruption breaking
+ its connect to a monitor, or be able to renew its authentication
+ ticket when it times out (by default, after 72 hours).
+
+ Patched monitors raise the ``AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED``
+ health alert if ``auth_allow_insecure_global_id_reclaim`` is enabled.
+ This health alert can be muted with::
+
+ ceph health mute AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED 1w
+
+ Although it is not recommended, the alert can also be disabled with::
+
+ ceph config set mon mon_warn_on_insecure_global_id_reclaim_allowed false
+
+#. Patched monitors can disconnect new clients right after they have
+ authenticated (forcing them to reconnect and reclaim) in order to
+ determine whether they securely reclaim global_ids. This allows
+ the cluster and users to discover quickly whether clients would be
+ affected by requiring secure global_id reclaim: most clients will
+ report an authentication error immediately. This behavior can be
+ disabled by setting ``auth_expose_insecure_global_id_reclaim`` to
+ ``false``::
+
+ ceph config set mon auth_expose_insecure_global_id_reclaim false
+
+#. Patched monitors will raise the ``AUTH_INSECURE_GLOBAL_ID_RECLAIM`` health
+ alert for any clients or daemons that are not securely reclaiming their
+ global_id. These clients should be upgraded before disabling the
+ ``auth_allow_insecure_global_id_reclaim`` option to avoid disrupting
+ client access.
+
+ By default (if ``auth_expose_insecure_global_id_reclaim`` has not
+ been disabled), clients' failure to securely reclaim global_id will
+ immediately be exposed and raise this health alert.
+ However, if ``auth_expose_insecure_global_id_reclaim`` has been
+ disabled, this alert will not be triggered for a client until it is
+ forced to reconnect to a monitor (e.g., due to a network disruption)
+ or the client renews its authentication ticket (by default, after
+ 72 hours).
+
+#. The default time-to-live (TTL) for authentication tickets has been increased
+ from 12 hours to 72 hours. Because we previously were not ensuring that
+ a client's prior ticket was valid when reclaiming their global_id, a client
+ could tolerate a network outage that lasted longer than the ticket TTL and still
+ reclaim its global_id. Once the cluster starts requiring secure global_id reclaim,
+ a client that is disconnected for longer than the TTL may fail to reclaim its global_id,
+ fail to reauthenticate, and be unable to continue communicating with the cluster
+ until it is restarted. The default TTL was increased to minimize the impact of this
+ change on users.
+
+
+Recommendations
+---------------
+
+#. Users should upgrade to a patched version of Ceph at their earliest
+ convenience.
+
+#. Users should upgrade any unpatched clients at their earliest
+ convenience. By default, these clients can be easily identified by
+ checking the ``ceph health detail`` output for the
+ ``AUTH_INSECURE_GLOBAL_ID_RECLAIM`` alert.
+
+#. If all clients cannot be upgraded immediately, the health alerts can be
+ temporarily muted with::
+
+ ceph health mute AUTH_INSECURE_GLOBAL_ID_RECLAIM 1w # 1 week
+ ceph health mute AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED 1w # 1 week
+
+#. After all clients have been updated and the ``AUTH_INSECURE_GLOBAL_ID_RECLAIM``
+ alert is no longer present, the cluster should be set to prevent insecure
+ global_id reclaim with::
+
+ ceph config set mon auth_allow_insecure_global_id_reclaim false
--- /dev/null
+.. _CVE-2021-3509:
+
+CVE-2021-3509: Dashboard XSS via token cookie
+=============================================
+
+* `NIST information page <https://nvd.nist.gov/vuln/detail/CVE-2021-3509>`_
+
+The Ceph Dashboard was vulnerable to an XSS attack that could expose the authentication
+cookie to other sites.
+
+
+Affected versions
+-----------------
+
+* Octopus v15.2.0 and later
+
+Fixed versions
+--------------
+
+* Pacific v16.2.4 (and later)
+* Octopus v15.2.12 (and later)
+* Nautilus v14.2.21 (and later)
+
+
+Recommendations
+---------------
+
+All users of the Ceph dashboard should upgrade.
--- /dev/null
+.. _CVE-2021-3524:
+
+CVE-2021-3524: HTTP header injects via CORS in RGW
+==================================================
+
+* `NIST information page <https://nvd.nist.gov/vuln/detail/CVE-2021-3524>`_
+
+A flaw was found in the radosgw. The vulnerability is related to the
+injection of HTTP headers via a CORS ExposeHeader tag. The \r
+character in the ExposeHeader tag in the CORS configuration file
+generates a header injection in the response when the CORS request is
+made.
+
+Fixed versions
+--------------
+
+* Pacific v16.2.4 (and later)
+* Octopus v15.2.12 (and later)
+* Nautilus v14.2.21 (and later)
+
+Recommendations
+---------------
+
+All users of Ceph object storage (RGW) should upgrade.
+
+Acknowledgements
+----------------
+
+Red Hat would like to thank Sergey Bobrov (Kaspersky) for reporting this issue.
+
--- /dev/null
+.. _CVE-2021-3531:
+
+CVE-2021-3531: Swift API denial of service
+==========================================
+
+* `NIST information page <https://nvd.nist.gov/vuln/detail/CVE-2021-3531>`_
+
+Unauthenticated users of the Swift API can trigger a server-side assertion with a
+malformed URL, leading to a denial of service.
+
+
+Affected versions
+-----------------
+
+* Nautilus v14.2.0 and later
+
+Fixed versions
+--------------
+
+* Pacific v16.2.4 (and later)
+* Octopus v15.2.12 (and later)
+* Nautilus v14.2.21 (and later)
+
+
+Recommendations
+---------------
+
+All users of Ceph object storage (RGW) should upgrade.
--- /dev/null
+
+Past vulnerabilities
+====================
+
++------------+-------------------+-------------+--------------------------------------------+
+| Published | CVE | Severity | Summary |
++------------+-------------------+-------------+--------------------------------------------+
+| 2021-05-13 | `CVE-2021-3531`_ | Medium | Swift API denial of service |
++------------+-------------------+-------------+--------------------------------------------+
+| 2021-05-13 | `CVE-2021-3524`_ | Medium | HTTP header injects via CORS in RGW |
++------------+-------------------+-------------+--------------------------------------------+
+| 2021-05-13 | `CVE-2021-3509`_ | High | Dashboard XSS via token cookie |
++------------+-------------------+-------------+--------------------------------------------+
+| 2021-04-14 | `CVE-2021-20288`_ | High | Unauthorized global_id reuse in cephx |
++------------+-------------------+-------------+--------------------------------------------+
+| 2020-12-18 | `CVE-2020-27781`_ | 7.1 High | CephFS creds read/modified by Manila users |
++------------+-------------------+-------------+--------------------------------------------+
+| 2021-01-08 | `CVE-2020-25678`_ | 4.9 Medium | mgr module passwords in clear text |
++------------+-------------------+-------------+--------------------------------------------+
+| 2020-12-07 | `CVE-2020-25677`_ | 5.5 Medium | ceph-ansible iscsi-gateway.conf perm |
++------------+-------------------+-------------+--------------------------------------------+
+| 2020-11-23 | `CVE-2020-25660`_ | 8.8 High | Cephx replay vulnerability |
++------------+-------------------+-------------+--------------------------------------------+
+| 2020-04-22 | `CVE-2020-12059`_ | 7.5 High | malformed POST could crash RGW |
++------------+-------------------+-------------+--------------------------------------------+
+| 2020-06-26 | `CVE-2020-10753`_ | 6.5 Medium | HTTP header injects via CORS in RGW |
++------------+-------------------+-------------+--------------------------------------------+
+| 2020-06-22 | `CVE-2020-10736`_ | 8.0 High | authorization bypass in mon and mgr |
++------------+-------------------+-------------+--------------------------------------------+
+| 2020-04-23 | `CVE-2020-1760`_ | 6.1 Medium | potential RGW XSS attack |
++------------+-------------------+-------------+--------------------------------------------+
+| 2020-04-13 | `CVE-2020-1759`_ | 6.8 Medium | Cephx nonce reuse in secure mode |
++------------+-------------------+-------------+--------------------------------------------+
+| 2020-02-07 | `CVE-2020-1700`_ | 6.5 Medium | RGW disconnects leak sockets, can DoS |
++------------+-------------------+-------------+--------------------------------------------+
+| 2020-04-21 | `CVE-2020-1699`_ | 7.5 High | Dashboard path traversal flaw |
++------------+-------------------+-------------+--------------------------------------------+
+| 2019-12-23 | `CVE-2019-19337`_ | 6.5 Medium | RGW DoS via malformed headers |
++------------+-------------------+-------------+--------------------------------------------+
+| 2019-11-08 | `CVE-2019-10222`_ | 7.5 High | Invalid HTTP headers could crash RGW |
++------------+-------------------+-------------+--------------------------------------------+
+| 2019-03-27 | `CVE-2019-3821`_ | 7.5 High | RGW file descriptors could be exhausted |
++------------+-------------------+-------------+--------------------------------------------+
+| 2019-01-28 | `CVE-2018-16889`_ | 7.5 High | encryption keys logged in plaintext |
++------------+-------------------+-------------+--------------------------------------------+
+| 2019-01-15 | `CVE-2018-16846`_ | 6.5 Medium | authenticated RGW users can cause DoS |
++------------+-------------------+-------------+--------------------------------------------+
+| 2019-01-15 | `CVE-2018-14662`_ | 5.7 Medium | read-only users could steal dm-crypt keys |
++------------+-------------------+-------------+--------------------------------------------+
+| 2018-07-10 | `CVE-2018-10861`_ | 8.1 High | authenticated user can create/delete pools |
++------------+-------------------+-------------+--------------------------------------------+
+| 2018-03-19 | `CVE-2018-7262`_ | 7.5 High | malformed headers can cause RGW DoS |
++------------+-------------------+-------------+--------------------------------------------+
+| 2018-07-10 | `CVE-2018-1129`_ | 6.5 Medium | network MITM can tamper with messages |
++------------+-------------------+-------------+--------------------------------------------+
+| 2018-07-10 | `CVE-2018-1128`_ | 7.5 High | Cephx replay vulnerability |
++------------+-------------------+-------------+--------------------------------------------+
+| 2018-07-27 | `CVE-2017-7519`_ | 4.4 Medium | libradosstriper unvalidated format string |
++------------+-------------------+-------------+--------------------------------------------+
+| 2018-08-01 | `CVE-2016-9579`_ | 7.6 High | potential RGW XSS attack |
++------------+-------------------+-------------+--------------------------------------------+
+| 2018-07-31 | `CVE-2016-8626`_ | 6.5 Medium | malformed POST can DoS RGW |
++------------+-------------------+-------------+--------------------------------------------+
+| 2016-10-03 | `CVE-2016-7031`_ | 7.5 High | RGW unauthorized bucket listing |
++------------+-------------------+-------------+--------------------------------------------+
+| 2016-07-12 | `CVE-2016-5009`_ | 6.5 Medium | mon command handler DoS |
++------------+-------------------+-------------+--------------------------------------------+
+| 2016-12-03 | `CVE-2015-5245`_ | | RGW header injection |
++------------+-------------------+-------------+--------------------------------------------+
+
+.. toctree::
+ :hidden:
+ :maxdepth: 0
+
+ CVE-2021-3531 <CVE-2021-3531.rst>
+ CVE-2021-3524 <CVE-2021-3524.rst>
+ CVE-2021-3509 <CVE-2021-3509.rst>
+ CVE-2021-20288 <CVE-2021-20288.rst>
+
+.. _CVE-2021-3531: ../CVE-2021-3531
+.. _CVE-2021-3524: ../CVE-2021-3524
+.. _CVE-2021-3509: ../CVE-2021-3509
+.. _CVE-2021-20288: ../CVE-2021-20288
+.. _CVE-2020-27781: https://nvd.nist.gov/vuln/detail/CVE-2020-27781
+.. _CVE-2020-25678: https://nvd.nist.gov/vuln/detail/CVE-2020-25678
+.. _CVE-2020-25677: https://nvd.nist.gov/vuln/detail/CVE-2020-25677
+.. _CVE-2020-25660: https://nvd.nist.gov/vuln/detail/CVE-2020-25660
+.. _CVE-2020-12059: https://nvd.nist.gov/vuln/detail/CVE-2020-12059
+.. _CVE-2020-10753: https://nvd.nist.gov/vuln/detail/CVE-2020-10753
+.. _CVE-2020-10736: https://nvd.nist.gov/vuln/detail/CVE-2020-10736
+.. _CVE-2020-1760: https://nvd.nist.gov/vuln/detail/CVE-2020-1760
+.. _CVE-2020-1759: https://nvd.nist.gov/vuln/detail/CVE-2020-1759
+.. _CVE-2020-1700: https://nvd.nist.gov/vuln/detail/CVE-2020-1700
+.. _CVE-2020-1699: https://nvd.nist.gov/vuln/detail/CVE-2020-1699
+.. _CVE-2019-19337: https://nvd.nist.gov/vuln/detail/CVE-2019-19337
+.. _CVE-2019-10222: https://nvd.nist.gov/vuln/detail/CVE-2019-10222
+.. _CVE-2019-3821: https://nvd.nist.gov/vuln/detail/CVE-2019-3821
+.. _CVE-2018-16889: https://nvd.nist.gov/vuln/detail/CVE-2018-16889
+.. _CVE-2018-16846: https://nvd.nist.gov/vuln/detail/CVE-2018-16846
+.. _CVE-2018-14662: https://nvd.nist.gov/vuln/detail/CVE-2018-14662
+.. _CVE-2018-10861: https://nvd.nist.gov/vuln/detail/CVE-2018-10861
+.. _CVE-2018-7262: https://nvd.nist.gov/vuln/detail/CVE-2018-7262
+.. _CVE-2018-1129: https://nvd.nist.gov/vuln/detail/CVE-2018-1129
+.. _CVE-2018-1128: https://nvd.nist.gov/vuln/detail/CVE-2018-1128
+.. _CVE-2017-7519: https://nvd.nist.gov/vuln/detail/CVE-2017-7519
+.. _CVE-2016-9579: https://nvd.nist.gov/vuln/detail/CVE-2016-9579
+.. _CVE-2016-8626: https://nvd.nist.gov/vuln/detail/CVE-2016-8626
+.. _CVE-2016-7031: https://nvd.nist.gov/vuln/detail/CVE-2016-7031
+.. _CVE-2016-5009: https://nvd.nist.gov/vuln/detail/CVE-2016-5009
+.. _CVE-2015-5245: https://nvd.nist.gov/vuln/detail/CVE-2015-5245
--- /dev/null
+==========
+ Security
+==========
+
+.. toctree::
+ :maxdepth: 1
+
+ Past Vulnerabilities / CVEs <cves>
+ Vulnerability Management Process <process>
+
+Reporting a vulnerability
+=========================
+
+To report a vulnerability, please send email to `security@ceph.io
+<security@ceph.io>`_.
+
+* Please do not file a public ceph tracker issue for a vulnerability.
+* We urge reporters to provide as much information as is practicable
+ (a reproducer, versions affected, fix if available, etc.), as this
+ can speed up the process considerably.
+* Please let us know to whom credit should be given and with what
+ affiliations.
+* If this issue is not yet disclosed publicly and you have any
+ disclosure date in mind, please share the same along with the
+ report.
+
+Although you are not required to, you may encrypt your message using
+the following GPG key:
+
+**6EEF26FFD4093B99: Ceph Security Team (security@ceph.io)**
+
+| **Download:** `MIT PGP Public Key Server <https://pgp.mit.edu/pks/lookup?op=vindex&search=0x6EEF26FFD4093B99>`_
+| **Fingerprint:** A527 D019 21F9 7178 C232 66C1 6EEF 26FF D409 3B99
+
+
+Supported versions
+==================
+
+Security updates are applied only to the current :ref:`active-releases`.
--- /dev/null
+Vulnerability Management Process
+================================
+
+#. The report will be acknowledged within three business days.
+#. The team will investigate the reported issue and will update the email
+ thread with relevant information. The team may ask for additional
+ information regarding the reported issue.
+#. If the team does not confirm the report, no further action will be
+ taken and the issue will be closed.
+#. If the report is confirmed by Ceph team members, a unique CVE identifier
+ will be assigned to the report and then shared with the reporter. The Ceph
+ security team will start working on a fix.
+#. If a reporter has no disclosure date in mind, a Ceph security team
+ member will coordinate a release date (CRD) with the list members
+ and share the mutually agreed disclosure date with the reporter.
+#. The vulnerability disclosure / release date is set excluding Friday and
+ holiday periods.
+#. Embargoes are preferred for Critical and High impact
+ issues. Embargo should not be held for more than 90 days from the
+ date of vulnerability confirmation, except under unusual
+ circumstances. For Low and Moderate issues with limited impact and
+ an easy workaround or where an issue that is already public, a
+ standard patch release process will be followed to fix the
+ vulnerability once CVE is assigned.
+#. Fixes for issues of "Medium" and "Low" severity will be released as part of
+ the next standard release cycle. List members will receive seven days of
+ advance notice prior to the release date of these fixes. The details of the
+ CVE fix will be included in the release notes, and the release notes will be
+ linked in the public announcement.
+#. Commits will be handled in a private repository for review and
+ testing and a new patch version will be released from this private
+ repository.
+#. If a vulnerability is unintentionally already fixed in the public
+ repository, a few days are given to downstream stakeholders/vendors
+ to prepare for updating before the public disclosure.
+#. An announcement will be made disclosing the vulnerability. The
+ fastest place to receive security announcements is via the
+ `ceph-announce@ceph.io <ceph-announce@ceph.io>`_ or
+ `oss-security@lists.openwall.com <oss-security@lists.openwall.com>`_ mailing
+ lists. (These lists are low-traffic).
+
+If the report is considered embargoed, we ask you to not disclose the
+vulnerability before it has been fixed and announced, unless you
+received a response from the Ceph security team that you can do
+so. This holds true until the public disclosure date that was agreed
+upon by the list. Thank you for improving the security of Ceph and its
+ecosystem. Your efforts and responsible disclosure are greatly
+appreciated and will be acknowledged.
======
Bluestore uses its own memory to cache data rather than relying on the
-operating system page cache. In bluestore you can adjust the amount of memory
-the OSD attempts to consume with the `osd_memory_target` configuration
-option.
+operating system's page cache. In Bluestore you can adjust the amount of memory
+that the OSD attempts to consume by changing the `osd_memory_target`
+configuration option.
- Setting the `osd_memory_target` below 2GB is typically not
- recommended (it may fail to keep the memory that low and may also cause
- extremely slow performance.
+ recommended (Ceph may fail to keep the memory consumption under 2GB and
+ this may cause extremely slow performance).
- Setting the memory target between 2GB and 4GB typically works but may result
in degraded performance: metadata may be read from disk during IO unless the
active data set is relatively small.
-- 4GB is the current default `osd_memory_target` size. This default
+- 4GB is the current default `osd_memory_target` size. This default
was chosen for typical use cases, and is intended to balance memory
- requirements and OSD performance for typical use cases.
+ requirements and OSD performance.
- Setting the `osd_memory_target` higher than 4GB can improve
- performance when there many (small) objects or large (256GB/OSD or more) data
- sets are processed.
+ performance when there many (small) objects or when large (256GB/OSD
+ or more) data sets are processed.
.. important:: OSD memory autotuning is "best effort". Although the OSD may
unmap memory to allow the kernel to reclaim it, there is no guarantee that
the kernel will actually reclaim freed memory within a specific time
- frame. This is especially true in older versions of Ceph where transparent
+ frame. This applies especially in older versions of Ceph, where transparent
huge pages can prevent the kernel from reclaiming memory that was freed from
fragmented huge pages. Modern versions of Ceph disable transparent huge
pages at the application level to avoid this, but that does not
the kernel reclaiming freed pages. That 20% value might be more or less than
needed, depending on the exact configuration of the system.
-When using the legacy FileStore backend, the page cache is used for caching
-data, so no tuning is normally needed, and the OSD memory consumption is
-generally related to the number of PGs per daemon in the system.
+When using the legacy FileStore back end, the page cache is used for caching
+data, so no tuning is normally needed. When using the legacy FileStore backend,
+the OSD memory consumption is related to the number of PGs per daemon in the
+system.
Data Storage
projects / ceph.git / commitdiff