Front page | perl.perl5.porters |
Postings from March 2013
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.
Thanks for this.
Your description of this this change is a bit unclear; in particular, I'm
assuming that "Disallow binary pathnames" only refers to disallowing \0,
rather than some more general non-ASCII prohibition???
From what I understand of this patch, it makes the following changes:
First in the absence of 'use warnings' (or in the presence of
'no warnings "safesyscalls"), it makes system calls like
open my $fh, ">", "foo\0bar"
return false and sets $! to 'no such file' or some such appropriate
error.
Second, in the presence of 'use warnings', it instead causes the open to
croak (captureable with eval as usual).
Is this a correct assessment?
Before discussing the detailed implementation on the patch, I think we
need a rough concensus on what semantics we desire.
My own personal opinion is that I like the first part: causing system
calls to mandatorally (and unchangeably) return failure in the presence of
\0.
I'm not very keen on the second part. For a start, it doesn't add that
much over the first part: the file won't have been opened under any
circumstances and writes to it will still fail, even if the return code
isn't checked. It's just that suddenly the whole program dies, just because
the code contains 'use warnings'. This seems a big escalation, If people
want that behaviour, they can always use autodie.
--
The crew of the Enterprise encounter an alien life form which is
surprisingly neither humanoid nor made from pure energy.
-- Things That Never Happen in "Star Trek" #22
Thread Previous
|
Thread Next