Bug 59637 - environment problem
Summary: environment problem
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: usermode   
(Show other bugs)
Version: 7.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Martin Bacovsky
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2002-02-11 16:36 UTC by Joe Krahn
Modified: 2007-04-18 16:40 UTC (History)
0 users

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

Attachments (Terms of Use)

Description Joe Krahn 2002-02-11 16:36:06 UTC
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 15:19:41 UTC
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 17:36:06 UTC
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 11:21:04 UTC
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 18:22:43 UTC
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 17:21:10 UTC
Changing component.

Comment 6 Tim Waugh 2002-02-19 17:21:51 UTC
Nalin, does consolehelper already clear out the environment?

Comment 7 Martin Bacovsky 2006-07-31 14:03:43 UTC
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.