buildFHSChrootEnv requires root, possibly unnecessarily

[copumpkin]

It seems like we could have buildFHSChrootEnv work without root by using user namespaces.

[Mathnerd314]

See buildFHSUserEnv and https://nixos.org/wiki/FHS_environments.

Steam uses buildFHSUserEnv, nothing uses buildFHSChrootEnv; maybe we should just remove buildFHSChrootEnv?

[zimbatm]

It might be possible to use unshare --mount --map-root-user and then run chroot in it

[abbradar]

I've tried to implement buildFHSUserEnv in bash first before moving on to Ruby. I can't remember exact problems, but it seemed impossible to get proper user and filesystem namespace with mounts and user map using bash. It was something to do with unshare and mount and friends being separate forked processes.

[zimbatm]

buildFHSUserEnv basically does the unshare + chroot that I was talking about, not sure if the ChrootEnv is even needed anymore.
The only drawback of using ruby is that it probably leaks file descriptors (here would be a potential fix: #11602 )

[abbradar]

I've left buildFHSChrootEnv because it has somewhat different semantics -- its sandboxes persist between runs and may be entered multiple times simultaneously. I don't know if anyone has a usecase for this, though.

[abbradar]

Is this still relevant? buildFHSChrootEnv is somewhat "meant" to work as root because of its "simultaneous multiple users" usage. On the other hand, buildFHSUserEnv gained support for running as root some time ago.

[copumpkin]

Yeah, probably not. I guess I'd mostly just want a better name for it that paints the distinction better, but I don't have a real proposal for what that name should be.