Currently the volume is owned by say framework user A when a CREATE is done. When a task is launched, the ownership of the volume is changed recursively to say user B, which means the root directory and all of its content has now ownership of user B. This enables user B to write into this persistent volume but as a result it changes ownership of all existing contents of persistent volume to user B as well.
I think change just changes ownership of the root directory to user B but keeps the ownership of the existing content of persistent volume to user A. This would still allow the task to write onto the persistent volume as user B (at least at root level) but not allow existing content to be deleted or overwritten that is owned by a lower privileged user. I think this would work and would restrict lower privileged user to not modify contents of higher privileged users. Thanks Anindya > On Jun 21, 2016, at 5:07 AM, Joris Van Remoortere <jo...@mesosphere.io> wrote: > > 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 >>
