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

if you have directories defined as /a/b/c and /a/b/d

"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 

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 
** 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

Reply via email to