[
https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371881#comment-16371881
]
Guillaume Nodet edited comment on SSHD-730 at 2/21/18 7:21 PM:
---------------------------------------------------------------
Actually, I wonder why this method exists at all.
It's used in 2 places:
* in {{sendPath}}
* in {{sendLink}}
In the first case, the path is supposed to have been normalized by the
underlying FileSystem already. In the second case, I don't really see why we
should alter the link, it will be resolved and normalized when used later.
was (Author: gnt):
Actually, I wonder why this method exists at all.
It's used in 2 places:
* in {{sendPath}}
* in {{sendLink}}
In the first case, we could simply let the underlying FileSystem do the job and
call {{Path.normalize()}} instead.
In the second case, I don't really see why we should alter the link, it will be
resolved and normalized when used later.
> 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)
