Re: "file:" URLs?



On 2001.08.20 13:26 Brian Stafford wrote:
> On Mon, 20 August 12:04 Toralf Lund wrote:
> 
> > > My take on this issue.  File URLs referencing localhost, explicitly
> or
> > > implicitly, in a message should be regarded as a potential security
> > > problem
> > > and disallowed.  I cannot think of any situation where such URLs are
> > > useful.
> > > 
> > > File: URLs containing an explicit host name, on the other hand, are
> > > potentially
> > > useful and passed on to a helper program.  The helper program would
> be
> > > free to
> > > choose the access method, e.g. using NFS or SMB to mount the remote
> file
> > > system mapping the path name appropriately or mapping the file: URL
> to
> > > an appropriate HTTP, FTP or TFTP action to retrieve the content of
> the
> > > file.
> > 
> > I don't agree. I think one of the premises of NFS is that the user
> > shouldn't have to worry about where a file is actually stored.
> 
> Yes but the text of RFC 1738 says "The file URL scheme is unusual in that
> it does not specify an Internet protocol or access method for such files"
> 
> Balsa cannot therefore assume that NFS is the method used to retrieve the
> file
> (nor can you enforce that assumption).
I'm not saying that it should. What I'm saying is that "localhost" access
may have it's place because the files that are local from the application's
viewpoint may actually be visible on multiple hosts, thanks to NFS (or
SMB.)

> For example if TFTP is to be
> used,
> both host name and path name are needed.

> In any case, balsa does not interpret
> the URL, the helper program does.
Exactly, but this really means that there is no good reason not to have
"highlight" code for _all_ URLs; the "dangerous" ones can (and should)
always be disabled via the handler setup.
> In the case of a file: URL helper
> program,
> it is likely to be a shell script  
or just the default web browser...
> which is free to do whatever it likes.
>  So
> if you know that NFS is in use the helper can just open the file
> referenced by
> the path protion of the URL.  As an extra check the mount point could be
> verified
> against the host name.
> 
> Remember, internet messaging has different security implications to file
> sharing.
Definitely, but like I said, addressing these issues is perhaps the
responsibility of the handler, or maybe even the MTA.
--
- Toralf






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]