Relative TFTP path resolution

Angus Gratton angus.gratton at
Thu Nov 18 00:23:08 UTC 2010

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:

and I issue something like


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.



More information about the users mailing list