Closed Bug 76463 Opened 23 years ago Closed 23 years ago

formpost files should use 600, not 666, for permissions

Categories

(Core :: DOM: Core & HTML, defect, P1)

x86
Linux
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.7

People

(Reporter: j, Assigned: bzbarsky)

References

()

Details

(Keywords: privacy)

Attachments

(1 file, 1 obsolete file)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-ac9 i686; en-US; 0.8.1) Gecko/20010412
BuildID:    2001041214

When a file is uploaded through a form, Mozilla creates a /tmp/formpost file (or
formpost-xxx to avoid overwriting) .
This file is created with the 666^~umask perms. On most distros, the standard
umask is 022, therefore, /tmp/formpost* files are world readable. As they can
hold private content, this is an insecure behavior.

Reproducible: Always
Steps to Reproduce:
1.Upload a file through a form
2.Read /tmp/formpost

Actual Results:  Any user can read the posted data.

Expected Results:  Permissions should be enforced to 600
This is technically a dup of bug 15320.  But that bug has recently gotten
futured, so the correct solution (not creating temp files) is not going to
happen anytime soon.

confirming this bug as a request to just change the file permissions.  In that
form, nominating for beta1 and mozilla0.9.1 as a major security hole.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Uploading a file exposes its content to other users → formpost files should use 600, not 666, for permissions
reassigning, known issue, probably a dup
Assignee: rods → pollmann
Unfutured the other bug.  Marking this a dup.  Time to clean this up...

*** This bug has been marked as a duplicate of 15320 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
ok, verifying
Status: RESOLVED → VERIFIED
Reopening since this is a much more serious issue than bug 15320 and that bug is
nowhere close to being fixed.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
taking 
Assignee: pollmann → darin
Status: REOPENED → NEW
Priority: -- → P1
Target Milestone: --- → mozilla0.9.7
Attached patch Proposed patch (obsolete) — Splinter Review
this patch looks good, except it might be really nice to take this time to
switch over to using nsIFile instead of nsFileSpec (since you are switching from
nsIFileSpec to nsFileSpec... might as well do the right thing and switch to
nsIFile).
I was trying to, actually, but I see no way to do the equivalent of MakeUnique()
with nsIFile.  I suppose I could roll my own....  would that be better than
using nsFileSpec for this functionality?
-> bz, pointed him to nsIFile::CreateUnique... he's going to work on a new patch
that uses nsIFile :)
Assignee: darin → bzbarsky
CreateUnique is a bastard child that doesn't do what you'd expect it to... But
if you treat it right, it _can_ do the right thing.  :)
Attachment #59911 - Attachment is obsolete: true
Alexandru, would you review?
Keywords: patch, review
Comment on attachment 59981 [details] [diff] [review]
Patch using nsIFile

sr=darin

BTW it's valid to write NS_ADDREF(*aMultipartDataFile = tempDir)... NS_ADDREF
actually corresponds to an inline function :)
Attachment #59981 - Flags: superreview+
Comment on attachment 59981 [details] [diff] [review]
Patch using nsIFile

r= alexsavulov

OPTIONAL:
could we use everywhere nsIFile and get rid of nsIFileSpec usage?
Attachment #59981 - Flags: review+
Yes, but that's a separate bug... :)
checked in
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
no more temp files on linux.. verifying
Status: RESOLVED → VERIFIED
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: