Subject: bin/4637 Re: tftpd oddity, PR 4637, code fix enclosed
To: Aidan Cully <aidan@kublai.com>
From: Alexis Rosen <alexis@panix.com>
List: current-users
Date: 02/03/1999 03:18:41
On Wed, Feb 03, 1999 at 01:30:19AM -0500, Aidan Cully said:
> On Fri, Jan 29, 1999 at 04:38:04PM -0500, Alexis Rosen wrote:
> > [...]
> > Reading the source made it clear: NetBSD's tftpd demands (in validate_access())
> > that "full path name must be given as we have no login directory", according
> > to a comment (line 459 of tftpd.c).
> > 
> > This turns out to be PR 4637. The fix recommended there is to search in all
> > of the paths listed in the invocation. I disagree- it should simply try to
> > use / or the / of the chroot as a default. The other alternative violates
> > the Principle of Least Surprise.
> 
> I've discussed this with Alexis a bit in private email (since I gather he
> wants me to commit the change), and I said I disagreed with him about his
> change vs. the first reccommended fix vis-a-vis "the Principle of Least
> Surprise."  Thing is, I think that the file being written to could quite
> often be different than the file being read, under his scheme.  (e.g., if
> we ran tftpd as
> /usr/libexec/tftpd /tftpboot
> and wrote a file without an absolute path, it'd go into /, but any
> relative file we read will come from /tftpboot.  (I'm pretty green to
> tftpd, so I could be completely bonkers here, but I think I follow.)
> 
> [good analysis and proposed change in function deleted]

I've thought about this some more, and while I'm happy to see either of the
proposed changes committed, since neither is as broken as the current tftpd,
I still think my proposed patch is more "correct".

As I see it, the list of directories given to the tftpd command line serves
two purposes. First, it prevents changes outside of those dirs. But equally,
it serves as a list of shortcuts, somewhat like CDPATH does in the shell.
And just as CDPATH doesn't apply to all operations, so this list shouldn't
either.

Anyway, having said that, I don't care all that much, and it would be cool
if someone other than Aidan and myself would indicate which of the two
patches is preferrable (or, I suppose, a patch for the original proposed
solution). Otherwise, I suspect Aidan and I will flip a coin to decide
what to put in. :-)

/a