Does anyone know of a security analysis of btrfs receive? I assume that just using btrfs receive requires root (is that so?). But I was thinking of setting up a backup server which would receive snapshots from various client systems, each in their own path, and I wondered how much the security of the backup server (and other clients' backups) was dependent on the security of the client.
Does the "path" argument of btrfs-receive mean that *all* operations are confined to that path? For example, if a UUID or transid is sent which refers to an entity outside the path will that other entity be affected or used? Is it possible for a file to be created containing shared extents from outside the path? Is it possible to confuse/affect filesystem metadata which would affect the integrity of subvolumes or files outside the path or prevent other clients from doing something legitimate? Do the answers change if the --chroot option is given? I am confused about the -m option -- does that mean that the root mount point has to be visible in the chroot? Lastly, even if receive is designed to be very secure, it is possible that it could trigger/use code paths in the btrfs kernel code which are not normally used during normal file operations and so could trigger bugs not normally seen. Has any work been done on testing for that (for example tests using malicious streams, including ones which btrfs-send cannot generate)? I am just wondering whether any work has been done/published on this area. Regards Graham -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
