Bug 136030
| Summary: | firefox %postinstall generates files without regard to umask | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mike Perry <mikepery> |
| Component: | firefox | Assignee: | Christopher Aillon <caillon> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | dag, mattdm, nobody+pnasrat, wtogami |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 1.5 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-10-30 15:52:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 136451 | ||
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. 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. 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. 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 ? Why do you blame the package when the files are installed conformant to the sysadmin's umask? Anyways, I'll reassign to firefox/mozilla ... 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. 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. 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. 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. (umask or chmod) 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. 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: /usr/lib/firefox-1.0.4 -rw------- 1 root root 24 Jul 12 10:53 defaults.ini /usr/lib/firefox-1.0.4/components -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... mozilla-1.7.7-1.4.2 RHEL-4 mozilla is a little worse when you run mozilla as root with umask 0077: /usr/lib/mozilla-1.7.7/ drwx------ 2 root root 4096 Jul 12 11:25 greprefs drwx------ 2 root root 4096 Jul 12 11:25 init.d /usr/lib/mozilla-1.7.7/components drwx------ 2 root root 4096 Jul 12 11:25 myspell -rw------- 1 root root 74771 Jul 12 11:25 xpti.dat 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 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. *** Bug 163137 has been marked as a duplicate of this bug. *** FYI: 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. Resolving. Reopen if this still occurs in FC6 or rawhide. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041003 Firefox/0.10.1 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): rpm-4.3.1-0.3 How reproducible: Always 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: rpm-4.3.1-0.3 Preparing packages for installation... firefox_0%3a0.9.3-0.fdr.4_i386.rpm -rw-r--r-- 1 root root 24 Oct 16 08:24 components.ini Preparing packages for installation... firefox_0%3a0.9.3-0.fdr.4_i386.rpm -rw-r----- 1 root root 24 Oct 16 08:26 components.ini Firefox then fails to run as non-root user. Additional info: