Documentation #12642
closedsnap_unprotect() requires access to all pools
0%
Description
Hi,
we have a setup with multiple users and pools which prevents the users from unprotecting their snapshots.
Steps to reproduce:
Create two users A and B and two pools A and B. User A can only access pool A, user B only pool B.
User A creates a RBD image in pool A and snapshots it and then protects the snapshot.
User A will never be able to unprotect (e.g. in order to delete it) this snapshot.
The problem is in snap_unprotect() in librbd/internal.cc: it loops over all existing pools to look for children and it fails once it encounters a pool that it doesn't have read access to - something that is certain to happen in any multi-tenant scenario.
This problem seems to be present in all versions.
One way to fix this would be saving to children of an image in its metadata instead of searching all pools.
But issue #4868 tells me that you probably aren't a fan of this solution.
The following mailing list post also describes this problem, but I couldn't find a bug report for it here.
https://www.mail-archive.com/ceph-users@lists.ceph.com/msg16670.html
Paul
Updated by Josh Durgin over 8 years ago
The reason we didn't store the children with the parent image is to let a user without write access to the parent pool to create clones. Instead, rbd_clone() stores the index of parents to children in a per-pool rbd_children object in the pool where it creates the clone. This way snap unprotect does not need read access to the entirety of all pools, only to the rbd_children object in each pool.
For example, a client that can clone and unprotect only in the 'volumes' pool can be created with:
ceph auth get-or-create client.cinder mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=volumes'
Is there an issue with allowing read-only access to this single object in each pool?
Keep in mind pools are not designed to map directly to end users since that approach does not scale.
Updated by Paul Emmerich over 8 years ago
Josh Durgin wrote:
The reason we didn't store the children with the parent image is to let a user without write access to the parent pool to create clones. Instead, rbd_clone() stores the index of parents to children in a per-pool rbd_children object in the pool where it creates the clone. This way snap unprotect does not need read access to the entirety of all pools, only to the rbd_children object in each pool.
That makes sense, thanks for the explanation. I also found issue #2718 which introduced the rbd_children object
Is there an issue with allowing read-only access to this single object in each pool?
That should work for us, thanks for the explanation.
The real issue here seems to be documentation.
Documents like http://ceph.com/docs/master/rados/operations/user-management/ don't explain the effects of permissions sufficiently. For example, the 'class-read' option is not really explained.
The man page of ceph-authtool uses the rbd_children Option as an example, however, without any explanation of why it is needed.
Can you maybe change this bug to 'documentation'?
Keep in mind pools are not designed to map directly to end users since that approach does not scale.
It works for us as we have few clients with relatively large amounts of data, so we don't have to create too many pools.
We are of course looking forward to better support for namespaces :)
Updated by Jason Dillaman over 8 years ago
- Tracker changed from Bug to Documentation
Updated by Jason Dillaman over 6 years ago
- Status changed from New to Resolved
Luminous documentation includes details for using the new "profile rbd" caps