The name alias occurs because said file has shell meta characters in it,
specifically, the . Since according to the RFC, all commands from
the mailcap file are to be passed to /bin/sh, including shell
meta-characters in the filename can cause problems.
Imagine trying to open a file named such:
picture; rm -rf / .jpg
btw, filenames cannot contain slashes, at least on systems where slashes are
used as pathname separators :)
Okay... .. or ~, then. Besides, said file doesn't have to actually
exist; you just have to substitute said filename in the command.
Imagine a web browser that tries to save the file but doesn't check
whether it was successful or not before calling the command on that
file. Or an email program that tries to be too smart and will create a
picture; rm -rf directory with a .jpg file.
When it comes to security, never trust what you don't absolutely have to.
You would end up trying to erase every file on your system. Thus,
mime-support creates an alias for any files with such characters.
The first thought of an alternative would be to simply escape the
meta-characters so the shell doesn't try to interpret them.
Unfortunately, the RFC did not address this issue but did state that the
command must be run exactly as-is with the needed substitutions. Thus,
quoting meta-characters may not work in all cases
image/jpeg: xv %f would be okay
but image/jpeg: xv '%f' would be wrong
In the latter case, the \ quoting would be considered part of the
filename and said file would not be found.
Sorry, but there is no easy (or hard, for that matter) fix for this.
Best if you don't include such characters in your filenames.
I've looked at this problem and it looks that if '%s' is provided within the
mailcap file, the filename won't get substitued even if containg
metacharacters. That's probably why all of records in my current mailcap
call '%s' instead of %s which would be imho a bug in them, not in
run-mailcap.
Actually, the update-mime program that creates the mailcap file will
add quotes around the %s if not already there, just as a safety
precaution. This makes no difference to the run-mailcap tool but may
offer some additional protection to other programs that use their own,
less vigilant, code.
Always do security in layers.
I think that run-mailcap could check if the filename is provided as '%s' and
if so, not to use temporary name but provide the filename directly.
It could, but how do you _guarantee_ that it won't be interpreted by the
shell? What about a rule
image/jpeg: xv ''%s'' (pairs of single quotes)
Now the single-quotes cancel out when passed to the shell. True, a rule
like this shouldn't exist, but it illustrates the point. The mailcap
file is outside of the control of a mime-aware program and so should be
granted only limited trust.
.. It's not always possible not to use filenames, especially when accessing
remore read-only filesystems :)
That is why run-mailcap creates a temporary symlink to the oddly named
file and uses that.
Brian
( [EMAIL PROTECTED] )
---
Successful people do the things unsuccessful people don't want to do.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
