From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) 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):
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.
Some RPM versions:
If you do this as root:
rm -rf /var/cache/foomatic/pcache/* /var/cache/foomatic/compiled/*
does it work?
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
PERLLIB, PATH, LD_LIBRARY_PATH.
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?
In this case, root priveleges are acquired by the user typing in root's
But since it's a consolehelper thing, it ought to unset those variables so that
it works right. Fixed in CVS.
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.
Nalin, does consolehelper already clear out the environment?
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.