build: Add --network option

[KyleFromKitware]

This option allows builds to have network access inside the chroot.

[Conan-Kudo]

I don't think this is a good idea. This makes it difficult to have custom resolv.conf in the environment, and may result in broken setups if the host resolv.conf is not a real file.

[Conan-Kudo]

In addition, I want resolv.conf to not be present by default in chroot environments. I use chroot environments and intentionally add a small bit of friction to make it so internet access works.

In general, package builds should not have internet access, and overriding this behavior should be exceptional, not normal.

[adrianschroeter]

this is an incompatible change and reproducible builds must work without external resources. So we won't merge it that way.

However, we could offer this optional via an additional parameter, similar to --vm-net.

[KyleFromKitware]

Lack of /etc/resolv.conf does not completely block internet access, only DNS resolution (which is admittedly a big part of it.) Programs inside the chroot can still connect directly to IP addresses. If you want to truly block internet access, you need to take away their socket privileges.

However, we could offer this optional via an additional parameter, similar to --vm-net.

I agree this might be better. What do you think the name should be?

[adrianschroeter]

On Dienstag, 24. März 2020, 15:20:35 CET wrote Kyle Edwards:

Lack of `/etc/resolv.conf` does not completely block internet access, only DNS resolution (which is admittedly a big part of it.) Programs inside the chroot can still connect directly to IP addresses. If you want to truly block internet access, you need to take away their socket privileges.

there are indeed shortcommings in chroot mode, but this is no excuse ;)

> However, we could offer this optional via an additional parameter, similar to --vm-net. I agree this might be better. What do you think the name should be?

Ideally --network ... but it should also work with other modes like kvm in that case.

…

-- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany

[KyleFromKitware]

Ideally --network ... but it should also work with other modes like kvm in that case.

I thought about this, but VMs would be tricky to support, especially if the host is using dnsmasq or systemd-resolved. Those both point /etc/resolv.conf to 127.0.0.1, which would not have the same meaning inside the VM. Perhaps we could say that --network support is limited to chroot for now?

[adrianschroeter]

On Dienstag, 24. März 2020, 15:30:20 CET wrote Kyle Edwards:

> Ideally --network ... but it should also work with other modes like kvm in that case. I thought about this, but VMs would be tricky to support, especially if the host is using `dnsmasq` or `systemd-resolved`. Those both point `/etc/resolv.conf` to `127.0.0.1`, which would not have the same meaning inside the VM. Perhaps we could say that `--network` support is limited to chroot for now?

KVM has already support via --vm-net ... it gets an own device and gets an own IP via dhcp usualy. IMHO you should use KVM esp together with network mode, because you don't really know what kind of code get downloaded and executed. (Except it is your own code)

…

-- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany

[KyleFromKitware]

IMHO you should use KVM esp together with network mode, because you don't really know
what kind of code get downloaded and executed. (Except it is your own code)

In my case, yes, the code is trusted. I also fear that using KVM would have a performance penalty (though probably not as much as outright emulation.)

[Conan-Kudo]

IMHO you should use KVM esp together with network mode, because you don't really know
what kind of code get downloaded and executed. (Except it is your own code)

In my case, yes, the code is trusted. I also fear that using KVM would have a performance penalty (though probably not as much as outright emulation.)

There's not much of a performance penalty. You certainly won't notice it in package builds beyond the additional ~3-5 seconds to boot up the VM.

[KyleFromKitware]

We're getting a little off topic here. Let's take this back to the email thread, and I'll leave this open until I reach a verdict.

[KyleFromKitware]

I have attempted to use KVM and have not had much success. I will go back to attempting to add a --network option to chroot.

[KyleFromKitware]

OK, this change now conditionally copies /etc/resolv.conf from the root if --network is specified.

[adrianschroeter]

there is meanwhile a --vm-network switch, so closing this one.

[KyleFromKitware]

What's the status on this? Are we still expected to use KVM for network support? I never did manage to get KVM to work in my setup.