Using SSL socket as stdin for subprocess.Popen

Chris Angelico rosuav at gmail.com
Mon Mar 21 07:36:32 EDT 2016


On Sun, Mar 20, 2016 at 4:44 AM, Matt Ruffalo <matt.ruffalo at gmail.com> wrote:
> Hi all-
>
> I'm writing a backup client for automating the synchronization of btrfs
> snapshots between machines -- essentially piping the output of `btrfs
> send` on my laptop/desktop to `btrfs receive` on a server. I've been
> doing this manually for quite a while, and something automated would be
> much more convenient.
> ...
> I've been using SSL for the communication between the client and server,
> both in a static "control port" and a dynamic data port that is assigned
> for each individual call to btrfs send | btrfs receive. In addition to
> verifying the client certificates against a trusted CA, this also allows
> things like selecting the backup destination based on the common name in
> the client cert.
> [snip details of subprocess.Popen issues]

Hmm. Any particular reason you're not using SSH here? That seems like
the most obvious way to pipe the output of a command on one computer
into a command on another. Instead of verifying client certificates,
you'd have a set of authorized public keys, and you could prevent
shell access by using your custom script as the shell of a dedicated
user - so it'd be something like "btrfs send|ssh backup at server".

Whenever I need to encrypt stuff, I try to let someone else do all the
work :) Whatever shell is used for that user, it will get "btrfs send"
piped into it, and all the authentication and encryption is completely
invisible.

ChrisA



More information about the Python-list mailing list