8000 Artisan::call fails with error with enabled open_basedir · Issue #42171 · laravel/framework · GitHub
[go: up one dir, main page]
Skip to content

Artisan::call fails with error with enabled open_basedir #42171

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
rw4lll opened this issue Apr 28, 2022 · 2 comments
Closed

Artisan::call fails with error with enabled open_basedir #42171

rw4lll opened this issue Apr 28, 2022 · 2 comments

Comments

@rw4lll
Copy link
rw4lll commented Apr 28, 2022
  • Laravel Version: 8.83.9
  • PHP Version: 7.4.29
  • Database Driver & Version: -

Description:

If open_basedir is enabled on the server and Artisan:call() command called from the web, not from the console (e.g. in the controller),
the whole script fails with php error: realpath(): open_basedir restriction in effect. File(/) is not within the allowed path(s)

open_basedir_issue_example

I've investigated the problem from my side. It comes with the update of symfony/console package from 5.3 to 5.4.
Related issue: symfony/symfony#44457

Place in the code: https://github.com/symfony/symfony/blob/d11e41be6cb23016894c564d5c2b9ef3357ecaa7/src/Symfony/Component/Console/Command/DumpCompletionCommand.php#L44

Since 5.4 version it calls realpath($_['PHP_SELF']) inside. Everything works well if it's called from console.
But if make Artisan:call from web, then PHP_SELF returns "/". It works also ok until open_basedir is disabled.
But when the restrictions are enabled, it fails with the error, because "/" path is not allowed.

Steps To Reproduce:

  1. Prepare server with php 7.4.29 and latest laravel 8.
  2. Enable open_basedir on the server with some directory enabled (e.g. /var/www).
  3. Add following code to the controller:
    \Artisan:call('cache:clear');
  4. Open the page with the controller and see the result.
@driesvints
Copy link
Member

I'm afraid that there's nothing we can do here since we don't own the code. The best course of action is to attempt a PR to symfony. Sorry

@rw4lll
Copy link
Author
rw4lll commented Apr 29, 2022

@driesvints thanks for the answer, I'll try to make a PR there.

@rw4lll rw4lll mentioned this issue May 8, 2022
Merged
nicolas-grekas added a commit to symfony/symfony that referenced this issue May 10, 2022
@nicolas-grekas
bug #46291 [Console] Suppress unhandled error in some specific use-ca…
60836ff 
…ses. (rw4lll)

This PR was merged into the 5.4 branch.

Discussion
----------

[Console] Suppress unhandled error in some specific use-cases.

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | Fix #... <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| License       | MIT
| Doc PR        | symfony/symfony-docs#... <!-- required for new features -->

If the package is used not in console with open_basedir enabled, since 5.4 it fails with unhandled php error here:
(https://github.com/symfony/console/blob/06974380c667d7d8e3cd0f24bf51f816a71ca6c6/Command/DumpCompletionCommand.php#L44) because of trying to call realpath("/") and, of course, it's not allowed.

It's a very specific use-case for Symfony, but can happen if it's used as dependency, e.g. in Laravel. I've described it in details here: laravel/framework#42171

I think that the best would be just suppress the error in that case.

Commits
-------

d975ca7 Suppress unhandled error in some specific use-cases.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@driesvints @rw4lll
0