You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Curd Reinert (Jira)" <ji...@apache.org> on 2021/03/28 12:49:00 UTC

[jira] [Comment Edited] (SSHD-1137) IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH SFTP client

    [ https://issues.apache.org/jira/browse/SSHD-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17310191#comment-17310191 ] 

Curd Reinert edited comment on SSHD-1137 at 3/28/21, 12:48 PM:
---------------------------------------------------------------

Hi [~lgoldstein],

{quote}| This fails equally on Windows, Linux or AIX for an initial open

I have not been able to ascertain this - on my Windows machine (Windows 10) there is no exception being thrown.
{quote}
It fails for me (also on Windows 10) with an "java.lang.UnsupportedOperationException: 'permissions' not supported as initial attribute", provided that
(a) you use a client that tries to set the permission attribute in the initial open. I observed this behavious with OpenSSH_7.9p1, OpenSSL 1.1.1a  20 Nov 2018, also on Windows 10.
(b) the file does not already exist, in which case all attributes are dropped in SftpFileSystemAccessor.openFile(...)


was (Author: curd reinert):
{quote}| This fails equally on Windows, Linux or AIX for an initial open

I have not been able to ascertain this - on my Windows machine (Windows 10) there is no exception being thrown.
{quote}
It fails for me (also on Windows 10) with an "java.lang.UnsupportedOperationException: 'permissions' not supported as initial attribute", provided that
(a) you use a client that tries to set the permission attribute in the initial open. I observed this behavious with OpenSSH_7.9p1, OpenSSL 1.1.1a  20 Nov 2018, also on Windows 10.
(b) the file does not already exist, in which case all attributes are dropped in SftpFileSystemAccessor.openFile(...)

> IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH SFTP client
> -----------------------------------------------------------------------------------------
>
>                 Key: SSHD-1137
>                 URL: https://issues.apache.org/jira/browse/SSHD-1137
>             Project: MINA SSHD
>          Issue Type: Bug
>    Affects Versions: 2.5.1
>         Environment: SFTP-Server running on AIX
> OpenSSH SFTP client
>            Reporter: Curd Reinert
>            Assignee: Lyor Goldstein
>            Priority: Minor
>              Labels: AIX, aix
>             Fix For: 2.7.0
>
>
> When accessing an SFTP server running on AIX with an OpenSSH SFTP client (e.g. OpenSSH_7.9p1, OpenSSL 1.1.1a 20 Nov 2018, but other versions as well), I get the following exception:
> [DEBUG][sshd-TravicLinkSftpSubsystem-thread-1] 01.03.2021 10:00:31,019 Class: org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper Method: handleSetFileAttributeFailure Line: 2645 - /nhandleSetFileAttributeFailure(TravicLinkServerSession [Thread =sshd-TravicLinkSftpSubsystem-thread-1, Mandant=DEKAFFM, Partner=DEALI001, pause=false, Hashcode=1524776343])[/kati/kursanfo_in/enk1.csv] posix:permissions=[OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ] failure details
> java.io.IOException: NOFOLLOW_LINKS is not supported on this platform
>  at sun.nio.fs.UnixPath.openForAttributeAccess(UnixPath.java:793)
>  at sun.nio.fs.UnixFileAttributeViews$Posix.setMode(UnixFileAttributeViews.java:242)
>  at sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions(UnixFileAttributeViews.java:272) 
>  at org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFilePermissions(AbstractSftpSubsystemHelper.java:2793)
>  at org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttribute(AbstractSftpSubsystemHelper.java:2672)
>  at org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttributes(AbstractSftpSubsystemHelper.java:2620)
>  at org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doSetAttributes(AbstractSftpSubsystemHelper.java:2541)
>  at org.apache.sshd.server.subsystem.sftp.FileHandle.<init>(FileHandle.java:77)
>  at org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doOpen(SftpSubsystem.java:911)
>  at org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doOpen(AbstractSftpSubsystemHelper.java:532)
>  at org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doProcess(AbstractSftpSubsystemHelper.java:386)
>  at org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doProcess(SftpSubsystem.java:344)
>  at de.ppi.fis.traviclink.transfer.transport.ftpserver.ssh.TravicLinkSftpSubsystem.doProcess(TravicLinkSftpSubsystem.java:75)
>  at org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.process(AbstractSftpSubsystemHelper.java:377)
>  at org.apache.sshd.server.subsystem.sftp.SftpSubsystem.run(SftpSubsystem.java:317)
>  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522)
>  at java.util.concurrent.FutureTask.run(FutureTask.java:277)
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>  at java.lang.Thread.run(Thread.java:785)
> I've had a look into the source code. It seems the permissions requested by the client (OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ) are not supported by the file systems. This fails equally on Windows, Linux or AIX for an initial open, and therefore the catch block in [FileHandle (line 75)|https://gitbox.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-sftp/src/main/java/org/apache/sshd/sftp/server/FileHandle.java;h=40c1056048f43184bc8aa589210dd18efb8130a7;hb=HEAD#l75] is reached. Here the openFile for the channel is repeated without file attributes - succesfully - and then an attempt is made to set the file attributes with subsystem.doSetAttributes(file, attrs, false) - but this call needs that third argument for the follow link option, and setting it to false leads to using the "NOFOLLOW_LINK" option, and that is not supported on AIX, which finally causes the opening to fail.
> My assumption is that when setting the file attributes, the caller assumed that "false" is a good choice as a default for a case when there is no indication if links should be followed or not. But I would say the reverse is true, and "true" should be used in this case, as it probably is if the original open does not fail.
> Changing "false" into "true" in FileHandle, line 77, should do the trick.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org