Re: bin/56631: rdump fails to back up to remote file

[mlelstv%serpens.de@localhost (Michael van Elst)]

The following reply was made to PR bin/56631; it has been noted by GNATS.

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/56631: rdump fails to back up to remote file
Date: Sat, 22 Jan 2022 09:21:24 -0000 (UTC)

 greywolf%starwolf.com@localhost writes:
 
 > On 1/15/22 11:20 PM, Michael van Elst wrote:
 > >  This can fail for several reasons.
 > >  
 > >  RCMD_CMD is called as $RCMD_CMD -4 -l $user $host /etc/rmt, so
 > >  that's IPv4 only. The $host is also canonicalized, e.g. a short
 > >  hostname (without fqdn) gets a '.' appended.
 > 
 > Seems a bit archaic; should it not be resolving the host to a FQDN?
 
 I don't see a reason to even canonicalize the hostname, probably
 some compatibility stuff.
 
 Restricting to IPv4 comes from the API, and that might also be
 some ancient compatibility issue, but probably just a cheap method
 to add IPv6 support.
 
 rcmd(...) calls rcmd_af(..., AF_INET).
 
 and rcmd_af() translates AF_INET into the -4 option and AF_INET6
 into the -6 option of rsh.
 
 
 > >  rcmd() uses a single file descriptor (stdin, stdout, stderr are
 > >  all the same), so ssh messages on stderr botch the RMT protocol.
 > >
 > 
 > Oooff.  Good to know, even if this seems to violate the POLA
 
 Yes, but not that uncommon. scp or rsync aren't transparent either
 and you can easily break them by sending output in e.g. .login.
 rsh also, unlike ssh, doesn't necesarily have a stderr channel.
 
 
 > I'm just not quite sure what to patch to make this work or to make it at
 > least an option to pass thru from rdump to rmt.
 
 You need to change multiple things.
 
 RMT protocol might need some abstraction to the mode argument to be portable.
 
 rdump needs an option to specify the mode, best some abstracted way,
 maybe also to distinguish between tapes and files.
 
 /etc/rmt might need to distinguish between files and devices, also
 to filter the mode. It could also try to emulate tape operations
 on and with files.
 
 rcmd() needs to understand an arbitrary protocol and not massage
 hostnames itself. There are proper IPv6 APIs.
 
 
 > (The fact that RCMD_CMD is taken as a full literal string with no
 > tokenization (i.e. one cannot include arguments in RCMD_CMD) seems
 > ALSO a bug, or at least a candidate for enhancement, but that's
 > something for another day.)
 
 I think that is intentional. The command isn't interpreted by a shell,
 but passed to execlp() directly. This avoids any shell injection issues,
 and for a command regularily run by root, that's better.
 
 You could think about splitting RCMD_CMD into words and prepend argv[],
 but that's limited. You could create a wrapper script and point RCMD_CMD
 to it.