czldb2 commented on issue #751:
URL: https://github.com/apache/mina-sshd/issues/751#issuecomment-2864835942
> All right, I see the problem. You have an `SftpServer` based on a
`SftpFileSystem`, and it's all SFTP v3. The server uses the `FileSystem`
abstraction, so the "long name" you get from the target server is lost, only
the file attributes view survives, and when the SftpServer then writes its own
response, it doesn't know the owner. Thus you end up with some default values
("OWNER@" and "GROUP@").
>
> This would be partially fixable by extracting the owner and group name
from the long name (if set) in `SftpHelper.complete()` and setting them on the
attributes object; something like
>
> ```
> if (!GenericUtils.isEmpty(longName)) {
> // SFTP v3: propagate user/group name to the Attributes, even if those
are defined only for SFTP > v3. This
> // will enable us to have these names available in the SftpFileSystem.
> String[] parts = longName.split("\\s+");
> if (parts.length >= 4) {
> String user = parts[2];
> String group = parts[3];
> if (!GenericUtils.isEmpty(user)) {
> attrs.setOwner(user);
> }
> if (!GenericUtils.isEmpty(group)) {
> attrs.setGroup(group);
> }
> }
> }
> ```
>
> However, that still wouldn't fix it for the "." and ".." entries: these
must be handled specially because Java doesn't return those when listing a
directory. So the server sends SSH_FXP_STAT to the target server for these, and
those replies from the target server do not contain any "long name", just the
SFTP v3 attributes, which have only numeric user and group id. So you'll still
have "OWNER@" and "GROUP@" on the "." and ".." entries of a directory listing.
>
> I'm not sure this is worth fixing.
>
> First, the SFTP v3 draft RFC explicitly [warns against parsing the "long
name"](https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-02#page-23):
>
> > The format of the `longname' field is unspecified by this protocol. It
MUST be suitable for use in the output of a directory listing command (in fact,
the recommended operation for a directory listing command is to simply display
this data). However, clients SHOULD NOT attempt to parse the longname field
for file attributes; they SHOULD use the attrs field instead.
>
> So doing the above parsing may not be the best idea.
>
> Second, chaining SFTP servers in this way using an `SftpFileSystem` is not
exactly a good way to "proxy" SFTP. It can easily introduce inefficiencies.
I've never needed this myself and have never tried it, but I think it might be
better to write a `SftpSubsystem` that doesn't use an `SftpFileSystem` at all
but that forwards raw SFTP packets as directly as possible between the client
and the target server.
Thank you very much for your ideas. I think my problem has been solved.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
