Comment 2 for bug 501822

Dave Gilbert wrote:
> I think the behaviour you are describing is the correct behaviour; since
> firefox shouldn't normally be reading libraries from /usr/local/lib it
> shouldn't have permissions in apparmor to let it read it.
>
Why would that be? If you have libraries in /usr/local/lib, you have
them there to be used. You have to go out of you way to get ld.so to
look there. What possible rationale could you come up with to say that
firefox shouldn't have access to one of the normal places to put
libraries? (For MANY source packages the $PREFIX is /usr/local. The
only effect of it, since if ld.so chooses that library, it IS the one
that firefox will get, is a denial of service attack on firefox. Also,
it's damn near impossible to figure out what's wrong because there's no
error messages when you run firefox from the gui. It's just a hard
failure. I'm a software engineer and it had me stumped for months! I
asked on all the forums, got some me toos, but nobody had a clue, or
could even give me a path to follow to debug it. I didn't know about
apparmor at all. Hadn't heard of it. I also didn't get to run
realplayer because of this:

Dec 27 16:38:29 dell kernel: [412052.692079] type=1503
audit(1261960709.131:876): operation="open" pid=16346 parent=1
profile="/usr/lib/firefox-3.5*/firefox{,*[^s][^h]}" requested_mask="::r"
denied_mask="::r" fsuid=1002 ouid=0
name="/opt/real/RealPlayer/mozilla/nphelix.so"

I suppose you'd say there's no reason for firefox to access
/opt/real/RealPlayer/mozilla/** either, but these are normal
configurations, and on ubuntu with this setup, it fails for normal use.
That's user hostile.

Developers are normal users of ubuntu, no?
> Dave
>
>