Received: (qmail 8145 invoked by uid 2012); 2 Dec 1998 18:15:42 -0000 Message-Id: <19981202181542.8144.qmail@hyperreal.org> Date: 2 Dec 1998 18:15:42 -0000 From: Jean-Marie de Boer Reply-To: sentient@pulse.nl To: apbugs@hyperreal.org Subject: directive acting strange X-Send-Pr-Version: 3.2 >Number: 3480 >Category: mod_access >Synopsis: directive acting strange >Confidential: no >Severity: serious >Priority: medium >Responsible: apache >State: closed >Class: doc-bug >Submitter-Id: apache >Arrival-Date: Wed Dec 2 10:20:00 PST 1998 >Last-Modified: Thu Dec 3 22:30:01 PST 1998 >Originator: sentient@pulse.nl >Organization: >Release: 1.3.3 >Environment: FreeBSD medusa.pulse.nl 2.2.5-RELEASE FreeBSD 2.2.5-RELEASE #0: >Description: I want to limit access to my file system. So I put this into a VirtualHost section, according to the Apache docs: Order deny,allow Deny from all Order deny,allow Allow from all If I now put a symbolic link to /etc/passwd in foobar's public_html directory, I go straight there. Hmm... If I use only, the first section, all access is blocked. So mod_access is working. >How-To-Repeat: >Fix: >Audit-Trail: State-Changed-From-To: open-closed State-Changed-By: marc State-Changed-When: Wed Dec 2 10:21:36 PST 1998 State-Changed-Why: As the docs say, if you enable the following of sym links (see the Options directive) then symbolic links will be followed. They are NOT treated as the "real" path, but as the "virtual" path. ie. a link from /foo/bar/whee to /whee will be treated as being /foo/bar/whee and not /whee. From: Marc Slemko To: Apache bugs database Cc: Subject: Re: mod_access/3480: directive acting strange (fwd) Date: Thu, 3 Dec 1998 22:19:10 -0800 (PST) ---------- Forwarded message ---------- Date: Thu, 03 Dec 1998 00:01:28 +0100 From: Jean-Marie de Boer To: marc@apache.org Subject: Re: mod_access/3480: directive acting strange > As the docs say, if you enable the following of sym links > (see the Options directive) then symbolic links will be > followed. They are NOT treated as the "real" path, but > as the "virtual" path. ie. a link from /foo/bar/whee > to /whee will be treated as being /foo/bar/whee and > not /whee. Hello Marc, thanks for the reply. All of you make a great product. Still, I am wondering about this section on security, taken from http://www.apache.org/docs/misc/security_tips.html: For instance, consider the following example: 1.# cd /; ln -s / public_html 2.Accessing http://localhost/~root/ This would allow clients to walk through the entire filesystem. To work around this, add the following block to your server's configuration: Order deny,allow etc. I am confused. In this example, public_html is a symlink, right? I can see that the example would close off /public_html and therefore / but it is not clear. A symlink has to be made to create this dangerous situation, and the solution does not prevent danger from symlinks. I do have another question on the same subject, if that's okay. I created a perl script which outputs a file from my /etc directory. (It's just a test you understand) This file resides in the scriptaliased cgi-bin of the (named) virtual host using these directives, and is being called via the webserver. The file from /etc is displayed. Am I correct in assuming that this is because the output is generated by the perl interpreter, and apache sees it as coming from the allowed space? Would mod_perl have the same behaviour? Thanks for yor time. Best regards, Jean-Marie de Boer Pulse.interactive -- If you think you have everything under control, you're not driving fast enough - Alain Prost *********************************************** Get my public pgp key from: http://sentient.pulse.nl/sentient_pgp_key.asc *********************************************** >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ]