openssh unix dev - Jun 2019 - sftp client: upload from pipe

Hi,

the sftp client from openssh package can't upload data from local pipe
to remote file. For example, such a command fails:

$ cat file | sftp -b <(echo 'put /dev/stdin /directory/filename') -i
~/.ssh/key user at remote.host
sftp> put /dev/stdin /directory/filename
/dev/stdin is not a regular file

What is a purpose for such a behaviour and limitation? As experiment,
I removed following piece of code which is responsible for this check
(sftp-client.c, do_upload() function):

        if (!S_ISREG(sb.st_mode)) {
                error("%s is not a regular file", local_path);
                close(local_fd);
                return(-1);
        }

and nothing bad happened. It was still possible to upload regular files,
but additionaly there was an opportunity for upload data piped from other
command (what in my opinion is very useful feature) and even directly
from terminal. Would it be possible to remove this restriction from sftp
client?

Regards.

On Fri, 21 Jun 2019, Adam Osuchowski wrote:
> Hi,
> 
> the sftp client from openssh package can't upload data from local pipe
> to remote file. For example, such a command fails:
> 
> $ cat file | sftp -b <(echo 'put /dev/stdin
/directory/filename') -i ~/.ssh/key user at remote.host
> sftp> put /dev/stdin /directory/filename
> /dev/stdin is not a regular file
> 
> What is a purpose for such a behaviour and limitation? As experiment,
> I removed following piece of code which is responsible for this check
> (sftp-client.c, do_upload() function):
> 
>         if (!S_ISREG(sb.st_mode)) {
>                 error("%s is not a regular file", local_path);
>                 close(local_fd);
>                 return(-1);
>         }
> 
> and nothing bad happened. It was still possible to upload regular files,
> but additionaly there was an opportunity for upload data piped from other
> command (what in my opinion is very useful feature) and even directly
> from terminal. Would it be possible to remove this restriction from sftp
> client?
IIRC it's there because reads on named pipes can hang if nothing is
attached to them and because reading from devices can have side-effects
(classic example being /dev/mt)

I'm not opposed to relaxing this restriction, but I think that we'd need
to
preserve the behaviour I just mentioned.

-d

Damien Miller wrote:
> IIRC it's there because reads on named pipes can hang if nothing is
> attached to them
And what is the problem with that? It should break nothing if this named
pipe was passed to sftp explicitly (I'm not talking about recursively
uploading of directory that contains named pipes). Besides, there is
O_NONBLOCK if it would be very necessary.
> and because reading from devices can have side-effects (classic example
> being /dev/mt)
As above, what is the problem with that? Nobody tells anybody to use
sftp with such devices. Sometimes, It could even be desirable if e.g.
somebody would like to backup content of device on remote host via sftp.
Again as above, I'm not talking about recursively uploading of directory
that contains devices; only devices that are explicitly specified in
command. If it would be a big problem, it's ok for me that sftp could
allow uploading regular files and pipes/fifos only.