Description of problem: If one receives a attachement by e-mail, e.g. a PDF file and opens it, it is stored in /tmp before opened by evince. Version-Release number of selected component (if applicable): thunderbird-1.5.0.4-1.1.fc5 How reproducible: Always Steps to Reproduce: 1. open a attached file received by e-mail 2. log-in as different user 3. ll /tmp Actual results: $ LC_ALL=C ll /tmp/ total 204 -rw------- 1 peter peter 10172 Jun 26 18:05 Document.pdf Expected results: Files would be a) stored in a subdirectory in /tmp to prevent other users for scanning for filenames. Additional info: File permissions are proper. BTW: until tmpwatch removes the file, it stays in /tmp BTW2: same occurs in Firefox. Is there any config option where temporary storage path can be changed?
Still happen with current version thunderbird-1.5.0.10-1.fc6 - it would be at least a good idea to create a subdirectory in /tmp for each user before storing the attachment file.
Fedora Core 6 is no longer supported, could you please reproduce this with the updated version of the currently supported distribution (Fedora 7, 8, or Rawhide)? If this issue turns out to still be reproducible, please let us know in this bug report. If after a month's time we have not heard back from you, we will have to close this bug as CANTFIX. Setting status to NEEDINFO, and awaiting information from the reporter. [This is mass-filed message to all open Fedora Core 6 bugs related to Xorg or Gecko. If you see any other reason, why this bug shouldn't be closed, please, comment on it here.]
Still happen with thunderbird-2.0.0.9-1.fc8
If this issue turns out to still be reproduceable in the latest updates for this Fedora Core release, please file a bug report in the the upstream bugzilla located at http://bugzilla.mozilla.org in the particular component. Once you've filed your bug report to the upstream bugzilla, if you paste the new bug URL here, Red Hat will continue to track the issue in the centralized upstream bug tracker, and will review any bug fixes that become available for consideration in future updates. Setting status to NEEDINFO, and awaiting upstream bug report URL for tracking. Thanks in advance.
Already done 2007-04-16: https://bugzilla.mozilla.org/show_bug.cgi?id=377630, but looks like no one cares about?
I am really sorry, but we won't probably help you either. Currently, we are too overloaded with the more important stuff (crashes) and our own packaging problems, that we don't have free capacities to do much upstream development. Red Hat will continue to track the issue in the centralized upstream bug tracker, and will review any bug fixes that become available for consideration in future updates. Thank you for the bug report.
Still no one cares about in upstream, but I found a nice workaround (see also https://bugzilla.mozilla.org/show_bug.cgi?id=377630#c2): Create # cat /etc/profile.d/usertemp.sh if [ ! -d /tmp/temp-$USER ]; then mkdir -m 700 /tmp/temp-$USER fi export TEMP=/tmp/temp-$USER Afterwards, thunderbird and firefox are using this directory for intermediate downloads (e.g. "view"). Other users except root are no longer able to see the file names. Perhaps such should be included in the firefox/thunderbird startup script or upper shown profile.d extension added to the the initscript package.
This is not a real solution, and we cannot here duplicate upstream task. Closing as WONTFIX.