hi

I have an non solved issue causing not generated pictures :
if the size of full image is less or equals than slideshow size, the picture isn't shown in the slideshpw because the cache image is not generated.
exemple : size of the picture 800*600 and size of the slideshow : 900.

some info in this topic : http://www.zenphoto.org/support/topic.php?id=17009 and this ticket : http://www.zenphoto.org/trac/ticket/2264

I do some test with an older release of zenphoto (1.4.2.4) and in that case, everything works fine.
- [b]you can see my issue here with 1.4.3.x [/b] http://test.vincentbourganel.fr/20120720-vacances-ete-2012-bretagne/img_7818.jpg.html
- [b]you can see no problem here[/b] : http://test2.vincentbourganel.fr/20120720-vacances-ete-2012-bretagne/img_7818.jpg.php

with some debug whe using i.php (the size of img_7818.jpg is 900*900) :
- http://test.vincentbourganel.fr/zp-core/i.php?a=20120720-vacances-ete-2012-bretagne&i=img_7818.jpg&s=900&q=85&wmk=!&debug => [b]doesn't work[/b]
- http://test2.vincentbourganel.fr/zp-core/i.php?a=20120720-vacances-ete-2012-bretagne&i=img_7818.jpg&s=900&q=85&wmk=!&debug => [b]works fine[/b]

so what is the problem with zenphoto 1.4.3.x ?

I am sorry, what is the issue? Both sites work for me and looking at the source there is an image servered from the cache. See screenshots here: http://zenphoto.maltem.de/Test/

Edit: I see the issue of the slideshow. No idea. As always any errors?

I just compared the 1.4.2.4 code to the dev branch (not 1.4.3.x)

And it LOOKS to me like one thing new is the attempt to symlink the image if upscaling is disabled. I think copying is also new for that matter. That's just a quick glance at the code and I don't know when those changes were made so not to make too much out of it, but still it leads to a thought:

Are there any symlinks created in your cache directory and does your server follow symlinks?

Maybe the experts can shoot down or confirm the possibility of this being an issue.

If the server does not support symlinks it should report an error when the link creation is tried. Then ZP reverts to copying.

I understood that failure to create a symlink falls back to copying. I don't have experience with the php symlink function and I only looked at the code a minute but I was going with the idea that

Options -FollowSymLinks

would not cause creation of the symlink to fail and would not force the copy instead, but would cause the image load to fail. If you're saying this is wrong, then never mind, just a guess, but a guess that is possibly related to recent changes and also to different servers.

My server does not support symlinks at all and it seems to work. Slideshow is set to colorbox with sized images.

Ok but that still doesn't disprove the theory. If your server doesn't support symlinks "at all", then a symlink won't be made. It will be copied instead as sbillard points out and of course you wouldn't have a problem.

The potential problem I'm talking about is if a symlink IS successfully made (so at least the file system supports symlinks), but the apache option is set to not follow symlinks. The symlink could be created, but apache will refuse to deliver it later.

see apache documentation:
http://httpd.apache.org/docs/current/mod/core.html#options

I suppose I should have been more verbose the first time I posted it. It's likely not even the problem, but it fits.

Actually it's hard, but possible, for me to believe this situation wouldn't be able to cause the OP's symptoms, but that doesn't mean it IS what's causing them either.

Sure, it might still be a server configuration issue not following the symlink after creating it. My point was actually just that the copying vs symlink in general is working.

Might be that "Options -FollowSymLinks" is needed to make that work generally or on some servers. On my local server it does work without it (Just to note, our live server does not support symlinks, too).

@VIncent: Please try adding that to the htaccess file.

Default behavior is for FollowSymLinks to be set, so normally it's not a problem but this could be considered a security issue on some servers I suppose and who knows, maybe wouldn't even be overidable.

I think there are two ways (and mulitple places) that the default options could be unset.
1) For the directory in question, use an Options syntax listing all desired options without the + or - prefixes on the options, and fail to include that option in the list.

2) Explicitly removing the option with the - prefix.
The +/- and bare syntaxes can't be mixed in the same line either.

By the way the - prefix that you (acrylian) listed would break symlinks. He would want the + prefix to add the option without overriding other option settings.

So in .htaccess he would try:
Options +FollowSymLinks

[i]By the way the - prefix that you (acrylian) listed would break symlinks.[/i]
Right, was just lazy copying the one from above...

hello

I added Options + FollowSymLinks at the beginning of .htaccess file: no effect on the generation of the cache.

I contacted my host who told me that :
- adding the above command allows symlink in php only
- but symlink is forbidden at the server level via Suhosin (advanced protection system for PHP installations used by my host): there is a list of functions disallowed by suhosin (suhosin.executor.eval.blacklist = stream_socket_server, stream_set_write_buffer, stream_socket_sendto, symlink)

now, symlink is allowed at the server level via php.ini by removing it from the blacklist (suhosin.executor.eval.blacklist = stream_socket_server, stream_set_write_buffer, stream_socket_sendto) and zenphoto works.

my host noticed me that configuration may cause vulnerability holes and adviced me to restore the blacklist of suhosin)

Well if the php symlink function was actually disabled in some way, then that shouldn't have caused a problem since it should have reverted to copying.

Either the symlinks were getting created (which is why I asked that) but not followed, or they weren't getting created and zenphoto failed to fall back properly to copying.

One case is a zp bug in some sense at least and one is not.

You say it works now though so this must be the issue somehow.

PS. as far as I know there should not be a space between + and FollowSymLinks . That will either get interpreted correctly anyway, will not be interpreted at all, or might be interpreted incorrectly. I have no idea which. If it's just a typo then never mind.

Also even if the symlinks were getting created (so not a bug really in that case), a feature request to optionally disable the symlink attempt entirely might be useful. It's an obscure option though and wouldn't be very obvious when it's needed. Maybe default could be to never symlink.

My host uses suoshin as well and as mentioned has disable symlinks as well for security reasons (since they can link to the outside - no idea if they can be limited to server internal targets). So apparently symlinks do not work on a server they should not even be created at all, I would think..

If a server does disable symlinks it should do so in a way that trying to create one fails. Then Zenphoto will fall back to copying the image. But if the server just lies and says it did create the symlink, then Zenpoto does get fooled.

It might be worse (or equally bad) than symlink returning true dishonestly:

From:
http://www.hardened-php.net/suhosin/configuration.html

suhosin.executor.func.blacklist

Type: String
Default:
Comma separated blacklist of functions that are not allowed to be called. If no whitelist is given, calling a function within the blacklist will terminate the script and get logged.

It seems suhosin doesn't even provide a simple way to see if a function is blacklisted either. So basically if your app uses suhosin blacklisted functions, you could as well just not install the app rather than install suhosin, since suhosin's approach is basically just to break the app anyway.

Below is a link to some code to do the check but good grief, should every php script check every function before calling it? I would think suhosin should play nicer and/or people should use it at their own risk:

https://github.com/swznd/CodeIgniter/commit/c9da86f4c47e49a47df782455ef2c6118d1ba879

Edit:
and/but here is the security issue with symbolic links:
http://www.hardened-php.net/advisory_082006.132.html

I'm not sure but it seems to me that this exploit already assumes the attacker has taken (or been given) control of your php environment to some extent and this is an escalation.

Your interpretation is correct--this is an escolation issue. I have no issue with people wanting a secure site, but the more security you apply the less useful your site becomes. After all, the complete security is not to have the site in the first place.

But I also think that these blockages should be designed to play well with others. Certainly coders cannot test each and every function to see if it was blocked. I do not see why the suhosin people can't just short circuit the function and return its error response.

of course, you can't check each function.
but it seems that some functions could create vulnerabilities.

it's hard for me to understand everything you said (I'm not senior in php) but I understood that failure to create a symlink falls back to copying.

So maybe you should test the function before uses it and if it black listed, apply the workaround with copying.

Yes, if the symlink attempt **REPORTS** a failure, then zp reverts to copying. Suhosin blacklisted functions, according to the manual, just end the whole process (the zenphoto script) without reporting anything, it seems maybe you got that, but I summarize anyway.

I have no comment about your workaround request, as it's not for me to comment on. I'm just some guy who able to help track this down.

two things :
- as you notice here : http://www.hardened-php.net/suhosin/configuration.html
`calling a function within the blacklist will terminate the script and get logged` : so, what and where are logged ?
- it is possible to test symlink with the function noticed here, before use it
https://github.com/swznd/CodeIgniter/commit/c9da86f4c47e49a47df782455ef2c6118d1ba879
there is two different ways to have a workaround.

maybe, another way is to reconsider the improvement of zp 1.4.3.x (as I noticed above, everything works well with 1.4.2.x : maybe no symlink are used...)