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" <[email protected]> > To: "OpenStack Development Mailing List (not for usage questions)" > <[email protected]> > 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 < [email protected] > 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Kind Regards > Valeriy Ponomaryov > www.mirantis.com > [email protected] > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
