Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 59637 - environment problem
environment problem
Product: Red Hat Linux
Classification: Retired
Component: usermode (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Martin Bacovsky
Depends On:
  Show dependency treegraph
Reported: 2002-02-11 11:36 EST by Joe Krahn
Modified: 2007-04-18 12:40 EDT (History)
0 users

See Also:
Fixed In Version: 1.85
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-31 10:03:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joe Krahn 2002-02-11 11:36:06 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20010901

Description of problem:
Using a printer with cdj970 as the driver, selecting "driver options" crashes
the edit-printer dialog. This occurs while reading a foomatic generated file:

with the following error message:
Storable binary image v2.4 more recent than I am (v1.0) at blib/lib/Storable.pm
(autosplit into blib/lib/auto/Storable/retrieve.al) line 203, at
/usr/lib/perl5/site_perl/5.6.0/Foomatic/DB.pm line 3360
It look like the newer print packages have some files that depend on an updated

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

How reproducible:

Steps to Reproduce:
1.Run printconf-gui, and select any printer
2.set the printers driver to HP -> DeskJet 990C -> cdj970
3.Click the Driver Options tab

Actual Results:  dialog crashes. Inserting a debug statement to
/usr/lib/perl5/site_perl/5.6.0/Foomatic/DB.pm shows that it is crashing while
That is a generated file, so it seems strange that it can be of a Storable
format that cannot be read later.

Additional info:

Some RPM versions:
Comment 1 Tim Waugh 2002-02-12 10:19:41 EST
If you do this as root:

rm -rf /var/cache/foomatic/pcache/* /var/cache/foomatic/compiled/*

does it work?
Comment 2 Joe Krahn 2002-02-13 12:36:06 EST
This fixed it, and I figured out the problem. I had a newer Storable.pm in my
private PERLLIB. Running printconf-gui from my login inherits my PERLLIB.
Running it from someone elses login does not. Maybe it would be good if
printconf-gui and similar root-privelege programs would reset things like

This is a general problem. As I see it, most of the environment should
be dropped whenever root priveleges are acquired, otherwise there is
a chance of security exploits, right?
Comment 3 Tim Waugh 2002-02-15 06:21:04 EST
In this case, root priveleges are acquired by the user typing in root's
password. :-)

But since it's a consolehelper thing, it ought to unset those variables so that
it works right.  Fixed in CVS.
Comment 4 Joe Krahn 2002-02-15 13:22:43 EST
If one launches printconf-gui from the gnome menu, is there any
inheritance from the user's .profile or .cshrc files? If not, then
I may have done su then printconf-gui, and been the real culprit.
Maybe accessing printconf-gui from the menu is already safe
from a user's PERLLIB.

About my point of dropping the environment when you become root:
I guess what I should have done is "su -l" not just "su". I think
the consolehelper should act more like su -l.
Comment 5 Tim Waugh 2002-02-19 12:21:10 EST
Changing component.
Comment 6 Tim Waugh 2002-02-19 12:21:51 EST
Nalin, does consolehelper already clear out the environment?
Comment 7 Martin Bacovsky 2006-07-31 10:03:43 EDT
Closing this old bug. It seems it is working.
Consolehelper now uses "safe" set of enviroment variables.

If the problem is still occuring, please, reopen the bug.

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