Cannot TFTP to !localhost, and finally grokked why.

[ClayJar]

I've been using a Knoppix CD to boot a workstation and configure it as a DHCP and TFTP server for use as a PXE boot server. (I use it to boot a modified copy of the Novell ZenWorks for Desktops Imaging system, which is itself a very small Linux system with their imaging program included.)

I've been using Knoppix 3.3, and it worked fine as of the 2003-11-19 ISOs. When I tried to upgrade my Knoppix CD to the 2004-02-09 ISO, I found that I had lost the ability to TFTP. I'm using the same scripts as I was using on 2003-11-19, and I see in.tftpd loaded ("in.tftpd -c -l -s /tftp"). I can TFTP to the server on localhost; that much works fine. What I cannot do any more is TFTP to anything other than localhost.

If, for example, the Knoppix workstation is currently 10.10.10.10, I can TFTP to localhost (obviously both "localhost" or 127.0.0.1 work), but I cannot TFTP to 10.10.10.10 from the local workstation nor from any other workstation. It works with 2003-11-19, but it "just doesn't work" with 2004-02-09.

The only thing I see in the changelog for 2004-02-09 is "fixed Knoppix-Terminalserver problem with new libacl"... wait a minute...

I should've known... with the new ISO, I needed to edit /etc/hosts.allow to allow tftp. A bit of source reading in /usr/sbin/knoppix-terminalserver was enough to tell me that adding a line something like "tftp in.tftpd : ALL@ALL : ALLOW" to the /etc/hosts.allow would be enough to shove it wide open (feel free to open it less wide if you're not reimaging the entire network ). I'm better now, but just in case anyone else was trying to figure this one out, I'll post this anyway.

[Harry Kuhman]

So what is the way a user deals with this if booting from CD rather than installing to a hard drive? Remastering seems like an overly complex fix for this. I'm far from even comfortable with Linux yet, but I don't understand the reason for this change. Doesn't an application have to be started to run TFTP? Unless I'm wrong about that, then the novice would be safe simply because they wouldn't start the application, so why bother to have a hosts.allow file that restricted this (anyone remastering to auto-start the service certainly could change the hosts.allow file, but why make a CD based distribution the block the utility of an application on the CD when the novice user was at no risk if they didn't run the application)?

And if by any chance TFTP or other similar application are running by default when booted, wouldn't it be better and safer to just not run them by default rather than run them by default but have a hosts.allow file that makes them rather useless.

[ClayJar]

If you're just using knoppix-terminalserver to remotely boot workstations off the running Knoppix, that script takes care of it for you. The only time you'd even possibly run into this is when you are rolling your own something or other, as I was, and then you'd just have to note that you need to change /etc/hosts.allow, which is simple enough -- just remove the symlink and replace it with your file, for example.

As far as requiring you to do this in the first place, it's almost always a good idea to place a high priority on security. If a user requires a lower level of security, it's easily enough accomplished, but being insecure by default would not be beneficial in general.

In this case, there was just a small thing I ran across that I had previously not encountered, and so, for the good of whomever may search here later, I documented it.