[ https://issues.apache.org/jira/browse/SSHD-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17297528#comment-17297528 ]
Lyor Goldstein commented on SSHD-1137: -------------------------------------- {quote} changing "false" into "true" in FileHandle, line 77, should do the trick. {quote} This is not cut-and-dry - there are (good) historical reasons why we use {{NOFOLLOW_LINKS}} (has to do with correctly accessing symbolic links and avoiding escape from the user's home directory). Perhaps a better solution would be to detect that we are running on AIX (though I am not sure how...) and avoid this flag and/or allow using an explicit configuration property (or both). That being said, can you attach to this issue the value of the {{os.name}} Java system property value for AIX - thx. > 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 > > 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-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org