[
https://issues.apache.org/jira/browse/SSHD-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17297959#comment-17297959
]
Curd Reinert commented on SSHD-1137:
------------------------------------
Thank you for looking into this!
I'm sure that doing symbolic links in a careful and secure way is difficult.
However, in this particular instance, we are in the catch block of an operation
that itself would not set NOFOLLOW_LINK. As it is the opening of a file, only
StandardOpenOption are considered, and FileHandle.getOpenOptions() would (in
the default branch) ignore any other options the client might have sent,
including a NOFOLLOW_LINKS.
Only because the opening fails (in this case due to some completely unrelated
attributes), we get in the catch block where the open without attributes is
done first - and still with all the open options! - and the attributes are set
afterwards. I'm not quite convinced that using "false" here was really a kind
of informed decision, it surely feels more of just a way to set the necessary
parameter which didn't cause any trouble for the considered operating systems.
If you really feel that keeping NOFOLLOW_LINKS is necessary for those cases
where it does not cause an UnsupportedOperationException, I would suggest that
instead of deciding this based on the name of the operating system, it should
rather be done depending on wether the JVM supports the NOFOLLOW_LINK option,
so either in a nested catch block for the UnsupportedOperationException that
will be raised here, or by checking once if the file system supports it and
keeping that information.
In any case, the os.name for AIX is 'AIX', it uses '/' as the file path
delimiter, and it has symbolic links. In most regards, it's a Unix System V
based operating system that is as unixoid as can be, the main differences to
other operating systems is that the Java is often a IBM J9 implementation, and
that it is a big endian system.
> 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
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
