Red Hat Bugzilla – Bug 59637
environment problem
Last modified: 2007-04-18 12:40:16 EDT
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: /var/cache/foomatic/pcache/compiled/combo/cdj970/530418.perl 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 perl-Storable Version-Release number of selected component (if applicable): How reproducible: Always 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 opening /var/cache/foomatic/pcache/compiled/combo/cdj970/530418.perl. 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: printconf-gui-0.3.61-3 perl-Storable-0.6.11-6 foomatic-1.1-0.20011218.3 Omni-0.5.0-4 printconf-0.3.61-3 Omni-foomatic-0.5.0-4
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 password. :-) 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.
Changing component.
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.