Closed Bug 115154 Opened 19 years ago Closed 19 years ago

"Save Page As" creates directory with wrong permissions

Categories

(Core Graveyard :: File Handling, defect)

x86
Linux
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bzbarsky, Assigned: bugs)

References

Details

(Keywords: platform-parity)

Attachments

(1 file, 1 obsolete file)

Spun off bug 114874 so it will actually get some attention:

------- Additional Comment #15 From R.K.Aa 2001-12-13 02:23 -------

ummm... this works on a fresh CVS, linux.
With a somewhat unexpected result:

I saved this very page as "web page, complete.." and it landed in a new
directory called "file:" where it started to reconstruct my homedir, so files in
reality now landed in /home/dark/file:/home/dark/thisbug.html
An accompanying subdir: thisbug_files was also created and i can't cd into it
because it has wrong file permissions set:
drw-r--r--    2 dark     dark         4096 des 13 11:13 thisbug_files

It should have had the x bit set for owner of course.
Changing chmod u+x on it and cd'ing into the dir: It's empty. No images/files
were saved.





------- Additional Comment #22 From Boris Zbarsky 2001-12-13 12:38 -------

In particular:

http://lxr.mozilla.org/seamonkey/source/embedding/components/ui/progressDlg/nsProgressDlg.js#403

has:  filesFolder.create(lfIID.DIRECTORY_TYPE, 0644);

That should be a 0755 if you want to create a usable directory (like one that
you can actually write things to).  Reopening this.  As is, save page cannot
possibly work on Linux.
Severity: normal → major
Keywords: mozilla0.9.7, pp
Summary: "Save As" createes directory with wrong permissions → "Save As" creates directory with wrong permissions
side note/reminder to self: Save Link and Save Image work fine, however.
Summary: "Save As" creates directory with wrong permissions → "Save Page As" creates directory with wrong permissions
Severity: major → critical
Status: NEW → ASSIGNED
Keywords: patch, review
Attached patch better patchSplinter Review
also, only create _files folder if one does not already exist. 

We'll automatically overwrite at this stage because the file picker guards
against overwriting & the code in contentAreaUtils.js will return early if the
user chooses not to overwrite, so if we reach this point, it's a given we'll be
saving into this directory.
Attachment #61714 - Attachment is obsolete: true
Comment on attachment 61716 [details] [diff] [review]
better patch

r=bzbarsky
Attachment #61716 - Flags: review+
Just my 2 cents:
I'm not very familiar with Mozilla's low level functions, but shouldn't we let
the Mozilla process's umask decide what permission bits _not_ to set? It would
be like this:

- filesFolder.create(lfIID.DIRECTORY_TYPE, 0755);
+ filesFolder.create(lfIID.DIRECTORY_TYPE, 0777);

, because: [from Linux programmer's manual, try 'man 2 mkdir']

int mkdir(const char *pathname, mode_t mode);
DESCRIPTION
mkdir attempts to create a directory named pathname.
mode  specifies  the  permissions to use. It is modified by the process
Ahem, bugzilla seems to have hosed the rest of my comment (because of some
strange kind of single quote char that got pasted from the terminal), I'll try
again:

int mkdir(const char *pathname, mode_t mode);
DESCRIPTION
mkdir attempts to create a directory named pathname.
mode  specifies  the  permissions to use. It is modified by the process's umask
in the usual way: the permissions of the created file are (mode & ~umask).

Unless filesFolder.create() uses some non-standard ways to create directories on
the filesystem (like meddling with permissions after the call to mkdir()) or
Mozilla does strange things with its umask by the use of umask call (man 2
umask), the usual UNIX ways should be used to determine what permissons aren't
granted on those files that are created.
Blocks: 115634
Unfortunately, the average user's umask is 000.  So if we want to keep _any_ 
data semi-private we can't create it as 777
Not really, not in Mandrake Linux anyway. These lines are found in /etc/profile
(system security is set to 'medium'):

##### Handle by Mandrake Security
#if [ `id -gn` = `id -un` -a `id -u` -gt 14 ]; then
#       umask 002
#else
#       umask 022
#fi
Can any RedHatters, Slackwarers or Debianers comment on this?
As to other UNIXes and the likes, on my OpenBSD 2.9 box I can see this in
/etc/login.conf:

default:\
        :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin:\
        :umask=022:\

So I think that we can assume that umask==0 is rarely seen.
sr=hyatt
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
I think there is really no unix/linux distribution which would set the umask to
000 as default. It would be completely insane non-secure setting. If some stupid
user/admin changes that to 000 he should receive what he wants -> the directory
should be writable for anyone.
Tom Mraz: I agree. Besides, If we use relaxed file creation modes, it's
relatively easy to modify this behaviour by modifying the umask (e.g. in the
shell before  Mozilla is started, or in the mozilla startup script, or in the
profile or other rc file), but the opposite - relaxing file/directory creation
modes when they are hardcoded to, say 644/755, requires heavy wizardry and
involves changing it in the source code to Mozilla, rebuilding the whole thing etc.
Even if one is skilled enough to do this, it's to much of a hassle. So the user
is then limited to the thing that's forced upon him.
A good compromise would be to use mode 664/775 (that is, write permisson for
owner and group, no write for others). It would still be &-ded with the umask
(so it can  be overrided), but the user has the possibility to write
group-writable things by default if he/seh chooses so (e.g. some workgroup
setups would possibly use this configuration).
And in typical scenarios, UID and primary GID of a user are both unique in the
system (because adduser script by default creates a new group along with a new
user) and group writables aren't a concern.
Ben, did this make it into the 0.9.7 branch?
Blocks: 114455
a=asa (on behalf of drivers) for checkin to 0.9.7
Checked into the 0.9.7 branch.

/be
No longer blocks: 114455
yep, dir now has 755 privs. vrfy fixed, using comm bits [2002.01.07.08] on linux
rh7.2.
Status: RESOLVED → VERIFIED
Running Linux 2002010708, trying to save http://www.veronica.nl:

dexter:~/www.veronica.nl_files$ ls -l
total 4
drw-r--r--    2 erik     users        4096 Jan  8 20:19 file_1_data/
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
bryner verified this was still fixed. he says variations "could be dependent on
your umask"
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Just encountered Erik's problem myself (_data). Filed bug 120307.
vrfy fixed using 2002.01.23.08 comm bits on linux rh7.2. yay!
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.