Closed
Bug 146345
Opened 23 years ago
Closed 23 years ago
why is mozilla trying to write files in /usr/lib/ ?
Categories
(SeaMonkey :: Build Config, defect)
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 128436
People
(Reporter: jwz, Assigned: blizzard)
Details
While investigating something else, I ran strace on mozilla, and I saw a
bunch of suspicious things; maybe these aren't problems, but then again,
maybe they are, so here you go.
This is the output of "strace mozilla" followed by quitting immediately.
From this output I deleted:
- all lines not containing 'open('
- all lines containing ' = [1-9]' (i.e., show only failures)
- all lines containing 'plugin', '\.so\.', or '/nis/'
Of special note are the lines containing "Read-only file system": those
are files that Mozilla should no way no how be writing, even if someone
mistakenly left them writable!
Also, why is someone trying to open "/dev/null/" as a *directory*?
open("/usr/lib/mozilla/i686/mmx/libgkgfx.so", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/usr/lib/mozilla/i686/libgkgfx.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/mozilla/mmx/libgkgfx.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/mozilla/libgkgfx.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/mozilla/libjsj.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/mozilla/libmozjs.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/mozilla/libxpcom.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/mozilla/libplds4.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/mozilla/libplc4.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/mozilla/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/ro/usr/lib/mozilla/component.reg", O_RDWR) = -1 EROFS (Read-only file system)
open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
open("/ro/usr/lib/mozilla/components/xptitemp.dat",
O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EROFS (Read-only file system)
open("/ro/usr/lib/mozilla/components/xptitemp.dat",
O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EROFS (Read-only file system)
open("/usr/lib/mozilla/libgtksuperwin.so", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/ro/usr/lib/mozilla/chrome/chrome.rdf",
O_WRONLY|O_CREAT|O_TRUNC|O_EXCL|O_LARGEFILE, 0666) = -1 EEXIST (File exists)
open("/ro/usr/lib/mozilla/chrome/chrome.rdf",
O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0664) = -1 EROFS (Read-only file system)
open("/usr/lib/mozilla/libgtkxtbin.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/mozilla/libXt.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/mozilla/libXext.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/home/guest/.java/properties131_02", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/home/guest/.mozilla/guest/n9jkgiqa.slt/chrome/userChrome.css",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/guest/.mozilla/guest/n9jkgiqa.slt/chrome/userContent.css",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/guest/.mozilla/guest/n9jkgiqa.slt/cookperm.txt",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/guest/.mozilla/guest/n9jkgiqa.slt/localstore.rdf",
O_WRONLY|O_CREAT|O_TRUNC|O_EXCL|O_LARGEFILE, 0666) = -1 EEXIST (File exists)
Comment 1•23 years ago
|
||
reassigning to blizzard, who writes the rpm spec files.
Assignee: sgehani → blizzard
Component: XP Apps → Build Config
Assignee | ||
Comment 2•23 years ago
|
||
Most of those messages are from LD_LIBRARY_PATH pointing at /usr/lib/mozilla.
ld.so is trying to load linked libraries from the path before loading them from
the system path. There are some interesting nuggets in here, though:
open("/ro/usr/lib/mozilla/component.reg", O_RDWR) = -1 EROFS (Read-only file system)
I don't know _where_ that is coming from. '/ro/'? Read only?
open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
I have no idea. I would love to know who is making that call.
There are known issues with trying to add the *.rdf files, xpi files and
component.reg file with write permission. Except for the access violation that
people whine about, it's harmless as near as I can tell.
Assignee | ||
Comment 3•23 years ago
|
||
dup.
*** This bug has been marked as a duplicate of 128436 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 5•23 years ago
|
||
> I don't know _where_ that is coming from. '/ro/'? Read only?
Yes, /usr is actually a symlink to /ro/usr (it's a side-effect of how these
diskless kiosks boot.) Anyway, there's not much practical difference between
/usr being mounted ro, and being -w from an app's point of view.
The fact that you're seeing /ro in messages means someone somewhere is
realpath-ing something. Probably doesn't matter.
Updated•21 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•