mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zhitao Li <>
Subject Re: narrowing task sandbox permissions
Date Fri, 15 Jun 2018 18:06:13 GMT
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
   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.


Zhitao and Jason

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message