[jira] [Commented] (SSHD-730) Relative symbolic links with .. is not resolved properly by sftp readLink
[ https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16372427#comment-16372427 ] Goldstein Lyor commented on SSHD-730: - I'm fine with it if it passes compilation and full unit tests - I guess we were trying to be smart and "collapse" all sort of strange paths, but it just seems to introduce more issues than solve them. > 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)
[jira] [Commented] (SSHD-730) Relative symbolic links with .. is not resolved properly by sftp readLink
[
https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371881#comment-16371881
]
Guillaume Nodet commented on SSHD-730:
--
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)
[jira] [Commented] (SSHD-730) Relative symbolic links with .. is not resolved properly by sftp readLink
[
https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371909#comment-16371909
]
Guillaume Nodet commented on SSHD-730:
--
So what about the following patch then:
{code}
diff --git
a/sshd-core/src/main/java/org/apache/sshd/common/util/SelectorUtils.java
b/sshd-core/src/main/java/org/apache/sshd/common/util/SelectorUtils.java
index 7fa19279..53bca902 100644
--- a/sshd-core/src/main/java/org/apache/sshd/common/util/SelectorUtils.java
+++ b/sshd-core/src/main/java/org/apache/sshd/common/util/SelectorUtils.java
@@ -533,72 +533,7 @@ public final class SelectorUtils {
return ret;
}
-/**
- * Normalizes the path by removing '.', '..' and double separators (e.g.
'//')
- *
- * @param path Original path - ignored if {@code null}/empty
- * @param separator The separator used for the path components
- * @return normalized path
- */
-public static String normalizePath(String path, String separator) {
-if (GenericUtils.isEmpty(path)) {
-return path;
-}
-
-boolean startsWithSeparator = path.startsWith(separator);
-List tokens = tokenizePath(path, separator);
-int removedDots = 0;
-// clean up
-for (int i = tokens.size() - 1; i >= 0; i--) {
-String t = tokens.get(i);
-if (GenericUtils.isEmpty(t)) {
-tokens.remove(i);
-} else if (t.equals(".")) {
-tokens.remove(i);
-removedDots++;
-} else if (t.equals("..")) {
-tokens.remove(i);
-removedDots++;
-if (i >= 1) {
-tokens.remove(--i);
-removedDots++;
-}
-}
-}
-
-if (GenericUtils.isEmpty(tokens)) {
-if (removedDots > 0) {
-return ""; // had some "." and ".." after which we remained
with no path
-} else {
-return separator; // it was all separators
-}
-}
-
-// serialize
-StringBuilder buffer = new StringBuilder(path.length());
-for (int index = 0; index < tokens.size(); index++) {
-String token = tokens.get(index);
-if (index == 0) {
-if (startsWithSeparator) {
-buffer.append(separator);
-} else if (OsUtils.isWin32() &&
isWindowsDriveSpecified(token)) {
-buffer.append(separator);
-}
-} else {
-buffer.append(separator);
-}
-buffer.append(token);
-
-// for root Windows drive we need to return "C:/" or we get errors
from the local file system
-if ((tokens.size() == 1) && OsUtils.isWin32() &&
isWindowsDriveSpecified(token)) {
-buffer.append(separator);
-}
-}
-
-return buffer.toString();
-}
-
-/**
+/** /**
* Converts a path to one matching the target file system by applying the
* slashification rules, converting it to a local path and
* then translating its separator to the target file system one (if
different
diff --git
a/sshd-core/src/main/java/org/apache/sshd/server/subsystem/sftp/AbstractSftpSubsystemHelper.java
b/sshd-core/src/main/java/org/apache/sshd/server/subsystem/sftp/AbstractSftpSubsystemHelper.java
index 2e043fbf..262bd053 100644
---
a/sshd-core/src/main/java/org/apache/sshd/server/subsystem/sftp/AbstractSftpSubsystemHelper.java
+++
b/sshd-core/src/main/java/org/apache/sshd/server/subsystem/sftp/AbstractSftpSubsystemHelper.java
@@ -1786,13 +1786,11 @@ public abstract class AbstractSftpSubsystemHelper
protected void sendLink(Buffer buffer, int id, String link) throws
IOException {
//in case we are running on Windows
String unixPath = link.replace(File.separatorChar, '/');
-//normalize the given path, use *nix style separator
-String normalizedPath = SelectorUtils.normalizePath(unixPath, "/");
buffer.putByte((byte) SftpConstants.SSH_FXP_NAME);
buffer.putInt(id);
buffer.putInt(1); // one response
-buffer.putString(normalizedPath);
+buffer.putString(unixPath);
/*
* As per the spec
(https://tools.ietf.org/html/draft-ietf-secsh-filexfer-02#section-6.10):
@@ -1803,7 +1801,7 @@ public abstract class AbstractSftpSubsystemHelper
Map attrs = Collections.emptyMap();
int version = getVersion();
if (version == SftpConstants.SFTP_V3) {
-buffer.putString(SftpHelper.getLongName(normalizedPath, attrs));
+buffer.putString(SftpHelper.getLongName(unixPath, attrs));
}
writeAttrs(buffer, attrs);
@@ -1819,16 +1817,10 @@ public abstract class AbstractSftpSubsystemHelper
[jira] [Commented] (SSHD-730) Relative symbolic links with .. is not resolved properly by sftp readLink
[ https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371417#comment-16371417 ] Lukas Waldmann commented on SSHD-730: - Why removedDots is int and not boolean? It is used only to check if there was some . or .. in the path, right? In any case second removedDots++; is not necessary > 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)
[jira] [Commented] (SSHD-730) Relative symbolic links with .. is not resolved properly by sftp readLink
[ https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369969#comment-16369969 ] Lukas Waldmann commented on SSHD-730: - I agree, the underlying FileSystem should now best how to interpret the path. > 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)
[jira] [Commented] (SSHD-730) Relative symbolic links with .. is not resolved properly by sftp readLink
[
https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369880#comment-16369880
]
Goldstein Lyor commented on SSHD-730:
-
Bottom line from the long :) comment - we should revise the _normalizePath_
code so that it is less aggressive in dealing with "." and ".." and the let the
underlying {{FileSystem}} resolve the result (reminder: the {{FileSystem}} is
the one obtained from the {{FileSystemFactory}} - so it can be anything we
like). In other words, try and "compress" convoluted paths such as
{{./a/b/./c/../d/../e}} to something more manageable while *preserving* leading
dot (or dots). The same applies for symbolic links - normalize the result and
delegate to whatever {{FileSystem}} implementation is currently provided to
{{SftpSubsystem}} to deal with them.
> 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)
[jira] [Commented] (SSHD-730) Relative symbolic links with .. is not resolved properly by sftp readLink
[
https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369756#comment-16369756
]
Goldstein Lyor commented on SSHD-730:
-
I think I did no explain my thoughts on this issue clearly thus the confusion -
so let's look at an example.
* Let us assume _user1_'s home is {{/home/user1}} and it contains some
files/folders - _a_, _b_, _c_
* The user creates an SFTP session and asks {quote}what is the real/canonical
path of "." ?{quote}
The implementation of the SFTP subsystem can decide on *several* possible
answers to this question
# {{/home/user1}}
# {{/user1}}
# {{/}}
# {{/whatever/other/path/it/wants}}
*All* answers are correct as long as the SFTP sub-system behaves *consistently*
- i.e.,
* When asked to list what lies under "." it should reply: _a_, _b_, _c_
* When asked to provide the real/canonical path for _a_ (or _b_ or _c_) - it
should reply either {{/home/user1/a}} or {{/a}} or whatever else - according to
the choice it made to answer about where is "."
If the user is asking {quote}What is the real path of ".." ?{quote} - again,
there are *several* possible answers
# {{/home}} - if the choice for "." was {{/home/user1}}
# {{/}} if the choice was {{/user1}}
# Error - {{SSH_FX_NO_SUCH_FILE}} if the choice was {{/}}
# etc.
the point being that it should be *consistent*. Which brings us to this issue
{quote}
if you have directories defined as /a/b/c and /a/b/d
{quote}
"defined" where ? on the file-system or in the *view* that is presented by SFTP
subsystem - there are *3* possible choices here
# If the system decided to expose "/" as your root then you can access
{{/a/b/c}} and {{/a/b/d}} via SFTP
# If the system decided to expose "/a" as your root then can access {{/b/c}}
and {{/b/d}} via SFTP - but *not* {{/a/b/c}} or {{/a/b/d}} the (compliant) SFTP
subsystem should return an *error* for such an attempt since that would mean
that you can escape from sandbox
# If the system decided to expose "/a/b" as your root then can only access
{{/c}} and {{/d}} via SFTP - and (IMO) furthermore, any attempt to access ".."
should return an error as it would also be tantamount to escaping from the
sandbox
To summarize, please remember that
* The SFTP subsystem presents an *abstract view* of some underlying addressable
entities that we call _files_ and _folders_ (for convenience and traditional
reasons) that the user is allowed to access.
* This view might be entirely different than the actual structure on the
file-system that actually holds the files/folders.
* As a matter of fact, I can easily envision a view where names are somehow
jumbled and there is some internal resolution mechanism that knows how to map
the *logical* name to the physical one - i.e. file _a_ on the disk could be
presented via SFTP as _bigBrother_. As long as when the user is asking to get
the contents of _bigBrother_ via SFTP we get the data in file _a_, then we are
fine (at least as far as the SFTP protocol compliance is concerned).
* Furthermore, we can even envision a "fragmented" view that presents
{{/dev1/location1}} and {{/dev2/location2}} as some *logical* {{/devices}} with
sub-folders named {{location1}} and {{location2}}
* Finally, we can even envision an entirely *virtual* view that maps _folders_
to databases, _files_ to table names in the database and file contents as all
the records in the database as CSV (or whatever other format)
Finally, symbolic links - bearing in mind that SFTP presents a *view* rather
than an actual file-system it begs the question(s)
* What does it mean to create a symbolic link between 2 files in a *view* ?
** Specifically, when the user is asking to create a link between _a_ and
_./c/d_ should it take it literally or translate it to the actual mapped view
values of _a_ and _./c/d_. In our example, if {{/home/user1}} is presented in
SFTP as {{/}} does linking _a_ to _./c/d_ mean that link is literally {{./c/d}}
or resolved to {{/home/user1/c/d}} when created ? Either choice has pros, cons
and consequences
* What is the operational consequence of having file _a_ be a symbolic link to
_../../b_
** Specifically, what if the SFTP view is restricted so the user is not allowed
to access ".." ?
** In our example, what if SFTP is asked what is the real path of {{../../b}}
and the presented view of {{/home/user1}} is {{/}} - in such a case is
{{../..}} even valid ?
I admit I don't have any good answers for this.
As to the issue at hand - my point is that we could easily solve the issue by
*assuming* (IMO *imposing*) a certain behavior based on some assumptions - but
we would lose the *abstracted* view that is the cornerstone of the SFTP
subsystem. That being said, I have nothing against the SFTP subsystem code
consulting some *interface* whenever it needs to resolve some path (BTW, this
interface is {{FileSystem}} so no need to invent a new one)
[jira] [Commented] (SSHD-730) Relative symbolic links with .. is not resolved properly by sftp readLink
[ https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369444#comment-16369444 ] Guillaume Nodet commented on SSHD-730: -- [~lgoldstein] The link should be resolved relative to the its location, so the _where_ is the link location which is known. > 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)
[jira] [Commented] (SSHD-730) Relative symbolic links with .. is not resolved properly by sftp readLink
[ https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369409#comment-16369409 ] Lukas Waldmann commented on SSHD-730: - Lyor, I really can't agree if you have directories defined as /a/b/c and /a/b/d where c is file and d is link "../b/c" than path /a/b/d clearly translates to /a/b/../b/c which equals to /a/b/c. There is nothing really elusive about it. As you said there is no "cwd" so server should always operates on absolute path and ".." than still translate to absolute path. Anyhow, regular unix servers I have tried didn't show the behaviour I see here. I will try to write a test so you can try it for yourself > 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)
[jira] [Commented] (SSHD-730) Relative symbolic links with .. is not resolved properly by sftp readLink
[
https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (SSHD-730) Relative symbolic links with .. is not resolved properly by sftp readLink
[ https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369278#comment-16369278 ] Lukas Waldmann commented on SSHD-730: - Sure, I can give it a try > 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)
[jira] [Commented] (SSHD-730) Relative symbolic links with .. is not resolved properly by sftp readLink
[ https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369233#comment-16369233 ] Guillaume Nodet commented on SSHD-730: -- [~luky] could you write a unit test in [https://github.com/apache/mina-sshd/blob/master/sshd-core/src/test/java/org/apache/sshd/client/subsystem/sftp/SftpFileSystemTest.java] maybe ? That would help understanding and fixing the issue. > 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)
[jira] [Commented] (SSHD-730) Relative symbolic links with .. is not resolved properly by sftp readLink
[ https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369167#comment-16369167 ] Lukas Waldmann commented on SSHD-730: - I beg to differ. We are not talking about "current directory" in interactive shell meaning. We are talking about traversing well defined directory structure, where ".." means go one level down > 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)
[jira] [Commented] (SSHD-730) Relative symbolic links with .. is not resolved properly by sftp readLink
[
https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369145#comment-16369145
]
Goldstein Lyor commented on SSHD-730:
-
There is an issue regarding what \{quote}current directory\{quote} means. I
have not found any RFC/de-facto standard that defines this concept for SFTP,
SCP. The protocol simply provides some way to access "." and/or ".." but the
*semantics* of these values is not well defined. They _assume_ some kind of
_Linux_-like structure where users have "home" directories, but the SFTP/SCP
protocols have no such concept. This is well demonstrated by the fact the the
SCP/SFTP implementations use an *abstract* {{FileSystem}} - which has no
concept of CWD or home directory. In order for this feature to work correctly,
we need to define what this means and how can programmers provide it on the
server side.
> 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)
[jira] [Commented] (SSHD-730) Relative symbolic links with .. is not resolved properly by sftp readLink
[ https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15894150#comment-15894150 ] Lukas Waldmann commented on SSHD-730: - Imagine dir tree like this: /dir1/dir2/file /dir1/dir3/link if "link" is ../dir2/file than normalizePath in sendLink function returns: dir2/file But your current directory is dir3 and if you want to process this link you don't have any knowledge where dir2 is located because normalizePath doesn't return absolute path neither keeps relative location of dir2 to dir3 I don't know why normalizePath call was introduced but it seems it screws handling of relative paths in links > 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 (v6.3.15#6346)
[jira] [Commented] (SSHD-730) Relative symbolic links with .. is not resolved properly by sftp readLink
[
https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15893717#comment-15893717
]
Goldstein Lyor commented on SSHD-730:
-
Please clarify the problem some more - specifically what is meant by {quote}is
invalid because in can not be resolved properly in the context of the current
directory which symbolic link is referring to{quote}. Can you give a concrete
example ? Mainly
* What is the full path of server-side current directory that ".." should be
resolved against ?
* What is the full path of server-side symbolic link path that "../test/file"
should yield when resolved ?
* What is the expected result of resolving the symbolic link that
"../test/file" references ?
> 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
(v6.3.15#6346)
