Bug 8014

Summary: Apache cannot handle NTFS Junctions (Symlinks)
Product: Apache httpd-2 Reporter: sam morris <sam>
Component: CoreAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: CLOSED FIXED    
Severity: major    
Priority: P3    
Version: 2.0.44   
Target Milestone: ---   
Hardware: PC   
OS: All   

Description sam morris 2002-04-12 13:42:27 UTC
For testing, I have an alias called /C that points to "C:\Documents and Settings\". I keep my 
profile directory on a separate disk that is mounted under "C:\Documents and Settings\Sam". 
However, the Sam\ folder does not appear in Apache's directory listing. Additionally, while the 
directory listing is being generated, this appears in the error.log:

[Fri Apr 12 14:33:05 
2002] [error] [client 127.0.0.1] symlink doesn't point to a file or directory: C:/Documents and 
Settings/Sam

Asking for anything under "http://localhost/C/Documents and 
Settings/Sam" manually throws a 403 back to the client, with the same error in the event 
log.

If I remove the "FollowSymLinks" option for the directory then the error message is 
instead:

[Fri Apr 12 14:41:29 2002] [error] [client 127.0.0.1] Symbolic link not allowed: 
C:/Documents and Settings/Sam

and a 403 is still returned to the browser.
Comment 1 Joshua Slive 2002-04-12 20:18:20 UTC
Please don't submit to the bug database and post to the newsgroup at the same
time.  You may reopen this report if you don't get a response within a few
days on the newsgroup.
Comment 2 sam morris 2002-04-18 10:16:49 UTC
Reopening, with more information:

Snippet from httpd.conf:
   Alias /C "C:/"
   <Directory 
"C:/">
      Options Indexes FollowSymLinks MultiViews
      AllowOverride None
      Order 
allow,deny
      Allow from all
   </Directory>

Requesting 
http://localhost/C/Documents%20and%20Settings/ returns a listing
of the directory, but 
with the expected "Sam/" entry (C:\Documents and
Settings\Sam\ is actually a mount point) 
omitted. Instead, "[error] [client
127.0.0.1] symlink doesn't point to a file or directory: 
C:/Documents and
Settings/Sam" appears in the error log.

Requesting 
http://localhost/C/Documents%20and%20Settings/Sam/, or anything
inside of it, returns a 
403 error and likewise adds "[error] [client
127.0.0.1] symlink doesn't point to a file or 
directory: C:/Documents and
Settings/Sam" to the error log.

Requesting 
http://localhost/C/Documents%20and%20Settings/All%20Users/ or any
of the other links 
from the directory listing works as it should.

After doing some reading, it appears that what 
Apache calls symlinks on
Windows are actually NTFS Junctions; most junctions have a target of 
a
regular pathname (such as "C:\Target\"), but the mount point junctions
Windows uses have a 
target in the form of
"\\?\Volume{90b9a960-b928-11d5-bbf2-806d6172696f}\" (the classid is 
the
volume's unique identifier).

The error message suggests that Apache is checking the 
junction target to
see if it is a valid path (which the mount point junction target is not) 
and
throwing the error. So it seems the problem lies within the code that Apache uses to check the 
symlink/juntion target.
Comment 3 William A. Rowe Jr. 2002-04-24 04:21:29 UTC
  This is fixed in the current 2.0.36-dev tree, and will be part of the
  next 2.0.36 release we expect to roll out within a week or so.

  Thanks for your report, your detailed examples, and for adopting Apache 2.0!

Comment 4 Skeuomorph 2003-03-28 07:46:10 UTC
The precise behavior noted in the original bug still occurs in 2.0.44 on UNC 
(remote share) paths under Win2K Server or Win2K3RC2:

Alias /nas/junction/dir1/dir2/ "//192.168.0.10/nas/junction/dir1/dir2/"
<Directory "//192.168.0.10/nas/junction/dir1/dir2">
    Options Indexes FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

[Thu Mar 27 22:24:03 2003] [error] [client 67.67.67.117] 
Forbidden: //192.168.0.10/nas/junction doesn't point to a file or directory

If FollowSymLinks is turned off, then:

[Thu Mar 27 23:24:07 2003] [error] [client 67.67.67.117] Symbolic link not 
allowed: //192.168.0.10/nas/junction

Either way, with indexing turned on and using the following mapping, Apache 
browses the directory fine, and generates an index, but does not see ANY of 
the junctions:

Alias /nas/ "//192.168.0.10/nas/"
<Directory "//192.168.0.10/nas">
    Options Indexes FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

It sees regular folders and files just fine.

NFTS can create at least two common types of junctions.  One is the MountVol 
target format shown in Sam's bug report, and the other is a path reference as 
created with "linkd.exe" from Win2K Resource Kit.  The above behavior is 
observed with BOTH types.  

I have rated this as MAJOR because without fixing this, Apache cannot be used 
to serve content from servers in a web farm that all work from a NAS server 
that mounts many RAID arrays using the "MountVol" or "LinkD" method.  While 
the LinkD method is uncommon, the MountVol method is offered in default 
Windows GUI Drive Management on volume creation, and is a common way to add 
new volumes into an existing path structure.


Comment 5 Kristofer Spinka 2003-03-28 13:02:26 UTC
  I'm not 100% this fixes the issue mentioned at 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8014 though I tried to 
reproduce the issue as I understood it.  If one of the bug submitters could 
test it that would be great.  Bill, if you could verify that this change is 
reasonable I would appreciate it, the 'wanted' thing is a little vague to me.

--- filestat.c.orig     Fri Mar  7 14:21:29 2003
+++ filestat.c  Fri Mar 28 07:16:02 2003
@@ -363,7 +363,8 @@
         finfo->size = 0x7fffffff;
 #endif
 
-    if (wininfo->dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) {
+    if (wanted & APR_FINFO_LINK &&
+        wininfo->dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) {
         finfo->filetype = APR_LNK;
     }
     else if (wininfo->dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) {


   /kristofer
Comment 6 André Malo 2003-04-10 18:09:33 UTC
Reopen to get this on the radar. Bill? your turn ;-)
Comment 7 William A. Rowe Jr. 2003-04-17 16:56:54 UTC
  This was fixed in 2.0.45.  Please upgrade, and if the problem persists, please
  reopen the bug with the new error log entries and observations.
Comment 8 William A. Rowe Jr. 2003-05-19 14:04:27 UTC
  I stand corrected; that patch wasn't committed.

  Now committed as of apr/file_io/win32/filestat.c revision 1.79,
  and I expect you will see this in the forthcoming Apache 2.0.46.