Firefox apparmor blocks old profile location

[Stephen Gildea]

Binary package hint: firefox

The apparmor profile for Firefox allows locking of
~/.mozilla/**/.parentlock with fcntl SETLK, which Firefox uses to
detect more than one instance of itself using the same profile.

However, I have old profiles stored in the old location ~/.firefox/**/,
and on upgrade from Hardy to Lucid, I find apparmor prevents Firefox
from locking my ~/.firefox/**/.parentlock file. The symptom is a
popup saying 'Firefox cannot use the profile "xyz" because it is in use.'

(If you run "firefox -P some_profile", you'll get a popup saying
"Firefox is already running, [sic] but is not responding.")

Please add support for the old profile location, by adding these
rules:

--- etc/apparmor.d/usr.bin.firefox-dist-10.04 2010-07-23 03:06:34.000000000 -0700
+++ etc/apparmor.d/usr.bin.firefox 2010-08-25 21:15:02.000000000 -0700
@@ -110,6 +110,15 @@
   owner @{HOME}/.mozilla/plugins/** rm,
   owner @{HOME}/.mozilla/**/plugins/** rm,

+ # Per-user configuration, for profiles originally created by old
+ # versions of Firefox.
+ owner @{HOME}/.firefox/ rw,
+ owner @{HOME}/.firefox/** rw,
+ owner @{HOME}/.firefox/**/*.sqlite* k,
+ owner @{HOME}/.firefox/**/.parentlock k,
+ owner @{HOME}/.firefox/plugins/** rm,
+ owner @{HOME}/.firefox/**/plugins/** rm,
+
   #
   # Extensions
   # /usr/share/.../extensions/... is already covered by '/usr/** r', above.

[Micah Gersten (micahg)]

@Securtiy team, Chris Coulson
I think we should migrate the old profile rather than adding this to the apparmor profile. Thoughts?

[Micah Gersten (micahg)]

Thank you for reporting this to Ubuntu. Would you happen to remember which version of Firefox created these profiles?

[Stephen Gildea (stepheng+launchpad)]

> Would you happen to remember which version of Firefox created these profiles?

I'm no longer sure, but I would guess Firefox 0.9.

[Jamie Strandboge (jdstrand)]

I have no strong opinion on migrate vs not-migrate but feel ~/.firefox to be a worthwhile addition to the profile. If we are not going to migrate, then I suggest the following:
- owner @{HOME}/.mozilla/ rw,
- owner @{HOME}/.mozilla/** rw,
- owner @{HOME}/.mozilla/**/*.sqlite* k,
- owner @{HOME}/.mozilla/**/.parentlock k,
- owner @{HOME}/.mozilla/plugins/** rm,
- owner @{HOME}/.mozilla/**/plugins/** rm,
+ owner @{HOME}/.{firefox,mozilla}/ rw,
+ owner @{HOME}/.{firefox,mozilla}/** rw,
+ owner @{HOME}/.{firefox,mozilla}/**/*.sqlite* k,
+ owner @{HOME}/.{firefox,mozilla}/**/.parentlock k,
+ owner @{HOME}/.{firefox,mozilla}/plugins/** rm,
+ owner @{HOME}/.{firefox,mozilla}/**/plugins/** rm,

[Chris Coulson (chrisccoulson)]

Do we actually use ~/.firefox in any currently support version of Ubuntu? Or is this from some really old and now unsupported version? If it's the latter, then I think I'd prefer not to migrate, which would add more complexity to the startup script. (Especially not to fix what looks like a very rare corner case, this late in the cycle)

[Launchpad Janitor (janitor)]

This bug was fixed in the package firefox - 4.0~b7+nobinonly-0ubuntu1

---------------
firefox (4.0~b7+nobinonly-0ubuntu1) natty; urgency=low

  * New upstream release v4.0 B7 (FIREFOX_4_0b7_RELEASE)

  [ Chris Coulson <email address hidden> ]
  * Don't build with -pie on Natty (LP: #663294)
    - update debian/rules
  * Update mozclient for mozilla-central
    - update debian/mozclient/firefox.conf
    - update debian/mozclient/firefox.mk
  * Auto-generate Debhelper files at build time, using the Mozilla
    text preprocessor. This makes it easier to maintain branches for
    different versions (because we'll avoid having different filenames for
    each version, which makes merging really difficult). We can also use
    standard preprocessor directives for our different build options,
    which means we drop a lot of logic from debian/rules
    - rename debian/abrowser.desktop => debian/abrowser.desktop.in
    - add debian/abrowser-branding.install.in
    - add debian/abrowser-branding.links.in
    - add debian/firefox-branding.install.in
    - add debian/firefox-branding.links.in
    - rename debian/apport/firefox.py => debian/apport/firefox.py.in
    - rename debian/firefox-final.desktop => debian/firefox-final.desktop.in
    - rename debian/firefox-gnome-support.install =>
       debian/firefox-gnome-support.install.in
    - rename debian/firefox.dirs => debian/firefox.dirs.in
    - rename debian/firefox.install => debian/firefox.install.in
    - rename debian/firefox.links => debian/firefox.links.in
    - rename debian/firefox.menu => debian/firefox.menu.in
    - rename debian/firefox.postinst.in => debian/firefox.postinst.in
    - rename debian/firefox.postrm.in => debian/firefox.postrm.in
    - rename debian/firefox.preinst.in => debian/firefox.preinst.in
    - rename debian/firefox.prerm.in => debian/firefox.prerm.in
    - rename debian/firefox.xml => debian/firefox.xml.in
    - updated debian/abrowser.desktop.in
    - updated debian/firefox-final.desktop.in
    - updated debian/firefox-gnome-support.install.in
    - updated debian/firefox.dirs.in
    - updated debian/firefox.install.in
    - updated debian/firefox.links.in
    - updated debian/firefox.menu.in
    - updated debian/firefox.postinst.in
    - updated debian/firefox.postrm.in
    - updated debian/firefox.preinst.in
    - updated debian/firefox.prerm.in
    - updated deibna/firefox.xml.in
    - updated debian/rules
    - add debian/firefox-mozsymbols.install.in
  * Simplify generating the Apport blacklist file to remove a superfluous
    debian/rules target
    - rename debian/apport/blacklist => debian/apport/firefox.in
    - update debian/rules
  * Auto-generate debian/control in the clean target
    - add debian/control.pp
    - update debian/rules
  * Drop the ability to disable patches on a per-release basis. This adds
    additional complexity, and we're not really using it at the moment.
    We can always add it back again if we need it
    - remove debian/disable-patches.sh
    - update debian/rules
    - remove debian/patches/series-disable-patches.8.04
  * Rework the branding selection logic so that we automatically use
    the nightly branding for nightl...