59808 - Change nsSpecialSystemDirectory::operator=(OS_TemporaryDirectory) to violate FHS

Status: NEW

(Firefox :: File Handling, enhancement, P3)

Description

[olaf]

(This is OS="generic Unix", but Bugzilla is missing that choice.)

Much of Mozilla uses a hardcoded path of /tmp for temporary files.
As demonstrated in bug 58371 and exposed about weekly on bugtraq, this is not
really a good thing. Temporary files generated by a user should be put in
a user-specific directory where they can not interfere with other users'
temporary files (or worse, get interfered with by other users).

Many applications use a TMPDIR environment variable. This is generic enough to
warrant a library routine of some sort which is called for every temporary file.
Ideally, that could do the following:
- if $TMPDIR exists, use that
- if $HOME/tmp exists, use that
- else use $HOME/.mozilla/tmp (create that if not available)
- ideally never fall back to /tmp

Really, /tmp is one of the worse ideas of Un*x. It is somewhat of a bigger
project, but should be worth the effort, to remove its usage from Mozilla.

Comment 1

[Daniel Veditz [:dveditz]]

Confirming.

Comment 2

[Peter "jag" Annema]

I would prefer just falling back to $HOME/.mozilla/$profile/$foodir/tmp first,
no $HOME/tmp. $foodir is that randomly generated dir created on new profiles.
And yes, some library call which gets you that path would rock.

Moving to component XP APPS for now (we need an architecture component or
something)

Comment 3

[sairuh (rarely reading bugmail)]

mscott, would this belong to you? if not, do reassign...thx!

Comment 4

[timeless]

Don't we already have some sort of thing in nsipath or nsifile or... egads, i 
need someone who knows all of our apis.

Comment 5

[timeless]

*** Bug 69938 has been marked as a duplicate of this bug. ***

Comment 6

[R.K.Aa.]

*** Bug 78173 has been marked as a duplicate of this bug. ***

Comment 7

[timeless]

we have this already. i can't figure out how we managed not to use it.

Comment 8

[Axel Hecht]

Hrm. Sorry, but I expect temporary junk to go in /tmp. That's the way unix
works, I don't think we should change that. If somebody sets TMP, ok, but don't
default to some whacky place somewhere in the users directory.
I would be pretty insulted to find that mozilla took all my quota just because
it didn't clear some tmp files, or my helper apps are misconfigured. That's an
insane idea. See http://www.pathname.com/fhs/, which specifies /tmp for 
temporary files, and nothing else. Especcially the cleanup of lost files is an
argument to put it at a place where standard procedures find it.

Comment 9

[timeless]

Followup, we do use the api i was looking for in nearly every case. I filed a
bug for the one instance i found that didn't.

... reporter i'm modifying the summary to (imo) more accurately describe the
request.

Personally, i'd suggest that a change like this be discussed in the newsgroups.
 If people there decide against doing this, then let it die (feel free to
maintain a patch for local use that behaves differently, although i'd just as
soon modify run-mozilla.sh to set $TMP to ~/tmp).

Comment 10

[Jamie Zawinski]

It seems to me that there is already a well-defined place for Mozilla to write
large amounts of temporary data: ~/.mozilla/*/Cache/.  All these temp files
should go there, or in subdirectories of it.  People already expect that
directory to get large, have already explicitly specified how large they want to
to get, and are already used to rm -rf'ing it when their disk fills up.

But note bug 59808 -- when you're writing a tmp file because you intend to
eventually *rename* that tmp file to its final name after it has all been
downloaded, you have to write your tmp files into the *same directory* that
you're eventually going to rename the file to.

So this only applies to, e.g., temp files handed to helper apps, not to temp
files created as an intermediary result of "Save Link As".

Comment 11

[Jamie Zawinski]

(duh, I meant bug 69938)

Comment 12

[Bo Brandt]

From http://secunia.com/advisories/36649/ (explaining why Firefox is an unpatched security risk):

>>
The security issue is caused due to the browser using a fixed path from the /tmp directory when a user opens a file downloaded for opening from the "Downloads" window. This can be exploited to trick a user into opening a file with potentially malicious content by placing it in the /tmp directory before the download takes place.

The security issue is confirmed in version 3.5.2 for Linux. Other versions may also be affected.
<<

Comment 14

[Jaap]

when I download a file I expect it to be in Downloads.
And it will half of time not be in Downloads. I did set preferences to use Downloads for downloading, but FF does not listen.

I do not want FF to decide where to put downloaded files.
This is really a very annoying bug in FF. Causes a lot of extra work.
When I download a file and it asks with what app it will be opened than FF puts it in TMP. So after editing the files disappears because FF removes files from tmp.