Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 647670 - incorrect file permissions within firefox-4.2a1pre x86_64 platform file
: incorrect file permissions within firefox-4.2a1pre x86_64 platform file
Product: Release Engineering
Classification: Other
Component: Other (show other bugs)
: other
: x86_64 Linux
: -- normal (vote)
: ---
Assigned To: John Ford [:jhford] CET/CEST Berlin Time
Depends on:
  Show dependency treegraph
Reported: 2011-04-04 05:39 PDT by
Modified: 2013-08-12 21:54 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description 2011-04-04 05:39:38 PDT
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 2 Ted Mielczarek [:ted.mielczarek] 2011-04-04 07:03:45 PDT
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 Thomas Ahlblom 2011-04-04 09:01:10 PDT
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 Thomas Ahlblom 2011-04-04 17:46:12 PDT
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?
Comment 5 Ted Mielczarek [:ted.mielczarek] 2011-04-05 08:19:15 PDT
We'll throw this over the wall at Release Engineering and see if they can deduce anything. (RelEng maintains the build machines.)
Comment 7 Aki Sasaki [:aki] 2011-04-05 22:53:17 PDT
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.
Comment 8 John Ford [:jhford] CET/CEST Berlin Time 2011-04-06 09:28:32 PDT
That is when the new Linux64 machines were rolled out.  I will fix the umask issue on those slaves
Comment 9 John Ford [:jhford] CET/CEST Berlin Time 2011-04-06 09:33:14 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.