[PATCH 0/1][SRU F/G] Fix regression opening some files in overlayfs
Seth Forshee
seth.forshee at canonical.com
Wed Jan 6 21:15:14 UTC 2021
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(-)
More information about the kernel-team
mailing list