|
|
|
|
||||||
| comp.info.servers.unix Web servers for UNIX platforms. |
![]() |
|
|
LinkBack | Outils de la discussion |
|
|
#1 (permalink) |
|
Messages: n/a
Hébergeur: |
Hi,
I have been labouring under the belief that files beginning with a dot were hidden from publick view on Unix. However I find that on my server this is only true for certain files such as .htaccess. Is there any way I can make the server hide all dot files? Thanks for your Mark |
|
|
|
#2 (permalink) |
|
Messages: n/a
Hébergeur: |
On Tue, 15 Mar 2005 10:27:28 +0000, in
comp.infosystems.www.servers.unix, Mark <watson@211bakerstreet.com> wrote: >Hi, > >I have been labouring under the belief that files beginning with a dot >were hidden from publick view on Unix. However I find that on my >server this is only true for certain files such as .htaccess. > >Is there any way I can make the server hide all dot files? > The following is from httpd.conf. I suspect that you could just change the argument list to the Files line from "^\.ht" to "^\." # The following lines prevent .htaccess files from being viewed by # Web clients. Since .htaccess files often contain authorization # information, access is disallowed for security reasons. Comment # these lines out if you want Web visitors to see the contents of # .htaccess files. If you change the AccessFileName directive above, # be sure to make the corresponding changes here. # # Also, folks tend to use names such as .htpasswd for password # files, so this will protect those as well. # <Files ~ "^\.ht"> Order allow,deny Deny from all Satisfy All </Files> HTH, Jim |
|
|
|
#3 (permalink) |
|
Messages: n/a
Hébergeur: |
On Tue, 15 Mar 2005 10:27:28 +0000,
Mark <watson@211bakerstreet.com> posted: > I have been labouring under the belief that files beginning with a dot > were hidden from publick view on Unix. As with *ix, they're hidden from view when listing a directory (i.e. it won't list dot prefixed file and directory names), but you can still view the contents of them if you know the file or directory name yourself. Hiding and denying access are two different things. > However I find that on my server this is only true for certain files > such as .htaccess. There's specific rules for them in the main configuration file. You can create more rules for other filenames you'd like to deny access to. -- If you insist on e-mailing me, use the reply-to address (it's real but temporary). But please reply to the group, like you're supposed to. This message was sent without a virus, please delete some files yourself. |
|
|
|
#4 (permalink) |
|
Messages: n/a
Hébergeur: |
On Thu, 17 Mar 2005, Tim wrote:
> On Tue, 15 Mar 2005 10:27:28 +0000, > Mark <watson@211bakerstreet.com> posted: > > > I have been labouring under the belief that files beginning with a dot > > were hidden from publick view on Unix. They aren't really hidden (if we're still talking about unix-ish file systems). > As with *ix, they're hidden from view when listing a directory (i.e. it > won't list dot prefixed file and directory names), "ls -al" on any unix-ish system that I've ever used. (OK, AFS is different. Let's not go there today...) > but you can still view the contents of them if you know the file or > directory name yourself. Whether a web server permits a resource to be seen and to be accessed depends on its configuration. There's nothing remotely magical about an initial "." prefix: it's no more than a convention that ls without the -a option omits dot files. If the server decides not to include them in a directory listing, that isn't because it couldn't, but plain and simple because a decision was taken to leave them out of the listing. > Hiding and denying access are two different things. True. > > However I find that on my server this is only true for certain files > > such as .htaccess. > > There's specific rules for them in the main configuration file. Indeed, and modern Apache versions by default deny access to filenames beginning with ".ht" In the old days, we used to counsel that .htpasswd files should be stored outside of the web tree, so that accidental web access to them would be impossible[1]. But it was so damned convenient to put individual .htpasswd files into the subdirectory that they were meant to control that many folks disregarded this counsel, and the logical move was to simply deny web access to anything resembling that kind of file. all the best [1] years ago I was asked to diagnose access problems to a large web server across the Atlantic, and quite by accident read the ..htpasswd file for its web document root. The file included a password hash even for a user called "root". No, I resisted the temptation to run crack against it... |
|
![]() |
| Outils de la discussion | |
|
|