in reply to Is it possible to modify __DATA__ via the DATA file handle or otherwise?

DATA is a plain, ordinary file handle to the source file, but it's open for reading (not writing). I don't know how to convert a handle opened for reading into a handle opened for writing (if it's even possible), but you can open a new handle to the current file, and use tell(DATA) to find the location of the start of the data.

die("Not safe for setuid") if ${^TAINT}; open(my $fh, ">>", __FILE__) or die("open: $!\n"); ( my $data_pos = tell(DATA) ) >= 0 or die("tell: $!\n"); truncate($fh, $data_pos) or die("truncate: $!\n"); say($fh "bar") or die("say: $!\n"); __DATA__ foo

Replies are listed 'Best First'.
Re^2: Is it possible to modify __DATA__ via the DATA file handle or otherwise?
by LanX (Saint) on Feb 10, 2018 at 12:29 UTC
    Pretty much what I had in mind, but to avoid race conditions due to parallel starts, I'd rather write to a temporary file and rename it at the end.

    Cheers Rolf
    (addicted to the Perl Programming Language and ☆☆☆☆ :)
    Wikisyntax for the Monastery

      I'd rather write to a temporary file and rename it at the end

      Good thing I wrote a module for that ;-)

      use warnings; use strict; use File::Replace 'replace2'; my ($infh,$outfh) = replace2(__FILE__); while (<$infh>) { last if /^__DATA__$/; print $outfh $_; } print $outfh "__DATA__\n"; print $outfh "New stuff! ".gmtime." UTC\n"; close $infh; close $outfh;
        Still using the tell of the DATA filehandle is the far better approach.

        There is no guaranty to correctly match __DATA__ without having a full Perl parser.

        Cheers Rolf
        (addicted to the Perl Programming Language and ☆☆☆☆ :)
        Wikisyntax for the Monastery

      Or use a locking mechanism (e.g. flock).

Re^2: Is it possible to modify __DATA__ via the DATA file handle or otherwise?
by YenForYang (Beadle) on Feb 16, 2018 at 19:20 UTC

    Sorry for this dumb question, but I was wondering what/why the first line (die ...) is used (for).

      setuid allows a user to execute a script as the script's owner.

      I believe it can be attacked as follows:

      1. Create a symbolic link to the setuid script.
      2. Execute the setuid script via that symbolic link.
      3. Immediately replace the symbolic link with a file.
      4. If you get the timing right, the setuid script will read and write the data from your file instead of from the script file. The script trusts the data since it expects to be the only one able to change it, but you actually have full access to the data.

      As a variation of the above, the attack could also replace the volume on which the script resides by unmounting it and mounting a new one.