Ceph » rbd

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.

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 :)