[GH-ISSUE #1264] Firejail in PHP exec() results in "Error: user .config directory is not owned by the current user" #860

Closed
opened 2026-05-05 06:59:32 -06:00 by gitea-mirror · 4 comments
Owner

Originally created by @tobltobs on GitHub (May 3, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1264

I am trying to jail the command I use in PHPs exec() with firejail.

The commands I tried:

firejail [cmd]
firejail --profile=/etc/firejail/default.profile [cmd]

But I always get the following error:

Error: user .config directory is not owned by the current user
Error: cannot establish communication with the parent, exiting...
Originally created by @tobltobs on GitHub (May 3, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1264 I am trying to jail the command I use in PHPs exec() with firejail. The commands I tried: ``` firejail [cmd] firejail --profile=/etc/firejail/default.profile [cmd] ``` But I always get the following error: ``` Error: user .config directory is not owned by the current user Error: cannot establish communication with the parent, exiting... ```
gitea-mirror 2026-05-05 06:59:32 -06:00
Author
Owner

@SkewedZeppelin commented on GitHub (May 3, 2017):

Because the www-data or httpd user doesn't have a home directory. And using firejail in PHP might not be the best idea. You might want to instead wrap your command with escapeshellarg() and wrap your user input with noHTML(). If you haven't, using a framework like Cake or Laravel might be worth looking into, it'll handle all that stuff for you (to an extent). There is also an old program called Skipfish which can detect some common mistakes in your PHP, its worth giving it a run.

//Credit: https://paragonie.com/blog/2015/06/preventing-xss-vulnerabilities-in-php-everything-you-need-know
function noHTML($input, $encoding = 'UTF-8') {
return htmlentities($input, ENT_QUOTES | ENT_HTML5, $encoding);
}

Edit: https://www.owasp.org/index.php/PHP_Configuration_Cheat_Sheet Also has lots of useful changes to php.ini that you can use to harden it.

<!-- gh-comment-id:298966340 --> @SkewedZeppelin commented on GitHub (May 3, 2017): Because the www-data or httpd user doesn't have a home directory. And using firejail in PHP might not be the best idea. You might want to instead wrap your command with escapeshellarg() and wrap your user input with noHTML(). If you haven't, using a framework like Cake or Laravel might be worth looking into, it'll handle all that stuff for you (to an extent). There is also an old program called Skipfish which can detect some common mistakes in your PHP, its worth giving it a run. > //Credit: https://paragonie.com/blog/2015/06/preventing-xss-vulnerabilities-in-php-everything-you-need-know function noHTML($input, $encoding = 'UTF-8') { return htmlentities($input, ENT_QUOTES | ENT_HTML5, $encoding); } Edit: https://www.owasp.org/index.php/PHP_Configuration_Cheat_Sheet Also has lots of useful changes to php.ini that you can use to harden it.
Author
Owner

@tobltobs commented on GitHub (May 3, 2017):

I am trying to reduce the risk of feeding user uploads to external programs like ghostscript or imagemagicks convert. Hardening PHP or escaping arguments is already done, but doesn't help with this attack vector.

And using firejail in PHP might not be the best idea.

I am evaluating firejail as a chroot alternative and from the offered feature it looks superior to me. Is there a special reason why using firejail in PHP might not be the best idea?

I could avoid calling firejail by www-data as the processing could also be done by background queue which can use a user with a home. However, I am having problems setting up a firejail for a command with one recursively white-listed directory where changes are persisted. I guess I will have to try harder.

<!-- gh-comment-id:298976143 --> @tobltobs commented on GitHub (May 3, 2017): I am trying to reduce the risk of feeding user uploads to external programs like ghostscript or imagemagicks convert. Hardening PHP or escaping arguments is already done, but doesn't help with this attack vector. > And using firejail in PHP might not be the best idea. I am evaluating firejail as a chroot alternative and from the offered feature it looks superior to me. Is there a special reason why using firejail in PHP might not be the best idea? I could avoid calling firejail by www-data as the processing could also be done by background queue which can use a user with a home. However, I am having problems setting up a firejail for a command with one recursively white-listed directory where changes are persisted. I guess I will have to try harder.
Author
Owner

@netblue30 commented on GitHub (May 3, 2017):

I would put all the server in a sandbox. Both apache and nginx are supported.

<!-- gh-comment-id:298976456 --> @netblue30 commented on GitHub (May 3, 2017): I would put all the server in a sandbox. Both apache and nginx are supported.
Author
Owner

@tobltobs commented on GitHub (May 3, 2017):

@netblue30 That might be an option. But restricting the calls to external programs could be more strict than the restrictions I could apply to the server. Eg. I could use --net=none for calls to ghostscript, but my PHP scripts require the ability to download a file.

<!-- gh-comment-id:298978491 --> @tobltobs commented on GitHub (May 3, 2017): @netblue30 That might be an option. But restricting the calls to external programs could be more strict than the restrictions I could apply to the server. Eg. I could use --net=none for calls to ghostscript, but my PHP scripts require the ability to download a file.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#860
No description provided.