Miklos Szeredi 42fea1c352 ovl: fail on invalid uid/gid mapping at copy up
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: <stable@vger.kernel.org> # v5.11
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Seth Forshee <sforshee@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-01 08:34:38 +01:00
..
2022-07-02 18:52:21 +09:00
2023-01-07 11:11:40 +01:00
2022-05-09 16:21:45 -04:00
2022-09-24 07:00:00 +02:00
2022-11-15 16:56:07 +00:00
2022-10-10 19:45:17 -07:00
2022-05-09 16:21:46 -04:00
2022-09-11 20:26:07 -07:00
2022-10-06 17:36:48 -07:00
2022-09-24 07:00:00 +02:00
2022-08-20 11:34:33 -04:00
2022-10-10 19:45:17 -07:00
2022-10-29 17:49:33 -07:00
2022-10-06 16:49:00 -07:00
2022-04-01 19:35:56 -07:00
2022-10-10 14:21:11 -07:00
2022-08-03 10:35:43 -07:00
2022-10-06 17:13:18 -07:00
2023-01-04 11:29:01 +01:00
2022-06-28 13:58:05 -04:00
2022-05-22 21:03:01 +01:00