ambionics / phpggc

PHPGGC is a library of PHP unserialize() payloads along with a tool to generate them, from command line or programmatically.
https://ambionics.io/blog
Apache License 2.0
3.2k stars 492 forks source link

Update Dockerfile #186

Closed baksist closed 5 months ago

baksist commented 5 months ago

Hi! When I was trying to run PHPGGC using Docker, I encountered 2 issues.

1). Build fails because of RUN pip install rich, as shown on the screenshot.

image

Replacing this command with a system-wide installation of py3-rich package via apk solved this issue and allowed to successfully build the image.

2). BusyBox env doesn't have an -S flag.

image

That's what I saw when running the image for the first time. I resolved this issue by changing the shebang of phpggc script to just #!/usr/bin/env php. Considering that the phar.readonly option is set via php.ini (when using Docker), it seems to be an appropriate solution. In order to not modify the script itself or to create a copy, I replace the shebang with sed during build.

With these fixes I managed to finally use the tool (which is awesome btw!)

UPD: only after creating the PR I realized that because of the issue with rich, installing pip is not necessary anymore :) So perhaps it is also worth removing it from RUN apk add command to reduce image size (which was done in the second commit)

cfreal commented 5 months ago

Hello baksist,

I must admit it has been a long time since I've tested the docker setup. Thanks for your contribution.

I'm pretty unhappy with the current state of the shebang, but I don't see any other way to proceed, as phar.readonly cannot be set from the PHP script.

Another solution would be to make the entrypoint call php -dphar.readonly=0 phpggc. We could even generalize this by replacing the phpggc file, which is currently PHP code, to a bash wrapper that calls the php binary, but then I guess that might introduce other problems?

Anyways, pushing your code to main.

Thanks again, Charles

baksist commented 5 months ago

Thank you for such a swift response!

Regarding the whole shebang situation, I guess it's also possible to use coreutils-env package in Alpine to bring back the consistency between what is run locally vs. in Docker. It will allow to use the original shebang in the container, but if you're looking for a way to move away from using this shebang completely, I don't have much else to add.

In any case, I was happy to contribute!