Bug 136030 - firefox %postinstall generates files without regard to umask
firefox %postinstall generates files without regard to umask
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
: 163137 (view as bug list)
Depends On:
Blocks: FC4Target
  Show dependency treegraph
Reported: 2004-10-16 20:35 EDT by Mike Perry
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version: 1.5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-30 10:52:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mike Perry 2004-10-16 20:35:47 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041003

Description of problem:
If root has a non-zero umask, it will be applied to files created
during the postinstall section. This is undesirable, as at least 3
packages (galeon, firefox and mozilla) create files in this state and
will fail to run for regular users if their rpms are installed by root
with a umask of 007.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
rpm -q rpm                                                           
rpm -e firefox                                                       
umask 000                                                            
rpm -iv firefox_0%3a0.9.3-0.fdr.4_i386.rpm
ls -la /usr/lib/firefox-0.9.3/components.ini                         
rpm -e firefox                                                       
umask 007                                                            
rpm -iv firefox_0%3a0.9.3-0.fdr.4_i386.rpm           
ls -la /usr/lib/firefox-0.9.3/components.ini            

Actual Results:  
Preparing packages for installation...                               
-rw-r--r--  1 root root 24 Oct 16 08:24 components.ini         
Preparing packages for installation...                               
-rw-r-----  1 root root 24 Oct 16 08:26 components.ini

Firefox then fails to run as non-root user.      

Additional info:
Comment 1 Jeff Johnson 2004-10-16 23:43:26 EDT
rpm honors umask to permit per-system overrides of
installed file permissions.

The behavior is no different than any other program
run by a user, and is what umask(2) was intended for.

Configure umask however you want, and control for the
value set when installing packages with rpm.
Comment 2 Mike Perry 2004-10-17 15:17:48 EDT
If this is the case, then rpm is behaving in a very inconsistent
manner, even to this principle. Files listed in the rpm file list do
NOT get the umask applied to their permissions. It ONLY applies to
files created in the postinstall. This makes little sense and is very
unexpected behavior.

In my view your argument is only valid in two cases, neither of which
hold for the current version of rpm:

1. If each RPM provided a list of files to which the umask would
apply, then the user could make some educated decision about their
umask. But as it is, as far as the user is concerned, it is entirely
random which files are generated during %postinstall versus installed
by the rpm archive itself.

2. If the umask applied to ALL files installed by the RPM, then this
would be much more consistent with your interpretation of umask. But
it does not. Again only a few files have umask applied, and it is done
  in a very opaque and unpredictable manner.

Comment 3 Jeff Johnson 2004-10-17 16:48:07 EDT
rpm makes no umask(2) call. Nor is rpm responsible for
anything that happens in a script other than starting and reaping
the exit code.

Again, adjust root's umask to taste.
Comment 4 Dag Wieers 2004-10-18 17:40:11 EDT
If this is like it is, I guess this can be forwarded to the mozilla
and firefox packagers, as they clearly have a bug. Mike, can you
change the affected component to mozilla/firefox ?
Comment 5 Jeff Johnson 2004-10-20 00:44:45 EDT
Why do you blame the package when the files are installed
conformant to the sysadmin's umask?

Anyways, I'll reassign to firefox/mozilla ...
Comment 6 Mike Perry 2004-10-20 01:44:42 EDT
Because something is wrong here. Just ONE file is being installed
according to umask. It doesn't make sense. umask should be applied to
all files or no files. So either rpm is fixed (all files), or firefox
is fixed (no files).

Since rpm has refused to fix it, this is now a per-package issue..
There are probably packages other than firefox that exhibit this
partial-umask issue as well.
Comment 7 Dag Wieers 2004-10-20 03:55:56 EDT
Jeff, the problem here is not how it is designed to work. The problem
is how people expect it to work. I can't say what other people expect,
but to me (and Mike Perry) the umask should not influence the
installation of files by a package so that it breaks proper functioning.

So if RPM is not at fault, the package is, and packagers have to
either set the umask to what they expect it to be or change the files
modes afterwards. The former is probably easiest in all cases.

In my opinion if packages are affected by a change in umask, it makes
umask useless for root. I can perfectly understand why someone wants
to change the umask and still expects normal package installation to work.
Comment 8 Matthew Miller 2005-04-26 12:38:13 EDT
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Comment 9 Warren Togami 2005-05-16 05:28:05 EDT
The easiest way to fix this is to run umask during %post.  This however is not a
solution for other packages which undoubtedly have this problem.
Comment 10 Warren Togami 2005-05-16 05:31:29 EDT
(umask or chmod)
Comment 11 Matthew Miller 2005-05-16 08:14:22 EDT
umask'd be better, because there'd be a (very short) window where something bad
could happen with chmod. But I'm not convinced that this shouldn't be back to
rpm itself -- maybe all scripts should be defined as having a certain umask.
Comment 18 Warren Togami 2005-07-12 17:08:12 EDT
It seems that earlier analysis about this in the firefox package was inaccurate.
 The latest RHEL-4 package during installation with umask 0077 does *not* create
any files with 600 or 700 permission.  However running as root with umask 0077
creates these two files:

-rw-------   1 root root     24 Jul 12 10:53 defaults.ini
-rw-------  1 root root   77529 Jul 12 10:53 xpti.dat

Given that it isn't happening during package install anymore but user runtime,
this is not a bug that can be fixed with a simple RPM workaround.  Furthermore
according to the package changelog it had an explicit umask in the scriptlets
since August 2004 long before it became a Red Hat package.

There is a quick but ugly way to fix this by adding umask 0022 to the
/usr/bin/firefox launch script.  Some may object to that though...
Comment 19 Warren Togami 2005-07-12 17:28:08 EDT
RHEL-4 mozilla is a little worse when you run mozilla as root with umask 0077:

drwx------  2 root root   4096 Jul 12 11:25 greprefs
drwx------  2 root root   4096 Jul 12 11:25 init.d
drwx------  2 root root    4096 Jul 12 11:25 myspell
-rw-------  1 root root   74771 Jul 12 11:25 xpti.dat
Comment 20 Warren Togami 2005-07-12 17:40:54 EDT
thunderbird-1.0.2-1.4.1 from RHEL-4 is broken similarly to firefox:

-rw-------   1 root root     24 Jul 12 11:40 defaults.ini
-rw-------  1 root root   93142 Jul 12 11:39 xpti.dat
Comment 21 Warren Togami 2005-07-13 01:48:24 EDT
Reproduce Test Procedure
1. Uninstall package.
2. umask 0077
3. Install package.
4. Check for files with bad permissions.  These are the result of either unowned
directories, unowned files, or files created during scriptlets.
5. Run software as root.
6. Check for files with bad permissions.  These are the result of files created
by root during execution.
Comment 22 Paul Nasrat 2005-12-01 17:59:00 EST
*** Bug 163137 has been marked as a duplicate of this bug. ***
Comment 23 Warren Togami 2005-12-01 21:17:35 EST
Apparently this should be less of an issue with Firefox-1.5, because of a
redesign in the way it works, it should no longer create files in the system
owned directories when run as root.  It should still be tested using the above
procedure to be sure.
Comment 24 Christopher Aillon 2006-10-30 10:52:47 EST
Resolving.  Reopen if this still occurs in FC6 or rawhide.

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