Description of problem: When upgrading some packages via pup (using consolehelper to elevate privileges), files appear to be installed as though a 0027 umask were in effect (no world read or execute permissions). Have noticed this with a recent upgrade of thunderbird, and suspect it is cause of previous problems when upgrading packages that run update-mime-info. See bug: 244901 Version-Release number of selected component (if applicable): pirut-1.3.7-1.fc7 How reproducible: Upgrading thunderbird. Steps to Reproduce: Run as a normal user with sudo privileges 1. sudo rpm -e thunderbird 2. sudo rm -rf /usr/lib/thunderbird-2.0.0.* 3. sudo rpm -ivh thunderbird-2.0.0.4-1.fc7.i386.rpm >/dev/null (assuming you've got that lying around somewhere) 4. ls -ld /usr/lib/thunderbird-2.0.0.4 (note that that permissions are good) 5. pup (enter root password and upgrade thunderbird to 2.0.0.5) 6. ls -ld /usr/lib/thunderbird-2.0.0.5 (note the bad permissions on the directory) Actual results: drwxr-x--- 12 root root 4096 2007-07-22 17:40 /usr/lib/thunderbird-2.0.0.5 Expected results: drwxr-xr-x 12 root root 4096 2007-07-22 17:38 /usr/lib/thunderbird-2.0.0.5 Additional info: If you do sudo -y update or sudo pup you _do_not_ get the error. Probably some thing wrong in PAM land.
Additional Info should read: If you do sudo yum -y update or sudo pup you _do_not_ get the error.
thunderbird should really own the directory to avoid this problem. But rpm could also be setting a different umask rather than counting on it to be something
So you want to fix an unowned directory problem in thunderbird packaging, and a claimed PAM problem, installing with up2date/pup tools, by changing rpm to set umask Sure that makes perfect sense to me ... UPSTREAM, rpm5.org always sets a default 022 umask no matter what else is fubar ...
I agree that RPM should not be responsible for fixing a packaging error. Defensive installation could hide a whole world of bugs. Then again, upstream is forcing a umask anyway:-) Also, this might not even be a umask problem. Either way, upgrades should not break packages. By owning the directory I gather you mean putting %files %attr(755,root,root) %{mozappdir} in the spec file. (Kal digs out his dusty old copy of Maximum RPM). I'm testing this to see if it solves the problem (have to set up a fake repo first) but I'm not entirely convinced. When I build the package as a normal user with umask 0007, the build root has the permissions set right, so cpio should set the right permissions, right?
OK, I don't get it, but it does fix the problem. Will submit a patch under bug 244901.
*** This bug has been marked as a duplicate of 83006 ***