[Review] Route stat() family of calls via wrapper ops.

The streams API has, since early in its introduction had the capacity to
perform stat() family calls on files under any wrapper.

In theory.

What's preventing wrapper->wops->url_stat from being useful is that the code
in ext/standard/filestat.c has never been routed through this layer.

I've put together a patch at http://169.229.139.97/test/stat-streams.diff to
accomplish this and it seems to test well with local files, local symlinks,
and remote ftp files (the ftp wrapper has had a limited url_stat method
waiting to be used for some months now).

However, since the stat() related code does a little voodoo in terms of
caching results and handling multiple function calls in a single do-all, I'd
like to get feedback from others on its suitability.

Also, this patch extends the stream_wrapper_ops structure slightly by adding
an access_check() method (for is_readable(), is_writeable(), etc...)

url_stat() and access_check() are both implemented in the plainfiles wrapper
with this path.

The ugliest part of this patch is that it requires special treatment for the
plainfiles wrapper in order to deal with symlink stat calls. An alternative
(and it wouldn't take much to convince me to go the other way) would be to
add a parameter to the url_stat() method to indicate if the stat is a
symlink_stat.

Look forward to your thoughts.

-Sara

pollita@php.net wrote:

The ugliest part of this patch is that it requires special treatment
for the plainfiles wrapper in order to deal with symlink stat calls.
An alternative (and it wouldn't take much to convince me to go the
other way) would be to add a parameter to the url_stat() method to
indicate if the stat is a symlink_stat.

If we implement url_stat() in such way, perhaps we can live without
access_check() method.

Yeah, I got to thinking that later on.... Perhaps the cleanest method
would be to pass on the filestat_type directly to the url_stat method.

plainfiles can then do VCWD_ACCESS, VCWD_STAT, or VCWD_LSTAT as
appropriate and other wrappers can do their thing. (additionally: http,
since it allows redirection, would be able to emulate the symlink layer by
returning information on the initial hit, rather than following 302
redirects)

The php_stat method in filestat.c can then focus on simply managing the
statecache and forming the statbuf into returnable zvals.

But the point is, not all wrappers can accept
*ix-like access control scheme..

Nor can they return full stat detail. i.e.: What's the filesize of
php://stdin ? Who "owns" http://example.com/foo.html ? Last I spoke to
Wez on the subject he indicated that we should just attempt to return as
much information as we can and default on the rest.

http:// wrapper:
is_writable() would always return false.
is_readable() would return true IF a HEAD request returned 2xx or 3xx
is_executable() would always return false.
file_exists() would return true if a HEAD request returned 2xx, 3xx, or
4xx (not including 404)
sb values such as mtime, size, etc... would be parsable from the
http-response headers, while ctime, atime, inode, uid, gid would be
unknown and default to 0 (or maybe -1)

ftp:// wrapper:
is_writeable() would return true if APPE <file> returned 2xx
is_readable() would return true if RETR <file> returned 2xx
is_executable() would always return false
file_exists() would return true if SIZE <file> returned 2xx
sb_size would be fetchable from SIZE <file>, however all other values
are not reliable on all platforms and would have to return 0.

-Sara