On 10/16/07, Michael G Schwern <[EMAIL PROTECTED]> wrote: > demerphq wrote: > >> Of course, the real problem is our default @INC order is backwards. It > >> should > >> be site, vendor, core not core, site, vendor. > > > > Isnt the reason security? Although I am surprised that vendor is after site. > > How does security enter into it?
Preventing people from using locally installed modules as an attack vector into other peoples processes. > Locally installed modules (site) trump everything, the user has to be able to > update stuff on their own. Vendor installed modules next. Finally the > original core modules come last. Yes, and then when users are allowed to install modules locally but arent allowed to touch the core modules they can create a dummy local module that installs into site which could then be used by root processes expecting to use the core version. Thus it repesents a vector for a privilege escalation attack. > This is like having a path of ~/bin:/usr/bin:/bin Except that site could be shared wheras such a path normally wouldnt be. BTW, im not saying im right, im saying that its the only rational justification for the situation at hand. Except that when you consider vendor it maybe doesnt make as much sense. In AS installs there is no vendor dir, just lib and site/lib, which is probably why i came up with this theory. :-) Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
