[openstack-dev] [manila] share dismantling policies

Csaba Henk chenk at redhat.com
Thu Jul 9 13:13:29 UTC 2015


Hi Valeriy,

thanks for your comments. It is true that I took the opportunity
to ask for opinions about what would be considered good practice.

Yet my main point was -- and my fault if I missed to get it through --
to reach a definite statement about general *minimum security requirements*
for drivers wrt. data deallocation / access denial.

Your answers do not deliver a reassuring level of definiteness, so please
bear me with querying further.

----- Original Message -----
> From: "Valeriy Ponomaryov" <vponomaryov at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Thursday, July 9, 2015 11:48:20 AM
> Subject: Re: [openstack-dev] [manila] share dismantling policies
> 
> 1) There is no cases that can come in my mind when some share backend can not
> be configured (separately from Manila) to destroy data for sure, like
> filling with zeros, etc... And it is OK to make share driver do it.

I did not have too much concern whether it's OK for a share driver to
overwrite/shred(*) the data upon share deletion. The main concern here: is
there a requirement on that front? Are drivers required to destroy data contained
in a deleted share?

(*) Note that proper shredding -- to make the data unrecoverable -- might need
further processing than simply just overwrite it with zeroes.

> 2) Agree that it is a problem. But Manila has no power on users to force them
> stop using share and then unmount it. Lets assume user uses some share
> constantly as storage for his application. Manila, potentially can discover
> presence of a user of a share, but can not make user's application stop
> using this share. So, it appears that it is completely up-to the user to
> think about safety of his mounts.

Sure, Manila cannot force the users to unmount the volume, but it *can*
render the mount unusable (ending up in a state whereby all system calls
to the mount fail). That's what generic driver -- and any driver with
kNFS as export mechanism -- does (disruptive access control). However, as
we found out, a user mount with glusterfs_native will remain usable after
access to share is revoked (non-disruptive access control). So ATM there is no
uniformity in access control disruptiveness across the drivers.

If I understand your answer, your point is that this non-uniformity is something
we can live with, and we are not about to make it a driver requirement
to implement disruptive access control. Can you agree with this phrasing? 

Thanks
Csaba

> On Wed, Jul 8, 2015 at 10:38 AM, Csaba Henk < chenk at redhat.com > wrote:
> 
> 
> Hi,
> 
> I'm tossing in the term "dismantling" to indicate
> the act of making a share less available
> (deprovision (deny access to) / unmanage / delete
> it).
> 
> I find it ambiguous what is to be done with
> the share's data('s accessibility) upon
> dismantling. Wrt. the concerns to follow below,
> I have these questions:
> - what is expected?
> - what is suggested?
> - what is acceptable?
> - what do existing drivers do?
> - should we explicitly specify/
> disambiguate the answer to
> these questions (in a less
> informal place than this thread)?
> - if there are multiple
> acceptable behaviors, should
> this variance be exposed to
> the users in any way?
> 
> So the particular concerns:
> 
> 1. Upon deleting a share, should the share's data
> be shredded?
> 
> A share delete request is usually passed down to the
> storage backend as its appropriate disallocation
> method. So far so good -- the dilemma is, beyond
> this, should we take extra measures to shred
> (irrecoverably destroy) the data contained in the
> share (to protect the privacy of the former tenant)?
> (Most likely it varies from backend to backed how
> close its basic deallocation method gets to
> "irrecoverable destruction".)
> 
> 2. Should share deprovisioning be disruptive?
> 
> Let me introduce another ad-hoc term in the context
> of an authentication system -- disruptiveness of
> revoking access to some resource. The act of
> revoking access is disruptive if it takes immediate
> effect on all potential and actual accessors;
> non-distruptive if only further access attepts of
> potential accessors is affected.
> 
> So if a certain venue comes with up a dress code as
> of which shorts are not allowed, then it shall be
> non-distruptive if wearing shorts is checked only at
> the gate; while it shall be disruptive if all
> people in the venue wearing shorts will be kicked
> out immediately. In computing, UNIX file access is
> non-disruptive while NFS exporting is disruptive (at
> least Linux with knfsd it is, as I just verified).
> 
> I'm sorry to burden you with my terminological
> creativity, were there an established term for this;
> I just don't know of such.
> 
> So I hope the question makes sense now -- a tenant
> gets access to a share, mounts it, starts to use it,
> then the tenant's access gets revoked. What should
> happen to the mount?
> 
> Beyond pure disruptiveness (all further fops fail
> with EACCES) and pure non-disruptiveness (the mount
> can be used until unmounted), there is the
> unpleasant middle ground that all further fops
> will hang. While that sounds to be far from ideal,
> the question arises if it's acceptable.
> 
> 
> Regards
> Csaba
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> --
> Kind Regards
> Valeriy Ponomaryov
> www.mirantis.com
> vponomaryov at mirantis.com
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list