Icky Gross and Disgusting @INC Kludges. (code, discussion)

deprecated has asked for the wisdom of the Perl Monks concerning the following question:

I am developing perl scripts in an environment (as I have mentioned before, at Isolating perldoc from the system perldoc) where I am not root. I am not the perl administrator, nor the webmaster. I'm just a consultant perl hacker.

So I have been asked to look into some new forms for the site which would allow us to move some of our processes from e-mail based to web-based. (yes I am being deliberately ambiguous, sorry.) I looked around, and I decided that I really liked HTML::FormTemplate, and wanted to use it.

You may know, however, that HTML::FormTemplate also requires the module Data::MultiValuedHash (which is a cool idea and cool module, I wind up reimplementing that wheel almost every time I write an application), and HTML::EasyTags, among a few others I think I am forgetting.

So I happily added these to my personal perl install (in ~/perl of course), and began hacking away at the form. When I was done with the initial concept phase of the code, I was ready to feed it to Netscape (server) and see what it looked like. I had, however, forgotten that /usr/local/bin/perl is NOT ~/perl/bin/perl (5.005 vs. 5.6.1 among other things), and did not include my modules either. So I went to the lead perl guy and said "so, um, I'd like to install a few modules. who do I talk to?" Well, as it turns out, the guys I need to talk to are out of the office today. So I can solve this tomorrow, most likely by installing the modules. But I will run into an issue like this again. His solution (the perl guy) was to just do this:

use lib qw{ lib/ };
[download]

and stuff all my modules into ./lib/. This kind of frightens me though, as they have to be a+r and any black hat who cares to go through my modules can. I'm not sure what the exact implications of that are, but it worries me. So I did what I figured would be easiest, I just copied ~/perl/lib to #where my script lives#/lib. But, this isnt going to work. First off, theyre different perl versions, and second, the script doesnt seem to be recursively looking through ./lib/. For example, it doesnt find ./lib/HTML/* and I'm not sure why.

How can I get around this problem?

How much of a security risk is this?

Does perl recursively look through use lib qw{ } dirs?

How can I happily mesh modules from ~/perl with the /usr/local/bin/perl install?

Is that even possible given that they are different perl versions?

(dreaming) How does one go about trying to convince the local administrator that upgrading to perl 5.6 is A Good Thing? (yes, I do use perl 5.6 functions, yes I have good reason for wanting it, I dont want to start a 5.5 vs 5.6 feud)

yours in perl,
brother dep.

--
Laziness, Impatience, Hubris, and Generosity.

Comment on Icky Gross and Disgusting @INC Kludges. (code, discussion) Select or Download Code

Replies are listed 'Best First'.
Re: Icky Gross and Disgusting @INC Kludges. (code, discussion) by mikfire (Deacon) on May 14, 2001 at 20:49 UTC
In approximately the order they were asked You really can't - sooner or later the web daemon has to read the files and any sufficiently capable blackhat can read them. The best solution I found was a directory where the webdaemon can read and you can write. This at least stops blackhats from reading your directory. I do not think ( and I am sure merlyn will correct me on this ) it is that much of a security risk. I would be far more concerned about bad input than about a blackhat discovering what modules I am using. Don't know :) First, only pure-perl modules will work - anything using XS is right out. Second, you need to make sure the modules are not using perl 5.6 specific widgets. Given those two conditions, things should just work. Personally, I wouldn't do it. I bet things would fail in spectacular fashions when one of the two conditions is not met. See previous Bribery. Speaking as an admin myself, bribery almost always works. Offer to buy the sysadmin a cup'a'joe/ soda/lunch, whatever. Let the SA know that you would like this as a personal favour. Mention that this would not involve breaking existing scripts - perl 5.6 could be installed in a completely different path. Tell your SA that you don't mind doing the compile/test phase. Tell your SA you will do the postinstall work as well. Mention that perl 5.6.1 is out ( the magic first revision ). More bribery. Begging rarely works, but it does sometimes amuse me :) HTH, mikfire	[reply]
Re (tilly) 1: Icky Gross and Disgusting @INC Kludges. (code, discussion) by tilly (Archbishop) on May 14, 2001 at 23:49 UTC
Were I on the inside, here would be my reactions. Moving from 5.005 to 5.6 involves internal testing of the existing scripts. That is a project in and of itself, and until that evaluation has happened you don't have a deliverable if it doesn't run under 5.005. (Hopefully they do have a plan to do that test. But you should not be driving their schedule.) Get your modules out of the web area. Unless you have put them through a security audit, you don't know whether they have holes. If you have put them through that audit then you only think you know they are good. In case they are discovered to have holes, you don't want their use advertised. Only give out that kind of information on a need to know basis. Perl does not recursively search the dirs in @INC. That is why the Perl person said to both put them there and then use lib so they would be picked up. But see my previous security comment and move them to an absolute location outside the web tree. Then use lib for that location. Meshing versions might or might not work. It won't with XS code. Pure Perl code is generally forwards but not necessarily backwards compatible. If that is not an issue then you will have less work to do getting your code to be a deliverable for the actual environment... Harsh? Perhaps. But it is your job to deliver code that works as well as possible in the target environment. Every release of any major piece of software has new bugs. Testing it before putting it into production is simple due diligence. Certainly at this point they should be scheduling when to evaluate an upgrade. But if they have a significant amount of Perl code, no decent admin should be willing to upgrade perl willy nilly.	[reply]
Re: Icky Gross and Disgusting @INC Kludges. (code, discussion) by DrZaius (Monk) on May 14, 2001 at 20:24 UTC
Why not use the old perl and use a prefix with your installation process like this: `perl Makefile.PL PREFIX=<pathtolib>/lib` [download] And if you need perl 5.6, why not use your perl 5.6 in the header of your scripts so they run under the new perl? Hope this helps.	[reply] [d/l]
Re (2): Icky Gross and Disgusting @INC Kludges. (code, discussion) by deprecated (Priest) on May 14, 2001 at 21:11 UTC
The reason I cannot just use `#!/path/to/my/perl5.6` [download] is that the Netscape server in question must: a) be able to read my home dir (not a chance) b) be aware that it is allowed to execute my perl (not a chance). having the Makefile install modules in the web directory would not be helpful, as they are already there. dep. -- Laziness, Impatience, Hubris, and Generosity.	[reply] [d/l]
Re: Icky Gross and Disgusting @INC Kludges. (code, discussion) by Masem (Monsignor) on May 14, 2001 at 20:49 UTC
Why would the modules installed at {$WEB_PAGES}/./lib need to be a+r? The only people that need to read it would be the user that that web server runs under, and yourself. CGI scripts ought to be 770, if not 700 (assuming that the script is owned by the server UID), if not 550/500 for finalized products. Support modules can be set to the same protection levels. In addition, at some point you will have to put your modules (the ones you are writing, not the ones that you need to install) in that space, and you'll have the same problems with blackhats as you do now. Dr. Michael K. Neylon - mneylon-pm@masemware.com \|\| "You've left the lens cap of your mind on again, Pinky" - The Brain	[reply]
Re (2): Icky Gross and Disgusting @INC Kludges. (code, discussion) by deprecated (Priest) on May 14, 2001 at 21:15 UTC
Well, Masem, you know what they say about assumptions. :) In this case, the server is not running as me, nor is the server a member of my group. So the file needs to be u+rw (u being me), g+r (g being my group), and o+r (o being others). Which is more succinctly expressed as "a+r". The good news is people I've talked to dont think its a big issue. I am concerned about our proprietary modules (read: the ones I coded) getting viewed by black hats though. So I'll be discussing this with the admins tomorrow I guess. -- Laziness, Impatience, Hubris, and Generosity.	[reply]
Re: Icky Gross and Disgusting @INC Kludges. (code, discussion) by Mungbeans (Pilgrim) on May 15, 2001 at 14:34 UTC
I get the same problem. The crowd I work with is bureaucratic, overly so. This makes it hard to install new modules, I dealt with this by getting my own box and getting rid of the sys admins. That's not an option here. Talk to your sponsors, bribe your sysadmins. Get a separate perl set up (maybe): `/usr/bin/perl5.6/perl with libs underneath /usr/bin/perl5.005/perl .. /usr/bin/perl symlinked to per5.005 - change to 5.6 for upgrade.` [download] Use the explicit path for your 5.6 scripts, you'll probably be able to leave them alone when 6 comes out unless you change them to use perl6.0. My 2p. Standard caveats apply - I am no security expert. PS Be nice to your sysadmin. They get flack for problems but no praise for installing new software. Life is hard...	[reply] [d/l]


Your skill will accomplish what the force of many cannot
	PerlMonks