On 10/16/07, Michael G Schwern <[EMAIL PROTECTED]> wrote: > 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]
I agree that this should be the default. The above was just conjecture. Thanks for shedding more light on the issue. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
