dnsmasq does in all cases prepend "tftp_root" to tftp-bootfiles

[Thomas Schweikle]

dnsmasq does in all cases prepend "tftp_root" to tftp-files.

tftp-root=/data/tftp
dhcp-boot=grub/i386-pc/core.0

now have some config files for different subnets:
dhcp-boot=net:172-18-1,grub/i386-pc/core.0,172.18.1.1
dhcp-boot=net:172-18-8,pxelinux.0,172.18.8.1
dhcp-boot=net:172-18-7,/var/lib/tftpboot/pxelinux.0,spacewalk-ber.bfs.de

Now booting clients within subnet 172.18.1.0/24 will boot grub with:
/data/tftp/grub/i386-pc/core.0

Booting clients within subnet 172.18.2.0/24 will boot pxelinux.0 with:
/data/tftp/pxelinux.0

And in subnet 172.18.7.0/24 clients will boot with:
/data/tftp/var/lib/tftpboot/pxelinux.0

and return a "File not found" error.

I'd expected:
172.18.1: grub/i386-pc/core.0 (file found within /data/tftp -- without exposing path)
172.18.2: pxelinux.0 (file found within /data/tftp -- without exposing path)
172.18.3: /pxelinux.0 (file found within /)
172.18.7: /var/lib/tftpboot/pxelinux.0 (file found within /var/lib/tftpboot/pxelinux.0)

or even better: some way to set tftp-root for every subnet-config and having only relative paths to access files regardless of giving absolute or relative paths.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: dnsmasq 2.79-1
ProcVersionSignature: Ubuntu 4.15.0-87.87-generic 4.15.18
Uname: Linux 4.15.0-87-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.10
Architecture: amd64
Date: Thu Feb 6 11:43:07 2020
InstallationDate: Installed on 2014-01-31 (2197 days ago)
InstallationMedia: Ubuntu-Server 13.10 "Saucy Salamander" - Release amd64 (20131016)
PackageArchitecture: all
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: dnsmasq
UpgradeStatus: Upgraded to bionic on 2018-11-23 (439 days ago)
mtime.conffile..etc.default.dnsmasq: 2014-02-19T17:19:28.429595
mtime.conffile..etc.dnsmasq.conf: 2016-08-17T12:18:41.225353

[Thomas Schweikle (tps)]

Simplest thing would be:

tftp-root

sets the tftp-root directory: /data/tftp -> /
or: /var/lib/tftpboot -> /

Whatever is done is relative to this. tftp-root is then NEVER
prepended to any file given for tftp retrival.

[Christian Ehrhardt  (paelzer)]

Hi Thomas,
as you already described yourself if you set in /etc/dnsmasq.conf
 tftp-root=/
then all paths you provide in per subnet config would work if each of them were added as absolute path.
This works as-is without any change to the package.

`tftp-root` is defined as:
--tftp-root=<directory>[,<interface>]
Look for files to transfer using TFTP relative to the given directory. When this is set, TFTP paths which include ".." are rejected, to stop clients getting outside the specified root. Absolute paths (starting with /) are allowed, but they must be within the tftp-root. If the optional interface argument is given, the directory is only used for TFTP requests via that interface.

Your example violates the "paths starting with / ... must be within the tftp-root" which is why it won't work. You could also just "not at all" set `tftp-root` as it is mostly a security feature to not serve something you'd never want to be served.

You can even do "per IP paths" in between with tftp-root + --tftp-unique-root - see the manpage for more details.

If all those config options aren't enough this is more a feature request to dnsmasq than a bug in Ubuntu. Go to [1] for that if you like to do so.

[1]: http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Christian Ehrhardt  (paelzer)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. I appreciate the quality of this bug report and I'm sure it'll be helpful to others to find this discussion if they are experiencing the same issue.

This sounds like an upstream bug to me. I have checked the latest upstream and there isn't a new option around that topic available that Ubuntu could add.

The best route to getting it fixed in Ubuntu in this case would be to file an upstream bug if you're able to do that. Otherwise, I'm not sure what we can do directly in Ubuntu to fix the problem.

If you do end up filing an upstream bug/discussion, please link to it from here. Thanks!

[Simon Kelley (simon-thekelleys)]

tftp-root is a security feature. The tftp protocol is entirely
unauthenticated, and if a request was allowed to go outside the
specified root directory, than that effectively makes all readable files
on the host available for internet-wide access, which is not generally
desirable. If you want TFTP to be able to access any file on the
machine, don't set a tftp-root.

Simon.

On 06/02/2020 11:02, Thomas Schweikle wrote:
> Public bug reported:
>
> dnsmasq does in all cases prepend "tftp_root" to tftp-files.
>
> tftp-root=/data/tftp
> dhcp-boot=grub/i386-pc/core.0
>
> now have some config files for different subnets:
> dhcp-boot=net:172-18-1,grub/i386-pc/core.0,172.18.1.1
> dhcp-boot=net:172-18-8,pxelinux.0,172.18.8.1
> dhcp-boot=net:172-18-7,/var/lib/tftpboot/pxelinux.0,spacewalk-ber.bfs.de
>
> Now booting clients within subnet 172.18.1.0/24 will boot grub with:
> /data/tftp/grub/i386-pc/core.0
>
> Booting clients within subnet 172.18.2.0/24 will boot pxelinux.0 with:
> /data/tftp/pxelinux.0
>
> And in subnet 172.18.7.0/24 clients will boot with:
> /data/tftp/var/lib/tftpboot/pxelinux.0
>
> and return a "File not found" error.
>
> I'd expected:
> 172.18.1: grub/i386-pc/core.0 (file found within /data/tftp -- without exposing path)
> 172.18.2: pxelinux.0 (file found within /data/tftp -- without exposing path)
> 172.18.3: /pxelinux.0 (file found within /)
> 172.18.7: /var/lib/tftpboot/pxelinux.0 (file found within /var/lib/tftpboot/pxelinux.0)
>
> or even better: some way to set tftp-root for every subnet-config and
> having only relative paths to access files regardless of giving absolute
> or relative paths.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 18.04
> Package: dnsmasq 2.79-1
> ProcVersionSignature: Ubuntu 4.15.0-87.87-generic 4.15.18
> Uname: Linux 4.15.0-87-generic x86_64
> ApportVersion: 2.20.9-0ubuntu7.10
> Architecture: amd64
> Date: Thu Feb 6 11:43:07 2020
> InstallationDate: Installed on 2014-01-31 (2197 days ago)
> InstallationMedia: Ubuntu-Server 13.10 "Saucy Salamander" - Release amd64 (20131016)
> PackageArchitecture: all
> ProcEnviron:
> TERM=xterm
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=de_DE.UTF-8
> SHELL=/bin/bash
> SourcePackage: dnsmasq
> UpgradeStatus: Upgraded to bionic on 2018-11-23 (439 days ago)
> mtime.conffile..etc.default.dnsmasq: 2014-02-19T17:19:28.429595
> mtime.conffile..etc.dnsmasq.conf: 2016-08-17T12:18:41.225353
>
> ** Affects: dnsmasq (Ubuntu)
> Importance: Undecided
> Status: New
>
>
> ** Tags: amd64 apport-bug bionic
>

[Thomas Schweikle (tps)]

asume following:

/
/data
/data/tftp
/data/tftp/grub
/data/tftp/pxe

tftp on some client:
tftp-root unset:
tftp grub/grub.0 -> file not found
tftp /grub/grub.0 -> file not found
tftp data/tftp/grub/grub.0 -> loads grub.
tftp /data/tftp/grub/grub.0 -> loads grub.

tftp-root=/data/tftp -- this prepends tftp-root to all paths given:
tftp grub/grub.0 -> /data/tftp/grub/grub.0 -> loads grub.
tftp /grub/grub.0 -> /data/tftp/grub/grub.0 -> loads grub
tftp data/tftp/grub/grub.0 -> /data/tftp/data/tftp/grub/grub.0 -> file not
found
tftp /data/tftp/grub/grub.0 -> /data/tftp/data/tftp/grub/grub.0 -> file not
found

This way tftp in dnsmasq exposes what directory tftp-files reside. I'd
awaited it to act if tftp-root is set as:
tftp grub/grub.0 -> grub/grub.0 -> loads grub.
tftp /grub/grub.0 -> grub/grub.0 -> loads grub
tftp data/tftp/grub/grub.0 -> data/tftp/grub/grub.0 -> file not found
tftp /data/tftp/grub/grub.0 -> /data/tftp/grub/grub.0 -> file not found

Thus meaning tftp-root acts like chroot making tftp-clients see set
tftp-root as root of the filesystem, not as forced path into a filesystem
how dnsmasq handles tftp-root makes it difficult to have further software
have correct paths to boot operating systems, because dnsmasq tftp handles
back full paths which may be never available to nfs or smb based remote
boots.

On Fri, Feb 7, 2020 at 10:25 PM Simon Kelley <email address hidden>
wrote:

> tftp-root is a security feature. The tftp protocol is entirely
> unauthenticated, and if a request was allowed to go outside the
> specified root directory, than that effectively makes all readable files
> on the host available for internet-wide access, which is not generally
> desirable. If you want TFTP to be able to access any file on the
> machine, don't set a tftp-root.
>
>
> Simon.
>
>
> On 06/02/2020 11:02, Thomas Schweikle wrote:
> > Public bug reported:
> >
> > dnsmasq does in all cases prepend "tftp_root" to tftp-files.
> >
> > tftp-root=/data/tftp
> > dhcp-boot=grub/i386-pc/core.0
> >
> > now have some config files for different subnets:
> > dhcp-boot=net:172-18-1,grub/i386-pc/core.0,172.18.1.1
> > dhcp-boot=net:172-18-8,pxelinux.0,172.18.8.1
> > dhcp-boot=net:172-18-7,/var/lib/tftpboot/pxelinux.0,spacewalk-ber.bfs.de
> >
> > Now booting clients within subnet 172.18.1.0/24 will boot grub with:
> > /data/tftp/grub/i386-pc/core.0
> >
> > Booting clients within subnet 172.18.2.0/24 will boot pxelinux.0 with:
> > /data/tftp/pxelinux.0
> >
> > And in subnet 172.18.7.0/24 clients will boot with:
> > /data/tftp/var/lib/tftpboot/pxelinux.0
> >
> > and return a "File not found" error.
> >
> > I'd expected:
> > 172.18.1: grub/i386-pc/core.0 (file found within /data/tftp --
> without exposing path)
> > 172.18.2: pxelinux.0 (file found within /data/tftp --
> without exposing path)
> > 172.18.3: /pxelinux.0 (file found within /)
> > 172.18.7: /var/lib/tftpboot/pxelinux.0 (file found within
> /var/lib/tftpboot/pxelinux.0)
> >
> > or even better: some way to set tftp-root for every subnet-config and
> > having only relative paths to access files regardless of giving absolute
> > or relative paths.
> >
> > Pr...

[Christian Ehrhardt  (paelzer)]

Changing the behavior in Ubuntu only would only break plenty of scripts automation and expectations.

I (personally) agree to Simon who also is "the upstream" on this that it is a security feature and people can still (if preferred) just not set it.

I have read the answer twice but don't really (sorry) see the pain point which is made harder by this. Feel free to convince Simon and I guess Ubuntu is happy to follow on this whatever upstream decides to do.