Mailing-List: contact user-help@mesos.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@mesos.apache.org
MIME-Version: 1.0
In-Reply-To: <CAJvN1BPBd0_7XOTtpA1mJtP-VOh25QGv7-gKyv+i84p_PUHp9Q@mail.gmail.com>
References: <CAJvN1BPBd0_7XOTtpA1mJtP-VOh25QGv7-gKyv+i84p_PUHp9Q@mail.gmail.com>
From: James Peach <jorgar@gmail.com>
Date: Tue, 21 Jun 2016 09:00:52 -0700
Message-ID: <CAL52fFaRXVhdtt2pxOsBg2CSsnwwPTZCnb1QqxWTiOj13ykYpQ@mail.gmail.com>
Subject: Re: Persistent volume ownership issue
To: user@mesos.apache.org
Content-Type: text/plain; charset=UTF-8
archived-at: Tue, 21 Jun 2016 16:01:03 -0000

Non-recursive chown is an improvement over recursive chown which seems
fraught and should be avoided. For an interim fix, could you make the
volume root world writeable with the sticky bit set? Then you wouldn't
have to chown and volume users would still be able to create files.

I wonder whether ACLs are the right solution to volume ownership?
Certainly I think inherited ACLs are a good solution for expressing a
consistent access control policy over a hierarchy (at least in the
Windows/Darwin/SMB/NFSv4/RichAcl ACL model).

On 20 June 2016 at 23:25, Jie Yu <yujie.jay@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


-- 
James Peach | jorgar@gmail.com