Closed
Bug 384172
Opened 17 years ago
Closed 17 years ago
Updated builds to latest trunk crashes with selinux error while loading shared library: /opt/firefox/libxul.so
Categories
(Core :: Internationalization, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.9beta1
People
(Reporter: cbook, Assigned: thep)
References
Details
(Keywords: crash, smoketest)
Attachments
(1 file)
1.19 KB,
patch
|
roc
:
review+
roc
:
superreview+
roc
:
approval1.9+
|
Details | Diff | Splinter Review |
The updated nightlies (via Software Update) on Linux from yesterdays trunk build to the latest trunk build crashs with error message :
/opt/firefox/firefox-bin: error while loading shared libraries: /opt/firefox/libxul.so: cannot restore segment prot after reloc: Permission denied
Reproduced with Fedora F7
Steps to reproduce:
Install the nightly from yesterday
Update via AUS to the latest trunk
Crash on restart after the update is applied
Flags: blocking-firefox3?
Comment 1•17 years ago
|
||
This error is an selinux error. I'm assuming libxul related fallout.
Version: unspecified → Trunk
I have done some testing on all platforms is this is what I have found:
Mac OSX:
--------
200706011 -> 20070612 via Check For Updates: no problems
200706011 -> 20070612 via Clean Install: no problems
Linux (Fedora 7):
-----------------
200706011 -> 20070612 via Check For Updates:
/firefox-bin: error while loading shared libraries: /libxul.so: cannot restore
segment prot after reloc: Permission
denied
200706011 -> 20070612 via Clean Install: no problems
Linux (Kubuntu 7.04):
---------------------
200706011 -> 20070612 via Check For Updates: Seg-fault
200706011 -> 20070612 via Clean Install: no problems
Windows Vista:
--------------
200706011 -> 20070612 via Check For Updates: Mozilla crash reporter dialog
200706011 -> 20070612 via Clean Install: no problems
Windows XP SP2:
---------------
200706011 -> 20070612 via Check For Updates: Mozilla crash reporter dialog
200706011 -> 20070612 via Clean Install: firefox.exe process hangs in task
manager
Comment 3•17 years ago
|
||
Can somebody please check the build from fx-linux-tbox after the libxul landing, which I believe is this one: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/fx-linux-tbox-trunk/
fx-linux-tbox will become the new nightly build and should have the correct relocatable sections
Reporter | ||
Comment 4•17 years ago
|
||
the Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/2007061211 Minefield/3.0a6pre build (its the one from the tbox) starts without problems here.
If my memory is correct, the problem is the R_386_PC32 relocations, which are for a bunch of _moz_cairo_* functions, according to objdump -R libxul.so | grep R_386_PC32.
Blocks: 359275
No longer blocks: 359275
Comment 6•17 years ago
|
||
see also bug #384179
Updated•17 years ago
|
Summary: Updated builds to latest trunk crashs with error messages rror while loading shared libraries: /opt/firefox/libxul.so → Updated builds to latest trunk crashes with selinux error while loading shared library: /opt/firefox/libxul.so
Comment 7•17 years ago
|
||
marking this fixed by bug 384150, switching to fx-linux-tbox
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Flags: blocking-firefox3? → blocking-firefox3+
Reporter | ||
Comment 9•17 years ago
|
||
its back with the latest trunk build on Fedora F7:
Its only working when i enter chcon -t textrel_shlib_t /opt/firefox/libxul.so into the terminal
/opt/firefox/firefox-bin: error while loading shared libraries: /opt/firefox/libxul.so: cannot restore segment prot after reloc: Permission denied
Summary
SELinux is preventing /opt/firefox/firefox-bin from loading
/opt/firefox/libxul.so which requires text relocation.
Detailed Description
The /opt/firefox/firefox-bin application attempted to load
/opt/firefox/libxul.so which requires text relocation. This is a potential
security problem. Most libraries do not need this permission. Libraries are
sometimes coded incorrectly and request this permission. The
http://people.redhat.com/drepper/selinux-mem.html web page explains how to
remove this requirement. You can configure SELinux temporarily to allow
/opt/firefox/libxul.so to use relocation as a workaround, until the library
is fixed. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi
against this package.
Allowing Access
If you trust /opt/firefox/libxul.so to run correctly, you can change the
file context to textrel_shlib_t. "chcon -t textrel_shlib_t
/opt/firefox/libxul.so"
The following command will allow this access:
chcon -t textrel_shlib_t /opt/firefox/libxul.so
Additional Information
Source Context root:system_r:unconfined_t:SystemLow-SystemHigh
Target Context root:object_r:usr_t
Target Objects /opt/firefox/libxul.so [ file ]
Affected RPM Packages
Policy RPM selinux-policy-2.6.4-26.fc7
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name plugins.allow_execmod
Host Name localhost.localdomain
Platform Linux localhost.localdomain 2.6.21-1.3228.fc7 #1
SMP Tue Jun 12 15:37:31 EDT 2007 i686 i686
Alert Count 4
First Seen Tue 12 Jun 2007 08:01:40 PM CEST
Last Seen Fri 20 Jul 2007 01:36:29 AM CEST
Local ID 66ffcda0-6838-4fde-91d4-84ac44647af9
Line Numbers
Raw Audit Messages
avc: denied { execmod } for comm="firefox-bin" dev=dm-0 egid=0 euid=0
exe="/opt/firefox/firefox-bin" exit=-13 fsgid=0 fsuid=0 gid=0 items=0
name="libxul.so" path="/opt/firefox/libxul.so" pid=11074
scontext=root:system_r:unconfined_t:s0-s0:c0.c1023 sgid=0
subj=root:system_r:unconfined_t:s0-s0:c0.c1023 suid=0 tclass=file
tcontext=root:object_r:usr_t:s0 tty=pts0 uid=0
Comment 10•17 years ago
|
||
With today's nightly:
objdump -R libxul.so | grep R_386_PC32
0025cba3 R_386_PC32 pango_get_log_attrs
0025cc53 R_386_PC32 pango_language_from_string
If bug 359336 were fixed, we'd have seen:
/usr/bin/ld: ../lwbrk/src/liblwbrk_s.a(nsPangoBreaker.o): relocation R_X86_64_PC
32 against `pango_language_from_string' can not be used when making a shared obj
ect; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
gmake[5]: *** [libi18n.so] Error 1
Looks like it's being tracked in bug 336959, though.
Reporter | ||
Comment 14•17 years ago
|
||
still happend again today with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007090404 Minefield/3.0a8pre under Fedora F7
[root@localhost ~]# /opt/firefox/firefox
/opt/firefox/firefox-bin: error while loading shared libraries: /opt/firefox/libxul.so: cannot restore segment prot after reloc: Permission denied
SELinux is preventing /opt/firefox/firefox-bin from loading
/opt/firefox/libxul.so which requires text relocation.
Raw Audit Messages
avc: denied { execmod } for comm="firefox-bin" dev=dm-0 egid=0 euid=0
exe="/opt/firefox/firefox-bin" exit=-13 fsgid=0 fsuid=0 gid=0 items=0
name="libxul.so" path="/opt/firefox/libxul.so" pid=2776
scontext=root:system_r:unconfined_t:s0-s0:c0.c1023 sgid=0
subj=root:system_r:unconfined_t:s0-s0:c0.c1023 suid=0 tclass=file
tcontext=root:object_r:usr_t:s0 tty=pts0 uid=0
Reporter | ||
Comment 15•17 years ago
|
||
reopen because i see this again with 2007090404
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 16•17 years ago
|
||
Probably, I should have adjusted the build flags in my patch for Bug 336969.
Updated•17 years ago
|
Target Milestone: --- → Firefox 3 M10
Updated•17 years ago
|
Assignee: nobody → thep
Status: REOPENED → NEW
Component: General → Internationalization
Flags: blocking-firefox3+
Product: Firefox → Core
Target Milestone: Firefox 3 M10 → mozilla1.9 M10
Comment 17•17 years ago
|
||
re-requesting blocking+ since it got lost due to the move.
Flags: blocking1.9?
QA Contact: general → i18n
Comment 18•17 years ago
|
||
Comment on attachment 279691 [details] [diff] [review]
Patch fixing build flags
Fallout from bug 336959.
Attachment #279691 -
Flags: superreview?(roc)
Attachment #279691 -
Flags: review?(roc)
Attachment #279691 -
Flags: approval1.9?
Attachment #279691 -
Flags: superreview?(roc)
Attachment #279691 -
Flags: superreview+
Attachment #279691 -
Flags: review?(roc)
Attachment #279691 -
Flags: review+
Attachment #279691 -
Flags: approval1.9?
Attachment #279691 -
Flags: approval1.9+
Comment 19•17 years ago
|
||
Checking in intl/build/Makefile.in;
/cvsroot/mozilla/intl/build/Makefile.in,v <-- Makefile.in
new revision: 1.25; previous revision: 1.24
done
Checking in intl/lwbrk/src/Makefile.in;
/cvsroot/mozilla/intl/lwbrk/src/Makefile.in,v <-- Makefile.in
new revision: 1.40; previous revision: 1.39
done
Status: NEW → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.9 M10 → mozilla1.9 M9
You need to log in
before you can comment on or make changes to this bug.
Description
•