[
https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369386#comment-16369386
]
Goldstein Lyor commented on SSHD-730:
-------------------------------------
{quote}
We are talking about traversing well defined directory structure, where ".."
means go one level down
{quote}
One level down (I am used to thinking about it as _up_) from where ? Hence the
elusive "." relative to which we go one level up/down... Note that the concept
of CWD is an "illusion" maintained by the client. It simply asks the server
where is "." and then presents to the user a *conveniently* "structured"
directory that has a "CWD" - which is known though only to the client. The
*semantics* of what it means to request access to "." (a.k.a. CWD) and ".." -
up/down is still entirely up to the *server*. As long as it behaves
consistently, it is not at fault and fully compliant with the SFTP protocol.
That being said, I do believe we should implement some way for the SFTP
subsystem to maintain a concept of a *sandboxed* "home" directory, then
represent "." as that mapped path and subsequently implement all other paths as
relative to it. I believe much of it is implemented by the
{{VirtualFuleSystemFactory}} - however, please note that it is not the default
implementation (the native FS is the default). This choice of the default may
lead to behavior such as the one outlined in this issue. I think this issue is
a good trigger for us to think about how to define and implement a consistent
model of the underlying FS exposed via SFTP and/or SCP so that "." and ".."
will be resolved correctly - but without escaping from the *sandboxed* root.
> Relative symbolic links with .. is not resolved properly by sftp readLink
> -------------------------------------------------------------------------
>
> Key: SSHD-730
> URL: https://issues.apache.org/jira/browse/SSHD-730
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 1.1.0, 1.2.0, 1.3.0
> Reporter: Lukas Waldmann
> Assignee: Goldstein Lyor
> Priority: Minor
>
> Using sftp to resolve symbolic links doesn't return proper resolution in case
> symbolic link contains ..
> Since version 1.1 the sendLink function of SftpSubsystem uses
> normalizedPath = SelectorUtils.normalizePath(unixPath, "/");
> to normalize path
> This function however return invalid path in case link contains ".."
> So for example if link is "../test/file" than normalizePath returns
> "test/file" which is invalid because in can not be resolved properly in the
> context of the current directory which symbolic link is referring to.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
