Nix: Expose `/etc/nsswitch.conf` and `/etc/protocols` etc to sandboxed nix builds?

[bennofs]

Right now, the following derivation fails in the nix sandbox:

with (import <nixpkgs> { config = {}; });

stdenv.mkDerivation {
  name = "networking";
  buildCommand = ''
    ${strace}/bin/strace getent protocols tcp > $out
  '';
}

This means that even packages that run their own server on localhost for testing fail, because getprotobyname fails.

[bennofs]

See alephcloud/hs-configuration-tools#40 for a package affected by this

[copumpkin]

Seems reasonable to me. Would need to switch on host system since these don't exist on Darwin.

My inclination would be to have them contain super boring predefined values that Nix defines somewhere, rather than passing through the host. That improves determinism, and we likely don't need anything fancy someone might have added to nsswitch.conf (which even supports loadable libraries!) inside a test that wants to hit localhost.

[domenkozar]

+1, just being able to do reverse dns on /etc/hosts would be a good start for some tests. Essentially the only reverse lookup possible would be for 127.0.0.1

[domenkozar]

If I understand correctly this needs hosts: files entry for /etc/nsswitch.conf besides https://github.com/NixOS/nix/blob/master/src/libstore/build.cc#L1990

This is for my use case: reverse dns. For this issue specifically probably other services as well.

[bennofs]

@domenkozar yes, and we should probably also use files for the other databases, like protocols and services.

[bennofs]

(And add /etc/protocols + /etc/services)

[edolstra]

I think this can already be done using --sandbox-paths /etc/protocols:....

[copumpkin]

What I was proposing was for them to be dummy files though, much like how /etc/passwd doesn't actually contain real passwd entries but is populated in build.cc.

[edolstra]

Yes, but especially for /etc/services it's not clear what the dummy contents should be.

[bennofs]

@edolstra is there no standard /etc/services? Just use the IANA standard?

The fact that there is no standard even increases the need to put a dummy into the build env for determinism.

[Mic92]

On Linux I currently use libredirect as a workaround to bring /etc/protocols into scope: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/python-modules/celery/default.nix#L32

[jonringer]

Just ran into another use case where this would have been incredibly helpful to have an /etc/protocols for the pythonPackages.eventlet package, which references it for the socket.getprotobyname('tcp') python command. (similar to @Mic92's example)