Relative TFTP path resolution

[Eric Norum]

The TFTP filesystem is quite simple-minded -- it is a 'trivial' file transfer protocol after all :-)
It was written to support simple bootstrapping applications.   Dealing with all the issues of '../' and chroot'd file systems was not handled.
You're certainly welcome to fix this, but I'd recommend moving up to NFS for applications requiring more complex remote file access.


On Nov 17, 2010, at 4:23 PM, Angus Gratton wrote:

> Using RTEMS 4.10, it looks like there's no generic filesystem support
> for relative paths that include the ".." previous directory signifier.
> 
> For instance, if my TFTP filesystem looks like:
> 
>        /
>        /dirA/
>        /dirB/
>        /dirB/file.txt
> 
> and I issue something like
> 
>        chdir("/TFTP/HOST/dirA/");
>        open("../dirB/file.txt");
> 
> then my TFTP server sees a request for "/dirA/dirB/file.txt", which is
> not what I expected.
> 
> 
> Looking in the code, it's not entirely clear whether the abstraction to
> support this should be implemented generally under
> rtems_filesystem_evaluate_path(), or be delegated to each filesystem
> type, so in this case rtems_tftp_eval_path().
> 
> At present the path with "../" prepended makes it all the way to
> tftp_eval_path, but then a custom fixPath() function strips it off.
> 
> 
> I can see a couple of ways that you could try to implement this, but
> none of them seem to fit neatly into the current design around
> rtems_filesystem_location_info_t. Which is why I thought I'd ask if
> anyone has any tips?
> 
> If possible, I'd rather not have a hack that sends my TFTP server
> "/dirA/../dirB/file.txt". In my case, atftpd (correctly) does not accept
> this kind of path, because the server doesn't run chrooted and therefore
> it's a security hole.
> 
> Does anyone have any guidance for me? Has this been improved or changed
> in more recent versions?
> 
> Thanks in advance.
> 
> Cheers,
> 
> Angus
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users

-- 
Eric Norum
wenorum at lbl.gov