Testing for Apache .htaccess settings
|
bromide
![]()
Joined: 2010-08-20
Posts: 28 |
Posted: Thu, 2010-09-02 14:51
|
|
From the feedback thread: bromide wrote:
I think I've set mod_rewrite and AllowOverride FileInfo Options in Apache properly but Gallery3 still isn't letting me edit permissions on albums. Does anybody know a handy way, perhaps a snippet of PHP code, to view the computed values for Apache settings on a particular folder? I have my own server, not a shared server account, so I have full access. bharat wrote:
Here's how you can debug it. Create a file in modules/gallery/controllers called "x.php" and put this in it: bromide wrote:
I tried your first step, creating x.php, and when I viewed it in the browser I got a Kohana_404_Exception if I recall correctly. I got this for a number of other files in that directory, incidentally. I found that welcome_message.php was the simplest one that also worked but when I tried copying it to x.php it still didn't work but I got a blank page without even any HTML instead of the 404 error. bromide wrote:
PHP 5.2.4 by the way, and Ubuntu 8.04 and MySQL 5.051 bharat wrote:
@bromide: Oh -- I had an error in my instructions. You need to browse to /gallery3/index.php/x/test <-- that "/test" part was missing. You're not trying to open x.php directly in the browser are you? That won't work. Either way, please start a new forum topic for this issue so that we're not having an in-depth conversation on this more general topic. |
|


Posts: 28
No, I was going to http://your.site/gallery3/index.php/x. I would try /x/test but my installation is completely nonfunctional now. Do you have any idea what's going on with that? I've only seen this kind of behavior before when there is a caching layer somewhere and the cache is getting corrupted.
To deal with this before now I've actually had to re-install Gallery3 completely... man, I just tried renaming the gallery3 directory, which would normally have dealt with a cache if it was a path-based mechanism, but nothing changed. I'm completely baffled. Do you have any idea what's going on with this issue - where if I change any code or "Advanced" variables, my installation gets messed up, and changing things back doesn't help? I don't have this problem with any other PHP applications on this virtual host (though the other apps are much simpler than Gallery.)
I could re-install Gallery again to try to continue with the tests above but I'm afraid that if I do that it'll just stop working again as soon as I change anything.
Ⓑ˳® bromide
⎵
Posts: 28
(and I'm replacing "your.site" and "/gallery3/" with the appropriate values for me in the URL above)
Posts: 7934
I have no idea. I can't really understand what's going on with the amount of information that I have currently. What's the URL to your Gallery? Maybe if I can see the problem happening I can get a clue.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 28
Sure. Here you go:
http://twitloops.com/93a969
There isn't much to see, at least not on the public-facing pages currently. If you'd like I can reinstall RC2 if you want to take a look before I try changing anything again.
Ⓑ˳® bromide
⎵
Posts: 7934
That site is down for me. Perhaps if you create a new install of the latest experimental code (see my sig for details) and we try debugging that?
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 28
Okay, I'm an idiot. The problem I was having editing files was that I forgot to chmod the setgid bit on the gallery3 directory. The way my text editor works it was changing the user and group of the access.php file, making Apache unable to access it. Sorry about the confusion.
So for posterity's sake, when the access.php file is unreadable (and only that file, all the other ones were readable), the effect is that index.php returns a completely blank page.
-
I went through your original instructions up above. I created x.php but browsing to the paths index.php/x/test and index.php/x did not work. But as I mentioned above, for whatever reason welcome_message.php in the same directory does work (by browsing to index.php/welcome_message) so I simply appended the expression (access::htaccess_works() ? "yes" : "no") to the output. As you predicted it evaluated to "no".
I then made the changes to helpers/access.php and reloaded index.php/welcome_message. Then I tried browsing to var/security_test/verify and I got a 403 Forbidden error. var/security_test/success also gets a 403 Forbidden.
So from the code above, the 403 is why access::htaccess_works() is returning "no"... but I'm not sure yet why I would be getting a 403 on those files in security_test. The files in var/albums have the same permissions but don't get 403s. I'll keep looking into it.
And BTW here's the new installation with the code from git I've been using:
http://twitloops.com/010074
Ⓑ˳® bromide
⎵
Posts: 28
This is bizarre... even setting the permissions to 0777 / rwxrwxrwx still results in a 403 error on var/security_test/success!
Ⓑ˳® bromide
⎵
Posts: 28
Okay, creating a subdirectory security_test/test and moving the .htaccess file down to in enables me to see security_test/success. The thing is, I don't use .htaccess files anywhere else so maybe some other Apache setting is unexpected.
It's possible to specify 403s by ending a RewriteRule with "[F]" but I don't see that anywhere... here are the contents of the generated .htaccess file:
I tried adding Allow from all but that just resulted in a 500 error with a log entry of "Allow not allowed here".
Okay, here's the answer in another log entry:
...and so adding the directive "Options +FollowSymLinks +SymLinksIfOwnerMatch" in the same place I put "AllowOverride FileInfo Options" solves the 403 problem. After having done that I'm now able to change permissions in Gallery3. It's odd though that this problem caused a 403 on the actual security_test/success file and not just on the security_test/verify rewritten path; I wonder if this is an Apache bug.
So I guess the question is whether SymLinks are needed by Gallery3 and if they are, just add that to the directions. (And some sort of more specific error messaging for the 403 problem might be appropriate, just remember that it might be caused by permissions as well.)
Ⓑ˳® bromide
⎵
Posts: 7934
Not sure what to make of that. Gallery 3 doesn't use symlinks anywhere, so there's no reason why a stock install would require you to add the various symlink related options. Are you symlinking your gallery3/var dir or do you have symlinks somewhere in your gallery3 hierarchy?
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 28
In terms of OS-level symbolic links I am not using any of those. I did the clone out of git, copied those files under my httproot, and chowned and chmodded them. In general I don't use SymLinks very much, which is why it was no problem for me to have them turned off in Apache.
But my interpretation of what it's saying above is that it considers a RewriteRule to be a SymLink in Apache terminology; so it was the RewriteRule in the .htaccess file that caused the problem when it was created. Remember - I moved the .htaccess file into a lower directory and that made the "success" file visible. If you Google there are many cases of this, where someone starts trying to use RewriteRules, runs into the above log error, and has to explicitly enable FollowSymLinks.
My expectation would be that Gallery usually gets installed in a Options +FollowSymLinks environment and that my case where I had Options -FollowSymLinks is unusual.
It seems like the next thing to do might be for you to set Options -FollowSymLinks on one of your test servers and see whether that causes any problems.
Ⓑ˳® bromide
⎵
Posts: 7934
Ah ha! You're totally right -- I was unaware of that requirement (or I learned it so long ago for Gallery 2 that I'd totally forgotten it). Either way, yeah, we have to specify "Options +FollowSymLinks" in both our security test code as well as the gallery3/.htaccess file. I had to add "Options -FollowSymLinks -SymLinksIfOwnerMatch" to repro it in my test server, but once I did that the fix was obvious. I've just committed a change for that so if you get the latest code it should start working for you. This is tracked in https://sourceforge.net/apps/trac/gallery/ticket/1335 -- Thanks for doing the legwork here, bromide!
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 2
I have the similar problem, but in a different environment. I have installed the gallery behind a firewall which operates as a ports mapper. When I edit an album's permissions within the internal network everything works perfectly. If I do the same from the Internet I get the message that I need to turn "mod_rewrite" on and to set the "AllowOverride Fileinfo Options". The assigned permissions are working correctly though. The content of the "var/security_test/success" folder is identical for the intranet and for the internet requests. It looks like the "htaccess_works" has a problem with the "verify" URL when a request was originated outside the local network.
Posts: 7934
Yeah, this is a common problem. We need a way to verify that a browser cannot access a given url. In most cases, the server can emulate a browser just fine, but if you have two different zones and the server is in a restricted inner zone that can't see the same view of your site as browsers in the public/outer zone, then it's hard for us to know that we got this right. Any suggestions for what to do in that case?
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 2
The problem requires further investigation. If the subsequent investigation bring me an idea or a solution I will share it with you.