File permissions and web access


#1

I was expecting file permissions set via SSH/Telnet to affect what a web user could see. It appears they basically don’t affect this. Is this how it works? Or is there something I’m missing?

For example, take a domain with one benign text file. No .htaccess file, no password protection. Very simple. I come in with a clean restarted browser and I can see this file and see its contents whether permissions are rrr, rr- or r–. When I remove all permissions, then I cannot see the file. So user, group, or other do not come into play with a web user, yes?

I understand other ways to protect for this. But I was expecting permissions to also have some effect.

Thanks for any comments,
Lu


#2

Works for me when using chmod to disable public read permission. Perhaps you’re still loading a copy from your browser cache. Try using http://web-sniffer.net/ instead

Is the file a script or an include?

:cool: Perl / MySQL / HTML CSS


#3

2 questions below –

Ok, it appears there is some delay (a few seconds or more)? I now see the wrong result for several reloads, and then it will turn into the right result.

This is regardless of restarting the browser. I restarted and still saw the wrong result, and then it changed. (I’m using Firefox.) I don’t want to clear the cache, would rather do reload. That seems to be adequate here but I will add your suggestion to my testing repertoire :wink:

I presume this delay is from propagating the change out to the location that my browser is actually accessing.

So which permissions affect web usage? Just “other”? Now that I’m waiting long enough, I think I see that behavior. A full minute sitting at 640 produced forbidden. Within seconds at 644, the file was viewable.

And I suppose the user and group permissions would come into play once someone has logged into a password protected location, yes?

thank you,
Lu


#4

The file permission change happens immediately but a given file may be cached somewhere along the way between you and us. We don’t do any sort of thing on our side that would prevent you from seeing the change right away.

Apache runs as a user called ‘dhapache’ which is not in your group so it will not be able to read files that are not world-readable. However, CGI scripts running under your website (including PHP run as CGI) will run as your own user and will be able to see all files you can see yourself. The best way to prevent public access to the files is by password-protecting the directory or use some other method to tell Apache to not allow access to the files.

I tried not to get too technical, but I may have added more confusion than information.

  • Dallas
  • DreamHost Head Honcho/Founder

#5

Ok, I got it. So it’s dhapache that follows “other” permissions. But somehow dhapache doesn’t need (??) the “other read” permission when the .htpasswd file is in the same directory as the .htaccess file, because this is how DH sets it up and it works.


#6

Each time you view a web page, your computer has to make connections to the DreamHost computer to download stuff. In order to reduce the number of connections, your browser will decide how long it it keeps something around before it tries downloading it again. Thus if it decides to wait a minute, it will be at least a minute before another connection to the DreamHost computer is made, and your browser is told it can’t have what it downloaded a minute ago.

Restarting the browser would only clear the memory cache. The browser also stores web pages in a disk cache. To override the cache mechanism, use Ctrl-F5 or hold down Shift when clicking on the Reload button.

The Web Panel changes the group ownership of the .htpasswd file to that of the same group as ‘dhapache’. And since the group-readable permission is enabled, this allows ‘dhapache’ to read the passwords.

:cool: Perl / MySQL / HTML+CSS


#7

Concerning browsers and connections to DreamHost (or wherever), with the latest Firefox I did not find the non-connection behavior that you described. I found that Firefox goes out to the net once for each and every click of the reload button. I could see network traffic in the Task Manager as well as explicit send and receive traffic in the connection details. Maybe other browsers act differently. I suspect the problem is more often the feed from Dreamhost to wherever. I know nothing of how that whole mechanism works but I’ve just now seen one change that took 15-30 minutes to propagate.

As for the memory cache and disk cache, yes, I understand now, thanks. I need to consider both.

And for the group-readable apache user scenario – the .htpasswd file above the web directory has the group permission of readable but it’s not accessible like it is if it is in the same directory as the .htaccess file.


#8

It’s not accessible because it also needs to belong to the ‘dhapache’ group. Right now the group it belongs to is yours. AFAIK, you can not manually make the file belong to the ‘dhapache’ group, so you’ll need to make it world-readable instead. Whether or not both files are in the same directory doesn’t make a difference; just the ownership and permissions.

:cool: Perl / MySQL / HTML CSS


#9

ahhh yessss … I get it now. the universe is realigned. thank you!

and after 10 posts, one becomes a Dreamling? kinda cute.