On Wed, Oct 05, 2016 at 05:45:58PM +0100, Mike Crowe wrote:
> In Message #75 2015-05-22 13:35 GMT+02:00 Ron <r...@debian.org> wrote:
> > It's not only tftp-hpa that would get burned by this. Any network
> > using service that needs to resolve or use an address would fail in
> > exactly the same way if started before your network is up. And lots
> > of them do. This isn't a new problem, you're just lucky that it's
> > the only thing that you are seeing it on.
>
> I don't believe that it's sensible for tftpd to assume that all network
> interfaces are up before it is started. We no longer live in a world of
> fixed network configurations.
Sure, but the majority of devices in that world are now phones, and
devices which won't typically host network services. And they'd stop
being very useful if the servers they relied on started roaming around
the network at random like an end-user device does.
If you have servers doing that, you have bigger problems to fix than
this. I don't think we can apply "50 million blowflies can't be wrong"
logic to this, we need to look at what is most appropriate for a server
if we're talking about what the default configuration should be.
You can't 'fix' that by just changing tftpd, there are lots of server
applications which assume or require this as part of configuring them
securely. Breaking that assumption has larger consequences than just
needing to implement netlink monitoring in them all.
> I believe that leaves daemons such as tftpd with three choices:
>
> 1. Bind to INADDR_ANY and accept connections on any network interfaces as
> they appear. Rely on firewalling to avoid unwanted connections.
>
> 2. Bind to network devices rather than addresses using SO_BINDTODEVICE.
> This isn't ideal since network devices may have multiple addresses.
>
> 3. Monitor network interfaces via netlink and bind to them as they appear.
Or leaves applications like NM with two choices to support people
running services:
1. Give them an option to block waiting on interfaces which are
expected to be up to be up, before starting services that
will be offered on them.
2. Provide hooks to (re)start or stop the services that are bound
to particular interfaces when those interfaces come or go.
And realistically, I think it must provide both those things to be
considered a functional application, regardless of what other
services do.
Don't get me wrong, I've been a huge fan of all things hotplug since
long before NM even existed, and support for that in the kernel
became widespread - but it is a Hard problem to solve well, and you
can't solve it by kicking the can down the road and saying "the rest
of you will all need figure out the problems this creates and then
rewrite your code".
See https://bugs.debian.org/816087#15
for another example of how "just let everything race" can go badly
wrong if you turn off the traffic lights at a major intersection
without paying enough attention to the consequences of that.
> The current tftpd-hpa package defaults to being available on all interfaces
> via an IPv4 address. In Message #25, Ron rightly questioned whether this is
> still a sensible default. But, as I said in Message #30, I don't believe
> that changing the default to TFTP_ADDRESS=":69" makes the situation any
> worse, and it does mean that tftpd does work correctly when no network
> interface is available at startup. Maybe if the default was changed then it
> could be turned into a debconf question?
What if it already was a debconf question ;?
The default is only used for people who don't answer that themselves
with something different.
What the default should be is mostly a balancing act between what is
sane for a relatively naive user who doesn't know what they should
answer there, and what would be right out of the box for most people
without 'special needs'. Whether it should be changed now, also adds
the question of line of least surprise for existing users, so there
is some inertia and risk there which we shouldn't ignore if changing
it now is not the clearly compelling thing to do.
I'm inclined to think that running this on a laptop is a special case.
And that changing it "because otherwise NM breaks" would be hiding a
bug in NM rather than fixing it at the real cause.
But I'm not ruling out that there might be other compelling reasons
to still change the default for this at some point. Whether that
should be to :69, or to something else, is still an open question.
Ron
