Re: Standardizing NO_NETWORK and USE_SYSTEM_DEPS environment variables

[Simon Josefsson <simon@josefsson.org>]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

Celeste Liu <uwu@coelacanthus.name> writes:

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

- Can it use localhost IP connectivity?

- TCP?

- Multicast?

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

- Can it rely on /etc/services being able to lookup network service
  names?

- 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1251 bytes --]