Adding James directly. On Fri, Jun 15, 2018 at 11:06 AM Zhitao Li <zhitaoli...@gmail.com> wrote:
> Sorry for getting back to this really late, but we got bit by this > behavior change in our environment. > > The broken scenario we had: > > 1. We are using Aurora to launch docker containerizer based tasks on > Mesos; > 2. Most of our docker containers had some legacy behavior: *the > execution entered as "root" in the entry point script,* setup a couple > of symlinks and other preparation work, then *"de-escalate" into a non > privileged user (i.e, "user")*; > 1. This was added so that the entry point script has enough > permission to reconfigure certain side car processes (i.e, nginx) and > filesystem paths; > 3. unfortunately, the "user" user will lose access to the sandbox > after this change. > > > While I'd acknowledge that above behavior is legacy and a piece of major > tech debt, cleaning it up for the thousands of applications on our platform > was never easy. Given that our org has other useful features available in > 1.6, I would propose a couple of options: > > 1. making the sandbox permission bits configurable > 1. Certain framework knows that their tasks do not leave sensitive > data on sandbox so we could provide this flexibility (it's very useful > in > practice for migration to a container based system); > 2. Alternatively, making this possible to reconfigure on agent > flags: This could be more secure and easier to manage, but lacks > flexibility of allowing different frameworks to do different things. > 2. Until the customization is in place, consider a revert of the > permission bit change so we preserve the original behavior. > > Thanks. > > Zhitao and Jason > -- Cheers, Zhitao Li
