Bug 196707 - attachment filename information disclosure in /tmp
attachment filename information disclosure in /tmp
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: thunderbird (Show other bugs)
8
All Linux
medium Severity medium
: ---
: ---
Assigned To: Gecko Maintainer
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-26 12:03 EDT by Peter Bieringer
Modified: 2008-03-20 17:19 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-20 17:04:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 377630 None None None Never

  None (edit)
Description Peter Bieringer 2006-06-26 12:03:26 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):
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?
Comment 1 Peter Bieringer 2007-04-11 10:01:19 EDT
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.
Comment 2 Matěj Cepl 2007-12-10 04:22:42 EST
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.]
Comment 3 Peter Bieringer 2007-12-10 14:38:41 EST
Still happen with thunderbird-2.0.0.9-1.fc8
Comment 4 Matěj Cepl 2007-12-10 15:10:20 EST
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.
Comment 5 Peter Bieringer 2007-12-10 15:46:06 EST
Already done 2007-04-16: https://bugzilla.mozilla.org/show_bug.cgi?id=377630,
but looks like no one cares about?
Comment 6 Matěj Cepl 2007-12-10 16:44:04 EST
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.
Comment 7 Peter Bieringer 2008-03-20 15:10:58 EDT
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.
Comment 8 Matěj Cepl 2008-03-20 17:04:42 EDT
This is not a real solution, and we cannot here duplicate upstream task.

Closing as WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.