I was thinking about this over breakfast; something was not quite right.
I'm glad you spoke up Tim.
Tim Gim Yee wrote:
> I'm not sure why there would be both an UNTAINT and a SAFEMODE option. It
> would seem that anyone asking for -T would prefer the extra security of
> UNTAINT/SAFEMODE over the security deficit caused by UNTAINT alone. Is it
> so people can avoid the extra overhead of Safe.pm if "fairly safe" is good
> enough?
SAFEMODE requires extra processing at startup time. (Parsing the config
file safely). I always want to make Inline start up as fast as possible,
so that people will not shun it for a lame reason. (I got a reputation
to protect ya know ;) But as Inline matures I need to add all this
cruft, so it becomes a balancing act.
>
> Here are some proposals:
>
> A) Anyone writing a book or documentations should always use UNTAINT and
> SAFEMODE in tandem:
>
> use Inline 'Untaint', 'Safemode';
>
> B) The use of SAFEMODE alone should imply UNTAINT, because 99.99% of the
> time that's what you want, and the other 0.01% of the time, adding UNTAINT
> isn't the bottleneck of your program:
>
> use Inline 'Safemode'; # Same as above
>
> C) The use of UNTAINT alone is dangerous. It should either...
> 1) produce a fatal error, or...
> 2) produce a warning if -w is on
Good points. Here's what I'll do:
1) UNTAINT always turns on SAFEMODE by default. So this will suffice:
perl -MInline=untaint -T script.pl
2) If you want slightly faster startup time under -T you'll need to say:
use Inline Untaint => Unsafe;
or
use Inline Config =>
UNTAINT => 1,
SAFEMODE => 0;
3) Use of SAFEMODE will not imply UNTAINT though. If you want both, just
say 'UNTAINT'.
Cheers, Brian
PS - SAFEMODE will evolve. The first implementation will just handle
evaling the config file in a sandbox. As I am alerted to other security
risks, I'll add them to SAFEMODE.
--
perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf
("Just Another %s Hacker",x);}};print JAxH+Perl'
