Comment 4 for bug 501822

1) How would they know to add to their apparmor profile? There's no error message at any time that says that anything failed because of apparmor. Even running from a command line, there's no error message that says that apparmor denied access. If when using a gui, and something was blocked by apparmor a gui popup came up and told me so, and that I would have to modify a file in /etc/apparmor.d if I wanted to proceed, or better a mother-may-I that would do it for me, I would have a little more sympathy for your position, but really, doing development is a normal use of a Linux box. /usr/local/lib is a default location for many things, and not letting firefox load a library that ld.so presents to it is a denial of service. I understand that you want to make sure that firefox can't do something that I didn't ask it to do, but I did ask it, now didn't I?

2) The path for RealPlayer was NOT included. I just added it today. I was also trying to figure out for months why mplayer quit working embedded. I found others with the same problem, but no answers anywhere. Google for people wondering why nphelix.so won't load. You'll find plenty of thrashing about, but not one "add a new rule to a file in /etc/apparmor.d". I'm trying not to come across as security clueless, or worse as a luddite. I just don't agree that it is a security problem, to allow a program to load libraries ld.so wants to load for it.

From the man page for ld.so:

       The necessary shared libraries needed by the program are searched for
       in the following order

       o Using the environment variable LD_LIBRARY_PATH
              (LD_AOUT_LIBRARY_PATH for a.out programs). Except if the exe‐
              cutable is a setuid/setgid binary, in which case it is ignored.

       o From the cache file /etc/ld.so.cache which contains a compiled
              list of candidate libraries previously found in the augmented
              library path.

       o In the default path /lib, and then /usr/lib.

In my case, (as in normal) ld.so.conf, used by ldconfig to know where to look for libraries, the so called augmented security path, has only a line to include all the files found in the directory /etc/ld.so.conf.d, In that directory there's a file libc.conf that has a line /usr/local/lib. That makes ldconfig build the cache including libraries in /usr/local/lib. It's the purpose of the thing! It's been there since 2007, and things used to work just fine. Then after some update firefox started not working with never an error that mentioned security, nor apparmor. There's not a comment in /etc/ld.so.conf, nor a README in /etc/ld.so.conf.d, nor a section in the man pages ld.so(8), nor ldconfig(8), nor a helpful message printed by ldconfig the many times it ran as part of running apt-get upgrade, that would say, this won't work if you use apparmor unless you add rules to make it so. I can tell you that it hasn't been fun! I pretty quickly figured out that removing the libraries from /usr/local/lib was a work around, but it was months before I figured out why. I asked on ubuntu forums, in the gcc-help list, and many other places, and no one knew the answer. I finally got on to it when trying to figure out if somehow, selinux could be harassing me even though I had it turned off. That lead me to /var/log/kern.log and FINALLY I got a clue that lead somewhere, not immediately to apparmor, but only a few minutes later.

It would be nice if apparmor used a variable for places that ld.so could use that would be built automatically and then that variable could be used in rules, but absent that, at the least, /usr/local/lib/** rm, should be included in /etc/apparmor.d/firefox-3.x

Patrick