Re: Persistent volume ownership issue
On 21 June 2016 at 12:25, Jie Yu wrote: > James, sticky bit means that there will be no write sharing between two > users even if the underlying permission allows it. I'd prefer not having > this restriction:) No, it just prevents users renaming or deleting each others files. http://man7.org/linux/man-pages/man1/chmod.1.html If you want multiple users to be able to write to the same files, they need to create with the right ownership. >> 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). > > > Are you suggesting that we don't expose the underlying unix user directly to > frameworks. Instead, expressing permissions and ownerships using ACLs? Well that could be an option, though I'm mainly thinking out loud. With shared volumes, it seems like you really want an access control policy that applies to the volume, rather than requiring processes to collaborate at a file granularity. One way to do that would be to make the owner the creator of the volume, then use ACL inheritance to grant additional access to other users. You'd have to reflow the inheritance, but it could probably done. -- James Peach | jor...@gmail.com
Re: Persistent volume ownership issue
I created https://issues.apache.org/jira/browse/MESOS-5680 to track. Since this is no objection, we'll make sure the fix go into 1.0. - Jie On Tue, Jun 21, 2016 at 12:25 PM, Jie Yu wrote: > James, sticky bit means that there will be no write sharing between two > users even if the underlying permission allows it. I'd prefer not having > this restriction:) > > 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). > > > Are you suggesting that we don't expose the underlying unix user directly > to frameworks. Instead, expressing permissions and ownerships using ACLs? > > - Jie > > On Tue, Jun 21, 2016 at 9:00 AM, James Peach wrote: > >> 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 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 | jor...@gmail.com >> > >
Re: Persistent volume ownership issue
James, sticky bit means that there will be no write sharing between two users even if the underlying permission allows it. I'd prefer not having this restriction:) 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). Are you suggesting that we don't expose the underlying unix user directly to frameworks. Instead, expressing permissions and ownerships using ACLs? - Jie On Tue, Jun 21, 2016 at 9:00 AM, James Peach wrote: > 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 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 | jor...@gmail.com >
Re: Persistent volume ownership issue
+1 if no one is relying on the old behavior. Jiang Yan Xu On Mon, Jun 20, 2016 at 11:25 PM, Jie Yu 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 >
Re: Persistent volume ownership issue
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 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 | jor...@gmail.com
Re: Persistent volume ownership issue
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 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 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 >>
Re: Persistent volume ownership issue
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 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 >
Persistent volume ownership issue
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
