Bug 249180 - running pup via consolehelper may set bad permissions on installed files/dirs
running pup via consolehelper may set bad permissions on installed files/dirs
Status: CLOSED DUPLICATE of bug 83006
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
7
All Linux
low Severity high
: ---
: ---
Assigned To: Paul Nasrat
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-22 05:18 EDT by Kahlil Hodgson
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-25 14:42:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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

  None (edit)
Description Kahlil Hodgson 2007-07-22 05:18:18 EDT
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.
Comment 1 Kahlil Hodgson 2007-07-22 05:20:39 EDT
Additional Info should read:

If you do 
   sudo yum -y update
or
   sudo pup
you _do_not_ get the error.
Comment 2 Jeremy Katz 2007-07-24 16:36:56 EDT
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 19:31:34 EDT
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-24 21:19:02 EDT
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?

Comment 5 Kahlil Hodgson 2007-07-24 22:43:54 EDT
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 14:42:54 EDT

*** 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.