You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@apr.apache.org by bu...@apache.org on 2009/08/04 06:10:39 UTC
DO NOT REPLY [Bug 47630] New: NTFS directory junctions ("mounted
folders") should be treated like n*x mount points (APR_DIR, not APR_LNK)
https://issues.apache.org/bugzilla/show_bug.cgi?id=47630
Summary: NTFS directory junctions ("mounted folders") should be
treated like n*x mount points (APR_DIR, not APR_LNK)
Product: APR
Version: HEAD
Platform: PC
OS/Version: Windows Vista
Status: NEW
Severity: normal
Priority: P2
Component: APR
AssignedTo: bugs@apr.apache.org
ReportedBy: dan_j_thompson@hotmail.com
--- Comment #0 from Dan <da...@hotmail.com> 2009-08-03 21:10:38 PDT ---
Overview:
APR currently treats any sort of NTFS reparse point as a symlink (see, for
instance, fillin_fileinfo). However, an NTFS reparse point may be one of
several things:
* A "symbolic link" (very similar to n*x symbolic links)
* A "hard link"
* A "directory junction", also called a "mounted folder" (very similar to a
mount point)
It's currently unclear to me if APR should treat hard links as APR_LNK or
APR_REG (I guess APR_REG), but APR should definitely treat junctions as APR_DIR
(the same as you would treat a mount point on Linux, etc.).
Determining if a reparse point is a directory junction described in the MSDN
documentation: "Determining Whether a Directory Is a Mounted Folder"
http://msdn.microsoft.com/en-us/library/aa363940(VS.85).aspx
Repro steps:
1. Use any APR API to determine the file type of a mounted folder ("directory
junction").
Expected result:
APR_DIR
Actual result:
APR_LNK
See: fillin_fileinfo in /apr/apr/trunk/file_io/win32/filestat.c. There may also
be other places that need to be updated; I'm not familiar enough with the APR
source.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
DO NOT REPLY [Bug 47630] NTFS directory junctions ("mounted
folders") should be treated like n*x mount points (APR_DIR, not APR_LNK)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47630
--- Comment #9 from Dan <da...@hotmail.com> 2009-08-05 08:00:22 PDT ---
(In reply to comment #8)
> No, you would not.
> A modestly privilaged unix user cannot change mounts.
Unless granted those privileges. Such as for cdrom.
> Any authenticated win32 user can edit junctions.
Any win32 user can edit directories.
> Therefore this is far less kernel-oriented and far more symlink oriented.
> And you've offered no argument for breaking the APR *portability* association
> of junctions and symlinks, other than "I don't think it should work this way."
> Other than to open up a raft of new security issues,
What is the specific security concern? I.e., a win32 user can create, remove,
or change a junction, so if the APR treated junctions as directories, this
would cause... what? Data loss vulnerability? Spoofing vulnerability? Tampering
vulnerability? DoS vulnerability? Repudiation vulnerability? Elevation of
privilege vulnerability? How? Like, "Alice creates a Junction in a directory
that Bob has write access to, and he deletes the junction, so..."
> what is your technical
> argument that the existing behavior is broken?
On windows, in my experience, if you want to "play tricks" with your filesystem
such as store a bunch of files on some other drive but make them show up
somewhere in your C: drive, you use a junction. Mountvol creates a junction. If
you use the disk managment GUI to mount a volume anywhere other than as a
separate drive letter, it creates a junction.
This is analogous to how mount points are used in unix. We even call them
"mounted folders". Wherever you use "mount" on unix, you use "mountvol" on
windows.
If you are using this method to play tricks with your directory structure, and
then use a program that uses the APR and does not happen to omit APR_FINFO_LINK
when getting info about a directory, then the trick does not work with that
program.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
DO NOT REPLY [Bug 47630] NTFS directory junctions ("mounted
folders") should be treated like n*x mount points (APR_DIR, not APR_LNK)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47630
--- Comment #1 from Will Rowe <wr...@apache.org> 2009-08-04 04:53:20 PDT ---
Symbolic links on Unix are polymorphic, just as you described for Junctions.
This behavior is by design.
Unlike a unix mount point, a Junction is not a directory. Unlike a unix
mount point, rm is not used to remove the intersection of the file systems.
And like Unix symlinks, a Junction may refer to a nonexistent or invalid
object.
A Junction is never a hard link; NTFS has hard links, these are well defined
objects and are invisible to the consumer after creation except by comparing
file ID (e.g. inode) for equality.
APR_LNK must be dereferenced to discover the target resource. Omitting the
apr_file_info flag APR_FINFO_LINK should resolve the referenced APR_DIR.
Is this not what you observe?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
DO NOT REPLY [Bug 47630] NTFS directory junctions ("mounted
folders") should be treated like n*x mount points (APR_DIR, not APR_LNK)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47630
--- Comment #7 from Dan <da...@hotmail.com> 2009-08-04 22:49:48 PDT ---
(In reply to comment #5)
> But Junctions have no relationship to unix mount points. Just like symlinks,
> junctions and mount points can be renamed. Unlike mount points, the change
> is immediate. It is not at the driver layer. In the unix case, the mount
> is at a much lower level, and that rename causes the system to fail (in fact,
> it isn't possible).
I think the layer is irrelevant. I don't understand "unlike mount points, the
change is immediate"--you can unmount /a/b and remount it as /a/c, just as
"immediately", right? (so what if you have to type two commands vs. one)
> You are missing the distinction between kernel layer/driver driven mounts, such
> as unix and also windows drivers, and userspace controllable filesystem
> aliases.
What does "mount --bind olddir newdir" do? And NTFS is not userspace. If you
want to fool around with the reparse point information, you have to send IOCTLs
via DeviceIoControl--to the kernel-mode driver.
> A Junction is a symlink-style alias, and for security must be represented as
> such, because any user can manipulate them. End of discussion.
Ironically, any user can create a junction, provided it has access to the
things it is linking, but for windows symlinks, you must have [elevated]
administrative privileges (unless you tweak security policy).
However, I don't understand why you think that is a security problem. On linux,
normal users can mount things if those rights are granted (like cdrom). With
junctions, it's as if there is a magic fstab file that grants the "user" option
to any places that the user has rights to. And a user has rights to manipulate
directories, so if the APR treated junctions as directories, why would that be
a security problem?
> Ok, this is clearly confusion on your point as to the flexibility of Junctions
> and where they sit on the driver stack. Meaning no disrespect, I am closing
> this bug as invalid.
No disrespect taken. But what does the driver stack have to do with anything?
Even if there are some behavior and implementation details that are different
between windows and unices, what is important to building a portable runtime is
that windows junctions are the moral equivalent to unix mount points.
Differences in implementation don't matter, and even some differences in
behavior don't matter, because APR treats mount points as directories, and
directories can and do change, by the actions of users or superusers.
For a portable program, where you would use a mount point on linux, you would
use a junction on windows. The Apache portable runtime should reflect this.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
DO NOT REPLY [Bug 47630] NTFS directory junctions ("mounted
folders") should be treated like n*x mount points (APR_DIR, not APR_LNK)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47630
Will Rowe <wr...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #3 from Will Rowe <wr...@apache.org> 2009-08-04 11:09:01 PDT ---
Understand that a unix mount point *is a directory*. That's what the
filesystem
sees. The driver handles those mounts, not the filesystem.
Unix also allows symlinks to point to other directories.
Similarly, Windows allows any driver to register a mount without the existence
of a Junction. The Junction is a filesystem entity, not a driver entity.
Junctions allow the user to point any directory at another.
junction.exe dir1 alias1
is completely valid. rd dir1 and you will find alias1 is broken. There is no
distinction in the filesystem driver between a junction to another directory
on the same volume, or a junction to another volume.
"Mount points" are only one use of junctions, and they are not the same as
a driver registering it's mount point in NTFS space.
This behavior is identical to the behavior of directory symlinks on Unix.
You did not answer my question of whether you are seeing these entities as
directories when APR_FINFO_LINK is omitted from the apr_file_info_get flags.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
DO NOT REPLY [Bug 47630] NTFS directory junctions ("mounted
folders") should be treated like n*x mount points (APR_DIR, not APR_LNK)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47630
Dan <da...@hotmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dan_j_thompson@hotmail.com
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
DO NOT REPLY [Bug 47630] NTFS directory junctions ("mounted
folders") should be treated like n*x mount points (APR_DIR, not APR_LNK)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47630
Will Rowe <wr...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |RESOLVED
Resolution| |INVALID
--- Comment #6 from Will Rowe <wr...@apache.org> 2009-08-04 21:51:28 PDT ---
Closing. If a problem exists in resolving Junctions w/o APR_FINFO_LINK flag,
feel free to reopen and recycle this incident.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
DO NOT REPLY [Bug 47630] NTFS directory junctions ("mounted
folders") should be treated like n*x mount points (APR_DIR, not APR_LNK)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47630
--- Comment #4 from Dan <da...@hotmail.com> 2009-08-04 21:33:16 PDT ---
(In reply to comment #3)
> Understand that a unix mount point *is a directory*.
But... for all intents and purposes, a junction is just as much of a directory:
The MSDN documentation states that "Because mounted folders
are directories, you can rename, remove, move, and otherwise manipulate them,
as you would other directories."
(http://msdn.microsoft.com/en-us/library/aa365237(VS.85).aspx)
> That's what the filesystem sees. The driver handles those mounts,
> not the filesystem.
NTFS is not a driver? Anyway, I don't think the implementation matters (it does
not matter where in the driver stack it is implemented, nor does it matter
whether a mount point is recorded in fstab or filesystem metadata); I think
that windows junctions are the moral equivalent of unix mount points. For the
purposes of creating a portable runtime, they should be treated the same.
> Unix also allows symlinks to point to other directories.
Windows also allows symlinks (distinct from junctions) to point to other
directories. Windows junctions and windows symlinks-to-directories are two
different things. Just like unix mount points and unix symlinks are different
things.
> Similarly, Windows allows any driver to register a mount without the existence
> of a Junction.
I don't know how that is accomplished; if you happen to know how, I would be
interested in that.
> The Junction is a filesystem entity, not a driver entity.
> Junctions allow the user to point any directory at another.
> junction.exe dir1 alias1
> is completely valid. rd dir1 and you will find alias1 is broken. There is no
> distinction in the filesystem driver between a junction to another directory
> on the same volume, or a junction to another volume.
As of Linux 2.4.0 (I don't know about other unices), it is possible to remount
part of the file heirarchy somewhere else ("mount --bind olddir newdir"). I
don't know where in the driver stack that is implemented, but again, for the
purposes of creating a portable runtime, I don't think that matters.
> You did not answer my question of whether you are seeing these entities as
> directories when APR_FINFO_LINK is omitted from the apr_file_info_get flags.
Sorry, I have not had time to test that. But I don't think it is relevant to
this bug; the point of this bug is that NTFS junctions are the moral equivalent
of unix mount points and should be treated as such by the APR.
For instance, if you go into the Disk Management tool (right-click Computer,
choose "manage", then drill into Storage-->Disk Management in the navigation
heirarchy), and you choose to mount a partition somewhere (this is the windows
GUI version of "mount"), it will create a junction. (Not a directory symlink,
and not some sort of special non-junction mount point that you refer to above.)
If I do find a problem with APR_FINFO_LINK and apr_file_info_get in the future,
I will be sure to open a separate bug for that issue.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
DO NOT REPLY [Bug 47630] NTFS directory junctions ("mounted
folders") should be treated like n*x mount points (APR_DIR, not APR_LNK)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47630
--- Comment #8 from Will Rowe <wr...@apache.org> 2009-08-04 23:48:00 PDT ---
No, you would not.
A modestly privilaged unix user cannot change mounts.
Any authenticated win32 user can edit junctions.
Therefore this is far less kernel-oriented and far more symlink oriented.
And you've offered no argument for breaking the APR *portability* association
of junctions and symlinks, other than "I don't think it should work this way."
Other than to open up a raft of new security issues, what is your technical
argument that the existing behavior is broken?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
DO NOT REPLY [Bug 47630] NTFS directory junctions ("mounted
folders") should be treated like n*x mount points (APR_DIR, not APR_LNK)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47630
--- Comment #5 from Will Rowe <wr...@apache.org> 2009-08-04 21:50:16 PDT ---
> Windows also allows symlinks (distinct from junctions) to point to other
> directories. Windows junctions and windows symlinks-to-directories are two
> different things. Just like unix mount points and unix symlinks are different
> things.
I am studying that relationship to determine how we will finally implement
apr_file_symlink_create() et al. Most likely, in XP/2003 directory symlinks
will continue to be junctions, while Vista/2008 with upgraded NTFS file systems
would gain symlinks. The 1/2 hour of testing I did today was not promising.
But Junctions have no relationship to unix mount points. Just like symlinks,
junctions and mount points can be renamed. Unlike mount points, the change
is immediate. It is not at the driver layer. In the unix case, the mount
is at a much lower level, and that rename causes the system to fail (in fact,
it isn't possible).
You are missing the distinction between kernel layer/driver driven mounts, such
as unix and also windows drivers, and userspace controllable filesystem
aliases.
A Junction is a symlink-style alias, and for security must be represented as
such, because any user can manipulate them. End of discussion.
> Sorry, I have not had time to test that. But I don't think it is relevant to
> this bug; the point of this bug is that NTFS junctions are the moral equivalent
> of unix mount points and should be treated as such by the APR.
Ok, this is clearly confusion on your point as to the flexibility of Junctions
and where they sit on the driver stack. Meaning no disrespect, I am closing
this bug as invalid.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
DO NOT REPLY [Bug 47630] NTFS directory junctions ("mounted
folders") should be treated like n*x mount points (APR_DIR, not APR_LNK)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47630
--- Comment #10 from Will Rowe <wr...@apache.org> 2009-08-05 09:04:20 PDT ---
junction path/to/cgi-bin path/to/htdocs/revealscript
is just one example, I'm not going to repeat 20 years of security issues
surrounding symlinks for your benefit.
Junctions are alias/symlinks. A junction cannot point at an unmounted volume.
E.g. although my checkouts to develop apr on httpd look like
build/
httpd-2.2/
apr-1.3/
apr-util-1.3/
apr-iconv-1.3/
so that svn up httpd-* apr-* bring all sources up-to-date,
build/
httpd-2.2/
srclib/
apr <junction to apr-1.3>
apr-util <junction to apr-util-1.3>
apr-iconv <junction to apr-iconv-1.3>
Please don't tell me that this facility doesn't expose the same issues as
symlinks raise. That's why APR was designed to handle symlinks in this manner.
The symlink protection is in there to help determine when aliases exist.
> If you are using this method to play tricks with your directory structure, and
> then use a program that uses the APR and does not happen to omit APR_FINFO_LINK
> when getting info about a directory, then the trick does not work with that
> program.
Precisely. This is exactly the same impact on unix of a symlinked directory.
Ergo the portability behavior is 100% correct, and this discussion really
is finished.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
DO NOT REPLY [Bug 47630] NTFS directory junctions ("mounted
folders") should be treated like n*x mount points (APR_DIR, not APR_LNK)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47630
--- Comment #2 from Dan <da...@hotmail.com> 2009-08-04 10:03:03 PDT ---
(In reply to comment #1)
> Symbolic links on Unix are polymorphic, just as you described for Junctions.
> This behavior is by design.
No, I think reparse points are polymorphic. A junction is a specific type/usage
of a reparse point. Reparse points are used to implement a lot of things; see
http://msdn.microsoft.com/en-us/library/aa365511(VS.85).aspx.
> Unlike a unix mount point, a Junction is not a directory. Unlike a unix
> mount point, rm is not used to remove the intersection of the file systems.
As far as I can tell, junctions are almost /exactly/ the same as unix mount
points, perhaps minus the restrictions on reparse points (like you can have
only 31 reparse points in a given path). Another term for a junction is a
"mounted folder". The MSDN documentation states that "Because mounted folders
are directories, you can rename, remove, move, and otherwise manipulate them,
as you would other directories."
(http://msdn.microsoft.com/en-us/library/aa365237(VS.85).aspx)
> And like Unix symlinks, a Junction may refer to a nonexistent or invalid
> object.
The only case that I am aware of where a junction can refer to a nonexistent or
invalid target is if the volume that the junction refers to fails. I'm not sure
how unix could do anything different. This is what the documentation says (from
same page referenced earlier):
"If a volume fails, any volumes that have been assigned to mounted folders on
that volume can no longer be accessed through those mounted folders. For
example, suppose you have two volumes, C: and D:, and that D: is associated
with the mounted folder C:\MountD\. If volume C: fails, volume D: can no longer
be accessed through the path C:\MountD\."
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
DO NOT REPLY [Bug 47630] NTFS directory junctions ("mounted
folders") should be treated like n*x mount points (APR_DIR, not APR_LNK)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47630
--- Comment #11 from Will Rowe <wr...@apache.org> 2009-08-27 19:07:48 PDT ---
As a few follow up observations;
MKLINK /J by default requires no security escalation, while MKLINK for files
or directories is usually denied to all but administrator by default. This
reaffirms the conclusion that Junction must be recognized as a symlink when
inspecting with lstat rather than stat or by open resource handle.
An arbitrary example of where junctions are effectively and frequently used as
symlinks can be found at;
http://www.mydigitallife.info/2007/05/22/create-symbolic-links-hard-links-and-directory-junctions-in-vista-with-mklink/
which notes that Vista et al default to creating one such Junction on the boot
drive by default; C:\Documents and Settings [C:\Users]
Reviewing the behavior tonight to validate that Junctions and Dir-Symlinks
both resolve to the directory when APR_FINFO_LINK is omitted, along with
File-Symlinks as well.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org