I am always worried by non-intuitive magic behaviour.
It may serve some obvious purposes, but for someone else it is going
to break things.
I worry.
> bluhm@ suggested, that this should be the default behavior. Thus, the
> ftpd(8) checks if a subdirectory with the client's ip address exists and
> contains the requested file. It not, it uses the original path as
> default. I implemented it in this diff:
>
> Index: tftpd.8
> ===================================================================
> RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.8,v
> retrieving revision 1.5
> diff -u -p -r1.5 tftpd.8
> --- tftpd.8 18 Jul 2015 05:32:56 -0000 1.5
> +++ tftpd.8 19 Oct 2017 18:41:07 -0000
> @@ -78,6 +78,14 @@ and therefore this path will be ignored
> .Ox
> network bootloaders access this path to harvest entropy during
> kernel load.
> +Also,
> +.Nm
> +always tries to rewrite the requested filename with a prefix of
> +the client's IP address.
> +If the rewritten path exists
> +.Nm
> +will serve this file.
> +If not, it will serve the original filename.
> .Pp
> The options are as follows:
> .Bl -tag -width Ds
> Index: tftpd.c
> ===================================================================
> RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.c,v
> retrieving revision 1.39
> diff -u -p -r1.39 tftpd.c
> --- tftpd.c 26 May 2017 17:38:46 -0000 1.39
> +++ tftpd.c 19 Oct 2017 18:27:24 -0000
> @@ -903,8 +903,17 @@ again:
>
> if (rwmap != NULL)
> rewrite_map(client, filename);
> - else
> - tftp_open(client, filename);
> + else {
> + char nfilename[PATH_MAX];
> +
> + snprintf(nfilename, sizeof nfilename, "%s/%s",
> + getip(&client->ss), filename);
> +
> + if (access(nfilename, R_OK) == 0)
> + tftp_open(client, nfilename);
> + else
> + tftp_open(client, filename);
> + }
>
> return;
>
>
