Closed Bug 163524 Opened 23 years ago Closed 17 years ago

installer creates components directory without exec perm

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: xalkina, Unassigned)

References

Details

(Keywords: regression)

Attachments

(3 files)

Output of strace mozilla
34.03 KB, text/plain
Details
Output of strace -f mozilla
196.33 KB, text/plain
Details
xptiInterfaceInfoManager.cpp patch
661 bytes, patch
dougt
: review-
dveditz
: superreview+
Details | Diff | Splinter Review
Using RedHat Linux 7.3 with all issued updates applied to base installation. Last build I can get to run is 2002080508. Have downloaded several since, but the effect is always the same: -running installer, everything gets installed and seems to be ok -installer runs -profilemanager as root, I always click Exit here -running mozilla as a normal user, it just exits without doing anything It's happening to quite a lot of builds lately, (each and everyone I downloaded), so I'm getting to thing it has to do something with dynamic libraries or something, since that's the main thing that's changed in my system lately. Will attache strace output, although it doesn't seem to point something out --at least to me :-)
Severity: normal → critical
Keywords: crash, stackwanted
It's no crash, neither can I provide a stack trace. As you can see from the strace output I attached, mozilla exits normally at the end!!!
Keywords: crash, stackwanted
you have successfully strace'd the mozilla startup scripts. if you want to strace mozilla-bin, you'll need to use the strace option to follow forked processes or add starce to the line in run-mozilla.sh that actually starts mozilla. sounds like the same issue as in bug 163213
Yes, looks very similar with bug 163213, though not sure yet. Also right about strace, forgot -f flag. Sorry!!! Root can start mozilla without problem. Reattaching strace -f mozilla, where you get lots of "access denied" for *.so files. Directory components is created with 0644. After changing to 0755 everything works fine!!! Must be it ;-)
As promised, although not needed anymore, I guess!
Thanks, Christos! I'm not sure why they aren't getting execute permission. I have been using nighlties without any problem. ==> Installer
Assignee: Matti → dveditz
Status: UNCONFIRMED → NEW
Component: Browser-General → Installer
Ever confirmed: true
Keywords: regression
QA Contact: asa → bugzilla
Summary: Mozilla won't start on RedHat Linux → installer does not install libs with execute perms
*** Bug 163213 has been marked as a duplicate of this bug. ***
Let me just note that it's not the *.so files themselves, but the components directory that has wrong permissions!!!
QA Contact: bugzilla → ktrina
> chmod a+x `find . -name "*.so"` (from Mozilla directory) > please reopen if that doesn't fix it It did not work. After that I downloaded the latest one (8/20) and tried with it. Same result: mozilla opens as root, does not open as non-root user. Since you have marked this a sup of another bug, I am not sure if I need to post this to which bug (as you also said: reopen if...). I am posting to both the bugs :) in my case, I don;t think, it has anything to do with execute permissions, as root is able to open mozilla. Please let me know what next to try... Thanks Ajay Gautam
Christos: do any of the directories have execute permission? (all directories and subdirectories should have world-execute permission)
Summary: installer does not install libs with execute perms → installer creates components directory with exec perm
Only the components directory has 0644 permissions after installation. My installdir is /opt/mozilla, that is /opt/mozilla/components. Everything else seems to be fine. After changing that dir's permissions, mozilla starts up as it should :-) The find command from Ajay tries to change permissions of files, which are as installed correctly.
*** Bug 163213 has been marked as a duplicate of this bug. ***
Summary: installer creates components directory with exec perm → installer creates components directory without exec perm
*** Bug 163652 has been marked as a duplicate of this bug. ***
*** Bug 164849 has been marked as a duplicate of this bug. ***
This is very strange because I had the 8/18 build ind it worked fine, and installed the latest nightly and the components directory had wrong permissions. But then I tried regressing, and none of the old buyilds worked either!
This is still in the 9/11 nightly build. Is anyone doing anything about it?
does root have a umask setting other than 022 here? that would be bug 111124, but with that bug ALL directories are created with the umask permissions, not just the components directory.
No, it is just the components directory. It is very hard to keep remembering that one must change these permissions when doing an install of a nightly build. Surely this is easy to fix. It didn't used to happen.
*** Bug 168345 has been marked as a duplicate of this bug. ***
*** Bug 172126 has been marked as a duplicate of this bug. ***
Why isn't this being fixed? It used to work.....
*** Bug 175385 has been marked as a duplicate of this bug. ***
*** Bug 176683 has been marked as a duplicate of this bug. ***
Come on mozilla developers! The installer forgets to get chmod +x the components directory!! How can a bug this elementary pass any kind of QA?
Erm... hasn't this been fixed? I just installed a nightly and didn't see this problem.
It worked for me also!
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
This is happening to too many people to be a simple WFM. Dig deeper. I'm the wrong assignee here, but I don't know who could help. Directories which don't exist are created with permission 755 http://lxr.mozilla.org/mozilla/source/xpinstall/src/nsInstallFile.cpp#206 It would probably be better to re-write this to use directory permissions found in any directories stored in the zip archive (give install author more control).
Status: RESOLVED → REOPENED
Keywords: helpwanted
Resolution: WORKSFORME → ---
It used to fail for me, and has worked on recent builds, so something got fixed.
Just checked. Still broken for me Build ID: 2002110408 The permisions for components is 664 instead of 755, which is a bit strange. I notice that the file "registry" also has permisions 664. Is there some reason that file should have write permision for group? Or is that an error (but with no visible symptoms) as well? This isn't critical for me, it's easy to work around, but many people won't be able to figure out how.
*** Bug 178819 has been marked as a duplicate of this bug. ***
I've been experiencing this problem for quite a while with the nightly builds. Today I played around with the install and noticed the permissions for components are incorrect only (for me, anyway) if MOZILLA_FIVE_HOME is set and you install to the location of MOZILLA_FIVE_HOME. If I install to a differnet directory than MOZILLA_FIVE_HOME the permissions are correct. If I unset MOZILLA_FIVE_HOME and do the install (which I did to various locations) the permissions were correct.
Wow, what an obscure set of conditions. I have no idea why that would matter, but thanks for discovering the connection.
*** Bug 181483 has been marked as a duplicate of this bug. ***
Depends on: 144331
*** Bug 182316 has been marked as a duplicate of this bug. ***
*** Bug 182349 has been marked as a duplicate of this bug. ***
Additional caveat: If mozilla is installed as a normal user, the installer fails entirely (cannot write in directory ./components, obviously, since its mode 644). However, chmod() to 755 and start the installation again fixes this. Mozilla installs and runs perfectly.
Why hasn't this been fixed already? It used to work
*** Bug 183376 has been marked as a duplicate of this bug. ***
*** Bug 184711 has been marked as a duplicate of this bug. ***
*** Bug 185001 has been marked as a duplicate of this bug. ***
*** Bug 185697 has been marked as a duplicate of this bug. ***
*** Bug 185771 has been marked as a duplicate of this bug. ***
removing 'helpwanted' since the problem here is known (bug 144331)
Keywords: helpwanted
*** Bug 186911 has been marked as a duplicate of this bug. ***
*** Bug 186795 has been marked as a duplicate of this bug. ***
*** Bug 171696 has been marked as a duplicate of this bug. ***
This bug is well on it's way to taking top spot for most duplicated bug. Would somebody please fix it? It's got to be a quick fix for the person(s) familiar with the installer code.
I found it. This was apparently introduced by the fix for bug 160404. mozilla/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp contains code to create the components directory if it doesn't exist, and it uses an incorrect mode when doing so--0666 instead of 0777. This code isn't part of the install process per se; it's just initializing some part of xpcom. When MOZILLA_FIVE_HOME is set, it wants to see a components directory within MOZILLA_FIVE_HOME. When MOZILLA_FIVE_HOME isn't set I think it's looking for "components" in /tmp/xpi.XXXXX/bin, a temp directory for the install process. There's already a components directory there so the bug doesn't trigger. The attached patch corrects the mode setting.
Attachment #112645 - Flags: superreview?(dveditz)
Attachment #112645 - Flags: review?(dougt)
*** Bug 178381 has been marked as a duplicate of this bug. ***
Comment on attachment 112645 [details] [diff] [review] xptiInterfaceInfoManager.cpp patch I am okay with this change i think, however, there are other places where we might not give the correct permission on some files. We should hit these all at once.
I'm not sure that's the right change, 0755 might be better (why was it 0666?). In any case part of the problem is that the stub is creating the component directory in the wrong place when MOZILLA_FIVE_HOME is set. When that flag is set it overrides the directory service's idea of where the current executable is running, so the component directory is created in the target location instead of in the temporary directory where the stub engine is running. Then when we actually do the install that directory already exists, so the permissions the install engine sets when it creates a directory are irrelevant. Dougt pointed me at a problem in xpistub.cpp, where we should be passing a directory to NS_XPComInit2 -- that would solve this problem without this patch. Doug: what do you think, should we change this obvious xpti issue anyway?
*** Bug 195251 has been marked as a duplicate of this bug. ***
Comment on attachment 112645 [details] [diff] [review] xptiInterfaceInfoManager.cpp patch If it's fine w/dougt sr=dveditz
Attachment #112645 - Flags: superreview?(dveditz) → superreview+
i wonder why we even bother creating the directory? Maybe the directory service provider implementation should ensure that this directory is created -- after all, this implementation should not assume that xpcom will create every directory in the path that it specifies.
Comment on attachment 112645 [details] [diff] [review] xptiInterfaceInfoManager.cpp patch minusing until we discuss this.
Attachment #112645 - Flags: review?(dougt) → review-
*** Bug 183201 has been marked as a duplicate of this bug. ***
What is the state of this bug and the discussion?
Product: Browser → Seamonkey
Assignee: dveditz → nobody
Status: REOPENED → NEW
QA Contact: ktrina → general
linux installer is mostly dead (only lives on the 1.8 branch)
Status: NEW → RESOLVED
Closed: 23 years ago → 17 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: