Broken executables in extensions in Firefox 3.6

Dave Townsend


Reposted from my blog in order to spread the word:

If you are an extension developer and include executable files in your XPI package (binary or shell scripts) then you may be seeing problems in Firefox 3.6.

Back between Firefox 3.6 beta and Firefox 3.6 RC we took a small fix to the extension manager that changed how we extract the files from the XPI package. The fix involved adjusting how we accessed files to avoid hitting problems with certain anti-virus tools that would occasionally lock files in the middle of extraction making us fail to install the add-on. A side effect to this fix leaves us setting file permissions on the extracted files in a slightly different way to previously. This side effect means that the executable permission is getting stripped from all extracted files. If you try to execute these files with nsIProcess it will likely fail.

There is a bug on file and I have a patch almost complete so hopefully this should be fixed in Firefox 3.6.1 but until then you can workaround this in your extension by setting the executable permissions on the file yourself. Assuming you have a file variable that is an nsIFile pointed at the executable, just do:

file.permissions = 0755;

In case you were wondering why we enforce file permissions at all, it is because it turns out there are quite a lot of different zip tools that developers use to build add-ons. Some of them are unfortunately broken and embed bogus permissions into the generated XPI. After extraction it leaves us with files that are unreadable/unwritable which makes the add-on fail to work correctly. This most commonly affects developers on windows (where permissions are a little laxer in general) who get odd bug reports from users on Linux which is respectfully refusing to use the files. The easy fix is to enforce read/write permissions on the extracted file in the first place.

5 responses

  1. Sylvain wrote on :

    Would this also affect extensions that include binary components (dll/so/dylib)?

  2. Dave Townsend wrote on ::

    No, Linux and OSX don’t seem to care whether a dylib/so have executable permissions or not. Windows doesn’t really have the concept of executableness at all so that is exempt from all this.

  3. Natanael L wrote on ::

    Libaries aren’t executed, they are just read and loaded into RAM and are kind of embedded into the process that loaded it. So they only need to be readable, not executable.

  4. Shrenik wrote on :

    Has this been fixed in FF 3.6.6? I can’t make out from the bug.

    1. Mossop wrote on ::

      No, it will be fixed in Firefox 3.6.8