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

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...

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 :)

reassign

Not sure how much more we can add to this :-) Can you try to install to another directory?

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.

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.

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.

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"

Because this is looking more common, I'm going to nominate this for nsbeta2. I'm also going to reassign this to Alec.

Putting on [nsbeta2-] radar. Not critical to beta2. Adding "relnote" keyword for PR2 release.

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?

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.

->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.

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.

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.

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.

*** Bug 46984 has been marked as a duplicate of this bug. ***

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.

Adding dependency meta bug, updating summary.

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?

plussing, sounds nasty.

*** 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. :(

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.

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);

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

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.

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 ***

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).

back to fixed.

verified.