Saving certain sites (theregister.co.uk, news.bbc.co.uk), Mozilla is creating a foo_data directory inside the _files directory. It's always empty. Worse, the permissions are wrong, making it difficult to delete: % ls -ld theregister.co.uk_files/regindex_data drw-r--r-- 2 mozilla mozilla 4096 Jan 16 09:49 theregister.co.uk_files/regindex_data 644, but should be 755. As complete is the default save mode, this should be fixed for 0.9.8.

->Ben. This is with 2002011606 (after his checkins).

Looks like a dupe of bug 120118 (which is fixed).

Adam--shouldn't we use 0775 instead of 0664 when creating the directory? I think we should reassign this bug to Adam.

Why is it creating the directories in the first place? They're empty.

I'll take the bug, but I need advice on the best and most secure working permission to use. Is 0775 the best to use - thats ug+rwx & o+x isn't it? I have noticed that subframes on Linux seem to have a problem which is probably due to the dir missing the +x bit.

Adam: 1) Third time (counting the implicit question in the original description): why is this directory being created at all? 2) If it does have a purpose, the correct permissions are: 0777 & ~UMASK No offense, but I'm somewhat concerned Netscape has you in charge of UNIX file issues, if you're suggesting to create a directory mode 0775. If this directory does need to be created, perhaps someone more familiar with UNIX file handling should take a look.

1. It's empty because the files cannot be saved because the permissions are wrong. Even so webbrowserpersist would create a dir for every subframe whether it contains data or not. I intend to implement a lazier dir creation on demand mechanism in due course but this suffices for now. 2. No one put me in charge of Unix permissions and neither do I want it. I asked for the correct permissions to use in the persist object and I will implement a patch based on that advice. As regards using 0777 - I would only use that if nsLocalFileUnix::Create fixed it up using the umask and it doesn't as far as I can tell. I would be adverse to polluting my code with umask calculations when it should happen in nsLocalFileUnix.cpp. I can raise a bug against the owner of nsLocalFileUnix on this issue if you like.

1) ah, subframes, fine. 2) it really really really should be using umask, or it's going to break for someone. Some systems really need 0755 and some want 0775 (and some 0751, etc). nsLocalFileUnix should definately be doing this (though I filed a bug on it a while ago). Until then, you want 0755 as a (bad) temporary workaround, as 0775 gives all users write permission on many systems. This is how the _files directory is created, though I assumed THAT was using umask.

question: could this be related to bug 115197, which was supposedly fixed via bug 114399? just curious...

whups, i confused bug 115154 for 115197. sigh. movin' right along...

Um.... pardon me, but umask seems to be applied correctly for me on Linux... All the dirs that mozilla creates 0755 are created 0700 for me.... I would suggest 0755 for the umask; that's the safest one for the user. Unfortunately, too many users have crappy umasks (like 007).

> umask seems to be applied correctly for me on Linux... what about _data directories? > mozilla creates 0755 are created 0700 for me.... mozilla shouldn't be creating anything 0755 > I would suggest 0755 for the umask You mean for permissions? > that's the safest one for the user. safe? who has a umask that's unsafe? what OS possibly does that? > Unfortunately, too many users have crappy umasks (like 007). Nothing wrong with 007. Whole point of umask is it's the users choice.

Patch changes dir creation permissions to 0755 and removes an unused variable. On Linux at least, the current umask is applied on top of these permissions.

Comment on attachment 65444 [details] [diff] [review] Patch changes file perms r=brade@netscape.com

at least on Linux? why in the world would it be OSspecific. Can someone check nsLocalFileUnix::Create to make sure umask is applied to all unices, so 0777 can be used here? I plan to eventunally check all file writing and file bugs on every place umask isn't used, I'd hate to have to revisit this particular spot.

> why in the world would it be OSspecific. Because the OS handles it. On both Linux and Solaris, open() and creat() system calls will do all the umask stuff themselves (taking the mode passed in and creating using "mode & ~umask"). I presume the same is true of all other sane unices, but that may not be the case... care to test? I still feel that using 777 is fundamentally wrong no matter what the umask is. If the user _really_ wants to make things world-writable and shoot themselves in the foot, they can use chmod.

Comment on attachment 65444 [details] [diff] [review] Patch changes file perms sr=blizzard

a=asa (on behalf of drivers) for checkin.

Fix is in.

looks good. vrfy'd fixed using 2002.01.24.08 comm bits on linux rh7.2.