zipnload tmp_dir relative path and chroot

[Michi]

Hi,

when trying to download a zip archive i run into the following issue using the latest ifm version in an chroot environment:

PHP message: PHP Warning:  ZipArchive::close(): Failure to create temporary file: No such file or directory in /htdocs/share/index.php on line 4570PHP message: PHP Warning:  mime_content_type(tmp/ifm-tmp-5eb95107bf749.zip): failed to open stream: No such file or directory in /htdocs/share/index.php on line 4489PHP message: PHP Warning:  filesize(): stat failed for tmp/ifm-tmp-5eb95107bf749.zip in /htdocs/share/index.php on line 4498PHP message: PHP Warning:  fopen(tmp/ifm-tmp-5eb95107bf749.zip): failed to open stream: No such file or directory in /htdocs/share/index.php on line 4500PHP message: PHP Warning:  stream_copy_to_stream() expects parameter 1 to be resource, bool given in /htdocs/share/index.php on line 4503PHP message: PHP Warning:  fclose() expects parameter 1 to be resource, bool given in /htdocs/share/index.php on line 4505

it looks like ifm doesn't honor the chroot environment in this case, while it works perfect for upload (relative path) and zipnload with absolute path.

non-working:

"root_dir" => "upload",
"tmp_dir" => "tmp"

working:

"root_dir" => "upload",
"tmp_dir" => "/htdocs/share/tmp"

Maybe you could support relative tmp_dir path as well?

Thanks you for this great little tool!

[Marco Dickert]

Fixed in 26aea21

Until now the tmp_dir was relative to the parent directory of the directory you want to download. It's now relative to the location of the IFM.

[Michi]

Thanks a lot, works like a charm! Just one additional question:

Would it be possible to suppress the zipnload icon next to the "dir up" link/entry? It seems to make really make no sense and doesn't work either 😁

[Marco Dickert]

Would it be possible to suppress the zipnload icon next to the "dir up" link/entry? It seems to make really make no sense and doesn't work either

It should work, and it's intended to give users of shared webspaces the chance to download "the entire webspace". If it does not work for you, please check the PHP error log, make sure that the webserver can write to tmp_dir, and ensure that the PHP user has read permissions for the directory.

[Michi]

OK, i've checked again:

• tmp_dir (both relative "tmp" and/or absolute "/tmp") exists and is writable for webserver user
• no error log
• access log example: [12/May/2020:10:28:50 +0200] "GET /share/?api=zipnload&dir=foo&filename=. HTTP/1.1" 200 0
• browser error msg: {"status":"ERROR","message":"Ung\u00fcltiger Dateiname \u00fcbergegeben."}

[Marco Dickert]

Hm. That might be another bug in the IFM. Does that function also fail in subdirectories or just on the highest level? Might also be related to your chroot setup. Can you describe that a little bit?

[Michi]

nothing special i guess... 😁

• OpenBSD 6.6
• build in httpd
• php-7.3.17

php files are served by PHP FastCGI Process Manager 'PHP-FPM', all running in default chroot directory /var/www, thus an example config could look like this:

ext_addr="egress"

server "default" {
    listen on $ext_addr port 80

    root "/htdocs"
    directory index index.php

    location "*.php*" {
        fastcgi socket "/run/php-fpm.sock"
    }
}

[Marco Dickert]

Did you turn off showhiddenfiles? If so, please turn it on and test again. I guess this is a bug in the filename validation.

[Marco Dickert]

Btw. it might be best to post your entire config. You can get the active config over the api:

curl -s "https://ifmdemo.gitea.de/ifm.php?api=getConfig" | python -m json.tool

(authentication details are automatically skipped)

[Michi]

Good shot, you hit it! It works with showhiddenfiles enabled.

The active config from the curl api call is as follows:

{
    "ace_includes": "",
    "ajaxrequest": 0,
    "auth": 0,
    "chmod": 0,
    "contextmenu": 0,
    "copymove": 1,
    "createarchive": 0,
    "createdir": 1,
    "createfile": 1,
    "delete": 1,
    "disable_mime_detection": 0,
    "download": 1,
    "edit": 0,
    "extract": 0,
    "forbiddenChars": [],
    "inline": false,
    "isDocroot": false,
    "language": "de",
    "remoteupload": 0,
    "rename": 1,
    "root_public_url": "",
    "selfoverwrite": 0,
    "showfilesize": 1,
    "showgroup": 0,
    "showhiddenfiles": 1,
    "showhtdocs": 0,
    "showlastmodified": 0,
    "showowner": 0,
    "showpath": 1,
    "showpermissions": 0,
    "timezone": "Europe/Berlin",
    "tmp_dir": "tmp",
    "upload": 1,
    "zipnload": 1
}

It seems the output is incomplete, at least root_dir is missing...

[Marco Dickert]

Ok, the bug should be gone in 359592c.

It seems the output is incomplete, at least root_dir is missing...

Yes, auth_source and root_dir are hidden for security reasons. This api endpoint is the source for the frontend configuration, and the frontend doesn't need either of these settings.

Let me know if you find any flaws, I restyled some of the code and fixed some flaws (for example that till now the zipnload function happily packaged .ht* files and hidden files, even if they were hidden by the configuration).

[Michi]

ok, it works. thank you!