254303 - 1.7.2 tar.gz package has wrong permissions

Status: RESOLVED FIXED

(SeaMonkey :: Installer, defect)

Description

[Harald Milz]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 MultiZilla/1.6.4.0b
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 MultiZilla/1.6.4.0b

Just installed the tar.gz package. The package unpacks as follows: 

nathan:/usr/local # l mozilla/
insgesamt 5080
drwxrwxrwx  12  500  500   4096 2004-08-04 19:16 ./
drwxr-xr-x  20 root root   4096 2004-08-04 19:19 ../
-rw-r--r--   1 root root      0 2004-08-04 19:16 .autoreg
-rw-rw-rw-   1  500  500  30869 1999-10-06 04:14 LICENSE
-rw-rw-rw-   1  500  500   9542 2004-03-13 07:25 README.txt
-rwxrwxrwx   1  500  500  20424 2004-08-03 22:07 TestGtkEmbed*
-rw-rw-rw-   1  500  500    208 2002-08-02 00:59 bloaturls.txt
drwxrwxr-x  22  500  500   4096 2004-08-04 19:16 chrome/
drwxrwxrwx   4  500  500   8192 2004-08-04 19:16 components/
drwxrwxrwx   8  500  500     87 2004-08-03 21:51 defaults/
-rwxrwxrwx   1  500  500   5460 2004-08-03 22:07 dirver*
-rwxrwxrwx   1  500  500  14552 2004-08-03 22:07 elf-dynstr-gc*
drwxrwxrwx   2  500  500     83 2004-08-03 18:59 greprefs/

etc. etc. i.e. most dirs and files are world writable and belong to a non-root
user. As a workaround, one can 

chmod -R go-w mozilla
chown -R root.root mozilla

Please correct this problem - it imposes a security risk for many non-savvy users. 

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[logan]

There's also bug 254309 for Firefox.

I couldn't find any earlier bugs to dupe this against, that's hard to believe. :P

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

bug 231083 is for the installer

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Um, what's your umask, and what version of tar are you using?  My version of tar
(1.13.25) respects my umask when extracting, as it should.  I don't think this
is a problem in our tar.gz file.

Comment 4

[Fridtjof Busse]

Of course this is a bug in your tarball, just do 
$ tar xvfpz mozilla mozilla-i686-pc-linux-gnu-1.7.2-installer.tar.gz 
$ ls -al mozilla/ 
So unpacking as a normal user can get you these permissions as well (you just 
have to preserve the original permissions) or unpack as root (I bet there many 
out there who do this). 
Only difference is that unpacking as root will give you some high UID/GID for 
the files while unpacking as a user gives you the UID/GID of your user. 
Fix for this is simple: Repackage the tarball with correct permissions, maybe 
even UID/GID 0 to avoid any confusion/errors. 

Comment 5

[Harald Milz]

(In reply to comment #3)
> Um, what's your umask, and what version of tar are you using?  My version of tar
> (1.13.25) respects my umask when extracting, as it should.  I don't think this
> is a problem in our tar.gz file.

I unpacked the file as root, and the standard umask is 022. tar is 1.13.25 like
yours. 

Just look at the tar package using tar ztvf, and you see what I mean. The
package has been built like this to begin with, which it should not be. 

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

If you're using -p as one of the options to tar, you're explicitly requesting
that your umask be ignored.

Original reporter:  were you using -p as well?

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I agree about the ownership, though.  We should probably run tar with --owner=0
--group=0.  But I'm really not sure about running with --mode="o-w" or
--mode="go-w".  And while we're there, should we use --numeric-owner?

For the record, what |info tar| says about -p is:

`--preserve-permissions'
`--same-permissions'
`-p'
     When `tar' is extracting an archive, it normally subtracts the
     users' umask from the permissions specified in the archive and
     uses that number as the permissions to create the destination
     file.  Specifying this option instructs `tar' that it should use
     the permissions directly from the archive.  *Note Writing::.

Comment 8

[Harald Milz]

(In reply to comment #7)
> I agree about the ownership, though.  We should probably run tar with --owner=0
> --group=0.  But I'm really not sure about running with --mode="o-w" or
> --mode="go-w".  And while we're there, should we use --numeric-owner?

I was using tar zxvf, nothing else. Yes I _could_ use -p but that doesn't change
anything because I was unpacking as root which preserves everything to begin
with. I just re-tried with tar zxpvf as root, umask 0022: 

hm@nathan:/tmp> l mozilla
insgesamt 5080
drwxrwxrwx  12 hm   users   4096 2004-08-03 22:07 ./
drwxrwxrwt  55 root root   12288 2004-08-05 12:38 ../
-rw-rw-rw-   1 hm   users  30869 1999-10-06 04:14 LICENSE
-rw-rw-rw-   1 hm   users   9542 2004-03-13 07:25 README.txt
-rwxrwxrwx   1 hm   users  20424 2004-08-03 22:07 TestGtkEmbed*
-rw-rw-rw-   1 hm   users    208 2002-08-02 00:59 bloaturls.txt
drwxrwxr-x  21 hm   users   4096 2004-08-03 21:52 chrome/
drwxrwxrwx   4 hm   users   8192 2004-08-03 22:07 components/
drwxrwxrwx   8 hm   users     87 2004-08-03 21:51 defaults/
-rwxrwxrwx   1 hm   users   5460 2004-08-03 22:07 dirver*
...


It would be the best solution to add chmod, chown to the Makefile section that
builds the tar archive. Everything else burdens non-savvy users. Please. And
while you're at it, re-check the other packaging mechanisms... 

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

(untested)

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 155499 [details] [diff] [review]
patch

This does what I expect.  Any opinions on o-w or go-w would be appreciated.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

Actually, I've decided on go-w.  And the first segment in the deliver.pl
changes belongs to bug 231083.

Comment 12

[Asa Dotzler [:asa]]

Comment on attachment 155731 [details] [diff] [review]
patch

a=asa for 1.8a3.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to trunk, 2004-08-16 17:14 -0700.

Comment 14

[Mike Kaply [:mkaply]]

Comment on attachment 155731 [details] [diff] [review]
patch

a=mkaply for 1.7

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to MOZILLA_1_7_BRANCH, 2004-08-17 13:24 -0700.

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to MOZILLA_1_7_2_BRANCH, 2004-08-27 13:35 -0700.

Comment 17

[Asa Dotzler [:asa]]

Comment on attachment 155731 [details] [diff] [review]
patch

a=asa for aviary checkin.

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to AVIARY_1_0_20040515_BRANCH, 2004-08-27 14:40 -0700.

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch for firefox installer

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 157344 [details] [diff] [review]
patch for firefox installer

Checked in to trunk, 2004-08-30 12:57 -0700.

Comment 21

[Robert Parenton]

*** Bug 254309 has been marked as a duplicate of this bug. ***

Comment 22

[Asa Dotzler [:asa]]

Comment on attachment 157344 [details] [diff] [review]
patch for firefox installer

a=asa for branch checkin.

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 157344 [details] [diff] [review]
patch for firefox installer

Checked in to AVIARY_1_0_20040515_BRANCH, 2004-09-01 17:34 -0700.