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.

side note/reminder to self: Save Link and Save Image work fine, however.

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.

Comment on attachment 61716 [details] [diff] [review] better patch r=bzbarsky

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.

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.

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?

a=asa (on behalf of drivers) for checkin to 0.9.7

Checked into the 0.9.7 branch. /be

yep, dir now has 755 privs. vrfy fixed, using comm bits [2002.01.07.08] on linux rh7.2.

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/

bryner verified this was still fixed. he says variations "could be dependent on your umask"

Just encountered Erik's problem myself (_data). Filed bug 120307.

vrfy fixed using 2002.01.23.08 comm bits on linux rh7.2. yay!