For the case where a container drops down in privileges and still wants to create a new file, this will result in an error if it is at the root of the persistent volume right?
Is the recommended pattern then to always create a stub directory at the root of the persistent volume, and then launch any lower privileged apps underneath that? For example: / <- Root of persistent volume (Owned by framework user / root) /Database/ <- Stub directory (Owned by lower privileged user) All new files by the lower privileged app must be created under /Database/* ? It would result in an error if the App tried to create /Database-backups/ ? Only the framework as its original user would be able to do that? — *Joris Van Remoortere* Mesosphere On Tue, Jun 21, 2016 at 8:25 AM, Jie Yu <yujie....@gmail.com> wrote: > Hi folks, > > Currently, the ownership of the persistent volumes are set to be the same > as the sandbox. In the implementation, we call `chown -R` on the persistent > volume to match that of the sandbox each time before we mount it into the > container. > > Recently, we realized that this behavior is not ideal. Especially, if a > task created some files in the persistent volume, and the owner of those > file might be different than the task's user. For instance, a task is > running under root and it creates some database files under user 'database' > and launch the database process under user 'database'. When the database > process is restarted by the scheduler, the current behavior is that the > we'll do a 'chown -R root.root' on the persistent volume, causes database > files to be chown to 'root'. > > The true fix of this problem is to allow frameworks to explicit specify > owner of persistent volumes during creation. THis is captured in this > ticket: > https://issues.apache.org/jira/browse/MESOS-4893 > > In the short-term (for 1.0), I propose that, instead of doing a recursive > chown, we do a non-recursive chown. That'll allow the new task to at least > create new files under the persistent volume, but do not change ownership > of files created by previous tasks. It should be a very simple fix which we > can ship in 1.0. We'll ship MESOS-4893 after 1.0. What do you guys think? > > Thanks, > - Jie >
