Commit 0b2e6bc2b0 started caching the directory entry type to improve
performance. Shortly after, we've seen flaky failures of the
buildFromIterator phar test.
When it fails, it's always a value error in the constructor of
RecursiveDirectoryIterator::__construct() with a "no such file or
directory" error. What's happening here is this:
1) A parallel test creates a subdirectory in the current working dir.
2) This test checks hasChildren() on a directory entry, the cached entry
returns "yes" on the subdirectory.
3) The parallel test finishes and removes the subdirectory.
4) The constructor mentioned above is called, causing an exception
because the directory is gone.
This race has always been possible, even before said commit. It's just
that it was very hard to hit before: the expensive stat call made the
race window hard to hit. The race is now easier to hit because of the
caching that is fast.
Since there's many tests that modify the current working directory, it
seems best to mark this as an "all" conflict. We cannot avoid every
TOC-TOU race when working with files with these phar tests.
In particular, mounteddir.phpt caused every conflict I saw on CI, but
there's more tests that create subdirectories in the current working
directory.
Closes GH-11869.
resource would stay uninitialized if the first call to zend_parse_parameters
fails, but the value is still passed to phar_add_file(). It's not used there if
cont_str is provided and so didn't cause any issues.
Closes GH-11202
As shown on the CI runs on my fork (which runs with UBSAN),
the pointers can sometimes be unaligned when trying to write.
This is UB and on platforms like ARM this *can* result in a bus error.
Replace it with memcpy, which at least on x86 and powerpc
architectures does result in the same assembly code.
Closes GH-10940.
Due to an incorrect check, the datetime was never actually set.
To test this we need to write the file using phar, but read the file
using a different method to not get a cached, or a value that's been
transformed twice and is therefore accidentally correct.
Closes GH-10769
The entry.flags was used to check whether the entry has the directory
flag. The flags however were masked to only contain the permissions. We
need to check the mode, before the permission masking, instead of the
flags to check whether it is a directory.
Closes GH-10464
Signed-off-by: George Peter Banyard <girgias@php.net>
I found this issue using static analysis tools, it reported that the condition was always false.
We can see that flags is assigned in the switch statement above, but a mistake was made in the comparison.
Closes GH-10328
Signed-off-by: George Peter Banyard <girgias@php.net>
When a tar phar is created, `phar_open_from_fp()` is also called, but
since the file has just been created, none of the format checks can
succeed, so we continue to loop, but must not check again for the
format. Therefore, we bring back the old `test` variable.
Closes GH-9620.
The phar wrapper needs to uncompress the file; the uncompressed file
might be compressed, so the wrapper implementation loops. This raises
potential DOS issues regarding too deep or even infinite recursion (the
latter are called compressed file quines[1]). We avoid that by
introducing a recursion limit; we choose the somewhat arbitrary limit
`3`.
This issue has been reported by real_as3617 and gPayl0ad.
[1] <https://honno.dev/gzip-quine/>
It is insufficient to check whether the `base` is contained in `fname`;
we also need to ensure that `fname` is properly separated. And of
course, `fname` has to start with `base`.
It's possible to change the returned type using setFileClass(),
which unfortunately only enforces that it's a subtype of
SplFileInfo, not PharFileInfo.
As suggested on the patch discussion, adding init/end macros. Plus,
prefixed the new functions with php_ to avoid possible symbol conflicts.
Signed-off-by: Anatol Belski <ab@php.net>
Niels Dossche