8000 [Process] Decouple Process::findExecutable() from open_basedir by Luc45 · Pull Request #54151 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[Process] Decouple Process::findExecutable() from open_basedir #54151

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.

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

Closed
wants to merge 2 commits into from

Conversation

Luc45
Copy link
Contributor
@Luc45 Luc45 commented Mar 4, 2024
Q A
Branch? 5.4
Bug fix? yes
New feature? no
Deprecations? no
Issues Fix #41006
License MIT

This PR ports the PR #47422 to Symfony Process 5.4

@Luc45
Copy link
Contributor Author
Luc45 commented Mar 4, 2024

This PR has a failing test because we only run SIGCHILD tests on PHP 7.2.

I wonder if this is specific to 7.2, or if we would see the same failures if we ran it on PHP 8+, too...?

@derrabus
Copy link
Member
derrabus commented Mar 5, 2024

#47422 was merged as a feature into 6.4 which was still under development at that time. If you want us to reclassify this change as a bugfix, I think you need to elaborate on that. Otherwise, this PR will be closed soon because we don't backport features to LTS branches.

@carsonbot carsonbot changed the title Port PR #47422 to Symfony Process 5.4 [Process] Port PR #47422 to Symfony Process 5.4 Mar 5, 2024
@Luc45
Copy link
Contributor Author
Luc45 commented Mar 5, 2024

Got it. I believe this is a bug.

$finder = new \Symfony\Component\Process\ExecutableFinder();

$finder->find('docker'); // /usr/bin/docker
exec('which docker') // /user/bin/docker

ini_set('open_basedir', '/tmp/foo');

$finder->find('docker'); // null
exec('which docker') // /user/bin/docker

@Luc45
Copy link
Contributor Author
Luc45 commented Mar 5, 2024

Actually, this behavior is present on Process ^5, ^6, and ^7. PR #47422 doesn't solve it as I expected.

php foo.php                                                                                                                                                                                                          [24/03/5| 5:45]
string(15) "/usr/bin/docker"
string(15) "/usr/bin/docker"
NULL
string(15) "/usr/bin/docker"

Test file:

<?php

require __DIR__ . '/vendor/autoload.php';

$finder = new \Symfony\Component\Process\ExecutableFinder();

var_dump($finder->find('docker'));
var_dump(exec('which docker'));

ini_set('open_basedir', '/tmp/foo');

var_dump($finder->find('docker'));
var_dump(exec('which docker'));

@Luc45
Copy link
Contributor Author
Luc45 commented Mar 5, 2024

It seems that is_executable('/usr/bin/docker') is affected by open_basedir restrictions and returns false, even though exec('/usr/bin/docker --version') works with the same open_basedir restrictions:

<?php

require __DIR__ . '/vendor/autoload.php';

$finder = new \Symfony\Component\Process\ExecutableFinder();

$finder->find('docker'); // /usr/bin/docker
exec('which docker'); // /user/bin/docker
is_executable('/usr/bin/docker'); // true
exec('/usr/bin/docker --version'); // Docker version 25.0.2, build 29cf629222

ini_set('open_basedir', '/tmp/foo');

$finder->find('docker'); // null
exec('which docker'); // /user/bin/docker
is_executable('/usr/bin/docker'); // false
exec('/usr/bin/docker --version'); // Docker version 25.0.2, build 29cf629222

ExecutableFinder uses is_executable, so it's affected by this. It seems like a PHP bug that should be reported upstream, but also ideally fixed and backported on Process if possible, do you agree?

@Luc45
Copy link
Contributor Author
Luc45 commented Mar 6, 2024

Actually, it's not that is_executable is affected by open_basedir when it shouldn't - it's that exec isn't, and I would bet that proc_open isn't, neither.

<?php

require __DIR__ . '/vendor/autoload.php';

$finder = new \Symfony\Component\Process\ExecutableFinder();

exec('mkdir -p /tmp/bar && rm -rf /tmp/bar/*.test');

touch('/tmp/bar/no-basedir-touch.test'); // Created.
exec('touch /tmp/bar/no-basedir-exec.test');  // Created.

ini_set('open_basedir', '/tmp/foo');

touch('/tmp/bar/touch-basedir.test'); // Not created.
exec('touch /tmp/bar/touch-basedir-exec.test'); // Created.

Result:

➜  bar ls -Al                                                                                                                                                                                                                                                                                              
-rw-r--r-- 1 lucas lucas 0 mar  6 11:38 no-basedir-exec.test
-rw-r--r-- 1 lucas lucas 0 mar  6 11:38 no-basedir-touch.test
-rw-r--r-- 1 lucas lucas 0 mar  6 11:38 touch-basedir-exec.test

So the bug, after all, is using is_executable, which is bound by open_basedir to invoke code that isn't bound by open_basedir, such as exec and proc_open. Although, "fixing" this could also be an unwanted security issue for existing code.

@nicolas-grekas nicolas-grekas changed the title [Process] Port PR #47422 to Symfony Process 5.4 [Process] Decouple Process::findExecutable() from open_basedir Mar 13, 2024
@nicolas-grekas
Copy link
Member

Works for me as a bugfix.

@nicolas-grekas
Copy link
Member

But indeed the tests need to be taken care of!

@Luc45
Copy link
Contributor Author
Luc45 commented Mar 13, 2024

Works for me as a bugfix.

This PR doesn't fix it, this is still present in Symfony ^7

@Luc45
Copy link
Contributor Author
Luc45 commented Mar 13, 2024

Initially, I thought that the upstream PR would fix it, but it doesn't.

We can either consider it a "feature" not a "bug", or we can fix it. I just wonder if there are any security concerns on fixing this.

@Luc45
Copy link
Contributor Author
Luc45 commented Mar 13, 2024

I'll close this PR and open a bug report

@Luc45 Luc45 closed this Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0