Re: pop @INC (".")

Let me answer your points in reverse order.

> Does anyone besides me share my concern that putting "." in the path isn't> always necessarily desirable?

I agree that it's not always desirable, but I'm not convinced that
it's never desirable, either.  Or rather, if undesirable, how/when
should it be removed from @INC.  Optionally with "-T" or mandatory
enforcement by the interpreter?

> There's about 4 test related files in core that would have to be patched to> get tests working. But I would be very concerned with breaking CPAN over> it.

Are you talking about just removing "." from @INC or are you talking
about forcing taint mode on always.  My gut instinct is that the
former would break lots of tests, but not lots of modules at runtime.
I suspect the latter would break a lot more at runtime.

> I asked this because I was actually considering submitting a patch for 5.18> to provide this as a Configure option.  While I'm not for taint being on> always, I worry that it's generally a potential security issue that @INC> paths are unpredictable if you can't control where the program will be run> from. I realize this concern has holes in it.

Something would get loaded from "." only if it's not found previously
in @INC.  So the worry is about code that loads missing modules
finding something bogus/risky instead of failing a module load
(whether it dies or is trapped in an eval)?

The sort of attack vector I could imagine is some code running with
elevated privileges and also using something like Module::Pluggable,
which would pick up appropriately named plugins from "." in @INC.

It seems like that's more easily addressed by running code that
requires elevated privileges under taint mode, rather than running
*all* programs under taint mode.

That latter bit might be an interesting configuration option to
explore -- to automatically enable taint mode when running as uid 0.

That should still allow CPAN modules to be installed as long as they
are built by a regular user and only installed with "sudo make
install".

It probably still breaks lots of things that don't expect to be
running in taint mode, but that might be an acceptable tradeoff to
protect uid 0.

-- David