Front page | perl.perl5.porters |
Postings from March 2013
Re: [perl #117265] [PATCH] e213661 no warnings 'safesyscalls', fatalnul checks
Thread Previous
|
Thread Next
From:
demerphq
Date:
March 25, 2013 14:15
Subject:
Re: [perl #117265] [PATCH] e213661 no warnings 'safesyscalls', fatalnul checks
Message ID:
CANgJU+UEKwHLKPvnywiVNnjfnLuoybBhq0TFnRxFWp=3Hbx1HQ@mail.gmail.com
On 25 March 2013 15:12, Reini Urban <reini@cpanel.net> wrote:
> On 03/23/2013 10:35 AM, Lukas Mai via RT wrote:
>>
>> Oops, I accidentally sent this to Reini only when I meant to send it to
>> the list. Sorry about that.
>>
>> -------- Original Message --------
>> Subject: Re: [perl #117265] [PATCH] e213661 no warnings 'safesyscalls',
>> fatal nul checks
>> Date: Sat, 23 Mar 2013 16:05:04 +0100
>> From: Lukas Mai <plokinom@gmail.com>
>> To: Reini Urban <reini@cpanel.net>
>>
>> On 23.03.2013 15:49, Reini Urban wrote:
>>>
>>>
>>>> On Thu, Mar 21, 2013 at 12:37:27PM -0700, Reini Urban via RT wrote:
>>>>>
>>>>> Add the fatal warnings category safesyscalls.
>>>>> Disallow binary pathnames and arguments to other syscalls, strings
>>>>> with embedded \0, which are ignored in the syscall but kept in
>>>>> perl. Allow an ending \0 though, as several modules add a \0 to
>>>>> such strings without adjusting the length.
>>>>> The hidden payloads in these invalid string args may cause unnoticed
>>>>> security problems, as they are ignored by the syscalls but kept around
>>>>> in perl PVs.
>>>
>>>
>>> There are four possible reactions: ignore, silently strip, warn and
>>> strip, or die.
>>
>>
>> I don't understand what you mean by "strip". Something like:
>>
>> my $foo = "XYZ\0ABC";
>> unlink $foo;
>> # $foo eq "XYZ"
>>
>> ?
>
>
> The syscall behind unlink sees only "XYZ", and deletes XYZ if it exists. So
> from the perl POV it's like a "silent strip" without actually stripping it.
>
> ...
>
>
>>> I explicitly allow typical harmless programmer errors adding another \0
>>> at the end.
>>
>>
>> My favorite semantics would be to not treat \0 specially, regardless of
>> warnings. That means failing with ENOENT if you pass such a string to
>> open, unlink, stat, ... etc, because as far as Perl is concerned, there
>> is a \0 in that string, and as far as the file system is concerned, no
>> such file exists. Similarly, glob("*\0") should return ().
>
>
> Agreed.
>
>
>> The only problem I see with this is that it might break older scripts
>> that use a 2-arg open call of the form open(F, "< $foo\0") but we could
>> add a special exception for this case (only). That is: In a call to
>> 2-arg open where the filename $X contains exactly one \0 and it is the
>> last character, treat it as substr($X, 0, -1) instead.
>
>
> That's why I said: "I explicitly allow typical harmless programmer errors
> adding another \0 at the end." I do exactly that, and for this case only.
> There were too many failures because of this habit. I only fixed
> ExtUtils-Manifest.
Reini, on Win32 filenames are stored internally as UTF-16. What affect
does your patch proposal have on opening files with widecharacters in
them? (Widecharacters as you know could easily contain nuls).
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next