CephFS authorize fails with unknown cap type
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu Cloud Archive |
Fix Released
|
Medium
|
Unassigned | ||
Queens |
Fix Released
|
Medium
|
Unassigned | ||
ceph (Ubuntu) |
Fix Released
|
Medium
|
Billy Olsen | ||
Bionic |
Fix Released
|
Medium
|
Unassigned |
Bug Description
[Impact]
Attempting to provide access to a user within Ceph to a specific mount path fails with unknown cap type. This appears to be due to the monitor not knowing how to validate the caps that are provided with the mount path per upstream bug https:/
This is fixed in Mimic (13.1.0+) and included in the current Luminous devel release (upcoming 12.2.13).
[Test Case]
Steps to recreate:
1. Install ceph w/ ceph-fs.
2. Mount ceph filesystem and create subdirectory for restricting access
$ ceph-fuse -k /etc/ceph/
$ mkdir /mnt/ceph-fs/bar
3. Authorize access for ceph user to rw a directory
$ ceph fs authorize ceph-fs client.foo /bar rw
Expected Results:
The authorize command to succeed
Actual Results:
Error EINVAL: unknown cap type '/bar'
[Regression Potential]
Regression potential is low as this has already been fixed upstream and has seen additional testing without additional problem reports from the change. The change does affect the validation of capabilities, so if a problem were to arise it would likely be in the verification of capabilities when the code is parsing.
[Other Info]
Upstream pull-request: https:/
Changed in cloud-archive: | |
status: | New → Triaged |
importance: | Undecided → Medium |
Changed in ceph (Ubuntu): | |
importance: | High → Medium |
tags: | added: sts-sru-needed |
Changed in cloud-archive: | |
status: | Triaged → Fix Released |
Changed in ceph (Ubuntu): | |
status: | Triaged → Fix Released |
Changed in ceph (Ubuntu Bionic): | |
status: | New → Triaged |
importance: | Undecided → Medium |
tags: |
added: verification-needed removed: verification-done |
This appears to have been broken by commit d63fccb52241a21 6a08a92e615bcff 008d365392 which added a validation for all of the capabilities in this code path. The fs authorize command works by adding a new capability keyed by the path. This capability with the path key was not understood by the standard capability check method being invoked so it returned False to indicate the capabilities are not valid, which results in an EINVAL value.
The patch included in the pull request fixes this by changing to only check the mds and osd capabilities instead of the full set.