APPLIED: [PATCH 0/1][SRU F/G] Fix regression opening some files in overlayfs
Kleber Souza
kleber.souza at canonical.com
Thu Jan 7 13:19:53 UTC 2021
On 06.01.21 22:15, Seth Forshee wrote:
> BugLink: https://bugs.launchpad.net/bugs/1900141
>
> [Impact]
>
> The backports to fix CVE-2020-16120 introduced a regression for overlay
> mounts within user namespaces. Files with ownership outside of the user
> namespace can no longer be accessed, even if allowed by both DAC and
> MAC.
>
> This issue is fixed by the following upstream commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b6650dab404c701d7fe08a108b746542a934da84
>
> This commit relaxes the check to remove O_NOATIME from the open flags
> for the file in the lower filesystem when the overlay filesystem mounter
> is not privileged with respect to the underlying inode, rather than
> failing the open as happens now.
>
> [Test Case]
>
> See the lp1900141.sh script attached to the bug report. Prior to the fix
> the script will show failure to access the file from the lower
> filesystem. With the fix the file can be accessed.
>
> [Where problems could occur]
>
> For the most part this patch restores previous behavior of allowing
> access to these files while keeping the enhanced permission checks
> towards the lower filesystem to help prevent unauthorized access to file
> data in the lower filesystem. The one difference in behavior is that
> files in the lower filesystem may no longer be opened with the O_NOATIME
> flag, potentially causing atime updates for these files which were not
> happening before. If any software expects O_NOATIME behavior in this
> situation then it could cause problems for that software. However, the
> correct behavior is that only the inode owner or a process with
> CAP_FOWNER towards the inode owner is allowed to open with O_NOATIME (as
> documented in open(2)).
>
> Thanks,
> Seth
>
> ---
>
> Miklos Szeredi (1):
> ovl: do not fail because of O_NOATIME
>
> fs/overlayfs/file.c | 11 +++--------
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
Applied to focal/linux and groovy/linux.
Thanks,
Kleber
More information about the kernel-team
mailing list