Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 202642 - Add Seamonkey to the group of Mozilla apps that require textrel_shlib_t
Add Seamonkey to the group of Mozilla apps that require textrel_shlib_t
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2006-08-15 13:20 EDT by Kai Engert (:kaie) (inactive account)
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: selinux-policy-2.3.7-2.fc5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-24 08:11:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
There are messages in /var/log/audit/audit.log (4.46 MB, text/plain)
2006-08-18 07:11 EDT, Jim Cornette
no flags Details

  None (edit)
Description Kai Engert (:kaie) (inactive account) 2006-08-15 13:20:10 EDT
Description of problem:
The Seamonkey application, successor to the Mozilla application suite, provided
in an rpm package in Fedora Extras, does not start up on Fedora Core 5 in
enforcing mode.

It seems an exception has been made already, to allow all other Mozilla based
apps (Firefox, Thunderbird, Mozilla, Sunbird) to run with textrel_shlib_t.

I propose the same rule gets applied to the Seamonkey application, too.

Version-Release number of selected component (if applicable):
(and seamonkey-1.0.4-0.5.1.fc5)

How reproducible:
Install seamonkey and try to start, while enforcing mode is enabled.

Steps to Reproduce:
- yum install semonkey
- setenforce 1
- ./seamonkey
Actual results:
Does not start, error shown in audit.log

Expected results:
App should start

Additional info:
See also the original request to fix this in bug 201648, where this was
identified as the cause.
Comment 1 Jim Cornette 2006-08-15 22:17:18 EDT

has information regarding the problem and also comments regarding text
relocation not being advisable. If possible, a fix for the mozilla and its
offshoots of the original mozilla should be fixed so they do not need test
relocation. I use seamonkey and was putting SELinux in permissive instead of
enforcing because of the limiting factor test relocation denials were causing
with seamonkey.

I am using comment #8 suggestion in bug 201648 which allows SELinux to be used
for the rest of the system.

libxpcom_core.so seemed to have the most avc denied messages in the
/var/log/audit/audit.log file on my system.

# ls -lZ /usr/lib/firefox-
-rwxr-xr-x  root root system_u:object_r:textrel_shlib_t
# ls -lZ /usr/lib/seamonkey-1.0.4/libxpcom_core.so
-rwxr-xr-x  root root system_u:object_r:lib_t
# ls -lZ /usr/lib/thunderbird-
-rwxr-xr-x  root root system_u:object_r:textrel_shlib_t 

adding to CC:
Comment 2 mark bokil 2006-08-17 20:10:12 EDT
Also RealPlayer's realplay application doesn't work with the new SELinux policy.
I had to switch mode to permissive for it to work. It should be added in too.
Comment 3 Daniel Walsh 2006-08-18 06:42:34 EDT
Please attach avc messages from /var/log/messages.
Comment 4 Jim Cornette 2006-08-18 07:11:13 EDT
Created attachment 134436 [details]
There are messages in /var/log/audit/audit.log

No AVC messages in /var/log/messages. The messages are in
Comment 5 Daniel Walsh 2006-08-22 09:42:42 EDT
Fixed in selinux-policy-2.3.7-2.fc5
Comment 6 Daniel Walsh 2006-08-22 10:19:52 EDT
Change to modified
Comment 7 Jim Cornette 2006-08-23 21:26:28 EDT
I installed selinux-policy-2.3.7-2.fc5 and then relabeled the system afterwards
to ensure that the system contained intended contents since I used the temporary
fix from the previous bug report.
Seamonkey starts fine in enforcing mode after the relabeling with touch
/.autorelabel followed by a reboot.

The installation of the rpm had a long delay during install on the last entry
and a process related to selinux was using a substantial amount of CPU time. I
don't recall the exact process. 
Comment 8 Daniel Walsh 2006-08-24 08:11:43 EDT
Yes this is because the rpm package is updating the files it has changed.  It is
using restorecon and sometimes can take a while.
Comment 9 Jim Cornette 2006-08-24 20:56:03 EDT
Thanks for clarifying. I suspected that it was locked up but allowed some more
time. I checked the processes with top and recognized the program consuming 90
plus percentage of the cpu was an selinux program. (Read the man pages to be sure)
Anyway, I figured I'd mention it in case it was out of the expected behavior scope.

Note You need to log in before you can comment on or make changes to this bug.