Re: [MacPerl] Taint Talk

[pudge@pobox.com (Chris Nandor)]

At 06.50 12/30/97, Bart Lateur wrote:
>On Mon, 29 Dec 1997, Chris Nandor wrote:
>
>>Basically, as per a previous request, MacPerl automatically adds
>>":site_perl" to @INC (where it is relative to the MacPerl app).  However,
>>Matthias adds it in such a way that it is "hardcoded", so that it is still
>>in @INC when taint checking is on.
>>
>>My question is this: does anyone see a problem with adding :lib (and
>>:lib:arch, wher arch is MacPPC or MacCFM68K (or Mac68K?)) in the same
>>hard-coded fashion?  This would basically make it like Unix perl.
>>Problems?  Either in security or otherwise?
>
>Yes I have a problem with this.
>
>":lib" is relative to the current directory, NOT the MacPerl app path.

:)  No, it is not.  I should have made that more clear.  Specifically, the
app makes it relative to the app itself.


>BTW why does taint checking makes a fuss about what is in @INC? Unless
>each directory in @INC by default is write protected, this won't be any
>guarantee. It is (or at least, can be) on Unix, for user "nobody", the
>CGI/browser clients.

We already know this is no guarantee on a Mac, let alone on a Unix box (I
as root can make the directories world-writable).  But, we cannot expect
Matthias to change the whole way tainting works in the perl core,
especially without some serious thought put into it.

In Unix, those directories usually are read-only for everyone but root (in
my experience).  So they assume those directories are safe.  If they are
not, that is root's fault (though some have suggested that taint checks
also check the permissions of those paths).  Regardless, the same taint
check mechanisms get automatically passed on to MacPerl.  This will not
change unless there is a good reason to change it.  Personally, I think it
is still a good thing, though; the issue of shared folders is especially
dangerous, and taint checks disables those by default (though they can be
reactivated with the BEGIN block).

But again, the main point is that the mechanisms themselves will not change
anytime soon, and that it should not stop us from using tainting in
MacPerl; rather, we should try to come up with an easy way to make taint
checks more useful, while understanding the problems that come with them,
and without making them more insecure.

--
Chris Nandor               pudge@pobox.com           http://pudge.net/
%PGPKey=('B76E72AD',[1024,'0824 090B CE73 CA10  1FF7 7F13 8180 B6B6'])
#==                    MacPerl: Power and Ease                     ==#
#==    Publishing Date: Early 1998. http://www.ptf.com/macperl/    ==#



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch