Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Proposed change regarding "Taint" support

by syphilis (Bishop)
on Aug 13, 2021 at 12:41 UTC ( #11135810=perlnews: print w/replies, xml ) Need Help??

Hi,

This post appeared on the p5p mailing list earlier today.
As someone who has never personally experienced any utilitarian benefit from perl's purported tainting capabilities, it was something that I was pleased to see.

However, from twenty years ago (give or take), I do recall a statement from a prominent perl figure named Larry in which he stated that he would not run perl scripts for any purpose at all unless taint checking was applied.
Are there others here that recall that statement ?
How do we reconcile that statement with the proposed change ?
Are there people here who would refuse to use a perl that was built without taint checking capability ?

Just wonderin' .....

Cheers,
Rob
  • Comment on Proposed change regarding "Taint" support

Replies are listed 'Best First'.
Re: Proposed change regarding "Taint" support
by choroba (Archbishop) on Aug 13, 2021 at 12:55 UTC
Re: Proposed change regarding "Taint" support
by hippo (Bishop) on Aug 13, 2021 at 13:24 UTC
    Are there people here who would refuse to use a perl that was built without taint checking capability ?

    There is at least one! Probably 80% of the Perl I write is either public-facing or at least untrusted-user-facing and therefore I use taint mode a lot and am extremely grateful for its demonstrable bacon-saving properties. Without it, perl would become much more dangerous with the upshot that it would either require some sort of front-end or wrapper which would peform the same task (tricky) or else $WORK would have to start looking at alternative languages. The latter would be a body blow as Perl is by far the best language in the toolbox.

    I can see the attraction to TPTB given that they might not have much/any use for taint mode themselves but to excise such a fundamentally important part of the system just for a speed gain seems like throwing the baby out with the bathwater. And if you, dear reader, feel that it would be no great loss then take care because next time it might well be your favourite feature which is to be deleted. I can only hope that sense prevails.


    🦛

      ... but to excise such a fundamentally important part of the system just for a speed gain seems like throwing the baby out with the bathwater

      In that thread, Tomasz Konojacki has referred to that "fundamentally important part of the system" as a "misfeature" that he would like to see "completely removed".
      So far, that assessment has not been questioned. Maybe it's in your best interests to let it be known that not everyone shares that view ?
      (If people don't tell 'em, they won't know ;-)

      Mind you, I don't think they would do anything so bold as to have it "completely removed", so you probably don't have to worry too much about that.
      Nevertheless, would you be content to live with the heightened possibility that perls built without taint checking capability existed ?

      Cheers,
      Rob

        Not sure about "content" but certainly less miffed. I'm content that PHP exists just so long as I don't have to have anything to do with it. :-)

        Tomasz Konojacki has referred to that "fundamentally important part of the system" as a "misfeature" that he would like to see "completely removed".

        I notice that Tomasz gives neither evidence nor rationale for this "misfeature" claim. Given your recall of Larry's view I am quite happy to be in his camp rather than in Tomasz's.


        🦛

Re: Proposed change regarding "Taint" support
by haj (Priest) on Aug 13, 2021 at 16:21 UTC

    Out of a habit, I run scripts under taint mode... if the CPAN dependencies permit it. I also more or less regularly run my unit tests under taint mode, and make sure my own stuff is taint-proof.

    However, I think Neil has a point with his P5P message. Taint mode was useful in the olden days, where everything (including server stuff) happened on a few Unix hosts and people shared their scripts and used other people's scripts freely because that was just convenient.

    Taint mode helps against a certain class of things which might turn out insecure, but today's attackers have found easier targets, and taint mode has always produced its share of false positives. If it goes away, I'll miss it, but only a bit.

      It might be nice to have a tool that is Perl with a taint mode or something like it left in for development and testing. The main language could have it completely gone so there's no performance penalty. Unfortunately if done just that way it's likely to rot. A completely separate analysis tool may be a better bet.

        I was about to recommend Ruby, but after a google search found out that Ruby has also removed taint checking mechanism in 2020. So that's that.
Re: Proposed change regarding "Taint" support [overhead]
by kcott (Bishop) on Aug 13, 2021 at 23:47 UTC

    G'day Rob,

    Thanks for advising of this proposal.

    I was wondering about the taint-related overhead. I'm not an XS programmer; however, I did some investigation using Devel::Peek and followed that up with some hunting around in perlguts.

    I'm genuinely interested in learning about this. My investigations are potentially incomplete and my inferences could easily be wrong. Any constructive criticism would be welcome.

    Without any implicit (setuid/getuid) or explicit (-T) taint checking:

    $ perl -e 'use Devel::Peek; my $x = $ENV{PATH}; Dump $x' SV = PVMG(0x8000c68f0) at 0x80008a8b8 REFCNT = 1 FLAGS = (POK,IsCOW,pPOK) IV = 0 NV = 0 PV = 0x80008c2c0 "... long list of pathnames ..."\0 CUR = 2026 LEN = 2028 COW_REFCNT = 1 $ perl -e 'use Devel::Peek; my $x = q{$ENV{PATH}}; Dump $x' SV = PV(0x800004670) at 0x80008a8a8 REFCNT = 1 FLAGS = (POK,IsCOW,pPOK) PV = 0x80008e250 "$ENV{PATH}"\0 CUR = 10 LEN = 12 COW_REFCNT = 1

    So, ignoring the hex numbers — which I assumed were related to memory locations, like HASH(0x800003c88), ARRAY(0x800003cd0), etc. — and the values directly related to the string content, it would seem that the elements taking part in any overhead are SV = PVMG (cf. SV = PV) and the additional IV and NV. I wasn't able to figure out exactly what that overhead might be.

    Now, I could be barking up the wrong tree, which is entirely possible, and, if so, please correct my conclusions. It seems there is no overhead unless there are tainted variables. Is there something else going on that I've overlooked or, perhaps, that I'm simply unaware of?

    For comparison and completeness, here's the Devel::Peek output when -T is used:

    $ perl -Te 'use Devel::Peek; my $x = $ENV{PATH}; Dump $x' SV = PVMG(0x8000c8850) at 0x80008b7d8 REFCNT = 1 FLAGS = (GMG,SMG,POK,IsCOW,pPOK) IV = 0 NV = 0 PV = 0x80008de60 "... long list of pathnames ..."\0 CUR = 2026 LEN = 2028 COW_REFCNT = 1 MAGIC = 0x8000447c0 MG_VIRTUAL = &PL_vtbl_taint MG_TYPE = PERL_MAGIC_taint(t) MG_LEN = 1 $ perl -Te 'use Devel::Peek; my $x = q{$ENV{PATH}}; Dump $x' SV = PV(0x800004670) at 0x80008bee8 REFCNT = 1 FLAGS = (POK,IsCOW,pPOK) PV = 0x800090220 "$ENV{PATH}"\0 CUR = 10 LEN = 12 COW_REFCNT = 1

    There's no change for the untainted $x. The tainted version has additional FLAGS and a new MAGIC section. I had found PERL_MAGIC_taint in perlguts and originally thought that was related to PVMG (but maybe that's wrong).

    — Ken

      Hi Ken,

      Looking at Steffen Mueller's original post on the idea, it seems that it achieves its speed up by turning taint-related operations (that normally get processed even when not running under -T) into no-ops.
      As such, I expect you'll need to build a perl with -DNO_TAINT_SUPPORT in order to measure any speed improvements.

      I've built such a version of current blead (on Windows), but haven't yet run any benchmarks.
      To build it, I just hacked perl.h by inserting
      #define SILENT_NO_TAINT_SUPPORT 1
      just before (the already existing)
      #if defined(SILENT_NO_TAINT_SUPPORT) && !defined(NO_TAINT_SUPPORT) # define NO_TAINT_SUPPORT 1 #endif
      and then built perl in the usual way.
      That seems to have resulted in the desired build. To use your first example:
      perl -Te "use Devel::Peek; my $x = $ENV{PATH}; Dump $x;" SV = PVMG(0x5d1fc8) at 0x56e6f8 REFCNT = 1 FLAGS = (POK,IsCOW,pPOK) IV = 0 NV = 0 PV = 0x575628 "... long list of pathnames ..."\0 CUR = 852 LEN = 854 COW_REFCNT = 1
      Note the absence of the "magic" flags.

      Running make test on that build results in a number of failures. This is expected because some scripts do not cater for the possibility that -T is now a no-op.
      Perhaps there are additional (ie unexpected) failures, too ... I don't know.
      See below for the full test summary report.

      Cheers,
      Rob

        ++ Many thanks for this. There's clearly a lot going on under the hood that I wasn't aware of; particularly with respect to "... normally get processed even when not running under -T ...".

        I decided to have a bit of a nose around some of the various items you discussed. The repo link on https://metacpan.org/pod/perl handily took me to the blead branch of the "Github - Perl/perl5" page.

        More of a curiosity than anything related to tainting; my eye was drawn to the browser tab which appeared to have the emoji for a Bactrian camel (🐫) rather than the usual Dromedary camel (🐪). The text on the tab is very small and I thought that maybe I was miscounting the humps 😕; but no, on checking the source, it appears on two lines:

          <title>GitHub - Perl/perl5: 🐫 The Perl programming language</title>
            <meta name="description" content="🐫 The Perl programming language ...>
        

        I thought this was odd, but then had a vague recollection of there being an O'Reilly ™, ® or © associated with the camel image when used with Perl. After searching through a number of O'Reilly, Perl.com and Perl.org pages, I finally found it in "perl.org - Site Information". Of course, I may be overthinking this; it could just be a typo: &#1212483; instead of &#1212482;.

        Anyway, back to tainting. I located perl.h — that was very generous of you to void your warranty to help me. :-)

        /* By compiling a perl with -DNO_TAINT_SUPPORT or -DSILENT_NO_TAINT_SU +PPORT, * ... * * DANGER! Using NO_TAINT_SUPPORT or SILENT_NO_TAINT_SUPPORT * voids your nonexistent warranty! */

        I also looked in the t/ directory for the tests you indicated had failed: run/switcht.t was OK with only 66 lines; op/taint.t was somewhat more daunting with 2,986 lines (I didn't read it all). Realising that there was probably tens of thousands of lines in total, I left it there.

        Thanks again.

        — Ken

Re: Proposed change regarding "Taint" support
by ikegami (Pope) on Aug 13, 2021 at 14:08 UTC

    Adding -DNO_TAINT_SUPPORT to my Perl install script :)

    The other custom switch I use is one that postpones the deep recursion warning to 1000 levels (-DPERL_SUB_DEPTH_WARN=1000).

    Seeking work! You can reach me at ikegami@adaelis.com

Re: Proposed change regarding "Taint" support
by Anonymous Monk on Aug 14, 2021 at 05:47 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlnews [id://11135810]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (1)
As of 2021-12-02 01:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    R or B?



    Results (16 votes). Check out past polls.

    Notices?