Open Stack

On Thu, Oct 23, 2014 at 3:44 PM, Preston L. Bannister <preston at bannister.us>
wrote:

>
> On Thu, Oct 23, 2014 at 7:51 AM, John Griffith <john.griffith8 at gmail.com>
> wrote:
>>
>> On Thu, Oct 23, 2014 at 8:50 AM, John Griffith <john.griffith8 at gmail.com>
>> wrote:
>>>
>>> On Thu, Oct 23, 2014 at 1:30 AM, Preston L. Bannister <
>>> preston at bannister.us> wrote:
>>>
>>>> John,
>>>>
>>>> As a (new) OpenStack developer, I just discovered the
>>>> "CINDER_SECURE_DELETE" option.
>>>>
>>>
>> OHHH... Most importantly, I almost forgot.  Welcome!!!
>>
>
> Thanks! (I think...)
>
:)

>
>
>
>
>> It doesn't suck as bad as you might have thought or some of the other
>>> respondents on this thread seem to think.  There's certainly room for
>>> improvement and growth but it hasn't been completely ignored on the Cinder
>>> side.
>>>
>>
> To be clear, I am fairly impressed with what has gone into OpenStack as a
> whole. Given the breadth, complexity, and growth ... not everything is
> going to be perfect (yet?).
>
> So ... not trying to disparage past work, but noting what does not seem
> right. (Also know I could easily be missing something.)
>
Sure, I didn't mean anything by that at all, and certainly didn't take it
that way.

>
>
>
>
>
>> The debate about whether to wipe LV's pretty much massively depends on
>>>> the intelligence of the underlying store. If the lower level storage never
>>>> returns accidental information ... explicit zeroes are not needed.
>>>>
>>>
> Yes, that is pretty much the key.
>
> Does LVM let you read physical blocks that have never been written? Or
> zero out virgin segments on read? If not, then "dd" of zeroes is a way of
> doing the right thing (if *very* expensive).
>

Yeah... so that's the crux of the issue on LVM (Thick).  It's quite
possible for a new LV to be allocated from the VG and a block from a
previous LV can be allocated.  So in essence if somebody were to sit there
in a cloud env and just create volumes and read the blocks over and over
and over they could gather some previous or other tenants data (or pieces
of it at any rate).  It's def the "right" thing to do if you're in an env
where you need some level of security between tenants.  There are other
ways to solve it of course but this is what we've got.

>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141023/dabc0534/attachment.html>