[ 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)