We're wary of adding too many knobs to the platform and exposing them

all the way down to app developers increases the cognitive load for folks
using the platform. Enabling/disabling it on a per-installation level, and
- maybe - a per-space level, might be a decent compromise?

Agreed. I'd argue this this probably not be a 'per-app' thing, as I too
amy way of the knobs that developers like to turn. I think a per space
level is just the right level.

On Wed, Jul 29, 2015 at 10:20 AM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:

That's still very much open for discussion. Obviously, someone with
administrative privileges should be in charge of this particular piece of
configuration.

Also making this a runtime config (e.g. feature flag) as opposed to a
deploy-time config (e.g. part of the CC config written out by BOSH) would
make the different behaviors more testable.

Thoughts? Preferences? We're wary of adding too many knobs to the
platform and exposing them all the way down to app developers increases the
cognitive load for folks using the platform. Enabling/disabling it on a
per-installation level, and - maybe - a per-space level, might be a decent
compromise?

Onsi



On Wed, Jul 29, 2015 at 9:54 AM, Matt Cowger <matt(a)cowger.us> wrote:

Once - configurable on a per-app, per space, or per deployment basis?

On Wed, Jul 29, 2015 at 9:50 AM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:

Hey all,

Based on the feedback we got and the relatively low cost to maintain
privileged support we'd like to propose making running privileged
containers on the platform configurable - we will recommend this be turned
off when running untrusted workloads and it will likely default to off. We
have longer term plans to support mounting persistent volumes in Diego at
which point support for mounting FUSE in unprivileged containers can become
a reality.

Thoughts?

Onsi

On Mon, Jul 13, 2015 at 4:42 AM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

On Mon, Jul 13, 2015 at 2:48 AM, Lerenc, Vedran <vedran.lerenc(a)sap.com

wrote:

Hi Onsi,



Ø Thoughts? Concerns?



Well, that’s bad news.



We, and I assume many others as well (like the folks from Stackato
who do it in the public), have used SSHFS + FUSE to implement a persistent
file system for old-fashioned apps/apps that are not Cloud-native. I don’t
want to fight an ideological battle here, it’s just that these apps do
still exist (in majority) and a file system service is an important
service/feature for them.



So if you remove FUSE (which we thought is not going away/was added
to stay), it’s pretty bad for us/many apps.



Best regards, Vedran

+1 - It would be sad to see FUSE support go away. It's been very
helpful for running apps that depend on a persistent FS, like Wordpress.
Perhaps this use case of mounting a remote SSHFS could be supported in some
other way?

Dan

*From: *Onsi Fakhouri
*Reply-To: *"Discussions about Cloud Foundry projects and the system
overall."
*Date: *Saturday 11 July 2015 01:10
*To: *cf-dev
*Subject: *[cf-dev] Removing FUSE support from CF



Hey CF-Dev,



The Garden team has been hard at work substantially improving
Garden-Linux's security features. Garden-Linux now employs user namespaces
and drops capabilities when creating unprivileged containers - we're
excited to bring both of these features to the platform!



Diego currently runs applications in *privileged* containers. These
lack the security features outlined above and we are planning on switching
to launch all CF applications in *unprivileged* containers.



Unfortunately, it has proved difficult to support
mounting FUSE filesystems from within unprivileged containers. We believe
the security benefits outweigh the features that FUSE give us and* are
planning on removing support for FUSE in favor of better securing our
containers.* If/when FUSE support in unprivileged containers
becomes possible we may add it back to the platform.



Thoughts? Concerns?



Thanks!



Onsi

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
-- Matt

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
-- Matt

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev