incorrect file permissions within firefox-4.2a1pre x86_64 platform file



Release Engineering
7 years ago
4 years ago


(Reporter:, Assigned: jhford)


Firefox Tracking Flags

(Not tracked)




7 years ago
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.2a1pre) Gecko/20110403 Firefox/4.2a1pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.2a1pre) Gecko/20110403 Firefox/4.2a1pre

The file for nightly builds of 4.2a1pre from around 20110403 for linux x86_64 extracts files with incorrect permissions - examples are mode 700 for all ".so" files, "firefox", "firefox-bin", "plugin-container", etc, etc instead of mode 755.

The i686 version from the same date looks to have the correct permissions.

Reproducible: Always

Steps to Reproduce: "Linux 64-bit Intel" file from
2.extract file
3.several extracted files have incorrect file permissions

Comment 1

7 years ago
The change occurred between these two releases:
Thanks for narrowing that down! Changesets in that regression range:
(For reference, you can get the changesets by looking at the .txt files next to each build: or using about:buildconfig if you run the builds.)

Comment 3

7 years ago
I'm not familiar enough with the Firefox build tree to track this down, but I've done a couple of observations:

The tar balls created in are made by subtracting the write permissions from the files: --mode="go-w"

My own firefox-4.2a1pre.en-US.debug-linux-x86_64.tar.bz2 packages created the latest two days do not have this permission problem. (But my build environment is probably far from standard.)

Anyway: Are the i686 and x86_64 packages built on different computers/accounts/shells with different umask:s?

Comment 4

7 years ago
Here the permission problem still exists:

But now it's suddenly gone:

That's just three changesets:

And I can't imagine how these three changesets could ever re-enable the read-/execute-permissions for x86_64. But I'm not a programmer...

Maybe this despite everything is an umask-question outside the buildtree itself?
We'll throw this over the wall at Release Engineering and see if they can deduce anything. (RelEng maintains the build machines.)
Component: Build Config → Release Engineering
Product: Firefox →
QA Contact: build.config → release
Version: unspecified → other

Comment 6

7 years ago
The problem still exists in the current nightly build:

But it's still gone in:

Comment 7

7 years ago
The linux64 buildbot.tac's need to set umask to 002 (instead of None).
This may be isolated to the new ix linux64 boxes; I haven't doublechecked the VMs.


7 years ago
Ever confirmed: true
That is when the new Linux64 machines were rolled out.  I will fix the umask issue on those slaves
Assignee: nobody → jhford
All machines other than

Have been fixed by setting umask = 002.  Those machines are not expected to be working because they are either defective or at IX.
Last Resolved: 7 years ago
Resolution: --- → FIXED
Product: → Release Engineering
You need to log in before you can comment on or make changes to this bug.