Bug 90187 - Does not work when installed with a umask of 077
Does not work when installed with a umask of 077
Status: CLOSED DUPLICATE of bug 110956
Product: Red Hat Linux
Classification: Retired
Component: fontconfig (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Owen Taylor
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-05 04:17 EDT by P Fudd
Modified: 2007-04-18 12:53 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:52:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description P Fudd 2003-05-05 04:17:06 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
Nothing would print on my hpdeskjet 920c, after a fresh install of rh9.0

It worked fine in 8.0.

If I added LogLevel debug2 to /etc/cups/cupsd.conf, I could see the following
error in /var/log/cups/error_log:

D [05/May/2003:00:19:16 -0700] [Job 12] Couldn't exec foomatic-gswrapper -q
-dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=ijs -sIjsServer=hpijs
-sDeviceManufacturer="HEWLETT-PACKARD" -sDeviceModel="DESKJET 920"
-dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dDuplex=false -r300
-sIjsParams=Quality:Quality=0,Quality:ColorMode=2,Quality:MediaType=0,Quality:PenSet=2
-dIjsUseOutputFD -sOutputFile=- - at /usr/lib/cups/filter/cupsomatic line 1097.

After *much* debugging, it turns out that foomatic-gswrapper was working, but gs
was failing silently.  An strace of gs showed that it was getting access denied
messages while trying to read its fonts.

Solution:
  chmod -R a+rX /usr/share/fonts

Maybe put something like this into /etc/rc.d/init.d/xfs ?


Version-Release number of selected component (if applicable):
foomatic-2.0.2-15, cups-1.1.18-4

How reproducible:
Always

Steps to Reproduce:
1.chmod go-rx /usr/share/fonts
2.lpr /usr/share/ghostscript/7.05/examples/tiger.ps
3.pull hair
4.chmod -R go+rX /usr/share/fonts
5.put hair back in

Actual Results:  discovered you can't put hair back in

Expected Results:  Fabio hair

Additional info:
Comment 1 Tim Waugh 2003-05-06 09:10:01 EDT
Fresh install already has the right permissions on that directory.
Comment 2 P Fudd 2003-05-06 15:18:51 EDT
Fine, yes, I get what you're saying.

Perhaps I didn't clearly state the situation.

When I'm root, I always have a umask of 077 when installing rpms.  When
diagnosing this printing problem, I examined the /usr/share/fonts directory and
all subdirectories, and I found that some files and some directories were not
readable by group or others.  Specifically, the directory containing the font
files for ghostscript could not be read by ghostscript when it was called from
the print spooler.

It could be that an rpm package rebuilt the font directories with the wrong
permissions, possibly obeying the umask when it shouldn't have.

My primary reason for sending in this bug report is so that other people who
have cryptic failures of their printing subsystem might find a solution in this
bug database.

My secondary reason was that I was hoping that someone might add some code to
the file /etc/rc.d/init.d/xfs that said 'chmod -R a+rX /usr/share/fonts', so
that nobody would have this sort of mysterious failure.  Since that file is
already running mkfontdir on boot if new fonts have been added, I figured that
would be as good a place as any to put the fix.

Alternatively, if chmod -R is too intrusive/may trample permissions that people
are setting up on purpose, then maybe just report that some files are not
readable by all, and let the administrator deal with it.

Or make ghostscript report that it can't read its fonts, and pass that error
back up the tree so that people like me don't have to strace the printing
subsystem in order to figure out it's a minor permissions problem, and not a bug
deep in the heart of the printing subsystem.

I mean, really, I'm an experienced Linux sysadmin, and it took me 2 hours and 37
seconds to debug this problem.  I *know* that I haven't done anything out of the
ordinary during the installation of this system.  If it takes me 2 hours, then
it's going to make a newbie give up.  And tell his/her friends that Linux sucks.
 I don't think anybody here wants that, do they?
Comment 3 Tim Waugh 2003-05-07 04:38:08 EDT
Aha, some package should own /usr/share/fonts, but none does.
Comment 4 Tim Waugh 2003-05-07 04:38:39 EDT
Maybe fontconfig should own /usr/share/fonts?
Comment 5 Miloslav Trmac 2004-02-10 16:28:53 EST

*** This bug has been marked as a duplicate of 110956 ***
Comment 6 Red Hat Bugzilla 2006-02-21 13:52:52 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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