[Buildroot] Failed to build in a user namespace without the root user

[Esben Nielsen]

Without FAKEROOTDONTTRYCHOWN it ends up in the kernel, which does a
lookup in the current user namespace and looks for uid 0 - which is
not there. Then it returns EINVAL, not EPERM.
When I set FAKEROOTDONTTRYCHOWN (from outside buildroot), I don't get that.

Hints how to reproduce:

bwrap --bind / / --uid 1000 --gid 1000 --dev /dev <make command>

bwrap 0.3.0 is compiled as user without suid bit set.

/Esben


On Tue, Apr 2, 2019 at 8:41 PM Peter Korsgaard <peter at korsgaard.com> wrote:
>
> >>>>> "Esben" == Esben Nielsen <nielsen.esben at gmail.com> writes:
>
>  > I try to build in an unpriviliged container (using bubblewrap), where
>  > I only have a single user id, not uid 0.
>
> Sounds special, but OK.
>
>  > I found the issue was in fakeroot, which per default when it does
>  > chown, it also asks the kernel if the id it does chown to actually
>  > exists. This is the default behaviour.
>
> Sorry, where do you see that? Looking at the fakeroot code, the only
> thing FAKEROOTDONTTRYCHOWN controls is if the wrapped chown also calls
> the real chown syscall:
>
> int chown(const char *path, uid_t owner, gid_t group){
> ..
>   if(!dont_try_chown())
>     r=next_lchown(path,owner,group);
>   else
>     r=0;
>   if(r&&(errno==EPERM))
>     r=0;
>
>   return r;
>
> Does lchown(path, 0, 0); return anything else than EPERM in your
> bubblewrap setup?
>
>
>  > Shouldn't it totally ignore the uid and gid map in the user namespace
>  > in the kernel?
>
> The goal is indeed that Buildroot builds do not differ based on the
> build host. We are not there yet though.
>
>
>  > Shoudln't that be default in buildroot? It is totally irrelevant,
>  > which is uids are mapped on the host when building a rootfs to run
>  > somewhere else.
>
> I have no problem with setting this environment variable the one place
> in fs/common.mk where we invoke fakeroot as there is indeed no reason to
> try to perform a chown "for real" for the Buildroot use cases, but I
> would like to understand what goes wrong exactly for you?
>
> --
> Bye, Peter Korsgaard