753267 - Firefox does not honour my filename with leading "dot" when saving a file

Status: RESOLVED WONTFIX

(Firefox :: File Handling, defect)

Description

[hawran]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120423130206

Steps to reproduce:

I have tried to save a file, I've added (intentionally) a leading dot to a name.


Actual results:

A file without a leading dot has been saved.


Expected results:

Firefox should save what I want to save.
If there's a "system specific" problem (I've noticed that https://bugzilla.mozilla.org/show_bug.cgi?id=346994), it should INFORM me about it, but still it SHOULD DO what I want.

Comment 1

[Matthias Versen [:Matti]]

It looks like that bug346994 removes trailing dots.

Comment 2

[Manuela Muntean [Away]]

With the latest Nightly (build ID: 20130911030258) on Ubuntu 12.10 32bit, I get the following behavior, following next steps:

- after opening http://www.education.gov.yk.ca/pdf/pdf-test.pdf and right clicking "Save Page As..", I set the file name to be ".pdf-test.pdf" and save it to the Desktop

- the file is downloaded and I can open it, with these steps: click the "Downloads" button, and then, in the Downloads Panel, click "Open Containing Folder"

But, I don't see the file on the desktop.

Hawran, are you also experiencing this?

Comment 3

[hawran]

(In reply to Manuela Muntean [:Manuela] [QA] from comment #2)
> With the latest Nightly (build ID: 20130911030258) on Ubuntu 12.10 32bit, I
> ...
> 
> Hawran, are you also experiencing this?


Hi Manuela, sorry for the delay.
I've just tried to save the file you'd tried before with results as follows:

1. Save to Desktop: saved as pdf-test.pdf
2. Save to other directory: saved as pdf-test.pdf

Hence, for me it's STILL NOT working correctly.

As for your your case, what are your settings for "Show hidden files"?
Such files are the files with a '.' (a dot character) at the very beginning of their names.

so you should try to run the command as follows within some your favorite xterm:
ls -a ~/Desktop/
or
ls -al ~/Desktop/

to see whether the file has been saved within the directory (in case it worked OK for you and the file has been saved).

Regards,
hawran

PS my current configuration:

Name: Firefox
Version: 24.0
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0

$ lsb_release -rd
Description:    Ubuntu 13.04
Release:        13.04

Comment 4

[Manuela Muntean [Away]]

> As for your your case, what are your settings for "Show hidden files"?
> Such files are the files with a '.' (a dot character) at the very beginning
> of their names.
> 
> so you should try to run the command as follows within some your favorite
> xterm:
> ls -a ~/Desktop/

I've tried this command, and I was able to see my .pdf-test.pdf file on the Desktop, so it works for me.

Could you please try the following, to see if you still reproduce the issue :

1) try this with a clean profile: http://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

2) running in Safe mode: http://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Comment 5

[hawran]

(In reply to Manuela Muntean [:Manuela] [QA] from comment #4)
> > As for your your case, what are your settings for "Show hidden files"?
> > Such files are the files with a '.' (a dot character) at the very beginning
> > of their names.
> > 
> > so you should try to run the command as follows within some your favorite
> > xterm:
> > ls -a ~/Desktop/
> 
> I've tried this command, and I was able to see my .pdf-test.pdf file on the
> Desktop, so it works for me.
> 
> Could you please try the following, to see if you still reproduce the issue :
> 
> 1) try this with a clean profile:
> http://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-
> firefox-profiles
> 
> 2) running in Safe mode:
> http://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-
> mode

Hi Manuela,
I've just tried to save a file in Safe mode.
Still the same problem, no dot saved.

PS I've changed the name of the file after the following window had appeared:
http://imageshack.us/a/img19/7994/t9bf.png

Comment 6

[:Gijs (he/him)]

It's odd that both this and bug 1034989 exist. Paolo, can you clarify? I expect the issue in this bug is with the (GTK) filepicker.  I also think more recent versions of Firefox will be using the gtk3 filepicker and might not have this issue anymore.

hawran, I know it's been a long time, but do you still see this? If so, can you take a screenshot of the filepicker you get?

Comment 7

[:Paolo Amadini]

(In reply to :Gijs from comment #6)
> It's odd that both this and bug 1034989 exist. Paolo, can you clarify?

I'm not surprised that we have several bugs on file for similar but different issues, also considering that there may be differences between platforms. Also, we have different code paths for choosing a file based on how the download was started, and we haven't defined a consistent policy between them.

If we don't ask the user with a file picker, then the situation is clear, we should never write to a file whose name has a leading dot.

If we ask the user, we should never suggest a file name with a leading dot.

In at least some code paths, if the user changes the name, we sanitize it again and remove any leading dots. This prevents the user from manually choosing a special file name, but it's safer from a security standpoint in that we're protected in depth from the theoretical case where a round-trip through the file picker would remove some characters, leaving us potentially with a leading dot again.

It's also safer for non-technical users, to avoid creating a hidden file inadvertently. This is related to the issue originally reported in comment 0. While it's true that as a technical user hawran is aware of the meaning of the leading dot, someone else might just intuitively type a description that starts with a leading dot, and they would lose their file.

Other code paths may just use whatever name the user selected in the file picker. This other approach ensures that we don't overwrite a file accidentally, as a result of a name collision caused by the sanitization.

> I expect the issue in this bug is with the (GTK) filepicker.  I also think
> more recent versions of Firefox will be using the gtk3 filepicker and might
> not have this issue anymore.

For example I wasn't aware of issues specific to the GTK file picker, but it sounds quite possible that some file pickers would prevent the user from choosing a hidden file to save to, unless special options are provided.

Comment 8

[hawran]

(In reply to :Gijs from comment #6)
> It's odd that both this and bug 1034989 exist. Paolo, can you clarify? I
> expect the issue in this bug is with the (GTK) filepicker.  I also think
> more recent versions of Firefox will be using the gtk3 filepicker and might
> not have this issue anymore.
> 
> hawran, I know it's been a long time, but do you still see this? If so, can
> you take a screenshot of the filepicker you get?

Hi Gijs,
results of my tests are as follows:

1. https://ubuntuforums.org/showthread.php?t=2252760&p=13167270#post13167270
Save image as...
Filepicker: attached: save-image.filepicker.png
Results:
$ ls -al /tmp/.save-image* /tmp/save-image* ~/tmp/.save-image* ~/tmp/save-image* /media/xxx/shared/tmp/.save-image* /media/xxx/shared/tmp/save-image*
ls: cannot access /tmp/save-image*: No such file or directory
ls: cannot access /home/xxx/tmp/save-image*: No such file or directory
ls: cannot access /media/xxx/shared/tmp/save-image*: No such file or directory
-rw-r--r-- 1 xxx xxx 69536 Jan  7 18:47 /home/xxx/tmp/.save-image-as.png
-rw------- 1 xxx xxx 69536 Jan  7 18:48 /media/xxx/shared/tmp/.save-image-as.png
-rw-r--r-- 1 xxx xxx 69536 Jan  7 18:47 /tmp/.save-image-as.png
$


2. http://download.thinkbroadband.com/5MB.zip
Save link as...
Filepicker: attached: save-link-as.filepicker.png
Results:
$ ls -al /tmp/.save-link* /tmp/save-link* ~/tmp/.save-link* ~/tmp/save-link* /media/xxx/shared/tmp/.save-link* /media/xxx/shared/tmp/save-link*
ls: cannot access /tmp/.save-link*: No such file or directory
ls: cannot access /home/xxx/tmp/.save-link*: No such file or directory
ls: cannot access /media/xxx/shared/tmp/.save-link*: No such file or directory
-rw-r--r-- 1 xxx xxx 5242880 Jan  7 18:59 /home/xxx/tmp/save-link-as.5MB.zip
-rw------- 1 xxx xxx 5242880 Jan  7 19:00 /media/xxx/shared/tmp/save-link-as.5MB.zip
-rw-r--r-- 1 xxx xxx 5242880 Jan  7 18:57 /tmp/save-link-as.5MB.zip
$

Click on a link:
Filepicker: attached: opening-5MB.zip.file.png, enter-name-of-file-to-save.5MB.png
Results:
$ ls -al /tmp/.save-file* /tmp/save-file* ~/tmp/.save-file* ~/tmp/save-file* /media/xxx/shared/tmp/.save-file* /media/xxx/shared/tmp/save-file*
ls: cannot access /tmp/.save-file*: No such file or directory
ls: cannot access /home/xxx/tmp/.save-file*: No such file or directory
ls: cannot access /media/xxx/shared/tmp/.save-file*: No such file or directory
-rw-r--r-- 1 xxx xxx 5242880 Jan  7 19:09 /home/xxx/tmp/save-file.5MB.zip
-rw------- 1 xxx xxx 5242880 Jan  7 19:09 /media/xxx/shared/tmp/save-file.5MB.zip
-rw-r--r-- 1 xxx xxx 5242880 Jan  7 19:06 /tmp/save-file.5MB.zip
$


3. http://docstore.mik.ua/manuals/ubuntu/6.06/pdf/xubuntu/C/ desktopguide.pdf
Save linka as...
Filepicker: opening-desktop.file.file.png, enter-name-of-file-to-save.pdf.png
Results:
$ ls -al /tmp/.desktopguide* /tmp/desktopguide* ~/tmp/.desktopguide* ~/tmp/desktopguide* /media/xxx/shared/tmp/.desktopguide* /media/xxx/shared/tmp/desktopguide*
ls: cannot access /tmp/.desktopguide*: No such file or directory
ls: cannot access /home/xxx/tmp/.desktopguide*: No such file or directory
ls: cannot access /media/xxx/shared/tmp/.desktopguide*: No such file or directory
-rw-r--r-- 1 xxx xxx 1892373 Jan  7 19:23 /home/xxx/tmp/desktopguide.pdf
-rw------- 1 xxx xxx 1892373 Jan  7 19:23 /media/skodxxxap/shared/tmp/desktopguide.pdf
-rw-r--r-- 1 xxx xxx 1892373 Jan  7 19:22 /tmp/desktopguide.pdf
$

Click on a link:
Filepicker: opening-desktop.file.file.png, enter-name-of-file-to-save.click-on-pdf.png
Results:
$ ls -al /tmp/.click-on-desktopguide* /tmp/click-on-desktopguide* ~/tmp/.click-on-desktopguide* ~/tmp/click-on-desktopguide* /media/xxx/shared/tmp/.click-on-desktopguide* /media/xxx/shared/tmp/click-on-desktopguide*
ls: cannot access /tmp/.click-on-desktopguide*: No such file or directory
ls: cannot access /home/xxx/tmp/.click-on-desktopguide*: No such file or directory
ls: cannot access /media/xxx/shared/tmp/.click-on-desktopguide*: No such file or directory
-rw-r--r-- 1 xxx xxx 1892373 Jan  7 19:31 /home/xxx/tmp/click-on-desktopguide.pdf
-rw------- 1 xxx xxx 1892373 Jan  7 19:31 /media/xxx/shared/tmp/click-on-desktopguide.pdf
-rw-r--r-- 1 xxx xxx 1892373 Jan  7 19:28 /tmp/click-on-desktopguide.pdf
$


I hope it helps.

NB That .../shared/... device is a shared ntfs disk.

Comment 9

[hawran]

(In reply to :Paolo Amadini from comment #7)
> ...
> it's true that as a technical user ...

I am a technical user, I hope.

Comment 10

[hawran]

Attachment: save-link-as.filepicker.png

Comment 11

[hawran]

Attachment: save-image.filepicker.png

Comment 12

[hawran]

Attachment: opening-5MB.zip.file.png

Comment 13

[hawran]

Attachment: enter-name-of-file-to-save.5MB.png

Comment 14

[hawran]

Attachment: opening-desktop.file.file.png

Comment 15

[hawran]

Attachment: enter-name-of-file-to-save.pdf.png

Comment 16

[hawran]

Attachment: enter-name-of-file-to-save.click-on-pdf.png

Comment 17

[:Gijs (he/him)]

(In reply to :Paolo Amadini from comment #7)
> In at least some code paths, if the user changes the name, we sanitize it
> again and remove any leading dots. This prevents the user from manually
> choosing a special file name, but it's safer from a security standpoint in
> that we're protected in depth from the theoretical case where a round-trip
> through the file picker would remove some characters, leaving us potentially
> with a leading dot again.
> 
> It's also safer for non-technical users, to avoid creating a hidden file
> inadvertently. This is related to the issue originally reported in comment
> 0. While it's true that as a technical user hawran is aware of the meaning
> of the leading dot, someone else might just intuitively type a description
> that starts with a leading dot, and they would lose their file.

This makes this sound like WONTFIX, though potentially we need to 'fix' the one case hawran listed where we do save the file with leading dot?

> Other code paths may just use whatever name the user selected in the file
> picker. This other approach ensures that we don't overwrite a file
> accidentally, as a result of a name collision caused by the sanitization.

Whereas this sounds like an argument not to sanitize.

From comment #8, it seems like we aren't consistent about what we do after the user explicitly fills in the filename in the 'save as' dialog. That seems unfortunate. How would you like to proceed?

Comment 18

[:Paolo Amadini]

After thinking about this, for the security reasons in comment 7, I've made up my mind that we shouldn't allow a file with a leading dot to be saved from the file picker, even if the name is edited by the user, on all platforms including Mac, Linux, and Windows. Users who know what they're doing can rename the file after downloading with a simple terminal command.

If we discover any code path where sanitization results in overwriting a file without asking, this is clearly a bug. If the file picker asks for overwrite confirmation but we end up changing the file name to another file that already exists, adding a progressive number at the end of the file name to avoid data loss is an acceptable compromise, although there may be better solutions.

I'll triage related bugs as they're filed, keeping this logic in mind.

Comment 19

[hawran]

(In reply to :Paolo Amadini from comment #18)
> After thinking about this, for the security reasons in comment 7, I've made
> up my mind that we shouldn't allow a file with a leading dot to be saved
> from the file picker, even if the name is edited by the user, on all
> platforms including Mac, Linux, and Windows. Users who know what they're
> doing can rename the file after downloading with a simple terminal command.
> ....


So you are trying to be smarter than a user and you know more than (s)he does.
Nice.

I presume that I'm not allowed to select a directory starting with the dot (when saving a file) is another part of this "We are Firefox's developers, resistance is futile!" attitude...

Comment 20

[:Paolo Amadini]

As Firefox developers, we're making decisions about our products all the time, and we make these decisions in public with an open discussion. We take security and user experience seriously, and I don't think we should implement what you proposed in comment 0 for the reasons in comment 7.

You may disagree with the direction, but expressing this by bringing the discussion to a personal level is certainly not the right thing to do. Our Etiquette and Contributor Guidelines probably express why this is the case much better than I could, please review them before considering whether you should resume the discussion on the direction that I expressed on this bug about seven months ago.

Comment 21

[Chris Henry]

(In reply to :Paolo Amadini from comment #20)

As Firefox developers, we're making decisions about our products all the
time, and we make these decisions in public with an open discussion. We take
security and user experience seriously, and I don't think we should
implement what you proposed in comment 0 for the reasons in comment 7.

You may disagree with the direction, but expressing this by bringing the
discussion to a personal level is certainly not the right thing to do. Our
Etiquette and Contributor Guidelines probably express why this is the case
much better than I could, please review them before considering whether you
should resume the discussion on the direction that I expressed on this bug
about seven months ago.

It is inherently personal when you deliberately design a product to go out of its way to not allow me, the user, to do a thing, even if I unambiguously express that I want to do that thing (e.g., by manually inputting a name that starts with a dot in the "Save As" file picker), because you think I'm too much of a moron to be trusted to decide whether I want to do it or not.

This is absurd and disgusting. My tools should do what I tell them to, within the limitations of what they are capable of. Firefox is 100% capable of saving files under the filenames I choose. It would actually be less work for you to allow it to do that. Instead, you do the equivalent of attaching massive guard buffers at the front and rear of a saw handsaw to ensure that I can't accidentally saw my own leg, and to hell with any problems that may create with my cutting things I intend to cut. And you don't merely attach them when you offer the saw for sale, which would be ridiculous enough to begin with (is this a general-purpose tool or a child's toy!?), you weld them in place to ensure that no one can remove them, because you feel the need to protect them for themselves.

This crap is what is destroying the modern internet.