From: Miklos Szeredi <[email protected]>
commit 4f11ada10d0ad3fd53e2bd67806351de63a4f9c3 upstream.
If st_uid/st_gid doesn't have a mapping in the mounter's user_ns, then
copy-up should fail, just like it would fail if the mounter task was doing
the copy using "cp -a".
There's a corner case where the "cp -a" would succeed but copy up fail: if
there's a mapping of the invalid uid/gid (65534 by default) in the user
namespace. This is because stat(2) will return this value if the mapping
doesn't exist in the current user_ns and "cp -a" will in turn be able to
create a file with this uid/gid.
This behavior would be inconsistent with POSIX ACL's, which return -1 for
invalid uid/gid which result in a failed copy.
For consistency and simplicity fail the copy of the st_uid/st_gid are
invalid.
Fixes: 459c7c565ac3 ("ovl: unprivieged mounts")
Cc: <[email protected]> # v5.11
Signed-off-by: Miklos Szeredi <[email protected]>
Reviewed-by: Christian Brauner <[email protected]>
Reviewed-by: Seth Forshee <[email protected]>
Signed-off-by: Danila Chernetsov <[email protected]>
---
fs/overlayfs/copy_up.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
index e466c58f9ec4..fd33abc0edc0 100644
--- a/fs/overlayfs/copy_up.c
+++ b/fs/overlayfs/copy_up.c
@@ -882,6 +882,10 @@ static int ovl_copy_up_one(struct dentry *parent, struct dentry *dentry,
if (err)
return err;
+ if (!kuid_has_mapping(current_user_ns(), ctx.stat.uid) ||
+ !kgid_has_mapping(current_user_ns(), ctx.stat.gid))
+ return -EOVERFLOW;
+
ctx.metacopy = ovl_need_meta_copy_up(dentry, ctx.stat.mode, flags);
if (parent) {
--
2.25.1
On Tue, May 30, 2023 at 5:44 AM Danila Chernetsov <[email protected]> wrote:
>
> From: Miklos Szeredi <[email protected]>
>
> commit 4f11ada10d0ad3fd53e2bd67806351de63a4f9c3 upstream.
>
> If st_uid/st_gid doesn't have a mapping in the mounter's user_ns, then
> copy-up should fail, just like it would fail if the mounter task was doing
> the copy using "cp -a".
>
> There's a corner case where the "cp -a" would succeed but copy up fail: if
> there's a mapping of the invalid uid/gid (65534 by default) in the user
> namespace. This is because stat(2) will return this value if the mapping
> doesn't exist in the current user_ns and "cp -a" will in turn be able to
> create a file with this uid/gid.
>
> This behavior would be inconsistent with POSIX ACL's, which return -1 for
> invalid uid/gid which result in a failed copy.
>
> For consistency and simplicity fail the copy of the st_uid/st_gid are
> invalid.
>
> Fixes: 459c7c565ac3 ("ovl: unprivieged mounts")
> Cc: <[email protected]> # v5.11
> Signed-off-by: Miklos Szeredi <[email protected]>
> Reviewed-by: Christian Brauner <[email protected]>
> Reviewed-by: Seth Forshee <[email protected]>
> Signed-off-by: Danila Chernetsov <[email protected]>
> ---
> fs/overlayfs/copy_up.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
> index e466c58f9ec4..fd33abc0edc0 100644
> --- a/fs/overlayfs/copy_up.c
> +++ b/fs/overlayfs/copy_up.c
> @@ -882,6 +882,10 @@ static int ovl_copy_up_one(struct dentry *parent, struct dentry *dentry,
> if (err)
> return err;
>
> + if (!kuid_has_mapping(current_user_ns(), ctx.stat.uid) ||
> + !kgid_has_mapping(current_user_ns(), ctx.stat.gid))
> + return -EOVERFLOW;
> +
> ctx.metacopy = ovl_need_meta_copy_up(dentry, ctx.stat.mode, flags);
>
> if (parent) {
> --
> 2.25.1
>
You are requesting to backport to kernel 5.10.y a fix to a bug that is tagged as
introduced in 5.11 with overlayfs unprivileged mounts.
IOW, in kernel 5.10, current_user_ns() would always be init_user_ns.
Am I missing something?
Thanks,
Amir.
>> From: Miklos Szeredi <[email protected]>
>>
>> commit 4f11ada10d0ad3fd53e2bd67806351de63a4f9c3 upstream.
>>
>> If st_uid/st_gid doesn't have a mapping in the mounter's user_ns, then
>> copy-up should fail, just like it would fail if the mounter task was doing
>> the copy using "cp -a".
>>
>> There's a corner case where the "cp -a" would succeed but copy up fail: if
>> there's a mapping of the invalid uid/gid (65534 by default) in the user
>> namespace. This is because stat(2) will return this value if the mapping
>> doesn't exist in the current user_ns and "cp -a" will in turn be able to
>> create a file with this uid/gid.
>>
>> This behavior would be inconsistent with POSIX ACL's, which return -1 for
>> invalid uid/gid which result in a failed copy.
>>
>> For consistency and simplicity fail the copy of the st_uid/st_gid are
>> invalid.
>>
>> Fixes: 459c7c565ac3 ("ovl: unprivieged mounts")
>> Cc: <[email protected]> # v5.11
>> Signed-off-by: Miklos Szeredi <[email protected]>
>> Reviewed-by: Christian Brauner <[email protected]>
>> Reviewed-by: Seth Forshee <[email protected]>
>> Signed-off-by: Danila Chernetsov <[email protected]>
>> ---
>> fs/overlayfs/copy_up.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
>> index e466c58f9ec4..fd33abc0edc0 100644
>> --- a/fs/overlayfs/copy_up.c
>> +++ b/fs/overlayfs/copy_up.c
>> @@ -882,6 +882,10 @@ static int ovl_copy_up_one(struct dentry *parent, struct dentry *dentry,
>> if (err)
>> return err;
>>
>> + if (!kuid_has_mapping(current_user_ns(), ctx.stat.uid) ||
>> + !kgid_has_mapping(current_user_ns(), ctx.stat.gid))
>> + return -EOVERFLOW;
>> +
>> ctx.metacopy = ovl_need_meta_copy_up(dentry, ctx.stat.mode, flags);
>>
>> if (parent) {
>> --
>> 2.25.1
>>
> You are requesting to backport to kernel 5.10.y a fix to a bug that is tagged as
> introduced in 5.11 with overlayfs unprivileged mounts.
>
> IOW, in kernel 5.10, current_user_ns() would always be init_user_ns.
>
> Am I missing something?
>
> Thanks,
> Amir.
>
Sorry for this inconvientions, really this issue was introduced in 5.11
Danila