Re: ceph kernel client orientation

[<Michal.Plsek@seznam.cz>]

My mistake, I meant image id. Yesterday I decided to put en/decryption into rbd_queue_rq() and process data while traversing buffer_head structures. Do not worry, I am very much aware of Never Roll Out Your Own Crypto :), this is not my idea though. I am just working on someone else's idea.

Thanks for your help.

>

> Thanks for swift answer.

>

> (This is my usage in librbd.cc)

>

> Basically there is a folder with symmetric keys used for block encryption, one key for one disk in some pool. For identification of key I need (pool_id, disk_id) of block. I am temporarily saving key to librbd::ImageCtx structure, so I don't have to get it from file every time. I use this key to encrypt/decrypt block data. Encrypt/decrypt is primitive, I'm not gonna mention it here, but it is done over the data provided by functions rbd_read() and rbd_write().

>

> If you could point how to edit rbd.c content to achieve similar behaviour, I would be much obliged.



I'm not sure what exactly you mean by disk id, but I assume image

id (displayed by "rbd info" in block_name_prefix field) is probably

part of that.  It is looked up in rbd_dev_image_id(), called from

rbd_dev_image_probe().  More generally, do_rbd_add() is roughly

equivalent to rbd_open() in librbd.  Everything related to "opening"

the image is done in or under do_rbd_add().



struct rbd_device is passed pretty much everywhere, so if you are

storing a key in librbd::ImageCtx, struct rbd_device is probably

the place to put it.



As for encryption, the easiest would probably be to stick it into

__rbd_img_fill_request().  But I want to stress that bolting on

your own crypto is very error-prone and highly unlikely to produce

anything remotely secure.  Unless you are doing it to get familiar

with the codebase or just for fun, I would advise against it.



Thanks,



                Ilya