Open Stack

On 07/08/2015 03:38 AM, Csaba Henk 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".)

The contract for deletion is that one a share is deleted, its data 
should never be accessible to that user/tenant or any other user/tenant 
again. This would seem to be an obvious requirement but it's actually 
violated by cinder in the case of deleting volumes on the LVM driver in 
the normal mode, and you have to turn on a slow-delete option to make 
the LVM driver meet the expected delete contract.

Note that it's not required that deleted shares are not accessible by an 
administrator. Such a requirement would be kind of silly because 
administrators can always read the contents of shares if they want to. 
So it would be acceptable to do lazy deletions of shares so long as the 
deleted shares are never accessible to any user without administrator 
intervention.

Some people are interested in secure deletion (cryptographic data 
shredding). Such a feature would be perfectly acceptable to implement 
using an optional extra spec / share type for those that want the extra 
security.


> 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.

Access deny should always result in immediate loss of access to the 
share. It's not okay for a client to continue reading/writing data to a 
share after access has been denied. The semantics for what should happen 
on the client side after access is denied are undefined and left up to 
the client. Many clients cache data and may continue to run from their 
cached copies until they find out that their access has been cut off, 
then return some application error. The important thing is that from the 
server's point of view, no writes/reads are serviced from clients 
without access.


> 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