-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Something changed recently about default apache configuration (FollowSymLinks disabled?) #1393
Comments
The images you've linked are CLI images and don't include Apache2 at all. 😅 Do you happen to have some more specific examples so we can investigate? We didn't change anything related to this recently (that I recall), so my hunch is that Debian probably had an update to their |
Oh, sorry I linked them incorrectly. The ones we are using are the apache ones: We just have some soft links called "behatrun1", "behatrun2", "behatrun3" (we use that for parallel behat execution using the same codebase) within
(aka, a simple With previous image versions, when we invoke I still have not looked what has changed (only suspicious commit that I've seen overlooking is one changing all the default permissions, not sure if it's related or no). But I've compared here some executions and the only difference in the whole stack (images, composer, codebase...) is the php image used. That leaded me to think it's caused by some recent change in the images (the apache that comes with them or something when creating the images). They were working ok until 2-3 days ago, just today when we pulled the latest we found the consistent error. If I find something else, I'll share it here. Hope it helps. Ciao :-) |
Quickest way to verify whether it's #1383 is to add |
Hi, I can confirm that, when Still, it's not clear for me if that's because of #1383 or because apache changed something in their perms checks / defaults now being stricter. I'll try to see in recent releases / CVEs if there is any change. In any case, those changes need to have happened over the last few days, because the image we were using (working "ok") previously was created March 27th. And the one that started to fail was March 30th). That's how we came to here, after checking that the only difference was that one:
In the good side, all we have to do is to add the Ciao :-) |
Uhm... so, looking to apache2 debian changelog (I imagine that's a good source, amend me if not, please): https://launchpad.net/debian/+source/apache2/+changelog It seems that their latest update to 2.4.56-1 happened on March 8th. And no changes since then. So, if I'm interpreting that correctly, the previous PHP images already were using that apache debian package. Hence, it seems that #1383 is the ultimate case for this change of (previous) behaviour to happen and apache not accepting root's soft links any more. Ciao :-) |
And, sort of confirmed... I've just connected to the container while it was still installing the testing environment, have executed So the 777 => 1777 modification (#1383) seems to be the one causing the change of behaviour, indeed. So, the question remains... should we adapt our scripts to use Ciao :-) |
We do not plan to revert #1383 because it is generally a more secure way to accomplish the original intent of our Alternatively, you could run your container itself with |
(see also "Running as an arbitrary user" under https://hub.docker.com/_/php) |
Thanks @tianon ! All ok for us. |
Recent changes to the upstream php-apache images now require us to explicitly create the behatrunXX sof links with the www-data user (previously it was ok with root too). See docker-library/php#1393 In fact we already were using the --user (-u) flag in a number of cmds, just the links command were missing them and causing behat reruns to stop working. Once this is merged, we'll proceed to unpin the php-apache images @ moodlehq/moodle-php-apache#174
Hi,
we have detected recently that, when using the latest/current builds from March 28th, some applications that previously were running and working ok have stopped working with apache logs plenty of errors:
Is this an intended change and now we have to proceed to enable
FollowSymLinks
or maybe some unexpected change that needs to be fixed?We have detected it in a few images:
But surely all them (apache) are the same.
Using the 8.1.16 ones or older 8.1.17 ones (before the very last ones commented above) it seems that the sym links are working ok.
Thanks for the nice work and ciao :-)
The text was updated successfully, but these errors were encountered: