From https://github.com/owncloud/core/issues/16287:
> This is caused by XCache at 8e59d4c64b/lib/private/util.php (L1276) where we are trying to reset the opcode cache with `XC_TYPE_PHP`.
> I suspect that while XCache is installed its opcode component is not used. Unfortunately, the XCache API is not really properly documented and thus I don't know what API we would have to call to check whether the `XC_TYPE_PHP` cache is populated. In fact, there is an [open XCache bug](http://xcache.lighttpd.net/ticket/176) since 7 years that discusses this problem and is likely to never get fixed since XCache is abandonware.
Fixes https://github.com/owncloud/core/issues/16287
Older versions of cURL that are unfortunately still bundled by distributors don't support these features which will result in errors and other possibly unpredictable behaviour.
Fixes https://github.com/owncloud/core/issues/16179 for master – stable8 requires another patch.
* Log condition for log level increase based on conditions. Once one of these
conditions is met, the required log level is set to debug. This allows to
debug specific requests, users or apps
* Supported conditions (setting `log_condition` in `config.php`):
- `shared_secret`: if a request parameter with the name `log_secret` is set to
this value the condition is met
- `users`: if the current request is done by one of the specified users,
this condition is met
- `apps`: if the log message is invoked by one of the specified apps,
this condition is met
* fix unit test and add app log condition test
This removes the hard-dependency on output buffering as requested at https://github.com/owncloud/core/issues/16013 since a lot of distributions such as Debian and Ubuntu decided to use `4096` instead of the PHP recommended and documented default value of `off`.
However, we still should encourage disabling this setting for improved performance and reliability thus the setting switches in `.user.ini` and `.htaccess` are remaining there. It is very likely that we in other cases also should disable the output buffering but aren't doing it everywhere and thus causing memory problems.
Fixes https://github.com/owncloud/core/issues/16013
* instead of a static rendering inside PHP use the
JS OC.Notification.showTemporary to hide the
notification after 7 seconds automatically
* fixes#14811
Rework of stream_seek handling; there where basically two bugs: 1. seeking to the end of the current file would fail (with SEEK_SET); and 2. if seeking to an undefined position (outside 0,unencryptedSize) then newPosition was not defined. I used the opportunity to simplify the code.
* this is the preparation for some upcoming logger related changes
* also fixes an issue in the public interface where we request
an internal class as parameter
When moving back the pointer to position 0 (using stream_seek), the pointer on the encrypted stream will be moved to the position immediately after the header. Reading the header again (invoked by stream_read) will cause an error, writing the header again (invoked by stream_write) will corrupt the file. Reading/writing the header should therefore happen when opening the file rather than upon read or write. Note that a side-effect of this PR is that empty files will still get an encryption header; I think that is OK, but it is different from how it was originally implemented.
This changeset hardens the temporary file and directory creation to address multiple problems that may lead to exposure of files to other users, data loss or other unexpected behaviour that is impossible to debug.
**[CWE-668: Exposure of Resource to Wrong Sphere](https://cwe.mitre.org/data/definitions/668.html)**
The temporary file and folder handling as implemented in ownCloud is performed using a MD5 hash over `time()` concatenated with `rand()`. This is insufficiently and leads to the following security problems:
The generated filename could already be used by another user. It is not verified whether the file is already used and thus temporary files might be used for another user as well resulting in all possible stuff such as "user has file of other user".
Effectively this leaves us with:
1. A timestamp based on seconds (no entropy at all)
2. `rand()` which returns usually a number between 0 and 2,147,483,647
Considering the birthday paradox and that we use this method quite often (especially when handling external storage) this is quite error prone and needs to get addressed.
This behaviour has been fixed by using `tempnam` instead for single temporary files. For creating temporary directories an additional postfix will be appended, the solution is for directories still not absolutely bulletproof but the best I can think about at the moment. Improvement suggestions are welcome.
**[CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html)**
Files were created using `touch()` which defaults to a permission of 0644. Thus other users on the machine may read potentially sensitive information as `/tmp/` is world-readable. However, ownCloud always encourages users to use a dedicated machine to run the ownCloud instance and thus this is no a high severe issue. Permissions have been adjusted to 0600.
**[CWE-379: Creation of Temporary File in Directory with Incorrect Permissions](https://cwe.mitre.org/data/definitions/379.html)**
Files were created using `mkdir()` which defaults to a permission of 0777. Thus other users on the machine may read potentially sensitive information as `/tmp/` is world-readable. However, ownCloud always encourages users to use a dedicated machine to run the ownCloud instance and thus this is no a high severe issue. Permissions have been adjusted to 0700.Please enter the commit message for your changes.
This Pull Request introduces a SabreDAV plugin that will block all older clients than 1.6.1 to connect and sync with the ownCloud instance.
This has multiple reasons:
1. Old ownCloud client versions before 1.6.0 are not properly working with sticky cookies for load balancers and thus generating sessions en masse
2. Old ownCloud client versions tend to be horrible buggy
In some cases we had in 80minutes about 10'000 sessions created by a single user. While this change set does not really "fix" the problem as 3rdparty legacy clients are affected as well, it is a good work-around and hopefully should force users to update their client
Make the call compatible with future Symfony version, and avoid
E_USER_DEPRECATED as thrown by the current 2.7.0-beta1:
The "_method" requirement is deprecated since version 2.2 and will be
removed in 3.0. Use getMethods() instead. at
…/Symfony/Component/Routing/Route.php#554
The "_method" requirement is deprecated since version 2.2 and will be
removed in 3.0. Use the setMethods() method instead or the "methods"
option in the route definition. at
…/Symfony/Component/Routing/Route.php#662
