Bug 143486 - Permissions misset on pango.modules
Permissions misset on pango.modules
Status: CLOSED DUPLICATE of bug 185419
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: pango (Show other bugs)
3.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Behdad Esfahbod
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-21 10:52 EST by cookgb
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-27 17:53:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description cookgb 2004-12-21 10:52:49 EST
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 10:33:03 EST
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 08:06:23 EST
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 01:12:40 EDT
Reassigning pango bugs to Behdad.
Comment 4 Behdad Esfahbod 2006-07-27 17:53:40 EDT

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

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