508118 - Text relocation make SELinux angry

Status: RESOLVED FIXED

(Firefox :: Sync, defect)

Description

[Matěj Cepl]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; cs-CZ; rv:1.9.1.1) Gecko/20090717 Fedora/3.5.1-3.fc11 Firefox/3.5.1
Build Identifier: 0.5 (on Fedora 11/x86_64) with Mozilla/5.0 (X11; U; Linux x86_64; cs-CZ; rv:1.9.1.1) Gecko/20090717 Fedora/3.5.1-3.fc11 Firefox/3.5.1

See the attached SELinux report pointing to http://people.redhat.com/drepper/selinux-mem.html

Reproducible: Always

Steps to Reproduce:
1.use weave
2.
3.
Actual Results:  
get sealert alert

Expected Results:  
nothing

Comment 1

[Matěj Cepl]

Attachment: output of sealert

Comment 3

[Jonathan Pritchard]

I'm also seeing this on Fedora Linux.

Comment 4

[Tom Hughes]

A better reference for the specific problem here is:

http://people.redhat.com/drepper/textrelocs.html

Running eu-findtextrel reports the following tet relocations:

either the file containing the function 'NSGetModule' or the file containing the function '_fini' is not compiled with -fpic/-fPIC
either the file containing the function 'NSGetModule' or the file containing the function '_fini' is not compiled with -fpic/-fPIC
either the file containing the function 'NSGetModule' or the file containing the function '_fini' is not compiled with -fpic/-fPIC

Comment 5

[Heiko Adams]

Attachment: setroubleshoot output for weave 0.7 on fedora 11

On Fedora 11 with activated selinux it is still not possible to use weave because of a new selinux exception

Comment 6

[Jonathan Pritchard]

Surprisingly, I've stopped seeing this everytime Weave has an update. I moved from 0.6 - 0.7 and I didn't see the now familiar setroubleshooter alert about the WeaveCrypto.so component.

Comment 7

[Heiko Adams]

It's a fresh weave installation.

Comment 8

[Jonathan Pritchard]

(In reply to comment #7)
> It's a fresh weave installation.

Sure, I'm just saying that I also saw this every time Weave updated and now I don't.

Comment 9

[Heiko Adams]

I've retested this with a fresh firefox profile and the problem is still present.

Comment 10

[Ed Lee :Mardak]

There have been reports of the latest Karmic working after updating and selecting "Start Over".

Comment 11

[Heiko Adams]

Selecting "Start Over" doen't fix the problem for me because the crypto module isn't loaded. And for me the selinux exception looks like there is a temporary file created at startup which has a wrong selinux lable.

Comment 12

[Paul Dickson]

I had to disable NoScript to allow the WeaveCrypto.so to be used (after I did a "chcon -t textrel_shlib_t <file>").  Once Mozilla started weave and loaded WeaveCrypto.so, I was able to enable NoScript.

I last previously used 0.6-pre3, but was never able to get the released 0.6 to work.  Using the 'Start Over' option got Weave functioning again for 0.7.

Comment 13

[Heiko Adams]

Attachment: SELinux error message weave 1.0b1 on Fedora 11

Comment 14

[Heiko Adams]

Additional infos on how to fix this might be found here: https://bugzilla.redhat.com/show_bug.cgi?id=533566

Comment 15

[Jonathan Pritchard]

(In reply to comment #14)
> Additional infos on how to fix this might be found here:
> https://bugzilla.redhat.com/show_bug.cgi?id=533566

I'll just put the link recommended in that now closed bug report here. They're basically asking the Weave developers to look at this link - http://people.redhat.com/~drepper/selinux-mem.html - and to fix the problem as it is allegedly on their end.

I'm seeing this very badly with Weave 1.0b1 because now I can't find the way to enable/disable weave in about:config, as this was 'fixed' in a previous bug. This was my workaround. To run the selinux relabelling and then force a re-enable of Weave.

Comment 16

[Ed Lee :Mardak]

Dolske, have you run into SELinux issues before?

Comment 17

[Justin Dolske [:Dolske]]

First I can remember hearing of it.

Sounds like the problem is due to compiling without -fPIC, but the Weave makefile seems to specify it. Comment 4 makes is sound like only WeaveCryptoModule.cpp has the problem, which is kind of weird.

Comment 18

[Tom Hughes]

Yeah I'm not sure eu-findtextrel is talking sense at all. Looking at it with "objdump -R" the problem relocations (the only ones which fall within the text segment) are:

0000631b R_386_PC32        _ZN18nsCString_externalC1ERK10nsACString
00006632 R_386_PC32        _ZN18nsCString_externalC1ERK10nsACString
00006c81 R_386_PC32        _ZN18nsCString_externalC1ERK10nsACString

Running that through c++filt decodes the name as:

nsCString_external::nsCString_external(nsACString const&)

That appears to come from libxpcomglue.a or libxpcomglue_s.a (it seems to be in both) in the SDK. So presumably those weren't compiled with -fPIC.

Comment 19

[Justin Dolske [:Dolske]]

bsmedberg: any clue here?

Comment 20

[Benjamin Smedberg]

Can someone link or attach a weave build log? I'd like to see the exact commands used to link the sharedlib.

Typically bad relocations like this on x86 show up as link errors on x86-64... are you guys building x86-64 weave and does it have any build problems?

Comment 21

[Tom Hughes]

I haven't actually managed to get it to build myself, but I believe that the command it is using is:

c++ -m32 -o WeaveCrypto.so WeaveCrypto.cpp WeaveCryptoModule.cpp -pthread -pipe -DMOZILLA_STRICT_API -Wl,-dead_strip -Wl,-exported_symbol -Wl,-z,defs -Wl,-h,WeaveCrypto.so -Wl,-rpath-link,/home/thh/src/xulrunner-sdk/bin /home/thh/src/xulrunner-sdk/lib/libxpcomglue_s.a -L/home/thh/src/xulrunner-sdk/lib -L/home/thh/src/xulrunner-sdk/bin -lxpcom_core -lxpcomglue -lxpcomglue_s -lnspr4 -lcrmf -lsmime3 -lssl3 -lnss3 -lnssutil3 -lplds4 -lplc4

Comment 22

[Benjamin Smedberg]

That command doesn't appear to have -fPIC, but it does link a very odd combination of libraries (xpcomglue_s, xpcom_core, and xpcomglue, xpcomglue_s again...). It should be linking -lxpcomglue_s -lxpcom

Comment 23

[Tom Hughes]

Sorry, that was my fault - I had added cppflags="-m32" to my make line to try and get a 32 bit build but that caused it not to add any of the standard flags in the makefile. The real command is:

c++ -shared -pipe -Os -fPIC -fno-rtti -fno-exceptions -fno-strict-aliasing -fno-common -pthread -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -include xpcom-config.h -I/home/thh/src/xulrunner-sdk/include -I/home/thh/src/xulrunner-sdk/include/system_wrappers -I/home/thh/src/xulrunner-sdk/include/nss -I/home/thh/src/xulrunner-sdk/include/xpcom -I/home/thh/src/xulrunner-sdk/include/string -I/home/thh/src/xulrunner-sdk/include/pipnss -I/home/thh/src/xulrunner-sdk/include/nspr -I/home/thh/src/xulrunner-sdk/sdk/include -fshort-wchar -o WeaveCrypto.so WeaveCrypto.cpp WeaveCryptoModule.cpp -pthread -pipe -DMOZILLA_STRICT_API -Wl,-dead_strip -Wl,-exported_symbol -Wl,-z,defs -Wl,-h,WeaveCrypto.so -Wl,-rpath-link,/home/thh/src/xulrunner-sdk/bin /home/thh/src/xulrunner-sdk/lib/libxpcomglue_s.a -L/home/thh/src/xulrunner-sdk/lib -L/home/thh/src/xulrunner-sdk/bin -lxpcom_core -lxpcomglue -lxpcomglue_s -lnspr4 -lcrmf -lsmime3 -lssl3 -lnss3 -lnssutil3 -lplds4 -lplc4

It still has the problem that it links xpcomglue before xpcomglue_s though, which I assume is the problem? The _s is a PIC version intended for shared builds?

Comment 24

[Justin Dolske [:Dolske]]

See also http://hg.mozilla.org/labs/weave/file/default/crypto/src/Makefile#l245

I've never actually built this on x64. The Makefile bits for WeaveCrypto date back to the early days of Weave, so it's entirely possible we've just been sneaking by with a hastily written config.

Comment 25

[Benjamin Smedberg]

At least the libs setting should use the wince version on all platforms, and the part which adds xpcom_core on Linux should be removed.

Comment 26

[Edward Rudd]

Can we update the title on this bug to something more appropriate?  

Also, not if it needs to be filed separately or not as it is directly related to this issue..  Anyways.. here goes.

1) Update weave (ie to 1.0b1 or now to 1.0b2)
2) restart firefox via the nice restart button in the addons dialog.
3) SELinux displays message "woah there! we can't allow text relocation"
4) goto command line and run restorecon -rv ~/.mozilla (I have additional rules defined for Selinux and why selinux doesn't do this automatically I'll never know and is a separate thing entirely.)
5) restart firefox again (via ubiquity)
6) weave still refuses to enable it self.  (and selinux is happy).
7) check about:config..  nope weave is not disabled
8) quit firefox
9) start firefox
10) weave STILL disabled?!?!
11) rinse and repeat a few times
12) still disabled?
13) disable ANY EXTENSION
14) restart firefox
15) weave works.
16) re-enable extension
17) restart firefox
18) weave STILL works?
19) Sit with a puzzled look on your face?!?

This is in Fedora 11 i386 using distribution firefox with targed selinux profile (I have it enabled so I can make sure a game I'm porting to linux works beautifully:-D )

Comment 27

[Eugene Kanter]

I had selinux enabled during my initial sign up. It resulted in no keys created in my storage area on mozilla servers as it turned out later.

Even though I applied required selinux tag to allow string relocation weave still can't work since no keys are found. There seems to be no feature to regenerate the keys. Should I file a separate bug/feature to allow key pair regeneration?

Comment 28

[Edward Rudd]

Did you try disabling and re-enabling the addon? Look at comment #26 and see if that helps get it working again.

Comment 29

[Mike Connor [:mconnor]]

This isn't awesome, but won't block 1.0, since I really don't want to futz with changing the binaries we've been shipping for five months.

bug 513798 is the long-term fix.

Comment 30

[Mike Connor [:mconnor]]

dolske, can you fix this?

Comment 31

[Justin Dolske [:Dolske]]

Low priority at the moment, it would help if someone already building on Fedora / SELinux could see if the info in comment 25 helps.

Comment 32

[Mike Connor [:mconnor]]

Fixed for trunk builds, which is as fixed as this will get.

Comment 33

[Heiko Adams]

after updating to latest weave rc SELinux claims missing text relocation again.

Using Fedora 13

Comment 34

[Jonathan Pritchard]

Weave was also meant to have fixed that by moving from a binary for the cryptography library to a Javascript version.

Comment 35

[Tom Hughes]

Well Weave 1.3 is now out but this problem still seems to be present - there is still an so for the crypto and it still has the problematic relocations and selinux still complains.

Comment 38

[Jonathan Pritchard]

I am still seeing this with Firefox Sync 1.4 on Fedora 13.

Comment 39

[Mike Connor [:mconnor]]

This is only fixed for Firefox 3.7a3 and higher.  3.5/3.6 will continue to see this issue.

Comment 40

[bugzilla.mozilla.org]

So what ? Firefox 3.6 is not supported anymore ? Why not issuing a bugfix for the 3.6 branch ?

Comment 41

[Mike Connor [:mconnor]]

It's supported, and works for lots of users.  Unless you're using SELinux.

If you are using SELinux, your options are "don't use SELinux against Firefox" or "use Firefox 4 Beta 1 or higher"

Comment 42

[Christopher Aillon (sabbatical, not receiving bugmail)]

FWIW, For many people, disabling SELinux is not an option.  Enterprises deploy with SELinux on, and normal users cannot tweak that.

Comment 43

[Edward Rudd]

Unfortunately I do believe the point here is that it is a non-trivial change to backport the changes that are going to be in Firefox 4.0 to 3.6, so you have to wait.    Now if you want to use it with selinux enabled with FF 3.6, which I am doing with Fedora 12 and Fedora 13 (just upgraded the system) and it works fine with these local selinux file_context overrides.


/home/[^/]+/.mozilla/firefox/.+/WeaveCrypto.so -- system_u:object_r:textrel_shlib_t:s0
/home/[^/]+/.mozilla/firefox/.+/npquakelive\.(i386|x64)\.so -- system_u:object_r:textrel_shlib_t:s0
/home/[^/]+/.quakelive/.+\.so -- system_u:object_r:textrel_shlib_t:s0

(threw one rules for Quake live just for fun, to show it's not a weave only issue).

What I do with this, is when I upgrade weave, I have firefox restart and in a terminal at the same time I run 

restorecon -Rv ~/.mozilla

a few times until I see the "weave" changes displayed (ie.. waiting for FF to move the updated plugin into place and before it fully loads it).

Yeah it's not perfectly clean, but it does work and have been doing this since weave 0.6.  From my understanding the restorecond is supposed to automatically do this, but I have not seen it do that ever.

Please just wait for FF 4.0 and add these overrides to make life easier, or use a FF 4.0 beta.

Oh, and really for "enterprise deployments" I would figure they wouldn't want users to install an addon that throws data like this out to a cloud (even if encrypted), Or they would be providing their own sync server and thus should probably make system install packages that have the correct selinux tags already set and deploy them on the systems.

Either way, this issue IS fixed for the "next release" of Firefox, and I agree with the Mozilla's reasoning for not backporting things to 3.6. Let them focus on making a quality 4.0 release.