Firefox fails to create profile's permanent storage

[RJ Johnson]

When creating a new profile (on first launch or with "firefox -P"),
Firefox fails to create the
"~/.mozilla/firefox/<profile>/storage/permanent" folder.

I have observed this behavior with Firefox 85, 86, and 78esr, although
more versions are likely affected. This behavior was observed on a
machine running -current.

The two most obvious symptoms of this failure are the browser's Web
Developer tools showing no page source in the Inspector tab (non-esr)
and various error messages in the Browser Console relating to IndexedDB.

This failure is caused by unveil. When creating a profile, Firefox
begins checking each directory in the path
"/home/<user>/.mozilla/firefox/<profile>/storage/permanent" for
existence (i.e., "/home" then "/home/<user>" then ...). If any directory
in this chain does not exist, Firefox gives up on creating the
"permanent" folder. This is easily observed in a ktrace. (I did
"ktrace -id firefox -P". Search for "permanent".) Since Firefox has no
access to "/home" (despite having access to the profile folder), the
"permanent" folder is never created.

The easiest way to fix this issue, for profiles both new and old, is to
manually create the "permanent" folder after Firefox creates the profile
for you. Once this folder exists, Firefox seems to have no more issues.
It only has trouble creating this folder initially.

There are two other possible "fixes" involving unveil which I include
for completeness only. Both of these changes can be reverted after
running Firefox once with them applied. The first is to disable
"unveil.main". The second is to add:

/home r
~ r

to "unveil.main". This allows the directory existence checks to pass,
and Firefox happily creates the "permanent" folder.

[Landry Breuil-5]

On Thu, Mar 04, 2021 at 07:30:18AM +0000, RJ Johnson wrote:

> When creating a new profile (on first launch or with "firefox -P"),
> Firefox fails to create the
> "~/.mozilla/firefox/<profile>/storage/permanent" folder.
>
> I have observed this behavior with Firefox 85, 86, and 78esr, although
> more versions are likely affected. This behavior was observed on a
> machine running -current.
>
> The two most obvious symptoms of this failure are the browser's Web
> Developer tools showing no page source in the Inspector tab (non-esr)
> and various error messages in the Browser Console relating to IndexedDB.
>
> This failure is caused by unveil. When creating a profile, Firefox
> begins checking each directory in the path
> "/home/<user>/.mozilla/firefox/<profile>/storage/permanent" for
> existence (i.e., "/home" then "/home/<user>" then ...). If any directory
> in this chain does not exist, Firefox gives up on creating the
> "permanent" folder. This is easily observed in a ktrace. (I did
> "ktrace -id firefox -P". Search for "permanent".) Since Firefox has no
> access to "/home" (despite having access to the profile folder), the
> "permanent" folder is never created.
>
> The easiest way to fix this issue, for profiles both new and old, is to
> manually create the "permanent" folder after Firefox creates the profile
> for you. Once this folder exists, Firefox seems to have no more issues.
> It only has trouble creating this folder initially.

That's a good finding. Someone (tm) (not me) with enough motivation
should look into fixing that in the code. Looking for 'PERMANENT' on
searchfox.org, the corresponding codepath seems to be around
https://searchfox.org/mozilla-central/source/dom/quota/ActorsParent.cpp#3548

im not 100% sure at all, but *maybe* the method creating the dir
hierarchy is
https://searchfox.org/mozilla-central/source/xpcom/io/nsLocalFileUnix.cpp#360 .

Or somewhere else. That's a 'nice' maze.. Good luck !

Landry

[RJ Johnson]

> im not 100% sure at all, but *maybe* the method creating the dir
> hierarchy is
> https://searchfox.org/mozilla-central/source/xpcom/io/nsLocalFileUnix.cpp#360 .

You were right. I've created a bug on Bugzilla at
https://bugzilla.mozilla.org/show_bug.cgi?id=1697721 about this issue.

If you are interested, a patch-compatible version is below.


Index: xpcom/io/nsLocalFileUnix.cpp
--- xpcom/io/nsLocalFileUnix.cpp.orig
+++ xpcom/io/nsLocalFileUnix.cpp
@@ -365,6 +365,8 @@ nsLocalFile::CreateAllAncestors(uint32_t aPermissions)
   // <jband> I promise to play nice
   char* buffer = mPath.BeginWriting();
   char* slashp = buffer;
+  int mkdir_result = 0;
+  int mkdir_errno;

 #ifdef DEBUG_NSIFILE
   fprintf(stderr, "nsIFile: before: %s\n", buffer);
@@ -393,9 +395,9 @@ nsLocalFile::CreateAllAncestors(uint32_t aPermissions)
 #ifdef DEBUG_NSIFILE
     fprintf(stderr, "nsIFile: mkdir(\"%s\")\n", buffer);
 #endif
-    int mkdir_result = mkdir(buffer, aPermissions);
-    int mkdir_errno = errno;
+    mkdir_result = mkdir(buffer, aPermissions);
     if (mkdir_result == -1) {
+      mkdir_errno = errno;
       /*
        * Always set |errno| to EEXIST if the dir already exists
        * (we have to do this here since the errno value is not consistent
@@ -408,23 +410,22 @@ nsLocalFile::CreateAllAncestors(uint32_t aPermissions)
       }
     }

-    /* Put the / back before we (maybe) return */
+    /* Put the / back */
     *slashp = '/';
-
-    /*
-     * We could get EEXIST for an existing file -- not directory --
-     * with the name of one of our ancestors, but that's OK: we'll get
-     * ENOTDIR when we try to make the next component in the path,
-     * either here on back in Create, and error out appropriately.
-     */
-    if (mkdir_result == -1 && mkdir_errno != EEXIST) {
-      return nsresultForErrno(mkdir_errno);
-    }
   }

 #ifdef DEBUG_NSIFILE
   fprintf(stderr, "nsIFile: after: %s\n", buffer);
 #endif
+
+  /*
+   * We could get EEXIST for an existing file -- not directory --
+   * but that's OK: we'll get ENOTDIR when we try to make the final
+   * component of the path back in Create and error out appropriately.
+   */
+  if (mkdir_result == -1 && mkdir_errno != EEXIST) {
+    return NS_ERROR_FAILURE;
+  }

   return NS_OK;
 }

[Landry Breuil-5]

On Thu, Mar 11, 2021 at 09:03:13AM +0000, RJ Johnson wrote:
> > im not 100% sure at all, but *maybe* the method creating the dir
> > hierarchy is
> > https://searchfox.org/mozilla-central/source/xpcom/io/nsLocalFileUnix.cpp#360 .
>
> You were right. I've created a bug on Bugzilla at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1697721 about this issue.
>
> If you are interested, a patch-compatible version is below.

well, thanks for that ! I'll make sure this is properly tracked.

note that in the upcoming 87.0, there's another issue with unveil and
downloads, being tracked in
https://bugzilla.mozilla.org/show_bug.cgi?id=1696958 - i dunno if those
issues can be more or less linked with each other..

Landry