On Tue, Jul 10, 2018 at 3:28 PM, Martin Chlumsky <martin.chlum...@gmail.com> wrote:
> It is the workaround that is right and the discussion part that is wrong. > > I am familiar with this bug. Using thin volumes *and/or* enabling zero > padding DOES ensure data contained > in a volume is actually deleted. > Great, that's super helpful. Thanks! Is there someone (Luke?) on the list that can send a correction for this OSSN to all the lists it needs to go to? // jim > > On Tue, Jul 10, 2018 at 10:41 AM Jim Rollenhagen <j...@jimrollenhagen.com> > wrote: > >> On Tue, Jul 10, 2018 at 4:20 AM, Luke Hinds <lhi...@redhat.com> wrote: >> >>> Data retained after deletion of a ScaleIO volume >>> --- >>> >>> ### Summary ### >>> Certain storage volume configurations allow newly created volumes to >>> contain previous data. This could lead to leakage of sensitive >>> information between tenants. >>> >>> ### Affected Services / Software ### >>> Cinder releases up to and including Queens with ScaleIO volumes >>> using thin volumes and zero padding. >>> >> >> According to discussion in the bug, this bug occurs with ScaleIO volumes >> using thick volumes and with zero padding disabled. >> >> If the bug is with thin volumes and zero padding, then the workaround >> seems quite wrong. :) >> >> I'm not super familiar with Cinder, so could some Cinder folks check this >> out and re-issue a more accurate OSSN, please? >> >> // jim >> >> >>> >>> ### Discussion ### >>> Using both thin volumes and zero padding does not ensure data contained >>> in a volume is actually deleted. The default volume provisioning rule is >>> set to thick so most installations are likely not affected. Operators >>> can check their configuration in `cinder.conf` or check for zero padding >>> with this command `scli --query_all`. >>> >>> #### Recommended Actions #### >>> >>> Operators can use the following two workarounds, until the release of >>> Rocky (planned 30th August 2018) which resolves the issue. >>> >>> 1. Swap to thin volumes >>> >>> 2. Ensure ScaleIO storage pools use zero-padding with: >>> >>> `scli --modify_zero_padding_policy >>> (((--protection_domain_id <ID> | >>> --protection_domain_name <NAME>) >>> --storage_pool_name <NAME>) | --storage_pool_id <ID>) >>> (--enable_zero_padding | --disable_zero_padding)` >>> >>> ### Contacts / References ### >>> Author: Nick Tait >>> This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0084 >>> Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1699573 >>> Mailing List : [Security] tag on openstack-dev@lists.openstack.org >>> OpenStack Security Project : https://launchpad.net/~openstack-ossg >>> >>> >>> ____________________________________________________________ >>> ______________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: >>> unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: >> unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
