I assume this is expected bahvior. At least on UNIX/Linux systems stat is defined as

     The stat()  function  obtains  information  about  the  file
     pointed  to  by  path. Read, write, or execute permission of
     the named file is not required, but all  directories  listed
     in the path name leading to the file must be searchable.

I assume it is similar on Windows.

If the zip extension is accessing the temp dir this should probably be documented.

Assigning to Pierre who knows zip and windows better :-)

Well, I've made another test. I've written a small c program compiled by VC9 containing calls of stat and fopen. In php I've called this program via exec(). When IUSR_XXXX has no right to list the temp folder the result was: stat() failed with -1, fopen succeeded.

So I think function _zip_file_exists() in zip/lib/zip_open.c should be rewritten. Instead of calling stat, it should be called fopen. Stat calls is made only for existence detection, no fields from struct stat are read. So you can replace stat without any limitations and users of ZipArchive::open will no longer be confused by behaviour of stat function.

zip_file_exists is about testing the existence of a file so stat usage is 
perfectly valid in this case. 

We also have to test if the file exists, because of the options available on 
zip_open (create, overwrite, etc.).

The function _zip_file_exists() is used only once in zip_open() after creating new or reading for open. The usage is not so universal. There is no need for testing of existence of file for which we have no read access. It's used in zip_open() and zip_open() reads or writes to a file. So you are testing existence of file and you have to have at least a read permission. So if you reimplement _zip_file_exists() with fopen you will not lose anything and users of ZipArchive will quite earn.

Case where implementation of some file_exists() via fopen cannot be used is for example implementaion of tempnam - function which tries to generate unique file and can randomly generate some filename. There is a probability that filename exists and you have no read right.

Again in zip_open() such universal behaviour of file_exists() function isn't required. So I thing you can reimplement it and you can spare a lot of time of ZipArchive users. See my test case: file_get_contents succeeded but ZipArchive:open not. Isn't it weird?

The bug is a side effect of the permission issue. But we have (I repeat: we have) 
to do the existence check for the reason I explained earlier.

I will see what can be done to still make it works but you better have to fix your 
perms instead.

The right permission for temp folder are default right permission for Windows Server systems. Microsoft probably has a security reason for not allowing IUSR_XXXX user for listing a temp dir.

Yes I can fix it by changing permissions or not using Windows Temp dir.

I do not fordid you not testing file existence. I offer not do it by stat function ;-)

What I mean by alternative solutions. Just not sure now if it is worth it. Also 
sharing one temp for all vhost is not a wised idea :)

> I assume it is similar on Windows.
Yes. In this case the needed X-Bit (X = directory traversal) is still set. Thus you can "cd" to this directory. But on Windows we have an additional right RD (list directory). This one is not allowed, and so you can't do a "dir" in this directory.
-> thus stat should normally work in this folder for own files.


> Also sharing one temp for all vhost is not a wised idea :)

If all vhosts have a (scripts are executed with a) different SID, that's not a problem. Only the creator SID (and admin/system) have full access to it own files in this folder, but no rights to files created from other SID's. (a little bit like 1777 on *nix. But an *nix you can still list other files. On Win not.)


But back to the topic and let me extend the testscript:
| <?php
| $zipfile = tempnam(sys_get_temp_dir(), 'zip');
| $zip = new ZipArchive();
| 
| $res = $zip->open($zipfile, ZIPARCHIVE::CREATE);
| if ($res !== true) {
|     printf("Can't create file (%d)", $res);
| }
| var_dump($res);
| $zip->close();
| 
| $res = $zip->open($zipfile);
| if ($res !== true) {
|     printf("Can't open file (%d)", $res);
| }
| 
| 
| unlink($zipfile);
| ?>

The result:
| boolean true
| Can't open file (11)

I can create a new Zip-File in this folder, but can't open an existing one.


BTW stat(). Here's an example with PHP stat() (and my favorite realpath):
| <?php
| $temp = tmpfile();
| $filedata = stream_get_meta_data($temp);
| var_dump(stat($filedata['uri']));
| var_dump(realpath($filedata['uri']));
| ?>

The result:
| array (size=26)
|   0 => int 2
|   ...
| boolean false

tmpfile, fopen, stat, whatever is working in this dir. But realpath fails...

@carsten_sttgt at gmx dot de
Can you please for my own sanity keep separate issues separated? Thanks.

The stat problem here is totally unrelated to realpath_r. There is a reason why 
we do it (see my other comment) and I already said that I have to see what else 
we can do to work around this problem without adding more platform specific 
changes in this implementation.

> thus stat should normally work in this folder for own files.

Ups, must correct me. stat (crt) is really not working, even "traverse folder/execute file" is allowed.


But I must agree with vavra. Checking the existence of a file is normally done with (f)open or access. Someone should report this to the libzip team.

No, stat exists for that.

hmmm,
> We also have to test if the file exists,

man 2 access
   access, eaccess, faccessat -- check accessibility of a file

man 2 stat
   stat, lstat, fstat, fstatat -- get file status

I think access is the winner (especially if there is a known problem with stat)

This problem is new to me and again, there are reasons why we use it.

In any case, thanks for the feedback, the problem is identified and has sufficient 
info. I will try to figure a portable way to make this special case working.

> So I think function _zip_file_exists() in zip/lib/zip_open.c
> should be rewritten.

That file belongs to the bundled libzip (which is unbundled as of
PHP 7.4).  If there are still issue, please report these
upstream[1].

[1] <https://libzip.org/>