Red Hat Bugzilla – Bug 196707
attachment filename information disclosure in /tmp
Last modified: 2018-04-11 14:29:15 EDT
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):
Steps to Reproduce:
1. open a attached file received by e-mail
2. log-in as different user
3. ll /tmp
$ LC_ALL=C ll /tmp/
-rw------- 1 peter peter 10172 Jun 26 18:05 Document.pdf
Files would be
a) stored in a subdirectory in /tmp to prevent other users for scanning for
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-184.108.40.206-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-220.127.116.11-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
# cat /etc/profile.d/usertemp.sh
if [ ! -d /tmp/temp-$USER ]; then
mkdir -m 700 /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
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.