1.7.2 tar.gz package has wrong permissions

RESOLVED FIXED

Status

SeaMonkey
Installer
--
major
RESOLVED FIXED
13 years ago
11 years ago

People

(Reporter: Harald Milz, Assigned: dbaron)

Tracking

({fixed-aviary1.0, fixed1.7.5})

Trunk
x86
Linux
fixed-aviary1.0, fixed1.7.5

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [patch]fixed1.7.3)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

13 years ago
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

13 years ago
There's also bug 254309 for Firefox.

I couldn't find any earlier bugs to dupe this against, that's hard to believe. :P
bug 231083 is for the installer
(Assignee)

Comment 3

13 years ago
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

13 years ago
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. 
(Reporter)

Comment 5

13 years ago
(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. 
(Assignee)

Comment 6

13 years ago
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?
(Assignee)

Comment 7

13 years ago
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::.
(Reporter)

Comment 8

13 years ago
(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... 


(Assignee)

Comment 9

13 years ago
Created attachment 155499 [details] [diff] [review]
patch

(untested)
(Assignee)

Updated

13 years ago
Assignee: general → dbaron
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [patch]
(Assignee)

Comment 10

13 years ago
Comment on attachment 155499 [details] [diff] [review]
patch

This does what I expect.  Any opinions on o-w or go-w would be appreciated.
Attachment #155499 - Flags: review?(bryner)
(Assignee)

Updated

13 years ago
Attachment #155499 - Attachment description: possible patch → patch
(Assignee)

Comment 11

13 years ago
Created attachment 155731 [details] [diff] [review]
patch

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

Updated

13 years ago
Attachment #155499 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #155499 - Flags: review?(bryner)
(Assignee)

Updated

13 years ago
Attachment #155731 - Flags: review?(bryner)
Attachment #155731 - Flags: review?(bryner) → review+
(Assignee)

Updated

13 years ago
Attachment #155731 - Flags: approval1.8a3?

Comment 12

13 years ago
Comment on attachment 155731 [details] [diff] [review]
patch

a=asa for 1.8a3.
Attachment #155731 - Flags: approval1.8a3? → approval1.8a3+
(Assignee)

Comment 13

13 years ago
Fix checked in to trunk, 2004-08-16 17:14 -0700.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
(Assignee)

Updated

13 years ago
Attachment #155731 - Flags: approval1.7.3?

Comment 14

13 years ago
Comment on attachment 155731 [details] [diff] [review]
patch

a=mkaply for 1.7
Attachment #155731 - Flags: approval1.7.3? → approval1.7.3+
(Assignee)

Comment 15

13 years ago
Fix checked in to MOZILLA_1_7_BRANCH, 2004-08-17 13:24 -0700.
Keywords: fixed1.7
(Assignee)

Updated

13 years ago
Attachment #155731 - Flags: approval-aviary?
(Assignee)

Updated

13 years ago
Keywords: fixed1.7 → fixed1.7.3
(Assignee)

Comment 16

13 years ago
Fix checked in to MOZILLA_1_7_2_BRANCH, 2004-08-27 13:35 -0700.
Whiteboard: [patch] → [patch]fixed1.7.2+

Comment 17

13 years ago
Comment on attachment 155731 [details] [diff] [review]
patch

a=asa for aviary checkin.
Attachment #155731 - Flags: approval-aviary? → approval-aviary+
(Assignee)

Comment 18

13 years ago
Fix checked in to AVIARY_1_0_20040515_BRANCH, 2004-08-27 14:40 -0700.
Keywords: fixed-aviary1.0
(Assignee)

Comment 19

13 years ago
Created attachment 157344 [details] [diff] [review]
patch for firefox installer
(Assignee)

Updated

13 years ago
Attachment #157344 - Flags: superreview?(bryner)
Attachment #157344 - Flags: review?(bryner)
Attachment #157344 - Flags: superreview?(bryner)
Attachment #157344 - Flags: superreview+
Attachment #157344 - Flags: review?(bryner)
Attachment #157344 - Flags: review+
(Assignee)

Comment 20

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

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

Comment 21

13 years ago
*** Bug 254309 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

13 years ago
Attachment #157344 - Flags: approval-aviary?

Comment 22

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

a=asa for branch checkin.
Attachment #157344 - Flags: approval-aviary? → approval-aviary+
(Assignee)

Comment 23

13 years ago
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.
Whiteboard: [patch]fixed1.7.2+ → [patch]fixed1.7.3
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.