Bug 249180 - running pup via consolehelper may set bad permissions on installed files/dirs
Summary: running pup via consolehelper may set bad permissions on installed files/dirs
Status: CLOSED DUPLICATE of bug 83006
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm   
(Show other bugs)
Version: 7
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-07-22 09:18 UTC by Kahlil Hodgson
Modified: 2007-11-30 22:12 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-25 18:42:54 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 244901 None None None Never

Description Kahlil Hodgson 2007-07-22 09:18:18 UTC
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):

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- >/dev/null
   (assuming you've got that lying around somewhere)
4. ls -ld /usr/lib/thunderbird-
   (note that that permissions are good)
5. pup
   (enter root password and upgrade thunderbird to
6. ls -ld /usr/lib/thunderbird-
   (note the bad permissions on the directory)
Actual results:

drwxr-x--- 12 root root 4096 2007-07-22 17:40 /usr/lib/thunderbird-

Expected results:

drwxr-xr-x 12 root root 4096 2007-07-22 17:38 /usr/lib/thunderbird-

Additional info:

If you do 
   sudo -y update
   sudo pup
you _do_not_ get the error.

Probably some thing wrong in PAM land.

Comment 1 Kahlil Hodgson 2007-07-22 09:20:39 UTC
Additional Info should read:

If you do 
   sudo yum -y update
   sudo pup
you _do_not_ get the error.

Comment 2 Jeremy Katz 2007-07-24 20:36:56 UTC
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

Comment 3 Jeff Johnson 2007-07-24 23:31:34 UTC
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 ...

Comment 4 Kahlil Hodgson 2007-07-25 01:19:02 UTC
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

%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?

Comment 5 Kahlil Hodgson 2007-07-25 02:43:54 UTC
OK, I don't get it, but it does fix the problem.  
Will submit a patch under bug 244901.

Comment 6 Panu Matilainen 2007-07-25 18:42:54 UTC

*** This bug has been marked as a duplicate of 83006 ***

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