demerphq wrote: > 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.
This assumes a failure of the file permissions system. And if an attacker can get at the site library directory they can probably get at the core library directory, too. >> 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. Seems a thin protection. It only protects against root processes which are only using core modules. Where it does become significant is when a vendor has patched a module to do something rather different. Then a site version won't have those patches. This is a nasty maintenance situation anyway. >> This is like having a path of ~/bin:/usr/bin:/bin > > Except that site could be shared wheras such a path normally wouldnt be. Ok, /usr/local/bin:/usr/bin:/bin then. > 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. :-) I think it has something more to do with the folks who do multi-architecture shared Perl directories. I asked about it once on p5p and got something obscure like that. The current @INC order came into being long before installing modules from CPAN was a common place occurance and well before dual-lifed CPAN modules. The idea of updating a core module didn't exist. Configure should probably have a simple dialog asking about this. How would you like @INC to be ordered? [site vendor core] -- Stabbing you in the face so you don't have to.
