Re: Standardizing NO_NETWORK and USE_SYSTEM_DEPS environment variables

Simon Josefsson <[email protected]> Thu, 23 Jan 2025 20:42:25 +0100
Newsgroups dev.linux.lists.distributions
Message-ID <[email protected]>
--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Celeste Liu <[email protected]> writes:

>> 1) NO_NETWORK -- if it's set to a non-empty value, it requests that
>> programs don't access the (TCP/IP) network.
>=20
> It may be better to be named NO_INTERNET. Network is a confusing word in =
Linux=20
> world. They can refer to something from only Internet to any protocols in=
=20
> network subsystem, even include AF_NETLINK... I have been asked why my ud=
ev is=20
> broken when my program is in a netns many times. Systemd also have to inf=
orm=20
> this point in their document of PrivateNetwork. So use more limited word=
=20
> Internet to avoid this.

You are right.  While my initial reaction to NO_NETWORK was positive, I
have realized that there are subtle issues that is really hard to
resolve.  I considered adding support for NO_NETWORK to GNU InetUtils
but I am beginning to feel that even NO_NETWORK has the same critical
concerns that USE_SYSTEM_DEPS has: What exactly should NO_NETWORK mean
to a package?  What can it assume and what MUST it fail on?

=2D Can it use localhost IP connectivity?

=2D TCP?

=2D Multicast?

=2D Can it rely on non-DNS /etc/hosts name resolution working?

=2D Can it rely on /etc/services being able to lookup network service
  names?

=2D Is it allowed to inspect routing table on the system?

etc

Disabling all of those functionality when NO_NETWORK is probably not
what was intended, right?

When doing self-checks for 'ftp' and 'ftpd' it makes sense to start your
newly built ftpd and test interop it against your newly built ftp
binary.  I don't think the intention is to forbid this.

/Simon

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmeSm6EUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJl/YgIBQkLehFUAAoJENc89jjFPAa+CboA
+wUa06RD5e5VTCxvSWtPS75Wq2qBeYGZnf0jvUMxa2n4AP4xkUeAPPnNuMsTm2fs
FCDIGaEM2Yn6Vb2huzzT1Fw/BLgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCZf2IKwUJC3oQqgCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+GcYA/26YQY05bLtnXiIjTiAzrGQrRXxTHPA8Av7TDFHvIetWAP9s
HSoU8OfTwmTiEnGwLlsV7QJclZg3YNz/Ypcp9TqQBrg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJl/YgwBQkLehDGAAoJENc89jjF
PAa+phoA/jrDqIrl/55vUMBhIQv+TP635d2iCTEnyFmbUcP9+gh6APoDsXalVd2c
OGxQtSC+TF8PkZMn1TLkJKAjVxr+xx40AgAKCRBRcisI/kdForTrAP93Z/L+Zfi/
CZVezQYY42lcFt8B76Z3aAJJWba4xoEsigD/ec9ltxS0FyjmfpYnp5833/Loy88J
dr6gKEojtuezkQY=
=b+Fo
-----END PGP SIGNATURE-----
--=-=-=--