On Wed, Feb 08, 2017 at 07:29:22AM -0500, Austin S. Hemmelgarn wrote:
> On 2017-02-07 13:27, David Sterba wrote:
> > On Fri, Feb 03, 2017 at 08:48:58AM -0500, Austin S. Hemmelgarn wrote:
> >> This adds some extra documentation to the btrfs-receive manpage that
> >> explains some of the security rel
On 2017-02-07 13:27, David Sterba wrote:
On Fri, Feb 03, 2017 at 08:48:58AM -0500, Austin S. Hemmelgarn wrote:
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 b
Am Fri, 3 Feb 2017 08:48:58 -0500
schrieb "Austin S. Hemmelgarn" :
> +that an incremental send streams actually makes sense, and it is thus
> +possible for a specially crafted send stream to create a subvolume
Sorry for the noise... Another one: shouldn't it say "sent
stream" (minus s) and "sent
Am Fri, 3 Feb 2017 08:48:58 -0500
schrieb "Austin S. Hemmelgarn" :
> +user who is running receive, and then move then into the final
> destination
Typo? s/then/them/?
--
Regards,
Kai
Replies to list-only preferred.
--
To unsubscribe from this list: send t
On Fri, Feb 03, 2017 at 08:48:58AM -0500, Austin S. Hemmelgarn wrote:
> 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
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
