You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem is mostly seen when using remote filesystems which root squash.
When the source of a path and the destination of a new path differ the clonepath function is called. It effectively calls mkdir, chown, chmod, utime, and copies regular and extended attributes. If the path already exists or partly exists it calls all the appropriate functions to clone the metadata. Overwriting what was there.
clonepath currently ignores errors from copying attributes since its common for them to be unsupported. However, all other errors are reported back.
The problem is that if root is squashed then it may not have the permissions to create or change a directory's metadata leading to errors when direct access would work fine. There is nothing that can be done on create when permissions are denied (the permissions just need to be fixed) but with changing values it might be argued that it shouldn't be done at all. It could change other's data. In practice this is less a security threat and more a quick fix for possibly out of sync permissions and therefore a nice to have.
To solve this if the directory already exists it will be left alone. If it doesn't exist then all the existing metadata copying will be attempted but permission errors will be ignored. If permission is denied at the open/create phase then that will be returned.
The problem is mostly seen when using remote filesystems which root squash.
When the source of a path and the destination of a new path differ the clonepath function is called. It effectively calls mkdir, chown, chmod, utime, and copies regular and extended attributes. If the path already exists or partly exists it calls all the appropriate functions to clone the metadata. Overwriting what was there.
clonepath currently ignores errors from copying attributes since its common for them to be unsupported. However, all other errors are reported back.
The problem is that if root is squashed then it may not have the permissions to create or change a directory's metadata leading to errors when direct access would work fine. There is nothing that can be done on create when permissions are denied (the permissions just need to be fixed) but with changing values it might be argued that it shouldn't be done at all. It could change other's data. In practice this is less a security threat and more a quick fix for possibly out of sync permissions and therefore a nice to have.
To solve this if the directory already exists it will be left alone. If it doesn't exist then all the existing metadata copying will be attempted but permission errors will be ignored. If permission is denied at the open/create phase then that will be returned.
Related to #467
The text was updated successfully, but these errors were encountered: