Hash: SHA1

David wrote:
> Hi Micah,
> Your're right - this was raised before and in fact it was a feature
> Mauro Tortonesi intended to be implemented for the 1.12 release, but it
> seems to have been forgotten somewhere along the line. I wrote to the
> list in 2006 describing what I consider a compelling reason to support
> file:// <file:///>. Here is what I wrote then:
> At 03:45 PM 26/06/2006, David wrote:
> In replies to the post requesting support of the "file://" scheme,
> requests were made for someone to provide a compelling reason to want to
> do this. Perhaps the following is such a reason.
> I have a CD with HTML content (it is a CD of abstracts from a scientific
> conference), however for space reasons not all the content was included
> on the CD - there remain links to figures and diagrams on a remote web
> site. I'd like to create an archive of the complete content locally by
> having wget retrieve everything and convert the links to point to the
> retrieved material. Thus the wget functionality when retrieving the
> local files should work the same as if the files were retrieved from a
> web server (i.e. the input local file needs to be processed, both local
> and remote content retrieved, and the copies made of the local and
> remote files all need to be adjusted to now refer to the local copy
> rather than the remote content). A simple shell script that runs cp or
> rsync on local files without any further processing would not achieve
> this aim.

Fair enough. This example at least makes sense to me. I suppose it can't
hurt to provide this, so long as we document clearly that it is not a
replacement for cp or rsync, and is never intended to be (won't handle
attributes and special file properties).

However, support for file:// will introduce security issues, care is needed.

For instance, file:// should never be respected when it comes from the
web. Even on the local machine, it could be problematic to use it on
files writable by other users (as they can then craft links to download
privileged files with upgraded permissions). Perhaps files that are only
readable for root should always be skipped, or wget should require a
"--force" sort of option if the current mode can result in more
permissive settings on the downloaded file.

Perhaps it would be wise to make this a configurable option. It might
also be prudent to enable an option for file:// to be disallowed for root.


If any of you can think of additional security issues that will need
consideration, please add them in comments to the report.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Reply via email to