warden/DEAs keeps container file systems for a configured amount of time,
something like 1 hr before removing the containers, i believe with standard
removal tools.
diego cells and garden removes container file system immediately after they
are stopped by the user or the system. when using docker images, the
container images are cached in the garden graph directory and i'm not quite
sure of their cleanup / garbage collection life cycle.
On Wed, Aug 19, 2015 at 1:08 AM, Chris K <christopherkugler2(a)yahoo.de>
wrote:
Hi,
I have a few questions regarding the way data is removed when an
application is removed and its corresponding warden container is destroyed.
As the Cloud Foundry instance my company is using may be shared with
multiple tenants, this is a very critical question for us to be answered.
From Cloud Foundry's GitHub repository I gathered the following
information regarding the destruction process:
"When a container is destroyed -- either per user request, or
automatically after being idle -- Warden first kills all unprivileged
processes running inside the container. These processes first receive a
TERM signal followed by a KILL if they haven't exited after a couple of
seconds. When these processes have terminated, the root of the container's
process tree is sent a KILL . Once all resources the container used have
been released, its files are removed and it is considered destroyed."
(Quote: https://github.com/cloudfoundry/warden/tree/master/warden)
According to this quote all files of the file system are removed before
the resources can be used again. But how are they removed? Are they
securely wiped, meaning all blocks are set to zero (or randomized)? And how
is data removed from the RAM before it can be assigned to a new warden
(i.e. new application).
In case the data is not being securely wiped, how much access does an
application have towards the available memory? Is it for example possible
to create files of arbitrary size and read / access them?
I'd be thankful for any kind of hints on this topic.
With Regards,
Chris
--
Thank you,
James Bayer
