Latest security patch prevents access to uploaded logos

It doesn't introduce any holes (at least, none that can be exploited easily through Drupal), but you're the second person to report this as a requirement to their .htaccess. I'm at a loss why as well.

Could you please provide Apache error log entries associated with "It didn't show". This will give insight into what is actually meant, from Apache's perspective, by "it didn't show."

Thanks.

After further thought, what I expect to see in the logs is "RewriteEngine not permitted here". Due to security considerations that I'll go into in more detail if anybody cares, Rewrite* directives are only permitted if Options FollowSymlinks is enabled. For most folks, Options FollowSymlinks is enabled everywhere, so this is a non-issue, but if you happen to disable it, you'd have to re-enable it here. Which is itself problematic, since most folks won't have 'AllowOverride Options' enabled.

Further experimentation is required to verify these theories. I haven't tested this yet.

Eh oh, DrB. Per the apache mailing list thread you had pointed us to, we had added Options None in an attempt to satisfy the "turn off MultiViews" requirement (it being, certainly, "stronger" than just Options -MultiViews). While I was unable to reproduce it on my own server, we did get one report from our testers of a server error which complained about RewriteRules - which, in this case, were being inherited from the parent .htaccess and complaining as you surmise - that FollowSymLinks or SymLinksIfOwnersMatch weren't enabled (due to our None) and thus RewriteRule wasn't allowed. I had him add a set of IfModules for mod_rewrite, with RewriteEngine off, and the problem went away. That's the .htaccess we're currently shipping.

I second the request for logs. We're switching off the Rewrite engine because we set Options None. Since it's off, you shouldn't get the error.

Would you mind testing the following .htaccess:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
RewriteEngine off

After updating from 4.7.1 to 4.7.2 no pictures are shown on my Drupal site anymore. If I try a direct call of a picture-URL I get the error: "Forbidden You don't have permission to access /files/xyz.jpg on this server."

With the new line "Options +FollowSymLinks", the problem is fixed.

I can confirm this issue. For me its exactly as for Daniel55. All my images from /files/siteX/... were broken after update (my Drupal's .htaccess is in /files/siteX/...) even those of gallery2, which are located at /files/gallery/... in a parellel directory. After adding "Options +FollowSymLinks" (or zero-out of htaccess of course) all works as expected.

I am experiencing this specifically for logos. The obnoxious thing about it is that I figured it had something to do with the new .htacess, but I couldn't delete it. It kept reappearing so I couldn't really test it thouroughly. I have the code in #5 in my htacess. I can't call images directly from http either.

@jo1ene, you can empty .htaccess or add the Options Followsymlinks as Steve describes.

Can you tell a bit more about the site(s) setup? For example; are these all multi-site installation?

I found the solution. My server didn't like any reference to options at all and it wanted the .htacess file itself to be 644 permissions. It had spawned itself at 600. Basically, I have an empty file now with 644 permissions and it's working.

I have the same issue in single site 4.7.2 with files and images, uploaded to "files" dir by upload module or FTP.
"Options FollowSymLinks" in "files/.htaccess" fixes my problem, thanks Steve.

according to the principle that Mobus knows more about apache than myself, this is good to go.

What happens to those who already have a .htaccess? The existing one won't get modified.

Irrelevant, I'd say. The bug is quite noticable - all your uploads won't work, including logos, user avatars, and so forth. People affected either are a) already working around it by manually adding the line this patch does or b) using a zero byte file, also as recommended by this issue. For those who don't have the particular set of Apache configurations that cause this bug, the newly revised .htaccess is unnecessary, and affords no extra, or less, protection.

ok, thanks for the explanation. :)

Committed to HEAD.

On dealing with upgrades- I'm not sure this is enough since the solution (which i think is rm files/.htaccess and let it be recreated automatically) is not actually obvious. I'll mark this as fixed, but someone should reopen if they have any plans for making this more obvious.

backported to 4.7

I have the same problem, but I do not understand what is said here. I understand the problem is fixed, but I am completely at a loss about what I should do.

I've got the described problem. Unfortunately none of the above mentioned suggestions does help me - except the one to empty the .htaccess file. I don't understand if that workaroung fixes the problem without getting into trouble because of security risks.

(Not running a server by my own I'm no expert in Apache logs, I guess I can't even see them, can I? However: single site in a subdirectory, .htaccess in "[subdirectory]/files"; do you need more info?)