This adds some extra documentation to the btrfs-receive manpage that
explains some of the security related aspects of btrfs-receive. The
first part covers the fact that the subvolume being received is writable
until the receive finishes, and the second covers the current lack of
sanity checking of the send stream.
Signed-off-by: Austin S. Hemmelgarn <ahferroin7@gmail.com>
Suggested-by: Graham Cobb <g.btrfs@cobb.uk.net>
Signed-off-by: David Sterba <dsterba@suse.com>
Reword several option descriptions, add missing short option -E,
formatting adjustments.
Visual bug fix: the first line is printed in short help, the second line
is long description, thus alternative calling syntax must be printed on
one line.
Signed-off-by: David Sterba <dsterba@suse.com>
Introduce new option, '--dump' for receive subcommand.
With this command, user can dump the metadata of a send stream.
Which is quite useful for education purpose or bug reporting.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
We can set not only btrfs mount point but also any path belong to
btrfs mount point as btrfs-receive's destination.
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
In a chroot environment we may not have /proc mounted, which makes btrfs receive
freak out since it wants to know the base directory where are are mounted for
things like clone and such. Give an option to specify where the mountpoint is
in these cases so you can still do a btrfs receive in a chroot. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
[added manpage documentation]
Signed-off-by: David Sterba <dsterba@suse.cz>
This patch forces btrfs receive to issue chroot before
parsing the btrfs stream using command-line flag -C
to confine the process and minimize damage that could
be done via malicious btrfs stream.
Signed-off-by: Lauri Võsandi <lauri.vosandi@gmail.com>
[added long option variant, added docs]
Signed-off-by: David Sterba <dsterba@suse.cz>
A few minor benefits:
* editors set highliting according to the extensions
* web access to the git repository (github) renders the .asciidoc
files:
* we can link to them from the wiki
* the files are editable via browser and such editations can be
submitted for merge easily
Signed-off-by: David Sterba <dsterba@suse.cz>
