CephFS authorize fails with unknown cap type

Bug #1847822 reported by Billy Olsen on 2019-10-11
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Cloud Archive
Medium
Unassigned
Queens
Medium
Unassigned
ceph (Ubuntu)
Medium
Billy Olsen

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://tracker.ceph.com/issues/39395 and subsequent pull requests.

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/ceph.client.foo.keyring --id foo -m 10.5.0.5:6789 /mnt/ceph-fs
$ 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://github.com/ceph/ceph/pull/28666

Changed in cloud-archive:
status: New → Triaged
importance: Undecided → Medium
Changed in ceph (Ubuntu):
importance: High → Medium
Billy Olsen (billy-olsen) wrote :

This appears to have been broken by commit d63fccb52241a216a08a92e615bcff008d365392 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.

Billy Olsen (billy-olsen) wrote :

I've added the regression-update tag due to this being introduced in the 12.2.12 update via the SRU process.

I've also built a package in a PPA with the latest version for testing purposes. You can find it at https://launchpad.net/~billy-olsen/+archive/ubuntu/lp1847822 and can verify that commit 9c18bd4e from the aforementioned PR fixes this.

tags: added: regression-update
Billy Olsen (billy-olsen) wrote :
description: updated

The attachment "bionic patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
tags: added: sts-sru-needed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers