Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90927
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.177 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <0D.E3.12955.15522A65@pb1.pair.com>
References: <9D.00.64206.7C430A65@pb1.pair.com> <CAGa2bXb0kUT9UstGHn1RTeKkmNQaVXmb6hbhfc-WCPmUMfgJxA@mail.gmail.com>
 <CAGa2bXbXsCKFHSPnw82vkVDmgrd-OQOtahozBdw8qMdN-n3PdQ@mail.gmail.com> <0D.E3.12955.15522A65@pb1.pair.com>
Date: Tue, 26 Jan 2016 13:15:40 +0900
Message-ID: <CAGa2bXbiQDPpcKzM78OG6T1dpy5bWKQitXUKsRiDbSHJLe9wzQ@mail.gmail.com>
To: Umberto Salsi <salsi@icosaedro.it>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Severe safety fail in file access and stream filters
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Umberto,

On Fri, Jan 22, 2016 at 9:49 PM, Umberto Salsi <salsi@icosaedro.it> wrote:
> thank you very much for the reply, I now start understanding better what
> happen and why currently i/o cannot be handled in user's space.

You're welcome.
I think you have pointed out important missing parts in PHP.

> Rather than an array of error, which might be quite expensive to handle,
> why not a simple "char * lasterror" field added to the stream struct,
> normally set to NULL, where a description of the last error occurred may
> be stored? The high-level functions, that is PHP fopen, fread, fwrite,
> fflush, fseek, fclose, may then check that string and, if set, trigger
> E_WARNING with a meaningful message after having reset that string back
> to NULL again. Many C libraries already provide such error strings,
> starting from the same C strerror().

Pgsql's "notice" logging is implemented this way at first. Then I changed
it to array of notices recently.  (Notice is raised during
transaction, for example)

It's very difficult or impossible to detect where something wrong happened
if there is only the last error. That's the reason why pgsql module is changed
to have array of notices.

The same would happen in streams, so it's better to store all errors during
operation. Zend hash is extremely fast and good enough for logging errors,
so we don't have to worry overheads.

>
> The same should then be done with the filters, which currently only may
> return PSFS_ERR_FATAL, but might have their "char * lasterror" string
> too with the same purpose. Knowing the exact reason of the failure is
> essential to distinguish, for example, a dead disk drive or corrupted file
> system, from a bare file mistakenly opened with the wrong decompressor
> or a file which was badly encoded.

I agree.

>
> Then all the specific stream and filter implementations can be adjusted
> to set that error string; for those still not fixed that string remains
> NULL and fopen, ferror, etc. will not report the error just as they do
> today, and will be fixed later step by step.

Agree here, too.
Someone have to volunteer for this. It's not difficult for people on this list.
I have too many backlogs for PHP project, so I hope someone volunteers
for this.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net