[PATCH 2/2] bup-on: reject use of standard input for now

0 views
Skip to first unread message

Rob Browning

unread,
May 19, 2024, 2:00:47 PMMay 19
to bup-...@googlegroups.com
Previously, any `bup on REMOTE ...` commands that attempted to read
from standard input (for example `bup on HOST split < something` or
`bup on HOST split --git-ids ...`) would read nothing instead of the
original content of standard input. Now those commands will either
reject the invocation, or just crash when they attempt to read a
closed stream.

Signed-off-by: Rob Browning <r...@defaultvalue.org>
Tested-by: Rob Browning <r...@defaultvalue.org>
---

Proposed for 0.33.x and main, and then perhaps a soonish 0.33.x
release.

lib/bup/client.py | 3 ++-
lib/bup/cmd/on__server.py | 9 +++++----
lib/bup/cmd/split.py | 7 +++++--
note/0.33.x.md | 10 ++++++++++
4 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/lib/bup/client.py b/lib/bup/client.py
index 2cf157e62..60f9bbfae 100644
--- a/lib/bup/client.py
+++ b/lib/bup/client.py
@@ -3,7 +3,7 @@ from __future__ import print_function

from __future__ import absolute_import
from binascii import hexlify, unhexlify
-import os, re, struct, time, zlib
+import os, re, struct, sys, time, zlib
import socket

from bup import git, ssh, vfs
@@ -91,6 +91,7 @@ class Client:
self.pout = os.fdopen(3, 'rb')
self.pin = os.fdopen(4, 'wb')
self.conn = Conn(self.pout, self.pin)
+ sys.stdin.close()
else:
if self.protocol in (b'ssh', b'file'):
try:
diff --git a/lib/bup/cmd/on__server.py b/lib/bup/cmd/on__server.py
index 13e2f8472..c6be2d248 100644
--- a/lib/bup/cmd/on__server.py
+++ b/lib/bup/cmd/on__server.py
@@ -35,10 +35,11 @@ def main(argv):
argv = [argv[0], b'mux', b'--'] + argv


- # stdin/stdout are supposedly connected to 'bup server' that the caller
- # started for us (often on the other end of an ssh tunnel), so we don't want
- # to misuse them. Move them out of the way, then replace stdout with
- # a pointer to stderr in case our subcommand wants to do something with it.
+ # stdin/stdout should be connected to 'bup server' that the caller
+ # started for us (often on the other end of an ssh tunnel), so we
+ # don't want to misuse them. Move them out of the way (to fds 3
+ # and 4 -- see Client()), then replace stdout with a pointer to
+ # stderr in case our subcommand wants to do something with it.
#
# It might be nice to do the same with stdin, but my experiments showed that
# ssh seems to make its child's stderr a readable-but-never-reads-anything
diff --git a/lib/bup/cmd/split.py b/lib/bup/cmd/split.py
index 6a646e782..840796a22 100644
--- a/lib/bup/cmd/split.py
+++ b/lib/bup/cmd/split.py
@@ -95,8 +95,11 @@ def opts_from_cmdline(argv):
opt.date = time.time()

opt.is_reverse = environ.get(b'BUP_SERVER_REVERSE')
- if opt.is_reverse and opt.remote:
- o.fatal("don't use -r in reverse mode; it's automatic")
+ if opt.is_reverse:
+ if opt.remote:
+ o.fatal("don't use -r in reverse mode; it's automatic")
+ if not opt.sources or opt.git_ids:
+ o.fatal('cannot currently use standard input with "bup on ..."')

if opt.name and not valid_save_name(opt.name):
o.fatal("'%r' is not a valid branch name." % opt.name)
diff --git a/note/0.33.x.md b/note/0.33.x.md
index 5c71356db..35342fce1 100644
--- a/note/0.33.x.md
+++ b/note/0.33.x.md
@@ -1,6 +1,16 @@
Notable changes in main since 0.33.3 (incomplete)
=================================================

+May require attention
+---------------------
+
+* Previously, any `bup on REMOTE ...` commands that attempted to read
+ from standard input (for example `bup on HOST split < something` or
+ `bup on HOST split --git-ids ...`) would read nothing instead of the
+ original content of standard input. Now those commands will either
+ reject the invocation, or just crash when they attempt to read a
+ closed stream.
+
Bugs
----

--
2.43.0

Rob Browning

unread,
May 25, 2024, 3:26:36 PMMay 25
to bup-...@googlegroups.com
Rob Browning <r...@defaultvalue.org> writes:

> Previously, any `bup on REMOTE ...` commands that attempted to read
> from standard input (for example `bup on HOST split < something` or
> `bup on HOST split --git-ids ...`) would read nothing instead of the
> original content of standard input. Now those commands will either
> reject the invocation, or just crash when they attempt to read a
> closed stream.
>
> Signed-off-by: Rob Browning <r...@defaultvalue.org>
> Tested-by: Rob Browning <r...@defaultvalue.org>
> ---
>
> Proposed for 0.33.x and main

Pushed.

--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Reply all
Reply to author
Forward
0 new messages