Re: systemd-nspawn with filesystem id mapping

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Fr, 04.06.21 14:53, systemd-devel@xxxxxxxxxx (systemd-devel@xxxxxxxxxx) wrote:

> Hi again,
>
> after some more debugging this EOVERFLOW seems to be the result of a call to may_o_create in fs/namei.c in the kernel.
> There is a check:
>
> if (!fsuidgid_has_mapping(dir->dentry->d_sb, mnt_userns))
> 	return -EOVERFLOW;
>
> This seems to be the one returning EOVERFLOW to nspawn and resulting in the container spawn to fail.
> My guess would be that this is a systemd bug when combining filesystem id mapping with --bind.
> Before I start spending more time debugging this, has anyone so far used --bind with --private-users=pick and --private-users-ownership=map successfull?
>
> As far as I understand the pull request #19438 , didn't add any handling to the mount_bind function. Was this maybe overlooked?
> In my understanding there is a remount_idmap missing in that function well as the touch needs to be done in the correct user namespace or with mapped uid/gids.
>
> I'm new to the systemd source code, could somebody confirm that I'm on the right track there and not heading in the wrong direction?

Let's follow up on the PR, it's the better place to development
discussions on specific bugs or problems. I replied on it the other
day.


Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel