Bug 249180

Summary:	running pup via consolehelper may set bad permissions on installed files/dirs
Product:	[Fedora] Fedora	Reporter:	Kahlil Hodgson <kahlil.hodgson>
Component:	rpm	Assignee:	Paul Nasrat <nobody+pnasrat>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	low
Version:	7	CC:	homepage6, james.antill
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-07-25 18:42:54 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:

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):
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 09:20:39 UTC

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

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