[
https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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) where the default
implementation is something consistent with the traditional behavior of SFTP -
which would somehow solve this issue as well. However, I believe we should not
force an interpretation that is not part of the SFTP protocol to satisfy a
particular need.
> 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)
