Compatibility improvement to reparse point handling.
Joe Lowe
joe@pismotec.com
Thu Apr 27 20:39:00 GMT 2017
Greetings,
Attached is a proposed patch that improves Cygwin reparse point
handling, to be compatible with reparse points whose SubstituteName does
not begin with one of the 3 prefixes specifically recognized in the
current code.
With the patch, Cygwin validates that the SubstituteName has one of the
two prefixes that Cygwin can correctly convert to a working readlink()
result, otherwise the reparse point is treated as a normal file or
folder. The new behavior is already similar to how Cygwin handles
unknown reparse point types and volume mount points, so the required
code changes were minimal and well isolated.
Example of current Cygwin behavior:
A junction with this SubstituteName value
"\Device\HarddiskVolume4\Users\joe\Documents" works in windows
applications to open my documents folder, but in Cygwin applications it
does not work. Cygwin treats the junction as a posix symlink with a
target of "/cygdrive/c/Device/HarddiskVolume4/Users/joe/Documents",
which does not exist.
Testing:
Testing the change against the currently supported types of reparse
points is straightforward. I did basic tests with symlink to UNC, mount
point, and a relative symlink, and behavior was unchanged from current code.
I also tested against currently broken cases using Pismo File Mount
Audit Package and by using a custom tool to create arbitrary reparse
points. Other testing options include EncFSMP and VirtualSynth. I can
provide additional info for testing to whoever is interested.
Background:
There are reasons that mount points or symlinks to 3rd party file
systems may not have one of the three prefixes that Cygwin currently
requires:
1) The UNC prefix causes the reparse target to go through the MUP
(Multi-UNC-Provider) arbitration process. This process involves network
IO and timeouts that for 3rd party file systems are likely unnecessary.
This negatively effects user experience and it leaks local system
activity onto the network. Also, the UNC prefix is not appropriate for
local volumes.
2) Drive letters are limited. Junctions and symlinks to volumes without
drive letters cannot have the drive letter prefix.
3) The volume GUID prefix implies a mount point for a local volume
managed by the windows plug-and-play system and volume manager. Some
applications will interpret volumes with mount points in this format as
having certain attributes or features. At a minimum, the volume GUID
prefix is not appropriate for reparse points targeting network volumes,
and is not handled by Cygwin for symbolic link type reparse points.
License:
The patch is entirely my own work. I do not consider the patch
substantial enough for copyright to apply, but if licensing is
considered necessary then the patch is licensed as follows.
2-clause BSD:
=========================================================================
Copyright (c) 2017, Joe Lowe
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
=========================================================================
Feedback appreciated.
Joe L.
-------------- next part --------------
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index 7d1d23d72..21cfdc33e 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -2261,6 +2261,50 @@ symlink_info::check_sysfile (HANDLE h)
return res;
}
+static bool
+is_absolute_reparse_target_posix_symlink_compatible (const wchar_t* path, size_t len)
+{
+ /* Native junction reparse points, or native non-relative
+ symbolic links, can be treated as posix symlinks only
+ if the SubstituteName can be converted from a native NT
+ object namespace name to a win32 name. We only know how
+ to convert names with two prefixes :
+ "\??\UNC\..."
+ "\??\X:..."
+ Other reparse points will be treated as files or
+ directories, not as posix symlinks. Possible values
+ include:
+ "\??\Volume{..."
+ "\Device\HarddiskVolume1\..."
+ "\Device\Lanman\...\..."
+ */
+ wchar_t d;
+ if (len >= 6 &&
+ path[0] == '\\' &&
+ path[1] == '?' &&
+ path[2] == '?' &&
+ path[3] == '\\')
+ {
+ if (path[5] == ':' && (len == 6 || path[6] == '\\'))
+ {
+ d = path[4];
+ if ((d >= 'a' && d <= 'z') || (d >= 'A' && d <= 'Z'))
+ {
+ return true;
+ }
+ }
+ else if (len > 7 &&
+ ((d = path[4]) == 'u' || d == 'U') &&
+ ((d = path[5]) == 'n' || d == 'N') &&
+ ((d = path[6]) == 'c' || d == 'C') &&
+ path[7] == '\\')
+ {
+ return true;
+ }
+ }
+ return false;
+}
+
int
symlink_info::check_reparse_point (HANDLE h, bool remote)
{
@@ -2299,14 +2343,27 @@ symlink_info::check_reparse_point (HANDLE h, bool remote)
return 0;
}
if (rp->ReparseTag == IO_REPARSE_TAG_SYMLINK)
- /* Windows evaluates native symlink literally. If a remote symlink points
- to, say, C:\foo, it will be handled as if the target is the local file
- C:\foo. That comes in handy since that's how symlinks are treated under
- POSIX as well. */
- RtlInitCountedUnicodeString (&subst,
+ {
+ /* Windows evaluates native symlink literally. If a remote symlink
+ points to, say, C:\foo, it will be handled as if the target is the
+ local file C:\foo. That comes in handy since that's how symlinks
+ are treated under POSIX as well. */
+ RtlInitCountedUnicodeString (&subst,
(WCHAR *)((char *)rp->SymbolicLinkReparseBuffer.PathBuffer
+ rp->SymbolicLinkReparseBuffer.SubstituteNameOffset),
rp->SymbolicLinkReparseBuffer.SubstituteNameLength);
+ if (!(rp->SymbolicLinkReparseBuffer.Flags & SYMLINK_FLAG_RELATIVE) &&
+ !is_absolute_reparse_target_posix_symlink_compatible(
+ subst.Buffer, subst.Length/sizeof(WCHAR)))
+ {
+ /* The absolute native symbolic link target does not
+ have a prefix we understand, so can not generate a
+ useful value to return from readlink(). Treat as a
+ normal file or directory. */
+ fileattr &= ~FILE_ATTRIBUTE_REPARSE_POINT;
+ return 0;
+ }
+ }
else if (!remote && rp->ReparseTag == IO_REPARSE_TAG_MOUNT_POINT)
{
/* Don't handle junctions on remote filesystems as symlinks. This type
@@ -2325,6 +2382,15 @@ symlink_info::check_reparse_point (HANDLE h, bool remote)
volume mount point. */
return -1;
}
+ else if (!is_absolute_reparse_target_posix_symlink_compatible(
+ subst.Buffer, subst.Length/sizeof(WCHAR)))
+ {
+ /* The junction target does not have a prefix we
+ understand, so can not generate a useful value to
+ return from readlink(). Treat as a normal directory. */
+ fileattr &= ~FILE_ATTRIBUTE_REPARSE_POINT;
+ return 0;
+ }
}
else
{
@@ -2397,6 +2463,17 @@ symlink_info::posixify (char *srcbuf)
The above rules are used exactly the same way on Cygwin specific symlinks
(sysfiles and shortcuts) to eliminate non-POSIX paths in the output. */
+ /* The following logic should use the relative flag from native NT symbolic
+ link reparse data. This logic functions without the flag because it makes
+ the following assumptions:
+ 1) Relative symlink targets never start with "\??\".
+ 2) Absolute symlink and junction targets always start with "\??\".
+ The first assumption, though arguably wrong, is unlikely to cause
+ issues since '?' characters are illegal on windows file systems.
+ The second assumption is incorrect and would cause compatibility
+ issues, but code in check_reparse_point() above makes sure the non-
+ conformers do not make it here. */
+
/* Eliminate native NT prefixes. */
if (srcbuf[0] == '\\' && !strncmp (srcbuf + 1, "??\\", 3))
{
More information about the Cygwin-developers
mailing list