Bug 180726 - Firefox/Evolution/NSS init fails on x86_64 with selinux set to enforcing
Firefox/Evolution/NSS init fails on x86_64 with selinux set to enforcing
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: nss (Show other bugs)
5
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Kai Engert (:kaie)
:
: 178706 178973 181601 181976 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-09 16:04 EST by Juergen Bullinger
Modified: 2010-07-12 17:13 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-15 03:05:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch (544 bytes, patch)
2006-02-15 02:56 EST, Kai Engert (:kaie)
no flags Details | Diff

  None (edit)
Description Juergen Bullinger 2006-02-09 16:04:32 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de-DE; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
if i start firefox i get the message, that it can not use encryption (SSL is disabled). Evolution exits immediately after starting. When I start it from a command line I get a message also refering to missing encryption support.

I am getting this message since yesterday evening when I did a yum update.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. install FC5 Test2 x86_64
2. yum update
3. start firefox/start evolution
  

Actual Results:  encryption is not supported

Expected Results:  encryption would be nice :o)
Without encryption you can not even file bugs in bugzilla unless you have a spare installation.

Additional info:

yum update seemed to hang several times, but I managed to resolve the conflicts and yum update now says that everything is up to date.
Comment 1 Kai Engert (:kaie) 2006-02-09 16:14:55 EST
Juergen, there is currently a large rebuild of most RPM packages underway. I
hope what you see is a consequence of incompatible packages.

I will shortly be able to test with a rawhide machine myself and will try to
reproduce.
Comment 2 Kai Engert (:kaie) 2006-02-09 19:32:09 EST
Juergen, I completed updating my machine. There were more than 500 packages
changed during the last 2 days.

I was able to start Firefox and surf to https:// pages.
I was able to start up Evolution.

Can you please update your computer again, and repeat your test?
Let us know if you still have the problem.
Thanks.
Comment 3 Juergen Bullinger 2006-02-11 11:22:41 EST
Hi Kai,

I already have updated my system. Yum has automatically updated 817 packages on
my machine (i guess my provider is happy now :o).
Unfortunately I still have the problem.
What can I do? Do you need any additional info? Please let me know.

Kind regards
Juergen
Comment 4 Kai Engert (:kaie) 2006-02-13 05:35:37 EST
I still can not reproduce your problem.

Maybe your Firefox profile is corrupt?
To create an additional profile and run it:
  firefox -CreateProfile test
  firefox -P test
Can you access https://bugzilla.redhat.com using that profile?

If you still have problems, what is the exact error message displayed?

What is the output of this command on your system?
  rpm -qa | egrep 'nss-|nspr-|firefox-'

What is the output of
  /usr/sbin/sestatus

Thanks.
Comment 5 Kai Engert (:kaie) 2006-02-13 05:37:18 EST
Actually, I just realize that I was testing on a i386 system, but you are
reporting the problem on a x86_64 system.

I will try to find a system to test that, but please still do the above tests,
it might help to understand the problem.
Comment 6 Juergen Bullinger 2006-02-13 17:22:57 EST
Thank you for your answer. I'll try that later. Unfortunately I always have to
reboot, to switch between the test environment and the FC4-environment on which
I can access bugzilla.

Please note, that also evolution doesn't work. It says something about a camel
:o)  I hope it does not call me a camel
...and then it says that encryption support is not working or something like
this. ...That are evolutions last words, before it dies.
Comment 7 Kai Engert (:kaie) 2006-02-13 17:49:00 EST
Maybe you could use konqueror as a backup to access bugzilla, while in rawhide,
until we have resolved this issue.
Comment 8 Juergen Bullinger 2006-02-13 18:30:41 EST
Hi Kai,

here is the output:

[juergen@prime ~]$ rpm -qa | egrep 'nss-|nspr-|firefox-'
nspr-4.6.1-2.1
nss-3.11-3.1
nspr-devel-4.6.1-2.1
firefox-1.5.0.1-2.1
nss-devel-3.11-3.1
xmlsec1-nss-1.2.9-4.1
nspr-4.6.1-2.1
nss-3.11-3.1

[juergen@prime ~]$ evolution
CalDAV Eplugin starting up ...

(evolution:2812): evolution-smime-WARNING **: Failed all methods for
initializing NSS

(evolution:2812): camel-WARNING **: Failed to initialize NSS


unfortunately I forgot to do sestatus. Do you still need this info?
Comment 9 Kai Engert (:kaie) 2006-02-13 19:02:56 EST
Jürgen, did you try the "new profile" test? That was the most important one.
Comment 10 Kai Engert (:kaie) 2006-02-13 19:11:29 EST
I installed a FC5 test 2 x86_64 system.
I can use Firefox to access https:// sites, no problems.

I will now do "yum update" to bring my system to the latest state and make a
final test.
Comment 11 Tim Mayberry 2006-02-13 22:59:36 EST
I also experience this problem on x86_64, I think it started with updates from a
few days after the test 2 build. Setting selinux to Permissive mode allows
evolution to start. If you need more information let me know.
Comment 12 Kai Engert (:kaie) 2006-02-14 00:12:26 EST
I finished updating my system to latest rawhide.

With default parameters, selinux enabled, I can't even log in!
Something seems to be broken at a different level.

However, I added "enforcing=0" as a boot prompt parameter, and I can log in,
start Firefox and Evolution fine, and access https:// addresses.

Still, I can't reproduce a problem where ONLY firefox/evolution are broken.
Comment 13 Kai Engert (:kaie) 2006-02-14 09:20:29 EST
I updated my system again, and the other problem I reported, not being able to
login at all, is gone.

And now, finally, I'm able to reproduce this bug!

It occurrs with selinux enforcing only, and work fine in permissive mode.

I'll now try to find out what's happening.
Comment 14 Kai Engert (:kaie) 2006-02-14 10:28:56 EST
I used "certutil" from package nss-tools to reproduce the problem in a minimal
environment.

Here is some output from a WORKING i386 rawhide:


[kaie@leise ~]$ uname -a
Linux leise 2.6.15-1.1948_FC5 #1 Mon Feb 13 21:05:36 EST 2006 i686 athlon i386
GNU/Linux
[kaie@leise ~]$
[kaie@leise ~]$ cat /etc/fedora-release
Fedora Core release 4 (Rawhide)
[kaie@leise ~]$
[kaie@leise ~]$ /usr/sbin/sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 20
Policy from config file:        targeted
[kaie@leise ~]$
[kaie@leise ~]$ cd /home/kaie/certs
[kaie@leise certs]$
[kaie@leise certs]$ sha1sum *.db
c67db9cf4a893d7182c767d8455a1e5ac2a0bccf  cert8.db
78eb5ccd16f0517530801e916084b8b3464cc5f6  key3.db
2432de67eab0f393ba25c5ca54c41e8281901f2b  secmod.db
[kaie@leise certs]$
[kaie@leise certs]$ certutil -d . -L |grep -i thawte
Thawte Personal Freemail Issuing CA - Thawte Consulting      c,,
Kai Wolfgang Engert's Thawte Consulting (Pty) Ltd. ID        u,u,u
[kaie@leise certs]$
[kaie@leise certs]$ strace certutil -d . -L 2>&1 |egrep -i 'mprotect|mmap' |grep
-i exec
mmap2(NULL, 172716, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x447000
mmap2(NULL, 163596, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x228000
mmap2(NULL, 528204, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x75d000
mmap2(NULL, 19364, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x73d000
mmap2(NULL, 12848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x68a000
mmap2(NULL, 228832, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x49f000
mmap2(NULL, 70076, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x111000
mmap2(NULL, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x580000
mmap2(NULL, 1217916, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x250000
mmap2(NULL, 332964, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xa8a000
mmap2(NULL, 235596, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x59a000
mmap2(NULL, 259800, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0xf43000
[kaie@leise certs]$


In the middle we execute certutil, and it dumps some certs, no problems.
Now the same series of commands run on a BROKEN x86_64 rawhide system:


[kaie@kaiefast certs]$ uname -a
Linux kaiefast 2.6.15-1.1948_FC5 #1 SMP Mon Feb 13 21:05:49 EST 2006 x86_64
x86_64 x86_64 GNU/Linux
[kaie@kaiefast certs]$
[kaie@kaiefast certs]$ cat /etc/fedora-release
Fedora Core release 4.91 (Pre-FC5)
[kaie@kaiefast certs]$
[kaie@kaiefast certs]$ /usr/sbin/sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 20
Policy from config file:        targeted
[kaie@kaiefast certs]$
[kaie@kaiefast certs]$ cd /home/kaie/certs
[kaie@kaiefast certs]$
[kaie@kaiefast certs]$ sha1sum *.db
c67db9cf4a893d7182c767d8455a1e5ac2a0bccf  cert8.db
78eb5ccd16f0517530801e916084b8b3464cc5f6  key3.db
2432de67eab0f393ba25c5ca54c41e8281901f2b  secmod.db
[kaie@kaiefast certs]$
[kaie@kaiefast certs]$ certutil -d . -L |grep -i thawte
certutil: function failed: An I/O error occurred during security authorization.
[kaie@kaiefast certs]$
[kaie@kaiefast certs]$ strace certutil -d . -L 2>&1 |egrep -i 'mprotect|mmap'
|grep -i exec
mmap(NULL, 1226080, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ae05e704000
mmap(NULL, 1220048, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ae05e830000
mmap(NULL, 1596808, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ae05e95a000
mmap(NULL, 1066480, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ae05eae1000
mmap(NULL, 1058464, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ae05ebe6000
mmap(NULL, 1281824, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ae05ece9000
mmap(NULL, 1131368, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ae05ee23000
mmap(NULL, 1061152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ae05ef38000
mmap(NULL, 2334888, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ae05f03c000
mmap(NULL, 1400816, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ae05f278000
mmap(NULL, 1355736, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ae05f3d0000
mprotect(0x7fffffa48000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) =
-1 EACCES (Permission denied)
mmap(NULL, 1355736, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x2ae05f53d000
mprotect(0x7fffffa48000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) =
-1 EACCES (Permission denied)
[kaie@kaiefast certs]$


On this system, certutil brings up an error message.
Running the same command under strace shows, we get "permission denied" errors.


If you compare the system environment, kernel version and selinux status are
identical, and the same cert database files are used on both systems.

I don't know why, but i386 and x86_64 make different mmap/mmap2/mprotect calls.
The call to mprotect fails, probably because selinux doesn't want to allow
PROT_EXEC ?


On the broken system I tried
  strace -f firefox 2>&1 |grep -i exec
and
  strace -f evolution 2>&1 |grep -i exec
and they report the same error.
Comment 15 Christopher Aillon 2006-02-14 23:53:11 EST
*** Bug 181601 has been marked as a duplicate of this bug. ***
Comment 16 Ulrich Drepper 2006-02-15 00:27:40 EST
The problem is that /usr/lib64/libfreebl3.so requires an executable stack.  This
is no problem with /usr/lib/libfreebl3.so (i.e., the ia32 version).  To check, use

readelf -l /usr/lib64/libfreebl3.so|fgrep STACK

There is most probably no good reason for this.  It's most likely just an
assembler without the appropirate marker:

.section .note.GNU-stack,"",@progbits


Look through the .o files used to build the DSO and search for one which has not
.note.GNU-stack section (use readelf -S OBJFILE to see the sections).
Comment 17 Ulrich Drepper 2006-02-15 00:31:28 EST
Just for completeness: instead of adding the magic section explictly you can
also compile the asm file by adding --noexecstack to the assembler command line
(i.e., use -Wa,--noexecstack on the gcc command line).  This option exists from
the earliest ExecShield days on.
Comment 18 Kai Engert (:kaie) 2006-02-15 02:54:56 EST
Ulrich, thanks for your concise explanation.

I was able to localize 2 object files, that did not contain the GNU-stack entry.
I decided to use the -Wa,--noexecstack approach.

I'm attaching a patch, it fixed the problem for me.
I just completed to build a new nss-3.11-4 RPM.
Comment 19 Kai Engert (:kaie) 2006-02-15 02:56:55 EST
Created attachment 124666 [details]
Patch
Comment 20 Kai Engert (:kaie) 2006-02-15 03:05:53 EST
Resolving bug as "fixed in rawhide".
Comment 21 Kai Engert (:kaie) 2006-02-15 03:09:45 EST
I filed
  https://bugzilla.mozilla.org/show_bug.cgi?id=327254
to get this issue fixed in the upstream version of NSS.
Comment 22 Wan-Teh Chang 2006-02-15 10:47:49 EST
Ulrich, thank you for helping us track down this bug.

Kai, this bug is already fixed on the NSS_3_11_BRANCH.
https://bugzilla.mozilla.org/show_bug.cgi?id=320497

Did you not include the patch from that bug in the NSS
3.11 RPM?  That patch added

  .section .note.GNU-stack,"",@progbits
  .previous

to the two assembly files.

Ulrich, if a version of gas understands the
.note.GNU-stack section (which is our current approach),
does it also understand the --noexecstack command line
option?  If so, I'd like to switch to the --noexecstack
approach.
Comment 23 Ulrich Drepper 2006-02-15 11:35:58 EST
The use of the .section-based approach requires no special assember support. 
All versions of the assembler understand it.  It's only the linker which in the
end does something special in the presence/absence of such a section.  For the
assembler it's only one more section.  It's more portable but the --noexecstack
option is also very old meanwhile that I don't regard it as a problem.
Comment 24 Juergen Bullinger 2006-02-17 03:23:02 EST
I did a yum update last night.
It updated over 1000 packages with 900 Megs without any problem. Great!
No evolution and firefox work, but I get some messages on startup of evolution.
I'll file them as a separate bug report not to cofuse things.
Comment 25 Kai Engert (:kaie) 2006-02-17 03:34:52 EST
> No evolution and firefox work

Now it works? Great.
Thanks for verifying the bug.
Comment 26 Christopher Aillon 2006-02-18 04:08:43 EST
*** Bug 181976 has been marked as a duplicate of this bug. ***
Comment 27 Christopher Aillon 2006-02-20 11:53:19 EST
*** Bug 178706 has been marked as a duplicate of this bug. ***
Comment 28 Wan-Teh Chang 2006-02-20 14:10:19 EST
*** Bug 178973 has been marked as a duplicate of this bug. ***
Comment 29 Wan-Teh Chang 2006-02-20 17:06:37 EST
*** Bug 178973 has been marked as a duplicate of this bug. ***
Comment 30 GJahchan 2010-06-30 23:42:10 EDT
Just upgraded evolution to 2.30.2-1.fc13.x86_64 and it stopped working.

When I start it from the command line, I get the following:

$ evolution
(evolution:11377): e-data-server-DEBUG: Loading categories from "/home/gjahchan/.evolution/categories.xml"
(evolution:11377): e-data-server-DEBUG: Loaded 29 categories

(evolution:11377): camel-WARNING **: Failed to initialize NSS

Other pertinent System Information
---------------------------------
$ uname -a
Linux fc13.compucenter.org 2.6.33.5-124.fc13.x86_64 #1 SMP Fri Jun 11 09:38:12 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/fedora-release
Fedora release 13 (Goddard)

$ rpm -qa | grep evolution
evolution-2.30.2-1.fc13.x86_64
evolution-help-2.30.2-1.fc13.noarch
evolution-data-server-2.30.2-2.fc13.x86_64

$ rpm -qa | grep '^nss'
nss-3.12.6-7.fc13.i686
nss-util-3.12.6-1.fc13.i686
nss-mdns-0.10-8.fc12.x86_64
nss-sysinit-3.12.6-7.fc13.x86_64
nss-tools-3.12.6-7.fc13.x86_64
nss_ldap-264-9.fc13.x86_64
nss-softokn-3.12.6-3.fc13.i686
nss-util-3.12.6-1.fc13.x86_64
nss-softokn-freebl-3.12.6-3.fc13.x86_64
nss-mdns-0.10-8.fc12.i686
nss-3.12.6-7.fc13.x86_64
nss_db-2.2.3-0.3.pre1.fc13.x86_64
nss_compat_ossl-0.9.6-1.fc13.x86_64
nss-softokn-3.12.6-3.fc13.x86_64
nss-softokn-freebl-3.12.6-3.fc13.i686

$ rpm -qa | grep firefox
firefox-3.6.4-1.fc13.x86_64

$ rpm -qa | grep '^selinux'
selinux-policy-targeted-3.7.19-28.fc13.noarch
selinux-policy-3.7.19-28.fc13.noarch
selinux-doc-1.26-5.noarch

[Unmodified targeted out-of-the-box policy set in enforcing mode].

$ date
Thu Jul  1 06:32:20 EEST 2010

$ sudo yum -y update
Loaded plugins: changelog, presto, refresh-packagekit, security
Skipping security plugin, no data
Setting up Update Process
No Packages marked for Update
Comment 31 Daniel Walsh 2010-07-12 17:04:15 EDT
Are you sure this is a problem with selinux?  Putting the machine in permissive mode does it work?
Comment 32 Christopher Aillon 2010-07-12 17:13:00 EDT
This bug is over 4 years old and is fixed.  If something is now broken, even though the problem looks similar, it's a completely separate issue from the one from 4 years ago, so please file a new bug.  Don't revive bugs from the dead.

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