If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

why is mozilla trying to write files in /usr/lib/ ?

VERIFIED DUPLICATE of bug 128436

Status

SeaMonkey
Build Config
VERIFIED DUPLICATE of bug 128436
16 years ago
13 years ago

People

(Reporter: Jamie Zawinski, Assigned: blizzard)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
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

16 years ago
reassigning to blizzard, who writes the rpm spec files.
Assignee: sgehani → blizzard
Component: XP Apps → Build Config
(Assignee)

Comment 2

16 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

16 years ago
dup.

*** This bug has been marked as a duplicate of 128436 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 4

16 years ago
v
Status: RESOLVED → VERIFIED
(Reporter)

Comment 5

16 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.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.