Created attachment 242821 [details]
The child process created by the attached program gets EOVERFLOW on its mkdir(2) call on its tmpfs mount with 4.8.1. With earlier versions, up to 4.7.5 at least, the mkdir(2) call would succeed as expected.
EOVERFLOW also with 4.8.4.
It seems like this "bug" (if it is a bug) is introduced with the following commit:
Author: Eric W. Biederman <firstname.lastname@example.org>
Date: Fri Jul 1 12:52:06 2016 -0500
vfs: Don't create inodes with a uid or gid unknown to the vfs
It is expected that filesystems can not represent uids and gids from
outside of their user namespace. Keep things simple by not even
trying to create filesystem nodes with non-sense uids and gids.
Acked-by: Seth Forshee <email@example.com>
Signed-off-by: "Eric W. Biederman" <firstname.lastname@example.org>
That was merged following this pull request: https://lkml.org/lkml/2016/7/26/297
Is there a use case Ludovic where you need tmpfs to handle user namespaces in this way?
I don't really have a "use case" for this. I stumbled upon this issue because one of our unit tests relies on the original behavior:
That said, mounting a tmpfs inside a user namespace doesn't seem that "exotic" to me, so I wouldn't be surprised if there's code out there that broke because of this.
Also, AIUI, mkdir(2) is not documented to return EOVERFLOW.
Thanks for your reply!
I'm investigating this further. I am however really new to kernel development, so I can't promise any progress.
Thank you for the unit test, I'll stick to the C program you provided though, but it's nice to have things in context.
I agree with you that EOVERFLOW is a "strange" error code to be returned by mkdir in this case.
So, after further investigation it turns out that this doesn't happen if there is a mapping for the uid and gid in the user namespace (/proc/pid/uid_map and /proc/pid/gid_map).
However, tmpfs is a FS_USERNS_MOUNT type filesystem so it would kind of make sense (I think?) to allow non-mappable uids and gids to be used inside tmpfs.
Some input from someone who knows more in-depth how this is supposed to work would help greatly :)
My current plan is to submit a small patch enabling tmpfs to create objects with non-mapped uids and gids and see what the response is.
Created attachment 244701 [details]
The patch that "solves" the bug. Use at your own risk.
I leave asbolutely no guarantee that this patch will not make your system insecure. Please make your own risk assessment before applying this patch.
So the right thing for testing system calls in your tests is to run the tests as a mapped user in a user namespace. Likely 0. Otherwise you are going to hit weird and strange corner cases, simply because you uid and gid are not mapped.
Weird cases like: What uid and gid does stat return?
If this failure shows up in something other than a test it will be fixed.
(In reply to Eric W. Biederman from comment #7)
> So the right thing for testing system calls in your tests is to run the
> tests as a mapped user in a user namespace. Likely 0. Otherwise you are
> going to hit weird and strange corner cases, simply because you uid and gid
> are not mapped.
> Weird cases like: What uid and gid does stat return?
> If this failure shows up in something other than a test it will be fixed.
IT returns the overflow uid/gid:
UID: 65534, GID 65534
In this case, it should indeed return an error? If yes, maybe man pages should be updated to reflect this behavior?