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)

x86
Linux
defect
Not set
normal

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)
reassigning to blizzard, who writes the rpm spec files.
Assignee: sgehani → blizzard
Component: XP Apps → Build Config
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.
dup. *** This bug has been marked as a duplicate of 128436 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED
> 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.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.