Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 3 product line. The current stable release is 3.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 143486

Summary:	Permissions misset on pango.modules
Product:	Red Hat Enterprise Linux 3	Reporter:	cookgb
Component:	pango	Assignee:	Behdad Esfahbod <behdad>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	high	Docs Contact:
Priority:	medium
Version:	3.0
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-07-27 21:53:40 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 cookgb 2004-12-21 15:52:49 UTC

Description of problem:

After upgrading to pango-1.2.5-5 from version 1.2.5-2.0, all text
rendering handled by pango failed.  After examining .xsession-errors,
I determined that the problem was that the file
/etc/pango/i386-redhat-linux-gnu/pango.modules had the incorrect
permissions (660) and was not readable by all users.  After changing
permissions of this file to (644) normal behavior resumed.

The problem occurs because the new version of pango assumes that the
user who is performing the update has a "normal" umask.  However, I
use a umask of "007".  During the update, the user is running commands
as root, but the umask of the user is used instead of a sensable umask
for system installation.  With a umask of 007, read permission are
denied to everyone but root.  This problem is the same as one fixed in
the "redhat-config-date" package and addressed in
http://rhn.redhat.com/errata/RHBA-2004-435.html


Version-Release number of selected component (if applicable):

pango-1.2.5-5

How reproducible:

Steps to Reproduce:
1. Log in as a non-root user on system with pango-1.2.5-2.0
2. Make sure umask is set to 007 within appropriate initialization
script for users default shell (eg .tcshrc).
3. Upgrade to pango-1.2.5-5 using up2date so that the "consolehelper
wrapper" is run to obtain the root password needed for the update,
then log out and log back in.
  
Actual results:  permissions on
/etc/pango/i386-redhat-linux-gnu/pango.modules is set to 660 and all
text rendering handled by pango fails.  Examining .xsession-errors
suggests that there was an error in the creation of
'/etc/pango/pango.modules'  and that it might be fixable by running
pango-querymodules. (Note /etc/pango/pango.modules has moved to
/etc/pango/i386-redhat-linux-gnu/pango.modules with the new version of
pango.)


Expected results: permissions on
/etc/pango/i386-redhat-linux-gnu/pango.modules should be set to 644
and text should be rendered as normal.


Additional info:
This behavior was seen in upgrading two systems where the users umask
was set to 007.

Comment 1 Brian Fristensky 2004-12-28 15:33:03 UTC

I also encountered this same problem, logged in as a regular user
running tcsh with umask 77. I ran the up2date client to do the
quarterly upgrade of Red Hat Enterprise Linux WS, so that I had to
enter the root password when up2date launched. Root runs bash with a
umask of 0022.

After the upgrade I rebooted to make sure that the kernel upgrades
took effect, and the GNOME login screen was devoid of all text.
After logging in, the GNOME (metacity) desktop also was missing all text.

As was reported, the problem was fixed by making
/etc/pango/i386-redhat-linux-gnu/pango.modules world-readable.

Comment 2 Erik Schaberg 2005-01-19 13:06:23 UTC

I had the same problem on my Opteron system. So this bug is also
present in the X86_64 architecture update.

Will my umask cause this kind of problems in the future with updates
of RPM's? Ifso I will have to go back to the more default and open
umask for root.

Comment 3 Matthias Clasen 2006-06-20 05:12:40 UTC

Reassigning pango bugs to Behdad.

Comment 4 Behdad Esfahbod 2006-07-27 21:53:40 UTC


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