You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Lyor Goldstein (Jira)" <ji...@apache.org> on 2021/03/08 16:56:00 UTC
[jira] [Assigned] (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:all-tabpanel ]
Lyor Goldstein reassigned SSHD-1137:
------------------------------------
Assignee: Lyor Goldstein
> 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: Major
>
> 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