Closed Bug 43091 Opened 24 years ago Closed 24 years ago

Some directories not read or executable, makes Mailnews disappear, and themes break.

Categories

(Core :: XUL, defect, P2)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: xalkina, Assigned: slogan)

References

Details

(Keywords: relnote, Whiteboard: [nsbeta2-][nsbeta3+])

Attachments

(2 files)

permission change from 0666 --> 0755
6.25 KB, patch
Details | Diff | Splinter Review
Permissions for /usr/local/mozilla/chrome/overlayinfo etc
1.21 KB, text/plain
Details 
Can start however using -mail command-line switch.
Currently on linux/2000061908
Working here on the same build.
I see "Mozilla Mail" on the Tasks menu with 2000061920.  marking wfm
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Still don't get one. Removed .mozilla after installing 061902, but does not work.
I've talked to two other people who verified that this item is, in fact, on the 
tasks menu.  Please ensure that if you're running installer, you're actually 
installing the mail component.  verifying wfm for now...
Status: RESOLVED → VERIFIED
still missing, 061920
xalkina@otenet.gr (Christos Cheretakis) you probably still have something
hanging around from a previous build.  make sure tha you've removed all mozilla
files.
I always do :-)
Still not there in 062408. I always remove all files from my mozilla
installation and the .mozilla directory. That's not it!
Reassigning to mail to let them figure this out :)
Status: VERIFIED → UNCONFIRMED
Component: Browser-General → Mail Window Front End
Product: Browser → MailNews
Resolution: WORKSFORME → ---
reassign
Assignee: asa → putterman
QA Contact: doronr → lchiang
Not sure how much more we can add to this :-)

Can you try to install to another directory?
QA Contact: lchiang → nbaca
Will give it a try with next nightly, though don't think there's anything to
change. Iremove everything from /opt/mozilla where i install mozilla and my
personal .mozilla directory. If that's not enough, nothing will do it!
did you kill your profile (/users50) ?
there's no such thing as /users50 in unix. btw, couldn't get latest build to
even unzip. will check with next one.
Installed in /opt/mozo5.0 instead of /opt/mozilla, removed .mozilla directory,
but mozilla just does not want to let me read mail! It's still missing from the
menu!
Installed in /opt/mozo5.0, instead of /opt/mozilla.
Removed .mozilla from my home directory.
Mail does not appear in Tasks menu of mozilla.
linux/062709
This is a complete mystery to me.  alec, putterman - do you know of any case 
when mail *wouldn't* be in the tasks menu?  The only possible cause I can think 
of is that if mail isn't installed (?)
is it on the task bar at the bottom of the screen?
What are all the menu items you do have in your Tasks menu?
add to qawanted to help reproduce this.  No one has had any luck reproducing 
this so far, including folks on mozilla.org QA.
Keywords: qawanted
Also, is it missing from every tasks menu in the app (composer, messenger, 
etc.) ?
Is mailTasksOverlay.xul in 
dist/bin/chrome/packages/messenger/messenger/content/?
Bottom task bar, I assume, are the three icons on the left side, below the
status bar. First one starts navigator, second starts composer, third produces a
Javascript error, from the icon it seems it is Mail. JS error says line 0:
toAddressBook is not defined
These are the items in my Tasks menu:
Navigator
Composer
<sep>
Address Book
Newsgroups (disabled)
<sep>
Privacy and Security (with submenus)
Tools (with submenus)
<sep>
<all open windows>

Mail does not appear in any Tasks menu, not even its own!
Finally, the file mailTasksOverlay.xul is in dist/chrome, not in
dist/bin/chrome.
Huh...
try moving mailTasksOverlay.xul to the directory that I mentioned and see what
happens.
There's no dist/bin directory. Sorry!
as long as it's in the messenger directory with the other messenger files it 
should be fine.
I had someone checking this out on Linux, latest CVS. Marking WfM.
Go ahead if you wanna sort this out, Christos. 

Reopen if someone can confirm this happening on Linux again or if its not gonna 
work for you at all, Christos.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
reopening.  

waterson may have some steps:

Just installed the commercial build on Linux. I installed it as root,
ran it once so that component.reg would get built. Now I try to run as
user. No mail overlays loaded! (No little mail folder at the bottom, no
mail in task menu.)

Run as root. Mail is there.
Run debug mozilla build, mail is there.
Change all file permissions to ugo+w in /usr/local/netscape6. Still no
mail running as user.
Recreate profile. Still no mail.

Also, I got email from someone else jsabatke@execpc.com who ran into this.  I'll 
add him to the cc: list.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
From alecf:

"I have had a few random occurances of this bug on my machine today - in once
instance I opened a mail search window, and mailWindowOverlay.xul wouldn't
load.. in the other instances, mozilla -mail wouldn't bring up any content..
but it almost always worked the second time.

This is on linux, never as root"
Status: UNCONFIRMED → NEW
Ever confirmed: true
Because this is looking more common, I'm going to nominate this for nsbeta2.
I'm also going to reassign this to Alec.
Assignee: putterman → alecf
Keywords: qawanted → nsbeta2
Status: NEW → ASSIGNED
Target Milestone: --- → M17
Putting on [nsbeta2-] radar.  Not critical to beta2.  Adding "relnote" keyword 
for PR2 release.
Keywords: relnote
Whiteboard: [nsbeta2-]
Checked in
http://lxr.mozilla.org/mozilla/source/xpfe/communicator/resources/content/tasksOverlay.xul
to find Mail or something like that, but there does not seem to be anything.
Neither does in my tasksOverlay.xul file installed at mozilla's root in my box.
Nor does the tasksOverlay.dtd of en-US include the word Mail.
Don't know if that's any help...
we use dynamic overlays to make mail insert itself into the tasks menu - we do 
not exist in the global overlay file.
Repro on every build in the last three or so weeks on linux.

I delete *everything* before installing new build (as root, via cron):

#!/bin/bash
cd /usr/local/src
/bin/rm mozilla-*
/bin/rm -rf package/
/bin/rm -rf /home/leary/.mozilla
/usr/bin/ncftpget -u anonymous -p leary@nwlink.com ftp.mozilla.org .
/pub/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu-talkback.tar.gz 
/bin/tar xvfz mozilla-i686-pc-linux-gnu-talkback.tar.gz 

Does not repro for root, *however*....

[root@jean leary]# diff -r .mozilla/ ~root/.mozilla/
Only in .mozilla/: default
Only in /root/.mozilla/: mozProfile
Binary files .mozilla/registry and /root/.mozilla/registry differ
[root@jean leary]#

why the difference?
arg, very sorry to flood :-(

does not repro for user after:

#chown -R leary package

*without* deleting .mozilla in my home dir.  So, it's a permissions thing with
the package/ tree...
syd figured out what the problem is...it's danm & hyatt's fault...
problem is this:

if you start as user a, overlayinfo directories containing overlays.rdf file are 
created underneath chrome with permissions drwx------. If you run as user b, 
then you can't read or traverse these directories because of the permissions. I 
think they should be created drwxr-xr-w.
so who should get this?
Keywords: nsbeta3
According to waterson, danm and hyatt should get this. But if they would like to
clue me in on what/how these dirs get created and where, I'd gladly do the work
and test it.
setting to browser, XPToolkit: XUL, reassigning.
Assignee: alecf → trudelle
Status: ASSIGNED → NEW
Component: Mail Window Front End → XP Toolkit/Widgets: XUL
Product: MailNews → Browser
QA Contact: nbaca → jrgm
->danm
Assignee: trudelle → danm
Flush() is always creating files with permissions 0700. This is wrong for the 
case of stuff created below chrome, in which case 0755 is more appropriate. A 
solution that seems to have some agreement would be to add an argument to 
Flush() that tells Flush() what sort of permissions flags to use. We could make 
the argument be the Unix permissions flags (which will map to DOS/Windoze bits) 
or we can pass in some enumeration value(s) OR'd together. If you want, hand me 
this bug and I will be glad to come up with a workable solution.
Severity: normal → major
Priority: P3 → P2
SOLUTION: I did an strace on this and found that it is opening
chrome/installed-chrome.txt for write.  When I chmodded it o+w it started to
work again.  I don't see why it should be writing this file in
particular and I don't want any user process writing in my install
tree at all, thankyou.
Doug: see earlier comments. We are a component based piece of software. During 
component registry, we have to write certain things into chrome. It is normal. 
The solution is to get the permissions correct.
During the strace I saw that it tried to write on the component registry,
 got denied permission, and then opened another copy in the user's file
space. Why doesn't it do the same thing with chrome? That seems like
the proper approach to me.  By the way, I love Mozilla mail - it's the
best client going for me, and I use it all the time despite the
various problems and crashes.  Thanks!
This bug, I think, is miscategorized/mis-summarized. The fact that mail 
is missing from the Tasks menu is only a symptom of the fact that mail is just 
plain missing altogether when logging in as anything other than root! Mail is 
nowhere to be found in Preferences, the Tasks Menu, or the Component Bar. Is 
this a XUL problem, or something else entirely?
I think that the real problem is that nsIFile (or some such) is creating files 
using the wrong permission bits, and not letting umask filter them. This causes 
the installation (when run as root) to create a directory with 0600 permissions 
(or some such). I'm pretty sure this is a dup of another bug -- or vice versa.

dougt, sound familiar? 
dougt claims to have fixed. Assigning to him so he can add comments and close.
Assignee: danm → dougt
last week, I changed the default permission of the xpcom file io streams to 0666 
(man 2 umask).  I am not sure if this made any difference.  
this worksforme with todays build.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
This still happens on build 2000.07.30.05, after a virgin install using the
installer, all distribution and user directories deleted.  The problem went away
after I did a chmod a+rx on /usr/local/mozilla/chrome/overlayinfo and all its
subdirectories and files.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
*** Bug 46984 has been marked as a duplicate of this bug. ***
Keywords: relnote2
On linux build 2000073009 M18 nightly, the overlayinfo directory is still being
created mode 700.  It should probably be mode 755 so that other users can enter
the directory.

drwx------    6 root    root        1024 Jul 30 15:28 overlayinfo

Clearing nsbeta2- status for reevaluation by PDT.  This is a simple fix and
should probably be done before m17 is released.
Whiteboard: [nsbeta2-]
Adding dependency meta bug, updating summary.
Blocks: 41057
Summary: Mail missing from Tasks menu → Some directories not read or executable, makes Mailnews disappear.
No longer blocks: 41057
Blocks: 41057
Syd, mozilla-bin must not write to the inst dir. This is a severe security
problem. See bug 41037 and bug 42184.
I think Ben meant bug 41057 not bug 41037.
Ben, but it does. So, are you going to change that? In the meantime, a quick fix
will avoid users in the scenario from talking about from losing access to mail
news until some other architecture is devised.

So, let's make the current design work, and stop fussing about how it might be
better, ok?
Putting on [nsbeta2-] radar.  Not critical to beta2.  Adding "relnote" keyword 
for PR2 release. Release note that user might have to chmod for the 
directory...is that a workaround for this problem?
Whiteboard: [nsbeta2-]
plussing, sounds nasty.
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
*** Bug 44338 has been marked as a duplicate of this bug. ***
Bug 44338 is about the classic theme not appearing in prefs, but the cause was
determined to be the same as this bug, that overlayinfo is not readable by other
users.  So, not only does this bug break mail/news but also themes. :(
Summary: Some directories not read or executable, makes Mailnews disappear. → Some directories not read or executable, makes Mailnews disappear, and themes break.
Does anyone know or have tracked down what code creates these directories?  What 
permissions are they 0666?


I did, a while back. Read earlier. It is the component registry, and the flush 
call in rdf needs a perms flag (in this case) to cause the underlying fs code to 
use 766 (the rest of the flush calls can just pass some predefined value so they 
use the value they always used before so we don't break anything). I've 
discussed with rjc and hyatt, both like it, let's do it.
Flush() creates directories??  something is wrong.

okay.  found the problem.  all nsFileStreams (nsFileSpec io) use 0666 as the 
permission.  It was once 0700 but I change it to 0600 based on man 2 umask.  I 
guess we need to do something else, like 0755 as I initally though that we 
should do.
Blocks: 44338
No longer blocks: 44338
Here's a diff to get the RDF XML datasource to use 755 instead of whatever 
default nsIFile uses:

Index: mozilla/rdf/base/src/nsRDFXMLDataSource.cpp
===================================================================
RCS file: /cvsroot/mozilla/rdf/base/src/nsRDFXMLDataSource.cpp,v
retrieving revision 1.96
diff -r1.96 nsRDFXMLDataSource.cpp
822c822
<     nsOutputFileStream out(path);
---
>     nsOutputFileStream out(path, nsOutputFileStream::kDefaultMode, 00755);
Assignee: dougt → syd
Status: REOPENED → NEW
actually, this is nsFileStreams, which is nsFileSpec

dougt: You are right, I meant nsFileSpec... which RDF is still using for writing 
out RDF/XML files.  Anyway, the diff is still correct for the issue at hand.  :^)

Fixed
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
This is *not* fixed in Linux build 2000080505.

Starting Mozilla as root, I can see mailnews, and I can download themes from
x.themes.org.

Starting as a normal user I do not see mailnews, nor do downloaded themes appear
in prefs.
When you say you can't see mailnews, does that mean there is a tasks menu item 
but that it doesn't work? Or there is no tasks menu item? Can you recursively ls 
-l dist/bin/chrome/overlayinfo and attach to this bug report? Also, what is your 
umask set to when you installed, or when you first ran?
Doug, am I reading the patch right?  You made the default permissions be 0755 
for all files, including directories?  That's not right, if so: calling context 
is required to know whether to use 0666 (modified by umask, as usual) for a 
regular file, or 0777 (modified by umask again) for a directory.  Some Unix 
utilities use 0755 for the default mode when creating necessary directories 
along the path to a new file, btw, but I think umask should govern which bits 
are turned off, so 0777 seems best in general.

Is the problemt that the "accessMode" is used both for creating the ultimate 
(leaf) file, and for creating any necessary directories along the path?  Or are 
we really creating leaf directories as well as files using the same method(s), 
in which case we've overloaded badly?

/be
Linux build 2000.08.06, umask is 002.  Installed with installer, complete
install.
no.  we did not use that patch.  

the final fix was in RDF (like other places in the code) to create files with 
755 permission. 

The problem is that nsFileSpec creates directories with 0700:

const mode_t mode = 0700;
nsFileSpecHelpers::MakeAllDirectories((const char*)ioPath, mode);


nsLocalFile (nsIFile) fixes this problem.  From the comment:

Ancestor directories get the same permissions as the file we're creating, with 
the X bit set for each of (user,group,other) with an R bit in the original 
permissions.  If you want to do anything fancy like setgid or sticky bits, do it 
by hand.
Doug: righteous, but set my silly mind at ease: when you wrote that "RDF 
[creates] files with 755 permission", you mean directories only, not regular 
files that aren't truly executable?

/be
files only :-(  that is probably why people are still complaining that this does 
not work for them.


Syd, can you verify that changing the permissions in nsFileSpecUnix, does indeed 
fix this problem?
Dougt: setting to 755 is not going to cause the failure, that is silly :-) -- 
just means the file is incorrectly marked as executable, not that it can't be 
read (if you try to execute the file the shell will try to interpret it and 
fail). The bug that some people still have for whatever reason is that a user 
that was not the creator of the overlayinfo dir is unable to read files because 
the directories about are not readable.

Brendan is prolly right, the 755 on files is unnecessary and perhaps a tad evil, 
the rdf-created stuff can be 644, and we should change it. My bad. The 
directories in the path should be 755 so they can be accessed by a different 
user than the 
creator, that is what the change in nsFileSpecUnix did, as dougt described 
earlier (700 was too restrictive), and what this bug is all about. Regardless of 
the issue with the "file" perms, my checkins fixed the bug as it was originally 
described. I verified it with the default umask and with a umask of 002. 

As you can see in the last attachment (by zach), the overlayinfo dir has been 
created with permissions inconsistent with the checked in fix. Setting umask to 
002, I did not get the same result as Richard Zach -- my permissions on 
overlayinfo are what I would have expected, drwxr-xr-x (his are drwx------ which 
will cause the failure case). 

I am *not* using the installer, but debug builds from m18 tip. The installer 
does not create chrome/overlayinfo so I can't see it as being relevant. 
Syd: just to be sure we agree, the octal literal passed for regular file mode 
should be 0666, and let umask turn it into 0644 or 0664 as the user desires.  
For directories created implicitly along the path to a new file, we should do 
what shaver et al. did in nsLocalFileUnix: use the file's mode with an 'x' bit 
for every 'r' bit added.

IOW, please to be respecting my umask setting, dammit!

/be
Undid the perms setting in rdfxmldatasource, picking up defaults for files which
are 0666 (I still think of we only want 644 it is strange to be setting 666 with
the hopes the umask will do what we want, why the heck not just use 644?)
Anyway, back to where we were except the real problem is solved, dir permissions
are correct.

Still need more info as to why someone is seeing 700 on overlayinfo, that should
no longer be happening... still works great for me:

[slogan@sydlap chrome]$ ls -l
total 5
lrwxrwxrwx   1 syd      users          51 Aug  7 16:20 all-locales.rdf ->
/opt/raptor/mozilla/dist/bin/chrome/all-locales.rdf
lrwxrwxrwx   1 syd      users          52 Aug  7 16:20 all-packages.rdf ->
/opt/raptor/mozilla/dist/bin/chrome/all-packages.rdf
lrwxrwxrwx   1 syd      users          49 Aug  7 16:20 all-skins.rdf ->
/opt/raptor/mozilla/dist/bin/chrome/all-skins.rdf
drwxr-xr-x   4 syd      users        1024 Aug  7 16:21 communicator
drwxr-xr-x   5 syd      users        1024 Aug  7 16:21 locales
drwxr-xr-x   6 syd      users        1024 Aug  7 16:20 overlayinfo
drwxr-xr-x   7 syd      users        1024 Aug  7 16:21 packages
drwxr-xr-x   4 syd      users        1024 Aug  7 16:20 skins
lrwxrwxrwx   1 syd      users          52 Aug  7 16:20 user-locales.rdf ->
/opt/raptor/mozilla/dist/bin/chrome/user-locales.rdf
lrwxrwxrwx   1 syd      users          50 Aug  7 16:20 user-skins.rdf ->
/opt/raptor/mozilla/dist/bin/chrome/user-skins.rdf

syd: if you know for sure that 0644 is right (no group member should be able to 
write, or to unlink the file from a sticky dir), go for it.  In a general 
purpose API, you can't know that.  Umask can only clear bits, never set them.  
Some people run in group-write-access mode, with umask of 002.  Others use 022. 
Different strokes, but don't preempt the choice.

/be
Sure, let's leave it at 0666. 
The number of the beast (Mozilla) ;-)
It's back!  Mail no longer works unless you run it as root. This seems like more
of these "Can't write in the registry" problems again.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Doug Collins, did you run mozilla once first as root to register the necessary
files?  You may be experiencing bug 42184.  If so then this bug is fixed or a
dup of bug 42184.  I don't have easy access to a linux box right now, can anyone
else on linux confirm this?
Yes, it's caused by the same thing as bug 42184 - basically because the registry
Doug, didn't get all of your last comment. Please update.

At any rate, if I either run the mozilla installer, or do a tar xvzf, and 
then run as root to get the initial registration done, when I subsequently
run as ~jrgm, I run fine, I have mail overlays, can run mail, can change
themes, ... the overlayinfo and other files created on the initial run as 
root are created with 644 for files and 755 for directories (given a root 
umask of 022).
marking as dup per Doug's last comment

*** This bug has been marked as a duplicate of 42184 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
All my great comments got deleted for some reason. Anyway, the gist
of it is that bug 42184 sounds like it is being treated like an
esoteric security issue but what I'm seeing today is that Moz
won't even *BOOT* as a user anymore but it runs perfectly as root.
So I "chmod -R a+w ." and guess what? Now it works fine.

John, did you change the owner/permissions back after the install-run and before
the run as normal user?

David, Doug Collinge, if you ran Mozilla once as root (and it ran fine), then
change the owner, and it doesn't work and more, then this is not a dup of bug
42184. If anything, it's a bug of bug 41057.
No. To be clear, I did not use 'chmod' at any time. After the initial run 
as root, I could run as 'jrgm' without error. 

However, what Doug says is correct: if you do not do the initial run as 
root (just do the install/untar as root), and then try to run as 'user', 
the program aborts completely. [I don't know if that is new behaviour or
if it was already like that, since I don't typically install the daily 
builds as root on my system].
> I did not use 'chmod' at any time

I did not use 'chown' or 'chmod' at any time
Seems like I misunderstood you, John. What you describe is indeed bug 42184. But
Doug Collinge seem to be completely unable to run Mozilla as normal user, which
would be a dup of bug 41057. Anyway, doesn't really matter (unless you want to
come up with a workaround again). All of you know the relevant bugs now :).
I verified again today that Mozilla crashes when run as a user. Details
are posted against bug 42184 and bug 41057.  This bug may be a duplicate
but it sure isn't resolved.
Okay, the crux of _this_ bug was what syd said, Jul 13: overlayinfo was 
being written with zero rwx permissions for 'go'. That is fixed: if user
A does the install and initial run, then user B can run that installed app.

The other bugs cover different issues: what app should do the initial install,
and whether bob the user needs write access to the bin directory at runtime
(although I did not need write access and could run fine).
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
back to fixed.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
verified.
Status: RESOLVED → VERIFIED
Blocks: 116669
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: